πŸ“š Booting Of Mobile Devices


Created: 20.09.2020

iOS

When an iDevice is started, two separate booting processes are taking place: booting of Application Processor and booting of Secure Enclave.

Booting of Application Processor

Meaning, without Secure Enclave.

During each stage the current code checks the integrity of the following one. The stages are:

  • BootROM
  • LLB
  • iBoot
  • Kernel

BootROM

  • BootROM
  • LLB
  • iBoot
  • Kernel

BootROM is an immutable code (i.e. it can’t be changes for it’s hardcoded on the chip during manufacturing). Therefore, since it can’t be changed, it’s implicitly trusted by other parts of the system. It’s called root of trust.BooROM contains root certificates of Apple that are used to check the integrity of the code that follows. This portion is read-only. If there is a vulnerability in this code, Apple won’t be able to fix it, since they will need to revise hardware. There are two BootROMs: old (before 2009) and new (after 2009). The first one has 0x24000 Segment Overflow that allowed a jailbreak. Read about different BootROM versions.

Booting of Secure Enclave

Android

Booting Process

chart2

Step 1: Power On and System Startup. When we press the power button, the Boot ROM code starts executing from a pre-defined location which is hardwired in ROM. Boot ROM is an unchangeable small piece of code. It loads the Bootloader into RAM and starts executing.

**Step 2: Bootloader. **The bootloader is a small program which runs before Android (kernel) does. This is NOT part of the Android operating system. The bootloader is the place where manufacturer puts their locks and restrictions. So, it’s vendor specific. It’s not dependent on the OS version (Android 7 or 3 or something else). It’s something like BIOS on the PC.

πŸ“ NB! This piece of code is usually overwritten or patched to enable rooting. Sometimes it’s locked by vendors (Samsung, Google HTC, Xiami or etc). To unlock, you need to enable Developer’s mode and unlock OEM in Developer Settings.

The first stage. Bootloader detects external RAM and loads a program which helps on the second stage.The second stage. Bootloader setups the network, memory, etc, which requires to run kernel. The bootloader is able to provide configuration parameters or inputs to the kernel for specific purposes. The bootloader can be found at:

<android source>/bootable/bootloader/legacy/usbloader

This legacy loader contains 2 important files:

  • Init.s :: Initializes stacks, zeros the BSS segments and call_main() in main.c
  • Main.c :: Initializes hardware (clocks, board, keyboard, console) and creates linux tags.

Step 3: Kernel. Since Android is based on Linux, Android kernel starts in a similar way as the Linux kernel. As the kernel launches, it starts to setup cache, protected memory, scheduling and loads drivers. When the kernel finishes the system setup, it looks for β€œinit” in the system files (not the init mentioned above, for bootloader).

Android vs Linux kerne

Android specific interprocess communication mechanism and remote method invocation system binder
New shared memory allocator, similar to POSIX SHM but with a different behavior and sporting a simpler file-based API ashmem (Android Shared Memory)
“Process memory allocator”: It is used to manage large (1-16+ MB) physically contigous regions of memory shared between userspace and kernel drivers pmem
This is the kernel support for the logcat command logger
used for power management files. It holds the machine awake on a per-event basis until wakelock is released. wakelocks
kills processes as available memory becomes low oom handling
lets user space tell the kernel when it would like to wake up alarm manager
Allows to save kernel printk messages to a buffer in RAM, so that after a kernel panic they can be viewed in the next kernel invocation RAM_CONSOLE
USB gadget driver for ADB
yaffs2 flash filesystem

Step 4: init process.

Init is the very first process, we can say it is a root process, or the grandfather of all processes. The init process has two responsibilities:

  1. Mounts directories like /sys, /dev or /proc
  2. Runs init.rc script

init process can be found at /init :: <android source>/system/core/init

init.rc file can be found at <android source>/system/core/rootdir/

Android has specific format and rules for init.rc files. More information about these rules can be found here. At the end of this stage, you see the Android logo in your screen.

Step 5: Zygote and Dalvik

In Java, we know that a separate Virtual Machine (not sandbox, but JVM) instance will pop up in memory per app, but in the case of Android, the VM should run as quick as possible for an app. But what happens if you have several apps thus launching several instances of the Dalvik (VM)? It would consume an immense amount of memory.

To overcome this problem, the Android OS has a system called β€œZygote”. The Zygote enables code sharing across the Dalvik VM, achieving a lower memory footprint and minimal startup time. Zygote is a virtual machine process that starts at system boot. The Zygote preloads and initializes core library classes.

The Zygote loading process:

  1. Load Zygote Init class:
    <android source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
  2. registerZygoteSocket(). It registers a server socket for zygote command connections.
  3. preloadClasses(). Is a simple text file that contains a list of classes that need to be preloaded, you can find the file at <android source>/framework/base
  4. preloadResources(). Everything that is included in the android.R file will be loaded with this method (themes and layouts).

At this time, you can see the boot animation.

Step 6: System service

After the above steps are completed, Zygote launches the system services. It forks a new process to launch the system services:

Core services Other services
Starting power manager Starting status bar service
Creating the Activity Manager Starting hardware service
Starting telephony registry Starting NetStat service
Starting package manager Starting connectivity service
Set activity manager service as system process Starting Notification Manager
Starting context manager Starting DeviceStorageMonitor service
Starting system contact providers Starting Location Manager
Starting battery service Starting Search Service
Starting alarm manager Starting Clipboard Service
Starting sensor service Starting checkin service
Starting window manager Starting Wallpaper service
Starting Bluetooth service Starting Audio Service
Starting mount service Starting HeadsetObserver
Starting AdbSettingsObserver

Voila, the booting process is completed!

For analyzing the booting process on Linux host:

adb logcat –d –b events | grep β€œboot”adb logcat –d | grep preload

For analyzing the booting process in PowerShell on Windows host:

adb logcat –d –b events | Select-String -Pattern β€œboot”adb logcat –d | Select-String -Pattern preload

Other

References

[1] Booting scheme of an Android device