Typical Android bootloader Analysis

1. What is bootloader?

 

In short, bootloader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize hardware devices and build a map of memory space to bring the system's hardware and software environment to a suitable state, in order to prepare the correct environment for the final call to the operating system kernel.
 

The Android system is based on Linux, so the bootloader is similar to the Linux running on traditional embedded devices. Most Android manufacturers except Google do not provide the source code of bootloader. Therefore, we need to use reverse engineering to analyze the bootloader of mobile devices, of course, with Google's official open-source bootloader code for reference, the analysis work can be much easier. The analysis tool used in this article is IDA 6.5, the target mobile device is N9006, And the firmware version is N9006ZCUDMK2.

 

2. Typical Structure of bootloader

 

This section uses Qualcomm MSM8960 as an example to introduce the typical structure of Bootloader.
 

Qualcomm MSM8960 contains multiple computing units and is responsible for guiding different functions in the process. sbl1 code is responsible for loading sbl2, sbl2 loading tz and sbl3, sbl3 loading apppsbl, and hybrid BL loading HLOS.

 

Figure 1 Code Flow of SecureBoot 3.0
 

Figure 2 MSM8960 simplified Process Flowchart
 

3. Note3 bootloader Structure Analysis

The China Mobile Note3 (N9006) uses the MSM8974 CPU, and its bootloader structure is similar to the typical MSM8960. The biggest difference is that sbl1, sbl2, and sbl3 are integrated into a file sbl1, both TrustZone and cmdbl are verified and loaded by sbl1. The following describes how to load code analysis for several main functions.
 

The function of sbl1 is to initialize the hardware and load other modules. The information of the modules to be loaded is stored in sbl1, the data of each module is a block of module information data with a size of 0x64 bytes. sbl1 has a cycle to verify and load all other required modules (tz, rpm, wdt, appsbl ), the loaded code calls different loaders to load and verify the code based on the data in the module information. The specific code is shown in.

 

Figure 3 code for loading all modules cyclically in sbl1
 

Figure 4 verify the loading module in sbl1
 

Figure 5 TZ module information data
 

Figure 6 APPSBL module information data
 

 

Tz In the firmware package. mbn is a module loaded in TrustZone. The module format is elf. The code in this module and the code of other modules in the system run in an isolated area, with higher permissions than other modules, many underlying security features of Samsung KNOX are also implemented in this part. For more information about TrustZone, refer to the official instructions of arm.
 

Firmware T. mbn is the memory BL module. The module format is bin. the header 0x28 at the top of the file describes the bin loading address and other information. The following data is the image actually loaded into the memory, in the whole bootloader, this module has the largest amount of code (a large part of it is openssl code), verification and loading of the Linux kernel (normal start and Recovery mode ), code such as the ODIN mode is included in this module.
 

 

Figure 7 sequence T. mbn File Header
 

Figure 8 determine the Boot Mode Based on the buttons and data in the shared memory
 

Figure 9 code of the Samsung-specific ODIN fl Mode
 

4. Preliminary analysis of the underlying code of the KNOX System in the bootloader of Note3
 

Note3 provides an enterprise security package KNOX, which includes the underlying Customizable Secure Boot and TrustZone-based Integrity Measurement Architecture (TIMA, currently version 2.0 ), securityEnhancements for Android (SE-Android) at the System layer and Samsung KNOX Container at the application layer, Encrypted File System (EFS), Virtual Private Network (VPN ), the Customizable Secure Boot and TIMA codes are included in the aboot of the Bootloader. mbn, tz. in the mbn, NON-HLOS.bin, the function is to ensure the integrity of the loaded Kernel During loading and runtime.

Through the previous analysis, we already know tz. mbn and limit T. the integrity of mbn has been verified by sbl1 during loading, tz. after mbn is loaded, it runs in the secure environment of the CPU. It monitors the integrity of the system from the high-Permission isolation area, and is responsible for loading the kernel t of the android kernel. mbn includes kernel Integrity Detection. Samsung adds its own signature at the end of each part of bootloader. The signature is verified before loading to ensure that the system has not been modified.
 

Figure 10 code for TIMA system initialization in tz. mbn
 

Figure 11 check whether SEANDROID is used in the kernel in memory T. mbn

When any part of the detection code finds a system exception, it will call the SMC command to notify the TIMA system running in TrustZone to set fuse as the system integrity damaged, once the fuse data is set, it cannot be reset, and the system cannot enter the KNOX system again.

Figure 12 kernel signature and TIMA measurement points are verified before kernel Loading
 

Figure 13 set the fuse value after the system integrity check fails

After all the above checks are passed, bootloader will copy the kernel to the specified memory address and jump to the kernel entry for further execution. At this point, it will enter the scope of the system kernel code, the mission of bootloader is complete. The code for redirecting to the Linux kernel entry is shown in figure 14.
 

Figure 14 after kernel loading and verification are completed, the system jumps to the kernel entry point to continue execution.
 

In addition to the two modules, Modem firmware-related NON-HLOS.bin also has a large number of TIMA system related files, because the TIMA system contains a large amount of hardware-related code (the implementation of the tima system in the N900 CPU of Samsung Orion is significantly different from that of the N9006 CPU of Qualcomm ), if you need to further analyze TIMA's behavior in modem, you need to learn more about TrustZone and modem working methods.

Figure 15 a large number of TIMA-related files contained in the NON-HLOS.bin