Aboot, sbl, boot rom explanation - GSM-Forum

coyote_kv · 01-27-2020, 17:03

The BootROM loads several other components, each from a dedicated partition. Chief amongst those is a secondary boot loader (SBL), which is responsible for overcoming the tight constraints of ROM - limited space and an inability to upgrade. When you "flash the bootloader", you flash those partitions (as discussed in the book). For now, however, our focus is Android's own boot loader, which often resides in a partition called "aboot".

aboot is a native ARM binary, which is wrapped by a very thin header, which is usually 40 bytes in length. This header provides metadata which is used by the SBL in the process of validating and loading aboot. Note, "validating and loading" - in this order - because the SBL will very likely reject an aboot image which is not properly signed by the vendor. This works to extend a chain of trust, which starts at the ROM, all the way to aboot, which further extends it to the boot.img (unless the boot loader is "unlocked"). In other words, the ROM has a built-in key (which, by its nature, cannot be modified), used to validate the precursors of the SBL. Those, in turn, validate the SBL, which validates aboot, thus securing the boot sequence and preventing any modification by malware (or unauthorized rooting attempts). aboot is the first component which may opt to break the chain - and this is what is meant by "boot loader unlocking": The unlocking simply disables the signature check on the next part of the boot sequence, which is loading the kernel and RAM disk from the boot partition (flashed from boot.img).

Not all boot loaders can be unlocked, however, as that is left to the vendor's discretion. For those which do, it is usually a straightforward matter - the device is placed into bootloader mode (adb reboot bootloader) and then a fastboot oem unlock is all it takes. Amazon's Fire-devices (FireTV, FirePhone, and the Kindle Fire) do not allow this, as well as some versions of Samsung's boot loader. Samsung appears to be more particular, in allowing some international versions of their devices to be unlockable, and other not. As discussed in Chapter 21, boot loader locking is as essential part of Android security, but by itself is insufficient to prevent rooting in most cases.

Thus, the SBL loads aboot, and inspects its header to find the "directions" for loading. You can obtain aboot from a factory image (by using imgtool to break apart the bootloader.img) or directly from the device's aboot partition (assuming a rooted device, of course). You can find the aboot partition number by consulting /proc/emmc (where available), or (in JB and later) /dev/block/platform/platformname/by-name/aboot.

If you want to read more go to Android Internals: A Confectioner's Cookbook.

01-27-2020, 17:03	#1 (permalink)
coyote_kv Freak Poster Join Date: Jan 2009 Location: SRB Posts: 185 Member: 941075 Status: Offline Thanks Meter: 51	Aboot, sbl, boot rom explanation The BootROM loads several other components, each from a dedicated partition. Chief amongst those is a secondary boot loader (SBL), which is responsible for overcoming the tight constraints of ROM - limited space and an inability to upgrade. When you "flash the bootloader", you flash those partitions (as discussed in the book). For now, however, our focus is Android's own boot loader, which often resides in a partition called "aboot". aboot is a native ARM binary, which is wrapped by a very thin header, which is usually 40 bytes in length. This header provides metadata which is used by the SBL in the process of validating and loading aboot. Note, "validating and loading" - in this order - because the SBL will very likely reject an aboot image which is not properly signed by the vendor. This works to extend a chain of trust, which starts at the ROM, all the way to aboot, which further extends it to the boot.img (unless the boot loader is "unlocked"). In other words, the ROM has a built-in key (which, by its nature, cannot be modified), used to validate the precursors of the SBL. Those, in turn, validate the SBL, which validates aboot, thus securing the boot sequence and preventing any modification by malware (or unauthorized rooting attempts). aboot is the first component which may opt to break the chain - and this is what is meant by "boot loader unlocking": The unlocking simply disables the signature check on the next part of the boot sequence, which is loading the kernel and RAM disk from the boot partition (flashed from boot.img). Not all boot loaders can be unlocked, however, as that is left to the vendor's discretion. For those which do, it is usually a straightforward matter - the device is placed into bootloader mode (adb reboot bootloader) and then a fastboot oem unlock is all it takes. Amazon's Fire-devices (FireTV, FirePhone, and the Kindle Fire) do not allow this, as well as some versions of Samsung's boot loader. Samsung appears to be more particular, in allowing some international versions of their devices to be unlockable, and other not. As discussed in Chapter 21, boot loader locking is as essential part of Android security, but by itself is insufficient to prevent rooting in most cases. Thus, the SBL loads aboot, and inspects its header to find the "directions" for loading. You can obtain aboot from a factory image (by using imgtool to break apart the bootloader.img) or directly from the device's aboot partition (assuming a rooted device, of course). You can find the aboot partition number by consulting /proc/emmc (where available), or (in JB and later) /dev/block/platform/platformname/by-name/aboot. If you want to read more go to Android Internals: A Confectioner's Cookbook.