This article was originally published on the TextNow Engineering Blog.
To fully grasp the role the Android boot and recovery images play, we first need to understand the general boot-up process of an Android phone. While embedded software is no longer part of my day-to-day work at TextNow, I used to wear the embedded-engineer hat in one of my previous jobs and I dabble with embedded electronics in my spare time, so I am intimately familiar with modern microprocessor boot-up routines. I must caution you that this is a very technical post, but one that is hopefully useful to somebody looking for a reference material on how this all fits together, with links to where to delve more in-depth if required. This type of post would have been very useful when I was learning it :)
The Android Boot-Up Process
When power and reset is applied to the processor,it wakes up and needs to figure out what to do. In modern processors, there isusually a very small program baked-in to the processor whose function is toverify the next component’s integrity. This first component is sometimes referredto as the secure boot ROM, and its job is to ensure the nextcomponent it loads is trusted, verified software. This prevents unwantedtampering of the system software and, as such, increases the security of thedevice. The verification usually involves some sort of cryptographic cipherusing a public/private key scheme, with the private key usually kept a closelyguarded secret by the manufacturer. Note: usually the publickey is programmed in at assembly time by the phone manufacturer and itscontents can never be changed, thereby requiring that processor to always run asigned bootloader, with the private counterpart of the public key burned in atassembly time.
The next component loaded by the secure boot ROM is the what people commonly refer to as the bootloader. The bootloader, as I mentioned, is usually signed with the phone manufacturer’s private key, and it has a few jobs:
1. Load a boot image from non-volatile memory (usually NAND flash nowadays) into volatile memory (RAM) and run it.
2. Optionally, that image needs to becryptographically verified before being loaded (as is the case with more andmore phones these days which don’t even provide a way to unlock the bootloaderto run unsigned images).
3. Provide the ability to flash new boot andother images to the non-volatile memory for future upgrades and recovery fromfailure.
4. Display some sort of information on thescreen, and optionally provide an interface for the user to interact with. Thisis commonly known as fastboot mode on some Motorola, Google,and other manufacturer’s devices.
Android Boot Images
We now come to the final component of the boot-upprocess - loading a boot or recovery image into RAMand running it.
Technically speaking, there are no structuraldifferences between boot and recovery images. The only difference is whichkernel and which initial ramdisk is loaded, but they are packaged the same. Wewill come back to how these are packaged to make a neat and tidy boot image.
There are a few sub-steps involved in running theboot image:
1. Cryptographic verification
2. Loading of the (Linux) kernel at the requiredmemory address
3. Loading of the initial ramdisk at the requiredmemory address
4. Jump to the start address of the kernel
The cryptographic verification is usually manufacturer-specificand it is typically very hard to reverse-engineer this method, though notimpossible - it’s been done before for certain phones (forexample, older Kit-Kat era LG phones).
The kernel is the heart of the operating system,as it ticks its constant heartbeat of interrupts and events which keep a modernoperating system running. This magic has very meager origin as a simple chunkof bytes that was compiled in such a way to wake up and start running from aparticular address of memory. This address varies depending on the particularphone and memory layout. Once execution starts, the kernel will start loadingdrivers and setup more advanced facilities so that it can start running some ofits own programs.
In and o