1. What is bootloader?
In short, bootloader is a small program that runs before the kernel of the operating system runs. Through this small program, we can initialize the hardware devices and establish the map of memory space, so as to bring the hardware and software environment of the system to a proper state, so as to prepare the right environment for the final call to the operating system kernel.
Android system is based on Linux, so the bootloader part is no different from Linux running on traditional embedded devices. Because most Android manufacturers except Google do not provide bootloader source code, so the analysis of mobile device bootloader needs to use reverse engineering. Of course, because of Google's official open source bootloader code as a reference, it can make the analysis easier. The analysis tool used in this paper is IDA 6.5, the mobile device is n9006, and the firmware version is n9006zcudmk2.
2. Typical structure of bootloader
In this part, we will take Qualcomm msm8960 as an example to introduce the typical structure of bootloader.
The Qualcomm msm8960 contains multiple operation units, which are responsible for different functions in the boot process. The sbl1 code is responsible for loading sbl2, sbl2 loading TZ and sbl3, sbl3 loading apppsbl, and appsbl loading hlos.
Figure 1 code flow of secureboot 3.0
Figure 2 simplified flow chart of msm8960 boot process
3. Analysis of the bootloader structure of note3
The CPU of the national version of note3 (n9006) is msm8974. Its bootloader structure is similar to that of the typical msm8960. The biggest difference is that sbl1, sbl2 and sbl3 are integrated into a file sbl1. Both TrustZone and appsbl are verified and loaded by sbl1. The following is the analysis of the loading code of several main functions.
The function of sbl1 is to initialize the hardware and load other modules. The module information to be loaded is stored in sbl1 in order. The data corresponding to each module is a piece of module information data with the size of 0x64 bytes. There is a cycle in sbl1 to verify and load all other modules (TZ, RPM, WDT, appsbl) required. The loading code will be based on the data in the module information Call different loaders to load and verify the code, as shown in the following figure.
Figure 3 code of loading all modules circularly in sbl1
Figure 4 verification of modules to be loaded in sbl1
Figure 5 information data of TZ module
Figure 6 information data of appsbl module
Tz.mbn in the firmware package is a module loaded in TrustZone. The module format is elf. The code in this module and other module codes of the system run in an isolated area, and the permissions are higher than other modules. Many underlying security features of Samsung Knox are also implemented in this part. For more information about TrustZone, please refer to the official instructions of arm.
The aboot.mbn in the firmware package is the appsbl module. The module format is bin. The first 0x28 byte header of the file describes the bin loading address and other information. The later 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 which is OpenSSL code), and the verification and loading of Linux kernel (normal startup and recovery module) Type), Odin mode and other codes are included in this module.
Figure 7. Aboot.mbn header
Figure 8 determine the boot mode according to the key and the data in the shared memory
Figure 9 Samsung's unique Odin brush mode code
4. A preliminary analysis of the underlying code of Knox system in the bootloader of note3
Note3 provides an enterprise security package Knox, which includes the underlying customized secure boot and TrustZone based integrity measurement architecture (TIMA, currently version 2.0), the system layer's security enhancements for Android (SE Android) and the application layer's Samsung Knox container, encrypted file system (EFS), virtual private Network (VPN), in which the code of customizable secure boot and TIMA is included in boot loader's abot.mbn, tz.mbn, non-hlos.bin. The function is to ensure the integrity of the loaded kernel at load time and runtime.
Through the previous analysis, we have known that tz.mbn and abot.mbn have been verified by sbl1 when they are loaded. After they are loaded, tz.mbn will run in the CPU security environment, monitoring the integrity of the system from the high authority isolation area, while the abot.mbn, which is responsible for loading Android kernel, contains the integrity detection of the kernel. Samsung is at the end of each part of bootloader It will add its own signature. Before loading, it will verify the signature to ensure that the system has not been modified.
Figure 10 code of TIMA system initialization in tz.mbn
Figure 11. Verifying whether the kernel uses sendroid in aboot.mbn
When any part of the detection code finds the system abnormal condition, it will call the SMC instruction to inform the TIMA system running in TrustZone to set fuse as the system integrity is damaged. Once this fuse data is set, there is no way to reset it, and the system can no longer enter Knox system.
Figure 12 verification of kernel signature and TIMA test points before kernel loading
Figure 13 set fuse value after system integrity test failure
After all the above tests are passed, the bootloader will copy the kernel to the specified memory address and jump to the kernel entry to continue execution. Here, it enters the system kernel code category, and the task of bootloader is completed. The code jumping to the Linux kernel entry is shown in Figure 14.
Figure 14 skip to the entry point of the kernel to continue after the kernel loading and verification
In addition, besides these two modules, there are also a lot of TIMA system related files in non-hlos.bin related to modem firmware. Because TIMA system contains a lot of hardware related codes (the implementation of TIMA system in N900 using Samsung Orion CPU is quite different from n9006 of Qualcomm CPU), if further analysis of TIMA's behavior in modem is needed, TrustZone and modem's working mode need to be analyzed Wait for more information.
Figure 15 a large number of TIMA related files contained in non-hlos.bin