ays) 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 of itself, the kernel wouldn’t know whatto do once it’s loaded. It would sit there and do nothing. But what the Linuxkernel expects is an initial ramdisk at a predefined memoryaddress. This ramdisk contains a very rudimentary and usually read-onlyfilesystem which contains the most basic root filesystem possible, and a fileunder /sbin/init which the kernel executes as the last thingit does as part of initialization. This
So now we come back to the difference between aboot and recovery image. While the kernel sometimes is the same as the bootimage, the recovery image ramdisk has a distinct sets of init scriptswhich don’t start the Java VM, but instead start a small C program called (didyou guess it?) recovery. Recovery displays a limited user interfacethat allows the user to start the system, factory reset, clear the cachepartition, etc. Some custom recoveries have their own program that offers evenmore functionality.
Packing an Android Boot Image
The Android boot images have a
The layout of an Android boot image
I should mention something of this second stage.To be completely honest, I do not know its raison d’être, theoriginal intent of it. I have seen it used in more recent times to hold thekernel’s device tree block (DTB, another long and deeply technical topic bestexplained elsewhere) by certain phone manufacturers. The older kernels had theDTB as part of the kernel image, now they’ve split it out into its own separatepiece to make it easier to build a more generic kernel that can be adapted to avariety of hardware configurations within the same architecture.
Moving swiftly along (and back!) to the bootimage header, this primarily tells the bootloader how to load the components ofthe boot image, and it looks something like this:
Android boot image header
As you can see, it has a few “book-keeping”fields about how large the other sub-components of the boot image are, whataddress to load them into, etc.
It also has a field called magic. Themagic field is simply a string of well-known characters to identify this a