[7" Kindle Fire HD General] fattire:
Observations/thoughts/questions

I'm very familiar with Bauwks' NT exploit (see cyanoboot), but I don't know anythign about the Verizon situation-- it sounds like you're saying the recovery wasn't checked at all-- couldn't that partition then have been used for the regular boot? (That leaves you without a recovery option, of course...)

I'm curious about the 7.1.5_D025_1534720 software update. As pointed out by hashcode and others, the updater-script has multiple, different methods for updating the boot files, depending on what it finds in /proc/product_name.

"Tate PVT" installs:

MLO-pvt

u-boot-prod.bin

boot-prod.img

"Tate DVT" installs:

MLO-dvt

u-boot-eng.bin

boot-eng.img

"Tate EVT3" installs:

MLO-evt

u-boot-eng.bin

boot.img

"Tate PreEVT2.1" installs:

MLO-dummy

u-boot-eng.bin

boot-eng.img

By "installs" above I mean dds to the appropriately named "x-loader" (mlo) "bootloader" (uboot) and "boot" (boot image) partitions.

All the above files are included in the update, including the -eng bits, and as many have speculated-- with a rooted system (or fastboot if it's enabled, but I'm guessing no), one could manually flash these into place and try booting. There's also some certificate file that gets swapped out, but I don't know what that's about exactly... I don't think the boot chain uses it, or does anyone know.

The problem is, if replacing these partitions doesn't work for any number of reasons, the boot chain is broken, and there's likely brickage. So it will take balls/overies of steel for someone who has a device (not me) and who knows what they're doing (not me) and who is willing to risk irreparable damage (still not me) to the device to try it. (NOTE: THIS IS NOT IN ANY WAY AN INVITATION, SUGGESTION, OR RECOMMENDATION FOR ANYONE TO TRY IT. DO NOT. I AM NOT POSTING SPECIFIC INSTRUCTIONS FOR HOW YOU WOULD EITHER. SERIOUSLY, DON'T DO THIS.) A idle thought-- probably the "safest" way to test would be to try only the signed boot-eng-- if that fails, at least hopefully rebooting to recovery will be an option to recover.

I mean, it can't be that simple-- but why are they including apparently engineering boot-chain files in their updates anyway?

Other observations:

From the above configurations, it looks like u-boot-eng can be used with various x-loaders (mlo), as long as it's signed probably... Similarly, u-boot or u-boot-eng can start up boot.img. So it seems to be a little mix-and-match (?)

There is an 858-byte security header (ending at 0x350, which is where the traditional "ANDROID!" begins...) on both boot..img files, both starting with "CertISW". Probably the signature... found this which may be of interest. Discarding this header results in a normal Android boot.img

There's a service called EmmcInit at boot (/system/etc/emmc_init.sh) that checks /sys/devices/platform/omap/omap_hsmmc.1/mmc_host/mmc0/mmc0:0001/manfid to make sure it's="0x000015" and if not, remounts /data, /cache, and /efs with mount remount,discard. No clue what this is about, but the script is run as root, so anyone with root who wants to have stuff run automatically at every boot might try piggybacking off this script. No change to the signed ramdisk needed, as far as I can tell. (Then again, I take no responsibility if you try modifying this file and suddenly have problems!)

Questions:

What is in /proc/product_name? I think Reverand Kyle mentioned the answer, but I forget. I'm guessing "Tate PVT".

Is this different from how recovery's kernel identifies itself (because it would really be recovery's, not the normal boot's kernel that matters)

What magic do you get when you use the -eng boot files? (Or, conversely, what horrors do you get?) Fastboot? Some of the other flags turned on that were discussed previously?

Again, I do not suggest anyone experiment with actual devices, and the above is provided for informational, educational purposes only. I don't have a HD device nor do I have any intention of getting one, for precisely the reason that it is locked down.