iBoot stage (main bootloader) security on macOS

My last article was about the Low-Level Bootloader (LLB) stage on Silicon Macs, its security design, and related exploits. This article covers the same topics for the iBoot stage. If I missed a notable exploit, please let me know. Let’s get started!

After LLB finishes its checks, it loads and transfers control to iBoot (often called the “boot firmware” on Macs). iBoot is a more feature-rich bootloader, similar to the one on iPhone. It brings up the rest of the system needed to load the macOS kernel.

On Macs, iBoot’s responsibilities include:

initializing additional system SoC components (like the Neural Engine, image signal processor, Always-On Processor, etc.),
loading their firmware, and
preparing the system to launch the kernel.

iBoot also verifies the integrity of the macOS boot assets. It checks the signatures or hashes of the Kernel Collections that will be used to run macOS.

Kernel collections are prelinked, code-signed bundles of the macOS kernel and required kernel extensions or drivers that are loaded early in boot to improve startup performance and enforce platform integrity.

Additionally, iBoot verifies the Signed System Volume (SSV) integrity check before handing off to the OS. In other words, iBoot is the stage that ensures the operating system about to launch has not been tampered with. Once all checks pass, iBoot loads the macOS kernel (XNU) and its pre-linked drivers into memory and executes it.

The macOS SSV is a cryptographically sealed, read-only system partition whose contents are verified at boot and update time to ensure the OS has not been modified, protecting platform integrity and reducing yikes persistence opportunities.

Installing a custom kernel extension – Apple Developer Documentation
The kernel and extensions 2: Secure Boot – Dr. Howard Oakely
Securely extending the kernel in macOS – Apple Support (BN)

Security

iBoot is heavily secured. I mean, it’s the last line of defense before the OS itself runs. Some security measures in iBoot on Silicon include:

code signing,
verification,
memory protections, and
signed system volumes / root hashes

Starting with code signing and verification,

iBoot will only load a macOS boot object (kernel or kernel collection) if it is properly signed or hashed according to the policy.

In Full Security mode, iBoot expects a ~personalized~ Apple signature on the Boot Kernel Collection (the set including the kernel and core system kexts).
In Reduced/Permissive mode, it will accept a globally signed copy (allowing older macOS versions to boot).

Any signature mismatch or missing component causes iBoot to halt the boot and fall back to Recovery OS.

iBoot also checks if an Auxiliary Kernel Collection (AuxKC) is required. AuxKCs are used when third-party or additional kernel extensions are allowed, such as in Reduced/Permissive mode.

If an AuxKC is present, iBoot verifies that it is signed by the Secure Enclave (same key as the LocalPolicy) and that its hash matches what the LocalPolicy dictates. This ensures that even optional, user-allowed kernel extensions cannot be loaded unless the user’s SEP has approved them. If the policy says an AuxKC should be present but none is found (e.g., user has since removed an allowed kext), iBoot will continue without it but still in a verified state.

The Secure Enclave is an isolated coprocessor with its own secure boot and memory protections that manages sensitive operations such as key handling, biometric data protection, and boot policy enforcement independently of the main CPU.

In terms of memory protections,

Once iBoot places the Boot Kernel Collection (and AuxKC, if any) into memory, it locks down that memory region with a protection called System Coprocessor Integrity Protection (SCIP). SCIP is a mechanism that prevents other coprocessors or peripherals from modifying the loaded kernel code in memory.

Essentially, iBoot marks the memory containing the kernel and core extensions as read-only and off-limits to direct memory access (DMA) from devices. This stops any rogue component (i.e., a compromised Thunderbolt device or a buggy peripheral) from altering the kernel after iBoot’s verification. It is a defense against DMA attacks or component firmware trying to tamper with the OS at the last moment.

Signed System Volume (SSV) root hash

Used on a post about Boot Security. Also used on iBoot post.

Boot Process Diagram by Apple.

Since Big Sur, macOS uses a Signed System Volume, which means the entire system filesystem is sealed by a cryptographic hash tree (Merkle tree) and ultimately signed by Apple.

