[Guide][MOD] Hide unlocked Bootloader warning boot screen

Search This thread


Senior Member
Jun 7, 2010
the hex-editor method does not work for me, I've extracted the raw-resources as described, they are all single image files that I just need to swap, but I do not know how to repack them

This is how I did it.

1. Open your raw_resources.bin file with hex editor. (in my testing raw_resources.img worked exactly the same, just keep the same extension throughout).
2. Modify according to picture in OP.
3. Save and close raw_resources.bin (or raw_resources.img).
4. Download the Hide_warning_F800s.zip from the OP.
5. Open it with 7-Zip.
6. Drag in your edited raw_resources.bin file overwriting the existing file. (If your file is raw_resources.img you will need to delete the existing raw_resources.bin in the zip as well as change the extension from .bin to .img in the updater-script file in the META-INF folder).
7. Close and rename the zip if you like.
8. Flash it.

Forgot to mention I did this on my V30S, not aV20. However, the method should still be the same.
Last edited:
  • Like
Reactions: RoboB
Dec 29, 2014
Hi there. So will it shorten the boot time?After dirty santa the boot process became annoying slow. Another question can i use and will it work the raw resource bin from oreo kdz? Thanks.


Senior Member
Aug 19, 2010
H918 this gives you orange text after you edit the addresses. It says to lock bootloader, seems to boot faster.


Senior Member
Jul 4, 2012
LG V20
H918 this gives you orange text after you edit the addresses. It says to lock bootloader, seems to boot faster.

H918 when bootloader unlocked does not give red warning screen and is fast to pass anyway.

Btw, when the code says Orange, is it in fact yellow or is there an Orange one as well. On my official unlocked G5 I get a yellow one, which passes in what 2/3 seconds...
  • Like
Reactions: pierro78


