Engineering Android's Aboot

Android's boot process starts with the firmware*, which loads from a ROM. The exact details of the firmware boot vary between devices and specific architectures (e.g. Qualcomm vs. NVidia). Nonetheless, they can be generalized in the following figure:

Figure 1: The generalized Android Boot Process (from ACC, Chap. 3)


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. Using busybox cp or dd, copy the partition to a file (say, «aboot»). Picking up on the experiment in the book, we have:

Output 1: aboot from a factory image


You can toggle between the devices shown here, but note the format of aboot is still very much the same. The Magic (0x0000005) misleads the file(1) command into thinking this is an Hitachi SH COFF object. The SBL, however, is not fooled, and validates the signature (usually 256 bytes, i.e. a 2048-bit PKI, immediately after HeaderSize + CodeSize) with the certificate chain that is loaded from the offset (HeaderSize+ImgSize + CodeSize + SigSize).If the signature is valid, the SBL proceeds to load the code immediately following the header (CodeSize bytes) by mapping into ImgBase.

The first byte of the aboot binary image is identifiable by the «eaXXXXXX» value. The book alludes to this being an ARM B(ranch) instruction, but stops short of explaining its significance — which is explained next.

ARM Processor Boot, in a Nutshell

ARM processors use an Exception Vector during their lifecycle. This vector is a set of 6 or seven addresses, set by the operating system, and instructing the processor what to do when certain traps are encountered. These traps are architecture defined, and so the vector indices are always the same across all oeprating systems**. This is shown in Table 1:

Table 1: The ARM Exception Vector


Disassembling Aboot

As discussed in the book, the standard aboot is derived from the «LittleKernel» project, hosted by CodeAurora. This project (often referred to as «LK»), is partially open sourced, in that some of its components can be found there (A simple way to get the sources is via git clone git://codeaurora.org/kernel/lk.git). You'll see something similar to this:



This should get you started on your own explorations of Android's Boot Loader. The platform support stuff isn't that interesting (USB being somewhat of an exception, due to its usage as a potential attack vector). Apps, in particular, are obviously important. Of special interest is Odin, to which I hope to devote another article at some point.