The iOS bootchain is a “chain” of different processes (links) that run before, and during the familiar fruit that lights up your device. The iOS bootchain is also called the “Chain of Trust” because every process that runs “trusts” that the process that ran below (before) it was not compromised. When you jailbreak a device, you are compromising a link in that chain. When you compromise a link in the chain, each link above (after) it stills trusts the compromised link, therefore allowing you to also take control of all processes above the compromised one. Each file has its own signature and no 2 signatures of different files are the same.
Below, I will explain all of major parts of the iOS boot chain and what they do, in a way that everyone can understand. Let’s get to it, shall we?
Immediately after pressing the power button (but before your screen turns on), the bootrom or “SecureROM” is loaded. It is the first component in the bootchain and every process must assume it is not compromised. The bootrom is coded into the hardware of your device at the time of manufacturing. Due to it being a hardware component, any problems relating to it cannot be fixed with a software update. ROM stands for Read-Only-Memory, meaning unlike a hard drive, you cannot write to it. The bootrom’s main function is to verify the integrity of LLB, to make sure it wasn’t tampered with. If it fails to verify LLB, your device is put into DFU (device firmware update) mode, forcing you to restore.
LLB stands for Low Level Bootloader and it is the first software component in the bootchain. The LLB runs several setup tasks that gets your device ready to run (once again, before your screen turns on). More checks are run, this time verifying the signature of iBoot before handing off control of the device. If any checks fail from this point forward, your device will be put into recovery mode, showing the “Connect to iTunes” screen.
There are 2 parts of iBoot, these pertain to restoring your device, and on normal boot:
During a DFU restore, IBSS and IBEC ARE uploaded to the device, and IBSS then tells IBEC to kick the device into restore mode. This happens because in DFU mode, nothing hardware related is loaded. Restore mode tells iTunes to start sending the new firmware. IBSS generates a nonce that is sent to iTunes and then checked to see if it matches the APTicket. If it matches, it will continue the restore, if it doesn’t, the restore will fail. This usually prevents downgrading to lower firmware (thanks Prometheus!).
The boot portion of iBoot is loaded every time you try to boot your iDevice. At this point your screen will turn on and show the Apple logo. iBoot verifies the kernel and the SEP (secure enclave processor) to make sure their signatures match what they should be (This is not related to KPP or the hypervisor). Once iBoot loads, there are 3 possible outcomes:
1. The iBoot detects a failed boot, such as a signature check failing, the device will then be put into recovery mode.
2. The iBoot starts the poweroff task, which turns off the device.
3. The kernel’s integrity is verified successfully, the kernel is loaded, and the rest of the boot proceeds.
Note: The SEP’s signature doesn’t have to be valid to continue the boot. If its signatures are invalid, Touch ID will not work.
Secure Enclave Processor
The secure enclave processor is a processor that is present in all A7 (and newer) chips. The SEP stores the encrypted Touch ID data. It lives in a section of the main CPU, but is completely isolated from all processes. The SEP itself is only 4MB, and runs its own operating system: SEP OS. For all intents and purposes, you can think of SEP as a separate device from your iDevice.
The kernel of iOS (and in most devices) handles all of the calls to the hardware from the software, as well as launching applications. The kernel is quite a bit harder than most operating system to exploit due to parts of the kernels code being loaded into a random area (within a defined space) of memory also known as LASLR (Kernel Address Space Layout Randomization). The thinking behind KASLR is that you can’t run the same exploit twice, because that part of the kernel won’t be be in the same area memory with each time. In addition, the kernel also controls app signing. It is responsible for checking to see if the apps provisioning profile is valid and, if it isn’t, it will refuse to launch the application.
As of iOS 9, Apple implemented a new security check to make sure that the kernel was not tampered with after the kernel was loaded. It checks at intervals while your devices is booted. Apple calls this Kernel Patch Protection or, KPP for short. If KPP detects that the kernel was patched by something (like a jailbreak) the device will panic, leading to a reboot. KPP makes Jailbreak’s in general considerably harder and less stable while having little security benefit. If KPP is either disabled or doesn’t detect any patches to the kernel, your device will continue to function normally.
We made it! Your device has passed all the checks and has finally booted. The bootchain is now complete. At this point, the Apple logo will fade and your lock screen will appear.
Credit to /u/nullpxiel for correcting some wrong information.
If you have any questions, feel free to sound off in the comments!