[7" Kindle Fire HD General] Loglud:
Yes your absolute correct, and in this matter a lot of companies do this. If i remember correctly this is how the nook tablet worked too, the exploit took advantage of the way that uboot reads the MAGIC headers. When looking though the source code of the Kindle Fire HD, the same exploit is possible, however you may be correct that it checks the security headers first.

The one thing about Bauwks boot that is really nice is that A, it is very early on in the boot chain, and B that it is a fundamental exploit for MAGIC_NUMBERS. In terms of raw information from the source code, there seems to be an issue with how their booting to use this exploit.

The Kindle (almost wrote kidney) Fire HD uses IDME to choose boot, which looks to be a proprietary boot selection in uboot. It has two ways of authenticating. First off, if it goes in to the MMC the first thing it does is booti and then checks for the security (cant exploit using bauwks). The second way is if its loading an memory address it does a bootm and then checks for the security (cant be exploited using bauwks). As it seems now in order for someone to exploit this, they would have to inject into the idme stage, though idme looks to be called after the verification to select the boot (aka vol up or vol down).

Interesting bit of code though is this:

...
#if defined(CONFIG_4430ZEBU) && !defined(CONFIG_4430ES2)
/* Give the standard Kernel jump command as boot cmd and without any delay */
#define CONFIG_BOOTDELAY 0
#define CONFIG_EXTRA_ENV_SETTINGS \
"bootcmd=go 0x80008000\0"
#else
...

This line is is the config file, and seems to show that there is a way to make the command go run instead of bootm or booti. This may be an internal env variable that cannot be changed, but its worth looking into. As for now I have not found any other holes.

Actually no, what we were talking about was how to load "bricked" devices. Aka, devices that have had their boot sectors corrupted.

Going to get nerdy here so skip if you don't care about crypto:

In order to reflash these, you need to be able to flash in the security checks, and have it so no security checks are in place. Most bootloaders UBOOT in this case have a condition for updating. The headers are secured using a combination of internal security algorithms, internal sec codes, and external sec codes. The internal sec codes are most likely some sort of single write memory (or efuse) then they have some ALU on chip that preforms all the processes that are required for sec checks (whether it be md5, crc, ase, or in this case M-Shield), and then an output bit, usually only one bit. With this they can then read a key from an update along with kernel and ramdisk information (most likely some sort of checksum) and then say with only one bit whether it passes or not. By isolating this and making it so it only has one output, it makes it hard to do a reverse analysis.

A ? ? = 0

B ? ? = 1

(simplified version)

Where A and B are your checksum and external sec code for two different packages (note that a md5 create a 128 bit number which means that their are 3.48e34 possibilities) , and the first ? is some unknown operation and the second ? is some unknown variable (your internal sec code and operator).

In this you'll notice that while we have three different variables and 2 equations, and by definition this operation is not defined now. There are attacks out there (collision attacks) which can create the same md5 check the problem is that the check is calculated inside of the code, and therefore if the check was falsified, most likely the file that was used to create this code (aka the boot.img) is now worthless as it contians no useful information, only that which was used to falsify.