iBoot is responsible for verifying the root hash of the system volume before the OS mounts it. iBoot doesn’t iterate over the whole filesystem (that will be done by the kernel later). But, it checks that the top-level hash of the system APFS snapshot matches Apple’s signed value and is authorized. This provides confidence that the system files haven’t been altered. iBoot passes the verified root hash to the kernel, which will use it to validate the file system contents at runtime.

If the SSV root hash check fails, the boot will be aborted. This would trigger recovery or a panic loop, as the kernel will detect an invalid seal.

Boot Process Diagram by Dr. Howard Oakley.

Memory-safe implementation

Apple hardened iBoot’s implementation against memory corruption. As of iOS 14 (which corresponds to macOS 11 Big Sur timeframe), Apple modified the compiler and runtime for iBoot to enable memory safety features.

This includes:

pointer bounds checking to prevent buffer overflows,
heap metadata protection to prevent use-after-free and double-free exploits, and
typed pointers to prevent type confusion.

These changes make it much harder for an attacker to exploit iBoot with techniques that historically plagued low-level C code. Essentially, Apple recognized that if an attacker somehow finds a vulnerability in iBoot (e.g., via a crafted external boot image or corrupt firmware), memory safety enforcement can stop many types of bugs from becoming exploitable. This defense aimed to eliminate entire classes of iBoot vulnerabilities.

Hardware security features

iBoot runs in the context of the Apple Silicon SoC, which provides hardware security features like Pointer Authentication Codes (PAC) and (on newer chips) Branch Target Identification (BTI). I’ve discussed these in previous articles.

PAC is enabled at the CPU level for all code running in the high exception levels. By the time iBoot is running, pointer authentication could be used to sign return addresses or function pointers to mitigate ROP attacks.

While Apple doesn’t provide a “master list” of every single pointer iBoot handles, the broader implementation details of Pointer Authentication (PAC) in iBoot are documented (see: OS integrity and OS integrity; named the same, but have different contents).

Additionally, iBoot uses the Secure Enclave for cryptographic operations that require device-specific secrets (e.g., decrypting FileVault keys or handling secure data), though most of iBoot’s verification uses public keys and signatures.

Read more: How to use ROP to bypass security mechanisms and CFI with Clang, macOS, and Clang on macOS – Olivia A. Gallucci

Now, let’s talk about iBoot attacks!!!

iBoot in iOS devices has been a target for jailbreakers. On Silicon, there are no public iBoot exploits to my knowledge, but we can look at analogous scenarios.

Boot loader exploits

In past iPhones, attackers discovered vulnerabilities in bootloaders that allowed them to execute unsigned code or load modified OS images. For example, the 2018 leak of iBoot’s source code spurred interest in auditing it for bugs.

A successful iBoot exploit on Silicon could potentially allow an attacker with local access (e.g., via a malicious Thunderbolt device or a corrupted OS installer image) to bypass signature checks and load an arbitrary kernel or modify it on the fly. This is a high bar. Memory-safe iBoot aims to eliminate the sorts of memory corruption bugs that enabled previous bootloader exploits.

So, this effort has paid off.

No jailbreak-like iBoot compromises are known on M1/M2/M3. One reason is that Silicon Macs don’t expose easy pathways to feed malicious input to iBoot. The iBoot process usually loads macOS from the internal disk or a trusted external installer, all of which are signed. Unlike on Intel PCs, you cannot point iBoot to a custom OS without going through the secure policy controls.

The Asahi Linux project is an example of this btw. The developers had to build a custom installer that guides through Apple’s official “1TR” (One True Recovery) mode to manually authorize a “Permissive Security” policy, which is the only way iBoot will agree to execute their non-Apple bootloader.

macOS boot structure on M1. Used on a post about iBoot.

Boot Disk Structure Diagram by Dr. Howard Oakley.

Bypassing SSV

An attacker might try to tamper with macOS system files to persist malware (e.g., inserting a backdoor into /usr/libexec/someSystemDaemon). However, the Signed System Volume design and iBoot’s checks make this difficult.

If any system file on the sealed APFS volume is altered, it breaks the cryptographic hash chain. The kernel would detect this when comparing the file’s hash to the expected value in the tree signed by Apple, and refuse to load it.

