s anAndroid boot image. In this case the string is “ANDROID!”, which fits neatlyinto 8 bytes.
Somebody familiar with the Linux kernel andboot-up process will recognize the kernel tags and command line argument fieldsas ways to pass more custom information into the kernel, such as where theconsole should be, and where to find that initial ramdisk from where to loadits init program.
Working With Android Boot Images
So, since we have custom recovery and boot imagesfor our Android phones (such as TWRP, CWM, etc.), obviously, someone had tocreate their own recovery image or modify an already existing boot image. Mostof the work was done using the already open-sourced Google Android code, butthere only was code there to create a boot image from its components. There wasno tool to unpack a boot image for modification. Now, you can use a tool like
Further Areas to Explore
There are some interesting aspects relating tothe initial ramdisk that apply to both the boot and recovery Android imagesthat this article won’t cover in detail due to its already burgeoning size, butthat are worth mentioning.
● The filesystem that initial ramdisks useis usually a gzipped CPIO archive
● You can pack and unpack the initialramdisks and modify them
● init scripts are written in their owndomain specific language (DSL) and you can read their
● Default SELinux file contexts and policyusually reside in the ramdisk’s root
We can spend many hours talking about and playingwith the above items, but at least for now I will leave them as an exercise tothe keen reader.