[Nexus 6P Original Android Development] makers_mark:
Thanks, once again, but there was nothing noteworthy in either aboot or abootbak. I found more of an explanation on the slots, but I apparently was wrong in thinking that they were just splits in any given partition. You have been great (even running the suspect partitions back through the main program), not to many would of done that without direction. Will you check 43 though? If not that's perfectly fine! This is the line you need to change in the batch file with a text editor if you feel like it.

Change this line:
for /l %%t in (1,1,43) do (
To:
for /l %%t in (43,1,43) do (

It will just pull the /system partition and check it.

There still lies the problem of where to put it. The aboot partition is the dead soul in your phone that awakens upon boot and sets up initial functionality and then loads the kernel, then dies. I like your insight, but there still is a little bit of data directly after the complete splash2.bin. It appears to be something that sets up nand. Even looking at the fastboot source, unlock critical "seems" to be able to let you edit the bootloader partitions, bypassing all signature checks. If that is the case and it's that easy, that extra data could easily be moved to tail the splash. There is even plenty of room in aboot to move it quite a bit. But that is wishful thinking, because I don't see how they could totally do away with un-modifiable bootloader partitions like that with an apparent movement towards security.

Typically, when the splash (and associated images) are changeable, they are in their own partition and you wouldn't have to worry about anything being overwritten. You could even have a splash that was smaller than the existing one, and after flashing the new one, those leftover bytes from the old one don't matter. It is because it is a file format that is very adamant about what it wants, and what goes where (it is pretty much how all file formats work). So when it knows the data for the last image is at (insert number) this exact byte, that's it. The extra "garbage" doesn't matter, and is never seen. When you go to substitute data (a) in place of data (b), they would have to be the exact same size because of the no room for extra data, stemming from the nand setup the very following byte. On top of that, there has never been an editable aboot partition when it comes even to Nexus (that I know of). This is very odd, and reminiscent of when I first got into the thrill of finding these encodings with the Nexus 7 2. I could get the images out, but there was no way to change them, because they were in aboot, and with the secure boot loader that checks the "competency" of the previous bootloader caller, it wasn't possible. (Anything is possible, it's just no one figured it out). Since the Nexus 5,5x,6,&9 they have all been editable and moved away from strict bootloader encoding. And those have been in a file format, JUST like this where you have your header...offset....size...name...in whatever order..

To anyone that wants to understand this encoding (since I haven't explained it yet), read below.

The format used in encoding these images is zipped with gzip. When Google released the image, I saw the SPLASH2!! header in the bootloader. It had the tale-tail signs of a format (offset, size, width, height...). You can even do this, use a hex editor and go to the offset that is listed by the program for any image (in the cutout splash.bin). Copy from there the number of bytes that is listed in the "size". Save that file as whichever image it is for easy reference, and add the extension .zip on it. Unzip it with 7-zip or gzip, and viola, you get the image in a BGR24 raw format.

I went above an beyond though, you have to when you can't test yourself. With Gzips there is an optional filename for the extracted zips, as well as a unix time stamp, and an indicator as to what type of machine actually compressed the data. I made all of this data transfer to the encoding of the image to be injected, it sounds easy but it wasn't. The goal, as always when doing this, was to make a program that could take the original encoding and change every single image in it, then build an encoder that produces an EXACTLY identical file.

Using 7-zip did the job initially (for decoding), but the data was off when encoding (no matter what setting), it was more of a quick novelty do decode. In the "Rebuild Images" batch file that is created, if you change "-b" to "-B" it will force every image to be injected (if the crc32 of any image didn't change, the existing encoding in the splash.bin was copied from the original file for speed). The filesize is the exact same, but more importantly (to me), the two files were binary twins.

Having said all of that, I think there may be one last hope as far as I can help (and it doesn't involve the bootloader partition). It was somewhat questionable when I realized what type of encoding this was. Typically there is very little "thought" by the device to process images on boot. They are usually encoded in a run-length manner which is super fast and efficient. This however has to be unzipped and then displayed. At first I said to myself, this must be really fast like nothing before (because of the max compression), or there is a driver built into the firmware to directly handle the zlib (which may be the case too).

There is the possibility that the images transported are decoded and stored somewhere else on the device in there unzipped BGR24 format. It doesn't seem logical, but neither does gzipping an image that needs to be pulled at the drop of a hat with minimal processing power. I will find the most obscure 16 or 32 bytes of data in one of the raw images and post a program to search for that set in all the partitions. Feel free to participate, but if that doesn't produce anything, I'm out! Kidding, but I will ask a moderator to move this thread to the Q&A if they don't do it anyways:cyclops:

I am including the "aboot.cab", which is an ELF, directly from the bootloader downloaded from google. This is not the partition checker for a not so random set of bytes. This is strictly for future reference and also to see if insight might come from a lurker:good: