ACE up the sleeve: (38c3)

With the iPhone 15 & iPhone 15 Pro, Apple switched their iPhone to USB-C and introduced a new USB-C controller: The ACE3, a powerful, very custom, TI manufactured chip. But the ACE3 does more than just handle USB power delivery: It's a full microcontroller running a full USB stack connected to some of the internal busses of the device, and is responsible for providing access to JTAG of the application processor, the internal SPMI bus, etc. We start by investigating the previous variant of the ACE3: The ACE2. It's based on a known chip, and using a combination of a hardware vulnerability in MacBooks and a custom macOS kernel module we managed to persistently backdoor it - even surviving full-system restores. On the ACE3 however, Apple upped their game: Firmware updates are personalized to the device, debug interfaces seem to be disabled, and the external flash is validated and does not contain all the firmware. However using a combination of reverse-engineering, RF side-channel analysis and electro-magnetic fault-injection it was possible to gain code-execution on the ACE3 - allowing dumping of the ROM, and analysis of the functionality. This talk will show how to use a combination of hardware, firmware, reverse-engineering, side-channel analysis and fault-injection to gain code-execution on a completely custom chip, enabling further security research on an under-explored but security relevant part of Apple devices. It will also demonstrate attacks on the predecessor of the ACE3. The Lightning and USB-C ports on Apple devices have been well known to "hide" secrets beyond just exposing USB and charging functionality: For example last year at CCC, we showed how we can gain access to JTAG on the iPhone 15 using a custom-build PCB ("Tamarin-C"). All this is handled on new Apple devices using a chip called the ACE3: While previous Apple USB-C devices used a slightly modified Texas Instruments TPS65986, the ACE3 is significantly more custom - and significantly more powerful: It runs a full USB stack (implementing the "Port DFU" mode) and is connected to different internal busses of the phone, making it an interesting target for persistent firmware-implant style attacks. Imagine modifying/backdooring the USB-C controller in a way where it will automatically compromise the main operating-system - essentially making (potential) USB jailbreaks untethered. But how do we approach a custom chip without any documentation and which has its firmware in an internal ROM? With the ACE2 it was possible to dump the integrated ROM using JTAG/SWD, which allowed us to identify & exploit a hardware (on all MacBooks except the M3 Pro & Max) vulnerability to persistently modify the ACE2. However the ACE3 is different: We don't even have a pinout for the chip (which has 120 pins), JTAG seems disabled, and the external flash does not even contain the actual firmware, but only tiny patches for the actual firmware in the chip - and the contents are cryptographically validated! After attempting different software avenues of attacking the ACE3 (including building a small fuzzer and finding a timing side-channel attack to enumerate available commands) with no success, and seeing that the ACE3 implements firmware personalization, it was time for the ace up the sleeve: Hardware attacks. After reverse-engineering the external flash layout (including CRCs) and finding that the flash is cryptographically verified (and that a secure-boot bypass vulnerability we found on the ACE2 does not work on the ACE3), the idea was born to use electro-magnetic measurements to determine when during the startup of the chip the validation fails. And by triggering a software-defined radio on the activity of the external flash, it was possible to gather a very precise point in time where the check is being done - perfect to try some fault injection! Unfortunately no good isolated power-supply for the ACE3 could be found to use with voltage fault injection, and so instead I decided to try electro-magnetic fault injection: By "blasting" the chip with strong electro-magnetic fields at just the point in time determined during the EM measurement I was hoping to be able to bypass the check - and after hours of trying, debugging, moving the injection tip, more debugging, and more time, it eventually succeeded: A modified patchset could be booted into the CPU. But … How do we make sure our "patch" actually gets executed? How do we dump the ROM without having any IO? And how do we even know what (in the 32-bit address space of the processor) we should dump? And can we implement the attack without thousands of dollars of hardware? We will look at all of these things during the talk. Itemized progression draft: - Introduction - whoami - History of Lightning/USB-C secrets on Apple devices - A quick look at ACE2 - Technical details & usage - Dumping the ACE2 - Analyzing the MacBook hardware - Building a kernel-level SWD probe to hack the ACE2 without opening the device - Disabling the secure-update functionality of the ACE3 - The ACE3 - iPhone 15 vs iPhone 16 vs MacBook with M3 Pro/Max - No matching Texas Instruments chip, no public documentation, no schematics - Software exploration - Apple's HPM bus - Discovering a timing-sidechannel for supported commands - Hardware exploration - Trying to find SWD (with which I think I succeeded - however it seems to be disabled) - Dumping the external flash - Flash exploration - No full firmware, just patches - Some CRCs found, but also firmware personalization (IM4M) - Seems to be cryptographically verified - Attempting to flash modified dumps (with fixed CRCs) unsuccessfully - Electro-magnetic measurement - Setup: HackRF + small inductor as antenna - Building a reliable Trigger signal for the SDR: Flash chip-select line - Compare when the chip-boot fails with correct and invalid CRCs in the flash - Identified point in time where the boot seems to abort (Screenshots for this can be found in the attachments) - Fault injection - Quick primer: Voltage FI vs EMFI - Setup: ChipSHOUTER on MacBook, ChipWhisperer Husky for trigger-generation, software to reboot the chip & arm the glitcher - Experimenting to determine correct parameters by attempting to fail the boot with correct firmware - The actual attack - Flash modified patchset (Changed version-string) - Reboot chip - Glitch chip at the right time - Test for success, repeat - Success - but what now? - Getting actual code-execution through the attack by overwriting a patched command - Using HPM bus to execute the command and dump 64 bytes at a time - A look at the dumped firmware - Reducing the attack-costs: Performing the attack with