|Operating system||Darwin, macOS, iPadOS and iOS|
iBoot is the stage 2 bootloader for all Apple products. It replaces the old bootloader, BootX. Compared with its predecessor, iBoot improves authentication performed in the boot chain.
For x86 macOS, the boot process starts by running code stored in secured UEFI Boot ROM (first stage). Boot ROM has two primary responsibilities: to initialize system hardware and to select an operating system to run (the POST and UEFI component). For ARM macOS, the Boot ROM is not UEFI component.
For iOS, the boot process starts by running the device's Boot ROM code. In systems with S1 processors or A9 or earlier A-series processors, the Boot ROM loads the Low-Level Bootloader (LLB), which loads iBoot. In systems with newer processors, the Boot ROM loads iBoot itself. If all goes well, iBoot will then proceed to load the iOS kernel as well as the rest of the operating system. If the LLB or iBoot fails to load iOS, or fails to verify iOS, the bootloader jumps to DFU (Device Firmware Update) mode; otherwise it loads the remaining kernel modules.
On x86 macOS, iBoot is located in
/System/Library/CoreServices/boot.efi. Once the kernel and all drivers necessary for booting are loaded, the boot loader starts the kernel’s initialization procedure. At this point, enough drivers are loaded for the kernel to find the root device.
Apple has modified the C compiler toolchain that is used to build iBoot in order to advance memory safety since iOS 14. This advancement is designed to mitigate entire classes of common memory corruption vulnerabilities such as buffer overflows, heap exploitations, type confusion vulnerabilities, and use-after-free attacks. These modifications can potentially prevent attackers from successfully escalating their privileges to run malicious code, such as an attack involving arbitrary code execution.
in 2018, a portion of iBoot source code for iOS 9 was leaked on GitHub, Apple then issued a copyright takedown request (DMCA) to GitHub to remove the repository. It was believed an Apple employee was responsible for the leak, However, this was not confirmed by Apple.