One of the most important things when considering security in Android is the Android startup process. The entire bootup process starts with the bootloader, which in turn starts the init process—the first userland process.
So, any change in bootloader, or if we loaded up another bootloader instead of the one present by default, we could actually change what is being loaded on the device. The bootloader is normally vendor-specific, and every vendor has their own modified version of the bootloader. Usually, this functionality is disabled by default by having a locked bootloader, which allows only the trusted kernel specified by the vendor to run on the device. In order to flash your own ROM to the Android device, the bootloader needs to be unlocked. The process of unlocking a bootloader might differ from device to device. In some cases, it could also void the warranty of devices.
Note
In Nexus 7, it is as simple as using the fastboot utility from the command line as follows:
$ fastboot oem unlock
In other devices, it might need much more effort. We will have a look at creating our own bootloader and using it in the upcoming chapters of the book.
Coming back to the bootup process, after the bootloader boots up the kernel, and launches init, it mounts some of the important directories required for the functioning of the Android system such as /dev, /sys, and /proc. Also, init takes the configuration for itself from the configuration files init.rc and init.[device-name].rc, and in some cases from the .sh files located at the same location.
If we do a cat of the init.rc file, we could see all the specifications that are used by init while loading itself, as shown in the following screenshot:
It is the responsibility of the init process to startup other necessary components, such as the adb daemon (adbd), which is responsible for the ADB communication and the
volume daemon (vold).
Some of the properties that are used while loading up are in
build.prop, located at location/system. It is the completion of loading of the init process, when you see the Android logo on your Android device. As we can see in the following screenshot, we get specific information about the device, by checking the build.prop file:
Once everything is loaded, init finally loads up a process known as Zygote, which is responsible for loading up the Dalvik Virtual Machines with shared libraries and minimum footprint to enable faster loading of the overall processes. Also, it keeps listening for new calls to itself in order to launch more DVMs if necessary. This is when you see the Android boot animation on your device.
Once fully launched, Zygote forks itself and launches the system, which loads up the other necessary Android components such as the Activity Manager. Once the entire bootup process has been completed, the system sends the broadcast of BOOT_COMPLETED, which many applications might be listening to using a component in Android applications called the Broadcast Receiver. We will learn more about Broadcast Receivers when we analyze malware and applications in Chapter 3, Reversing and Auditing Android Apps.