Inside the Apple T2
Analysts investigate attack surfaces and defenses concerning Inside the Apple T2.
Summary
## Overview At a security conference talk presented by Duo Labs researchers Michael Davidoff and Jeremy Erickson, the security architecture, hardware role, and firmware mechanisms of Apple’s T2 chip were examined. The T2 succeeds the T1 (which powered the Touch Bar and Touch ID) and serves as an embedded controller—analogous to a baseboard management controller (BMC) without a remote management stack.
The chip is primarily an ARM64 processor based on Apple's A10 design, operating alongside a Secure Enclave Processor (SEP) for encryption keys and Touch ID, an integrated flash controller that directly manages raw SSD flash storage (handling wear leveling and block allocation internally), and memory-mapped storage for its operating system and UEFI firmware. Running "BridgeOS" (a derivative of watchOS), the T2 functions as a privileged, DMA-capable entity that orchestrates power sequencing, thermal management, hardware disconnects (microphone/camera) to defeat malware, and password-derived key mixing to throttle offline decryption attacks.
## Firmware Extraction & Analysis Methodology BridgeOS and its accompanying firmware components can be acquired from Apple’s software update catalog or local system caches. The researchers outlined tools and methods to parse these update bundles: - **Bundle Composition:** Decompressed update bundles contain a root filesystem, model-specific kernel caches, and signed "golden" UEFI firmware images within the `/boot/firmware` directory. The encrypted iBoot and SEP images are packaged as well. - **Model Identifiers:** Firmwares correspond to internal device names, such as `J137` (iMac Pro), `J680` (MacBook Pro), `J174`, `J140K`, and candidate identifiers `J780` (Mac Pro) and `J132` (MacBook Air). - **Tooling:** Jonathan Levin’s toolset is central to extraction. The `image4` tool extracts raw payloads from Image4 archives; the `joker` tool decodes kernel caches for analysis in IDA Pro (facilitated by the IDA KernelCache extension for I/O Kit types); and the `ota` tool decompresses individual segments of the base BridgeOS filesystem.
## Secure Boot & The Enhanced SPI (eSPI) Architecture Traditionally, x86 motherboards attach the chipset to an external SPI flash chip holding UEFI firmware, leaving the initial execution phase (the security phase at the system reset vector) vulnerable to hardware-clipping attacks (e.g., "evil maid" scenarios) or software overwrites.
To eliminate vulnerable external SPI flash chips, Apple utilizes the Enhanced Serial Peripheral Interface (eSPI) bus with Intel's "Slave Attached Flash" feature. Although typically restricted to Intel Xeon server platforms, Apple partnered with Intel to enable Slave Attached Flash on consumer lines such as MacBook Pros. Under this architecture: - The motherboard chipset connects directly to the T2 via eSPI rather than an external flash chip. - The T2 serves as the sole arbiter of all flash access, redirecting read and write operations from the chipset to internal T2 storage.
## Early Boot Flow & UEFI Provisioning Boot execution begins in "early boot" well before the host power button is pressed: 1. **Hardware Root of Trust:** An immutable, die-hardwired masked ROM verifies the signature of the iBoot bootloader against an Apple Root CA located directly in the ROM. 2. **OS Initialization:** iBoot cryptographically verifies and launches the BridgeOS kernel, which starts PID 0 (`launchd`) and spawns various daemons, including the `mac_efi_util` utility. 3. **Firmware Loading:** `mac_efi_util` checks the device tree for Slave Attached Flash capability, reads a signed Image4 UEFI binary, and marshals it to the `AppleEFIManager` kernel extension (`AppleFirmwareUpdate.kext` checks cryptographic signatures). 4. **Hot-Patching:** `AppleEFIManager` checks T2 production mode fuses and boot arguments, writing one of two 64-bit indicator values directly into the loaded UEFI image. This modification effectively invalidates the original signature at the point of provisioning. 5. **eSPI DMA Configuration:** The manager configures the internal eSPI Slave Attached Flash DMA engine via memory-mapped registers, redirecting host read and write operations (including runtime state saved by low-level subsystems like Intel ME) to internal T2 storage.
Related talks
Black Hat·30 min
Analysts investigate attack surfaces and defenses concerning Jailbreaking Apple Watch.
Black Hat·4 min
Engineers explore architecture and security mechanisms for Welcome Video.