Senior Member
Btw, when the code says Orange, is it in fact yellow or is there an Orange one as well. On my official unlocked G5 I get a yellow one, which passes in what 2/3 seconds...
Both my H918 and US996 have the same light orange, similar to the XDA color, with the exact same ~20-second delay before the boot animation. It looks just like the middle one in this example (while all the DirtySanta'd models get the red one on the right): https://i-cdn.phonearena.com/images/articles/199500-image/Clipboard01.jpg
I don't think the yellow one exists for any V20.
  • Like
Reactions: ezzony

Top Liked Posts

  • There are no posts matching your filters.
  • 8

    This fix is for those who want to get rid of the annoying Red Corruption warning screen!!.

    Disclaimer: You apply the fix at your own risk. I'm not responsible for any software or hardware damage it can lead. The only thing i can assure is that i've tested fix on my lg v20 F800s with DirtySanta Bootloader unlocked, and it work just fine.

    Disclaimer 2: I don't provide any technical support for my fix through PM. So, please don't write PM about other devices. I share what i'm doing for myself .. and have no intention to do it to devices i don't have.

    The trick:
    This fix is not really fixes the problem, but it just replace the warning with the lg logo. so the boot time still higher as it is.

    The raw_resources on our V20 is the equivalent partition to imgdata, but they use RLE images that has no header like BMP or JPEG, so we can't easily replace it like Nexus 5X ...

    The trick that i use is changing the addresses of the warning images with the one of lg logo by patching raw_resources.bin file with Hex Workshop.

    Here is a short description of steps to follow if you want to do the same for other devices:

    1. download the KDZ firmware of your device.
    2. extract the raw_resources.bin from it.
    3. download and install Hex Workshop
    3. open the raw_resources.bin with Hex Workshop
    4. find the addresse of "lglogo_image" and copy it. (see the example image below)
    5. find the 2 addresses of "verifiedboot_red_01" and "verifiedboot_red_02" and replace with the adrresse of "lglogo_image". ( respect the exact place!)
    6. save your changes
    7. put the raw_resources.bin incide the flash zip (you can use my attached flash zip).
    8. flash the zip with TWRP.
    9. reboot your device.


    Attached: flash zip for my f800s OREO firmware

    It looks like my 100$ refurbished ls997 has a f800s motherboard.
    Okay, bit more analysis since I've actually kind of been wanting to be able to modify raw_resources (having my name/image on phone start would be kind of neat).

    The initial header appears to have 5 fields:
    struct rrheader {
        char magic[16]="BOOT_IMAGE_RLE\x00\x00";
        uint32_t entrycount;
        uint32_t unknown;
        char devicename[16];
        uint32_t dataend;

    The magic string is simply an identifier. Clearly suggestive of run-length encoding. The entrycount is the number of images stored in raw_resources. The unknown is a value which I don't know the meaning of, could instead be a pair of 16-bit numbers, but I suspect a single 32-bit little-endian is more likely. The devicename is something like "elsa_global_com". dataend identifies the complete length of all the data in raw_resources.

    At offset 0x1000 (think LBA 1) the image headers start. The format is:
    struct imageheader {
        char name[40];
        uint32_t dataoffset;
        uint32_t expect;
        uint32_t width;
        uint32_t height;
        char unknown[8];
    Name is effectively a filename, such as "lglogo_image" or "verifiedboot_red_01". I'm pretty sure this string is what the code is searching for when trying to display an image. dataoffset is a byte offset from the begining of raw_resources. expect is a count of RLE entries worth of data, as such LGE/Qualcomm's software would multiply this by 4 and read that many bytes.
    width and height are pretty obvious. The size of the image. I suspect the unknown is a pair of 4-byte integers, but I'm unsure of this. Presently I've got no idea of what it does. I'd love to have someone try modifying this value and see what it does.

    5 images take roughly 250KB of space each: lglogo_image, verifiedboot_orange_01, verifiedboot_orange_02, verifiedboot_red_01, and verifiedboot_red_02. If you wanted to save space in raw_resources, you might merge verifiedboot_orange_01 with verifiedboot_orange_02, and similar for verifiedboot_red_0[12]. A number of the other images are also pairs which differ only by the unknown field, these pairs could be merged by setting their dataoffset values to the same value, thus freeing up more space.

    My analysis in the previous post was on the money. The format is really dumb RLE. This is simple to encode, but doesn't offer very good compression ratios. These entries are 4-bytes long (expect counts these entries, not individual bytes). The first byte is a number value indicating a number of repeats, a 1 will result in 1 pixel of the color indicated by the next 3 bytes, a 2 will result in 2 pixels of the color, etc. The value 0 might well be untested, but it might cause 0 pixels of that color, 256 pixels of that color, 65536 pixels of that color, or perhaps a software crash.
    The raw_resources sample I found had the color data in the order blue-green-red.

    I'm attaching a simple Python 3 script which will decode a raw_resources image. Each portion will be dumped into a file matching the name in the image header. The format is "PPM" which is horribly inefficient, but easy to generate and modify by hand. Figure lglogo_image.ppm is 14MB for a 760x1544 image. The unknown in the image header will be emitted near the top of the PPM file (PPM is a text format, you can look at the raw data in a text editor). The data from the overall header including the raw unknown value will be emitted in a ".notes" text file matching the filename of the raw_resources image file.

    Have fun with the knowledge.
    Made one for the at&t H910 oreo not sure if it will work on nougat though. Works great on my H910 running alpha omega oreo. https://mega.nz/#!okADVKoB!N1W6kbYMbpXZpjuEgO1vIuELI_EV5ivUwQoM8gQM7_g
    You've got an interesting experiment here. Problem is with things at this stage I see too much potential for malicious mischief, and insufficient gain to assist right now.

    At the start of raw_resources is the string "BOOT_IMAGE_RLE". Almost certainly "RLE" stands for run-length encoding. Problem is, as mentioned in the Wikipedia article, there is lots of variation in what is called run-length encoding. If we could at least identify the start and end of some of the images we could think about doing something interesting.

    The table of contents starts at 0x1000 (4KB or the second block). The end of the table is likely either indicated by the null entry or assumed to end at 0x2000 (8KB or the third block). In a handy example the longest entry title I found was "system_recovery_factoryreset_image" as this is 34 bytes, this means at least 36 bytes are reserved for the string, though 40 is more likely (there may be a requirement to have a null byte terminator) and there could be 28 bytes of data though 24 is a bit more likely.

    24 bytes is a noticeable amount of data. That could be 6 32-bit numbers, or 3 64-bit numbers. At a minimum there would need to be a starting index, and either an end or a length. For "lglogo_image" I notice the first 4 bytes are "0x00 0x20 0x00 0x00". If this is little-endian (common for i386, AMD64 or ARM), then this would be "0x00002000" which looks suspiciously like the starting offset of the image data.

    The issue then is what the other 20 bytes are? One of them is either an end offset or a length (note: a length might be encoded as a frame-count). One of them might well be a delay, in which case setting that one to zero would speed startup.

    At offset 0x2000 of a handy raw_resources file the data starts with a few repeats of "0xFF 00 00 00". The byte sequence "0x00 00 00" could well be an encoding of black, in which case the 0xFF could be a count of 255 or 256 pixels. Looking through the file, I see a number of "0x01 xx xx xx" sequences, but no "0x00 xx xx xx" sequences. In which case it isn't likely that 1 is being added to the count, and those are 255 black pixels.

    That is what I can come up with from looking at an example without spending a bunch more time analyzing the data. Alas I've got 15 things which need me to spend time on them. :( I'm curious as to what kind of startup animations are going to show up...
    You've got an interesting experiment here. Problem is with things at this stage I see too much potential for malicious mischief, and insufficient gain to assist right now.
    I'm still rather concerned about the potential to hide that the phone has been rooted/modified and then being sold as unmodified. I am though interested in the capability to replace the startup image with my own.

    I suspect the unknown in the main raw_resources header may be some sort of version code. Alternatively it could be some magic values. Elsewhere I found a thread with a G4 raw_resources image. The first byte was 0x02, while the layout of the file pointed towards a 2KB block size. Add 9 and it could be interpreted as a shift value for the block size (2+9=11; 1<<11=2048), for the V20 that byte is 0x03 so 3+9=12, 1<<12=4096.

    More of the image entry fields filled in:
    struct imageheader {
        char name[40];
        uint32_t dataoffset;
        uint32_t expect;
        uint32_t width;
        uint32_t height;
        uint32_t unknown;
        uint32_t screenoffset;

    I'm quite sure "screenoffset" is a count of lines down from the top of screen specifying where the image should be placed. For the LG logo image in one version of raw_resources the value is decimal 160, which is specifying to place the image at the top of the main screen area and skipping the "second screen" (this is a crucial insight when interpretting the value).

    I'm still unsure what the unknown is. I'll hazard a guess that it is some sort of flag value. The verified boot orange and red files have this set to 0x0064. The NT_TYPE_* files have 0x00E1. The most common value is 0x0000.

    One other puzzle is left, how is the background color set? Several strategies come to mind. Reading a pixel in one of the corners and using that as background color is one. Another is to copy the whole border pattern outwards so everything ends up matching the border (this would explain why almost every image has at least 1 entire pixel of border).
    I'm pretty sure the image rendering procedure is start on line $screenoffset, and dump the image into the center of the screen.

    A fair bit of what I've seen in the data is rather odd. I'm left wondering whether LGE's tools for working with raw_resources are very primative, buggy or something else. Perhaps it is mostly being done by hand given some of the inconsistency. Is there a genuine need for borders (often wide) on all the images?
    All the images start at multiples of 0x1000 (4096). This could be required by limitations of the bootloader environment, alternatively this could be LGE Engineering hasn't had time to correct this limitation. I'm a bit concerned violating this could have the potential to crash the bootloader...

    There are a number of ways to free a great deal of space in raw_resources. Of note while they have different screenoffset values, the pair factory_reset_no_???_image and factory_reset_yes_???_image have identical payload data. Point them to the same address in raw_resources and you would free some space there. I also see how the factory_reset_???_line_image files could be merged, at which point the space used by factory_reset_1st_line_image could be freed. I don't know about some, but the battery_insert_nt_module_image is clearly for the G5 and not the V20 (reusing resources is one of the ways you save on your Engineering budget). Shrinking the large borders off various images would also save quite a bit of space.

    I am interested in trying to produce my own version of raw_resources. Due to the ethics concern mentioned above, anything done by me will show overt indications of being in orange/red boot state.

    I'm attaching an updated version of rrdecode I've been working on as part of the process of analyzing raw_resources. This includes 2 variants. The PPM variant outputs NetPBM format files, I'm a bit worried viewers for this format may be rare, but if you've got one it can be a handy format. The PNG variant will output PNG files once the Python Imaging Library is installed. This is a much more commonly used format so there are zillions of viewers out there.

    MD5: 8616b271853fa974fec7f1d3ea838da6
    SHA1: 78ebf2bb028d18bb571db92dc8af3d0bdd622bc0
    SHA512: 07845b06d8cb9ab9be2de2caf380cae96772b81613e1dbd79e20f979c94c74ff96af33e1c41869226bbc54cf740354862c58bfd54cc4947c2ec4425641fa15da