Security
ACE up the sleeve: Hacking into Apple's new USB-C Controller
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
Additional information
| Live Stream | https://streaming.media.ccc.de/38c3/glitch |
|---|---|
| Type | Talk |
| Language | English |
More sessions
| 12/27/24 |
In wenigen Wochen werden die Gesundheitsdaten von rund 73 Millionen in Deutschland Krankenversicherten ohne deren Zutun über Praxis- und Krankenhausgrenzen hinweg zentral in einer Akte zusammengeführt - in der [„elektronischen Patientenakte für alle“](https://www.bundesgesundheitsministerium.de/themen/digitalisierung/elektronische-patientenakte/epa-fuer-alle.html). Fortsetzung von 36C3 - [„Hacker hin oder her“: Die elektronische Patientenakte ...
|
| 12/27/24 |
We present fatal security flaws in the HALFLOOP-24 encryption algorithm, which is used by the US military and NATO. HALFLOOP-24 was meant to safeguard the automatic link establishment protocol in high frequency radio, but our research demonstrates that merely two hours of intercepted radio traffic are sufficient to recover the secret key. In the talk, we start with the fundamentals of symmetric key cryptography before going into the details of high frequency radio, HALFLOOP-24, and the ...
|
| 12/27/24 |
PHUZZ is a framework for Coverage-Guided Fuzzing of PHP Web Applications Fuzz testing is an automated approach to vulnerability discovery. Coverage-guided fuzz testing has been extensively researched in binary applications and the domain of memory corruption vulnerabilities. However, many web vulnerability scanners still rely on black-box fuzzing (e.g., predefined sets of payloads or basic heuristics), which severely limits their vulnerability detection capabilities. In this talk, we present our ...
|
| 12/27/24 |
The Chipolo ONE is a Bluetooth tracker built around the Dialog (now Renesas) DA14580 chip. This talk will present the research made on this device, from extracting the firmware from the locked down chip using fault injection up to getting remote code execution over Bluetooth. The talk will also present the disclosure process and how the vendor reacted to an unpatchable vulnerability on their product.
|
| 12/27/24 |
Digital identity solutions, such as proposed through the EU's eIDAS regulation, are reshaping the way users authenticate online. In this talk, we will review the currently proposed technical designs, the impact such systems will have, and provide an outlook on how techniques from modern cryptography can help to improve security and privacy.
|
| 12/27/24 |
Bewegungsdaten von 800.000 E-Autos sowie Kontaktinformationen zu den Besitzern standen ungeschützt im Netz. Sichtbar war, wer wann zu Hause parkt, beim BND oder vor dem Bordell.
|
| 12/27/24 |
Raspberry Pi's RP2350 microcontroller introduced a multitude of new hardware security features over the RP2040, and included a Hacking Challenge which began at DEF CON to encourage researchers to find bugs. The challenge has been defeated and the chip is indeed vulnerable (in at least one way). This talk will cover the process of discovering this vulnerability, the method of exploiting it, and avenues for deducing more about the relevant low-level hardware behavior.
|
