Learning Pentesting for Android Devices
上QQ阅读APP看书,第一时间看更新

Android startup process

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.

Android startup process

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:

Android startup process

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:

Android startup process

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.