Bypassing Apple’s Hardware-Backed Pointer Authentication on M1

TLDR: Apple’s implementation of ARM Pointer Authentication (PAC) on M1 silicon deviates significantly from the standard ARMv8.3 specification, introducing undocumented registers and custom hardware behaviors. This research uncovers how these proprietary mechanisms, while intended to mitigate cross-domain attacks, can be reverse-engineered to identify new attack surfaces. Security researchers can leverage these findings to better understand kernel-level protections and identify bypasses like CVE-2023-32424.

Pointer Authentication (PAC) was supposed to be the death knell for simple control-flow hijacking. By signing pointers with a cryptographic signature stored in the unused upper bits of a 64-bit address, ARM aimed to make return-oriented programming (ROP) and jump-oriented programming (JOP) significantly harder to execute. When Apple brought PAC to the M1, they didn't just copy the ARMv8.3 spec; they customized it. This customization created a "black box" of hardware-level security that remained largely opaque to the research community for years.

Understanding this implementation is not just an academic exercise. If you are hunting for vulnerabilities in the XNU kernel or developing exploits for macOS and iOS, you are fighting against these hardware primitives. The recent disclosure of CVE-2023-32424 proves that even with hardware-backed signing, the logic governing those signatures is susceptible to bypasses.

Reverse Engineering the Custom Hardware

Standard ARM documentation describes PAC as a feature controlled by specific system registers. However, Apple’s M1 implementation introduces undocumented registers that govern how these signatures are generated and validated. The primary challenge in reverse engineering this is the lack of official documentation. You cannot simply look up the register map in a vendor manual.

To map this, you need to treat the CPU as a state machine. By manipulating system registers and observing the resulting behavior of the pacia and autia instructions, you can infer the underlying logic. The most effective way to do this is by using a hypervisor-based debugger. The m1n1 hypervisor is the gold standard here. It allows you to intercept register access and set an unlimited number of breakpoints, which is essential when you are trying to trace how the kernel handles pointer signing across different exception levels.

When you start sniffing these registers, you will notice that Apple uses a custom "per-boot" diversifier. This means the keys used for signing change every time the system boots, which is a clever way to prevent static analysis of signed pointers. If you are trying to reproduce this, focus on the APCTL_EL1 register. This is the Apple-specific control register that dictates how PAC behaves. By toggling bits in this register, you can observe how the hardware reacts to different signing configurations.

The "Dark Magic" of Cross-Domain Mitigation

One of the most interesting findings is how Apple handles cross-domain attack mitigation. In a standard ARM implementation, the PAC keys are often shared across exception levels. Apple, however, implemented a system where the hardware differentiates between user-space and kernel-space signing. They achieved this without significant software overhead by using custom hardware logic that they refer to as "Dark Magic."

This logic ensures that a pointer signed in user-space cannot be used to hijack control flow in the kernel, even if the attacker manages to craft a valid-looking signature. The hardware effectively forces a different context for the signing operation. For a pentester, this means that your traditional "write-what-where" primitives are no longer sufficient. You need to find a way to leak the specific key or find a gadget that allows you to sign pointers within the target domain.

Practical Exploitation and Testing

During an engagement, you will likely encounter these protections when you attempt to overwrite a function pointer. If you simply overwrite a pointer with a raw address, the autia instruction will detect an invalid signature and trigger a kernel panic. To bypass this, you need to find a way to sign your payload.

If you have a primitive that allows you to read and write memory, you should look for existing signed pointers in the kernel and attempt to reuse them. Alternatively, if you can find a "signing gadget"—a piece of code that performs a pacia operation on attacker-controlled data—you can use that to sign your own pointers. The key is to identify which PAC key is being used for the specific pointer you are targeting. You can use Ghidra to perform static analysis on the kernel binary to locate these signing gadgets.

Defensive Considerations

For defenders, the takeaway is that hardware-backed security is not a silver bullet. While PAC makes exploitation significantly more difficult, it does not eliminate the underlying memory corruption vulnerabilities. The most effective defense remains rigorous input validation and memory safety. If you are managing a fleet of M1-based devices, ensure that your kernel is patched against known bypasses like CVE-2023-32424.

The complexity of Apple’s PAC implementation shows that proprietary hardware security features are often just as complex as the software they protect. As researchers, we need to continue pushing into these undocumented areas. The next time you are looking at a kernel crash on an M1 device, don't just assume it's a bad pointer. Start digging into the register state and ask yourself what the hardware is doing behind the scenes. The answers are there, hidden in the silicon.