[Captivate Android Development] AdamOutler:
Very close.. I will ammend a bit in the definitions portion... I'll start a Q&A in the Q&A section eventually, but lets hash this out here first... get it? Hash. Oh I have a million of them...

Remove the quotes so that the next person can get the bbcode by hitting the quote button. I'd like Rebellos to evaluate this too.

Definitions

iROM — true read-only memory; iROM is a boot ROM by the definition in my signature

BL1 IBL — the Initial Bootloader that is really two parts: BL1A and BL1B; While not true ROM, this is not overwritten by Odin for reasons unknown

BL1A — this is what Rebellos refers to as "BL1_stage1"; along with BL1B, it comprises BL1;

BL1B — this is what Rebellos refers to as "BL1_stage2"; along with BL1A, it comprises BL1;

BL2 PBL — the Primitive Bootloader. This can be overwritten

BL3 SBL — the Secondary bootloader; this can be overwritten

A few things about the S5PC110 system-on-a-chip, iROM, eFuse

The S5PC110 is also known as the "Hummingbird" processor.

The Hummingbird is speculated to share some components with those found Apple's A4 processor, but arranged in a different manner. In other words, don't expect iOS to run on a Hummingbird chip with no problems

Each firmware (Bada, iOS, WP7, Android) and manufacturer are free to remap the GPIOs meaning buttons, UART and i2C busses may be mapped to different pins by the bootloader currently running.

The iROM across most, if not all, devices that use Hummingbird are believed to be identical. This includes the Hummingbird processor in Wave devices, Samsung's Galaxy line up, and ODROID devices.

On the SoC (the Hummingbird processor), there are 160 eFuses. Each individual eFuse represents one bit and together they comprise a 160-bit hash of a public RSA key stored the beginning of a Hummingbird devices NAND memory.

While eFuses are largely cited as being the inhibitor to custom bootloaders (and, as a result, custom kernels) on most Motorola devices, they are only used to store configuration information for the boot ROM of their respective device.

eFuses can be modified, but only once. When you blow an eFuse, you have physically broken the fuse, and, depending on the implementation, a blown fuse may represent either a 1 or a 0.

Motorola uses TI's OMAP processors. The TI OMAP does not support secure boot modes. Booting is conducted from an internal NAND.

The hash is most likely SHA-1 and is truncated to 32 bits leaving a total of 4294967295 possible brute force attacks before collision.

If any of the eFuses are blown, the iROM will load the RSA key, hash it, and compare it to the hash represented by the eFuses. If it matches, it will then use the RSA key it hash to verify the digital signature on BL1A. Otherwise, you'll get an error.

If none of the eFuses are blown then the iROM will not attempt to load an RSA key (if any) and will not perform signature checks.

The boot process

Power on.

Some esoteric intermediate stuff happens that is not important.

iROM is executed and will check the value of each of the eFuses.

iROM will hash the RSA key and compare to the IBL firmware's(whether it be on an SD card, delivered over USB or UART, or from oneNAND or USB) signature, thus beginning the hardware instantiated "Chain of Trust".

Assuming the values matched, iROM will then use the RSA key to verify the digital signature of BL1A.

Assuming the signature is valid, the HIBL BL1A will jump to a static memory location thus beginning BL1B

BL1B will load the BL2.

BL2 initializes memory and other hardware, then loads BL3 to DRAM and executes

BL3 with massive amounts of space available initializes nearly all remaining hardware on the device and starts the kernel.

Note: the HIBL replaces BL1 and BL2. BL1A handles authentication with the IROM, The HIBL BL1B initializes memory and calls IROM code back to perform a second, insecure download of code. HIBL performs the function of the IBL and PBL within IBL memory space. [/QUOTE]