In practice, (I think) attackers would avoid trying to directly patch system files on Big Sur and later, because the SSV would reveal the modification immediately. The system would likely fail to boot or at least flag the volume as untrusted. The only way to modify the system volume is to disable SSV by booting the Mac in reduced security and using the csrutil authenticated-root disable command in Recovery… which is something an attacker cannot do without user/admin intervention.

Thus, malware can no longer implant itself in macOS system binaries or drivers persistently as was sometimes done in the past.* Instead, they focus on user-space or injecting into processes at runtime.

* Unless there is some 0-day I don’t know about! In that case, let me know. 😉

Next, malicious kexts or kernel code!

Because Reduced Security allows loading third-party kernel extensions (kexts), an attacker with root access might attempt to load a malicious kext to gain kernel privileges.

To achieve this, an attacker with root access would use the kmutil (Kernel Management Utility) command to load a malicious kext into the AKC, but the system would still require a physical reboot and manual approval in Recovery Mode to finalize the security downgrade.

How the “Reduced Security” attack flow works

Under Reduced Security, the “chain of trust” is not broken, but the “gate” is lowered to allow code not signed by Apple. Here is how a hypothetical attacker would proceed:

The attacker (with root/sudo privileges) places a malicious .kext file in /Library/Extensions, staging the malicious kext. Then, they would run sudo kmutil load --p /Library/Extensions/Malicious.kext to trigger the load. After that, macOS will immediately alert a system prompt stating that a “System Extension was Blocked.” This is a “User Consent” barrier. The attacker cannot bypass this via script; a human must click Open Security Settings.

Lastly, there is a reboot to recovery. To actually “activate” this kext under Reduced Security, the user is forced to reboot into Recovery Mode (1TR) to modify the kernel policy. This is where most attacks fail, since it requires physical interaction.

On Silicon with Full Security, this is impossible by default.

The kernel will refuse to load an unapproved kext. If the Mac is set to Reduced Security (like for using certain drivers), there is a window of risk. A local attacker could try to exploit a vulnerability in the kext loading mechanism or abuse a signed-but-vulnerable kext.

So far, most Mac malware steers away from writing custom kexts, since even in reduced mode, the kext must be notarized or approved manually. To this day, most macOS malware runs in user space and uses LaunchAgent persistence. This trend shows that attackers find it easier to operate above the kernel (where protections are weaker) than to fight the chain-of-trust in early boot.

Exploiting iBoot via peripherals

On systems with ~rich~ boot environments, peripherals (like USB or network) could feed input to the bootloader. Think of a malicious USB pretending to be a boot device.

Apple Silicon’s design minimizes this risk. iBoot doesn’t handle arbitrary file system parsing from USB at boot.

See: Apple Platform Security (HK), specifically in the LocalPolicy and Secure Boot sections. Secure Boot is the hardware-rooted verification process in which the Mac’s Boot ROM, Secure Enclave, and LocalPolicy cryptographically validate each stage of startup so only an authorized, unmodified operating system can boot.

There is a DFU mechanism in iBoot for restoration, but that accepts only a special signed image from Apple or Apple’s Configurator tool. I’d assume that some researchers have looked at DFU and recovery modes for vulnerabilities, since they involve iBoot-level code parsing an incoming restore image. However, no DFU exploit is known for M1/M2.

Apple Configurator Tool.

In contrast to my previous posts, the Checkm8 BootROM exploit on older devices was triggered in DFU mode. If a similar bug existed in M-series BootROM or iBoot DFU handling, it could be devastating.

Now, onto pointer authentication bypasses!

The introduction of Pointer Authentication in M1 chips was meant to stop traditional code-reuse attacks.

PACMAN

In mid-2022, MIT researchers unveiled PACMAN, a hardware side-channel attack against PAC on M1.

PACMAN showed that if an attacker has a memory corruption bug in the first place, they could use speculative execution to brute-force a correct PAC value and bypass pointer authentication, defeating that “last line of defense.”

Speculative execution is a CPU optimization where the processor temporarily executes predicted instructions before it knows they are needed, which can leak information or influence security checks even if the work is later discarded.

Wikipedia

