Skip to main content

iOS Architecture - Introduction

iOS runs exclusively on Apple's own silicon. Understanding the hardware is not optional for a pentester, nearly every privilege boundary, from the app sandbox to the Secure Enclave, is enforced at the silicon level. A jailbreak, at its core, is an attack that subverts the chain of trust baked into this hardware.

iOS Architecture

AArch64 and the CPU​

  • All modern iPhones and iPads use ARM64 / AArch64 CPUs.
  • AArch64 is a 64-bit RISC ISA with 31 general-purpose registers, a large instruction set, and hardware-accelerated cryptography (AES, SHA, etc.).
  • Apple's CPUs are customized ARM cores (e.g. the P-core / E-core split in the A15 and later), not off-the-shelf Cortex designs.
  • The ISA matters for exploit work: gadget hunting, ROP/JOP chains, and the PAC (Pointer Authentication Code) and BTI (Branch Target Identification) mitigations you will fight against on modern devices.

A-Series / M-Series Chips​

Apple's SoCs integrate several security-relevant blocks into one die:

  • CPU cores: general-purpose application cores.
  • GPU: used by the graphics stack and increasingly for compute.
  • Neural Engine: powers Core ML / Face ID inference.
  • Secure Enclave: a separate coprocessor (more below).
  • I/O and media blocks: image signal processor, audio, storage controller.

From a testing perspective you mostly care that these blocks are partitioned. A vulnerability in one should not automatically give you code execution in the kernel or in the Secure Enclave.

Secure Enclave​

The Secure Enclave Processor (SEP) is a physically separate CPU that runs its own firmware (SEPOS) and has its own boot process.

  • Holds the device's root secrets: the UID key, hardware keys for Keychain and Data Protection.
  • Never exposed to the application CPU, it communicates over a mailbox interface only.
  • Handles biometric matching for Face ID / Touch ID and performs signature operations.
  • An attacker with kernel code execution still cannot directly read SEP memory; they would need a separate SEP exploit.

This is why, in a real iOS engagement, you should assume that data you want is already accessible to the running apps, not that you will break the SEP. You won't.

The Boot Chain​

Boot is a strict chain of trust: each stage verifies the signature of the next before executing it.

  1. Boot ROM (SecureROM): immutable, burned into the chip. Runs first on reset. Verifies iBoot using the fused device key and Apple's root certificate. The SoC is only "clean" at this point.
  2. LLB + iBoot: the low-level bootloader and the main bootloader. iBoot verifies the kernel image (kernelcache) and its patch list.
  3. Kernel (XNU): once the kernel is running, it verifies and mounts the signed system volume (read-only on modern devices).
  4. Userland: launchd starts services, and each app's code signature is verified by amfid at execution time.

Why the boot chain matters for testing​

  • Jailbreaks target the boot chain. Untethered, semi-tethered, and tethered jailbreaks are distinguished precisely by how much of the boot chain they need to break and re-break.
  • Exploits that only land in userland give you a sandbox escape at best. To get a persistent jailbreak you typically need a kernel or even a boot chain bug (e.g. an iBoot or SecureROM vulnerability).
  • Checkm8 (SecureROM, older A7–A11 devices) and checkra1n are archetypal examples: they exploit the immutable BootROM, which cannot be patched by Apple, making the device permanently "jailbreakable."
  • The SEP is out of band of the main boot chain and has its own separate chain of trust, a fact exploit developers lean on for persistence.

Notes​

  • The hardware enforces isolation: app CPU, SEP, GPU, and peripheral buses are separated.
  • Full access (a real "rooted" state) almost always requires chaining a userland bug with a kernel bug, and true persistence usually requires a boot-chain exploit.
  • For app pentesting, you rarely need a jailbreak, the simulator, a non-jailbroken device with the app sandbox, and the debugger give you most of what you need. You only reach for jailbroken devices when you need to inspect the filesystem, tamper with other processes, or bypass codesigning.