Update: (Sep 6th, 2018): Integrated extraction code into ImgTool 0.7 so you can now expand all system.transfer.list files with stl=path_to_system_transfer_list, as I've seen this on other MTK (MediaTek) firmware. So it's an MTK thing, not an Android Thing
I couldn't resist getting myself another Kindle on Amazon so I could research how far their "FireOS" has evolved. The device came with 5.6.0 installed, and it provides ADB (using the standard Developer Options trick of tapping multiple times on build info), but no public root exists for it (yet). It does strike me as rootable, but part of the process requires reversing Amazon's custom binaries (and there are many of those). Problem - SELinux contexts restrict access to a lot of those. What to do?
The interesting part is, of course, the /system partition, which looks promising:
Moving over to a Linux and trying to mount it, however, we get errors:
So this is obviously a sparse image of some type, since its size is smaller than the actual filesystem size. Simple math reveals the blocksize to be 1,298,087,936 / 316916 = 4,096. That means the actual image file, if extracted, should be 1,692,692,480. Trying my standard image extraction tool (imgtool), however, lamentably reports it's not a known sparse image. So it's a different format.
Rummaging around in the extracted files, however, we find some clues. Specifically, system.transfer.list:
The "3" up there is probably some version number. Whatever.
Note "316916". That's the size of our file in blocks.
Note "erase 2,0,413255". This seems to imply that as a precursor step to installing the system image, the installer needs to erase the existing system. But what? "0,413255" spans the entire disk, because 1,692,692,480 = 413,255 * 4096! This led me to figure out that "2" is just the size of the parameter array.
This leaves the most important part, which is the "new,56,...". Indeed, 56 parameters follow, but what are the values?
I tried taking a better look at the system.new.dat, specifically , at block 32767. Back on the Mac (whose dd supports hex block sizes), we have:
The cryptic values up there: 0x193d0 = 103376 and 0x64e47 = 413255. The latter is most definitely the number of blocks. That alone didn't tell me much, but what did is the first block:
We have almost the exact same values starting at offset 0x400. And that is exactly where the ext2/3/4 superblock is! (Astute readers can see the ext magic, 0xef53, in both outputs - I didn't..). So this means that block 37,267 is a superblock backup!
HOWEVER... The first superblock backup is traditionally at the nicer number of 32,768 (0x8000 really is nicer than 0x7fff, right?). This also happens to be the next entry (third) in the "new" from system.transfer.list. So that made me think - what if in between the two is an empty block? If you took every two values (i.e. 0,32767, then 32768,32770, then 32873,32875) copy them as they are, and pad in between with empty blocks, you'd cover the entire NAND!
All I needed at this point was a quick tool to do this. So, without further ado:
moving back to Linux for a mount:
So off to explore the filesystem in the hopes of rooting this thing :-)
Android Internals Volume II is on track. Aiming for AS SOON AS I'M DONE WITH MOXiI Volume II - which is November. Believe me, I wouldn't be doing all this if I didn't also want to include FireOS aspects in the book as well. Android P just came out in developer preview, and so far I'm seeing only paltry changes. Volume II will be up-to-date when it comes out, I'll also do a Volume I revamp, AND I'll offer both in one book. Stay tuned.