Pulling off PACMAN in the iBoot context would be extremely unlikely. An attacker would first need to find an iBoot memory corruption bug (none known, as noted). After that, the attack would have to run within iBoot’s execution environment, which is very brief and does not allow arbitrary user code.

Apple said PACMAN is not useful as a standalone exploit. By itself, it cannot gain privileges and only works when combined with an existing vulnerability, so Apple did not view it as a serious risk to users.

Thus, PACMAN is more of a concern for the kernel stage (discussed in my next post) than for iBoot. Still, it shows security researchers probing the hardware for weaknesses.

Apple will likely introduce more countermeasures in future chips.

Armv9 features. Used on a post about iBoot.

ARMv9 features – ARM

For example, the ARMv9 architecture supports features to mitigate certain speculative attacks, and Apple’s M3 includes a Data Independent Timing (DIT) toggle that can mitigate some timing side-channels.

If they did more than this, let me know because I am behind!

In short, attackers have not hacked iBoot on Silicon. Most Mac attacks focus on userland and, occasionally, the OS kernel via exploits, rather than the bootloader, because the bar is so high.

Honestly, this is a testament to the secure, but unfortunately, obscure design. iBoot’s stringent checks (e.g., signature verification of everything, memory locking, etc.) and Apple’s proactive hardening (e.g., memory-safe iBoot, limited interfaces) leave little for an attacker to use.

Evolution

Apple updates iBoot via firmware updates bundled in macOS updates. If you search the update notes, they occasionally mention fixes for the “boot loader” or iBoot, though these are rare.

One example was Apple’s move to memory-safe iBoot on all devices with A13/M1 or later. This was likely in response to the cat-and-mouse with jailbreakers finding boot exploits. By enforcing pointer bounds and other checks at compile-time, Apple essentially prevented entire bug classes. Thus, even if iBoot contains a bug, it might not be exploitable into code execution. This was implemented in late 2020.

Apple also introduced mechanisms like Secure Boot auditing.*

The Mac records certain boot logs or “failboot breadcrumbs” in NVRAM (non-volatile memory) if something goes wrong during iBoot’s process.

While mostly opaque to me and users in general, this could help Apple or incident responders detect if something unusual occurred (e.g., a signature failure or unexpected component). It’s another layer of ensuring the integrity of the boot process.

Note: “Secure Boot auditing” is my personal way to explain the logging. It is not an official term.

Rapid Security Response

Starting in macOS Ventura, Apple also debuted Rapid Security Response updates (now called Background Security Improvements), which can patch system security issues without a full OS update.

If a critical bootloader bug were found, Apple could theoretically issue a special firmware update out-of-band. In other words, Apple could ship a special firmware update outside the usual macOS update process to fix a bug faster.

Additionally, Apple’s lockdown of external boot options unless the user lowers security is a defensive posture to protect consumers from inadvertently running untrusted boot code.

Finally, iBoot on Apple Silicon works hand-in-hand with the Secure Enclave to handle things like FileVault disk encryption.

When FileVault is enabled, the OS cannot access the disk until the user provides the password. In Silicon Macs, after iBoot verifies macOS, control is passed to the kernel, which may then invoke the Secure Enclave to unlock the volume. This often happens at the login window stage.

Design

The design ensures that even if iBoot were compromised, the user’s disk remains encrypted; the key is in the SEP and requires a user passcode.

In the T2 Intels, iBoot (on T2) would prompt for the password early. On M1, the password prompt is integrated in the macOS login window but enforced by SEP behind the scenes. The net effect is the same: an attacker in iBoot can’t bypass FileVault to get data without the password or a SEP exploit.

This layered security means Apple has compartmentalized trust. iBoot ensures the OS is legit, SEP ensures the user is legit, and so on.

In conclusion, iBoot starts the system required to load the macOS kernel. Once iBoot has successfully verified and launched the macOS kernel, the operating system (proper) begins to load. Kernel and user-space loading will be the focus of my next post.

If you enjoyed this post on iBoot security, consider reading my post on Low Level Bootloader (LLB) Security on macOS.

mom and me in New York! used on post about iBoot.

Also, “hi” from my mom and me in NYC! Photo was taken by Mr. James!

Sources, thanks, and where to learn more