[LG V20 Guides, News, & Discussion] emdroidle:
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