Hardware/Firmware Reverse Engineering on a Custom Apple Chip
0:00 Introduction: The talk focuses on reverse engineering, side-channel analysis, and fault injection to gain code execution on a custom Apple chip. The specific target is the USB-C controller (Ace3) in newer Apple devices.
0:58 Background: The speaker, Thomas Roth, discusses previous research into the lightning connector and a custom cable, "Tamarind," for accessing internal buses. Apple's switch to USB-C on the iPhone 15 rendered this research less immediately applicable but provided a new avenue of investigation.
2:07 Lightning Connector Era: Older iPhones used the lightning connector, which allowed for charging, USB, video, audio, JTAG debugging, and a protocol called SDQ.
2:30 Tamarind Cable: An open-source cable was developed to access these buses for about $10, making it easier for people to explore than the previous $700-$800 hardware requirement.
2:50 USB-C Transition: Apple's move to USB-C with the iPhone 15 effectively invalidated existing work on the lightning connector.
3:18 Tamarind C: A year ago, the speaker released "Tamarind C", a PCB for accessing the USB-C bus on the iPhone 15 to control its various pins and access buses like UART and SWD for debugging.
4:21 Ace Chip: Older iPhones used the "Triar" chip for controlling the lightning connector and pinout configuration, while the newer USB-C iPhones use the "Ace3" chip to do the same.
4:41 Ace3: The Ace3 chip is larger than its predecessors and is the focus of the research, with a similar chip called Ace2 found in older MacBooks.
5:58 Ace3 Functionality: On the iPhone 15, Ace3 sits between the main processor and the USB-C port, handling power delivery, charging setup, and vendor-defined messages (VDM). VDM commands are used by Apple to reconfigure the USB-C port for various functions like SWD, UART, and USB access.
7:05 DFU Mode: When an iPhone 15 is put into DFU mode (firmware upgrade mode) it goes into a mode called "port DFU", where a full USB stack runs on the charging controller and after exiting the mode, it goes to actual DFU mode of the SSoC. This was a point of curiosity as it was theorized that an exploit could be run directly on the USB-PD controller.
8:00 Getting the Firmware: The Ace3 chip was a complete black box at first without schematics or a pinout, and no public data. The speaker pivoted to researching the Ace2, as it was more publicly documented and is likely an evolutionary step for Apple.
8:16 Ace2: The Ace2 chip is found in older MacBooks, is a rebranded Texas Instruments (TI) chip (TPS65986). It has debugging ports enabled and its firmware was previously dumped by the t812 team. The speaker had to dump his own firware due to legal issues, and then reversed it.
10:07 Ace2 Command Handler: The speaker found that the A2 has a command handler for special commands, including privileged ones like "m r" and "m w" for memory read and write, which are disabled in production devices.
10:30 Apple HPM Bus: Communication to the A2 happens through the Apple HPM bus (host port microcontroller), which uses an I2C interface.
11:04 4CC Commands: A simplified protocol using 4 character commands is used to send instructions to the Ace chip.
11:21 Ace Tool: The speaker developed "Ace Tool" based on Thunderbolt Patcher to communicate with these chips. It allows sending commands and reading status registers to track chip states.
11:58 Ace2 SPI Flash: The external SPI flash on the Ace2 contains patches for the read-only memory. The complex nature of it makes reversing challenging since each function goes through a layer of indirection.
12:50 Firmware Updates: The Ace2 chip receives firmware updates with RSA 3072 signatures. However, the signatures are only checked during updates, enabling persistence after successful code execution.
14:19 Debugging Via GPIO: The speaker discovered that the SSoC had a GPIO line going to the programming port of the Ace2, allowing him to bitbang SWD to it using software, allowing him to dump the firmware without physically modifying the device.
15:52 Ace2 Dump: A tool called "ace2 dump" was created to access the firmware of the Ace2 using a userspace application which uses the IO kernel R/W extension.
16:16 Taming Kernel: An open-OCD driver called "Taming Kernel" was also developed to bitbang SWD on the Apple SSoC using GPIOs.
17:30 Ace3 Challenge: The Ace3 is also made by Texas Instruments and has no public information at the time. It uses a different upgrade mechanism than the Ace2, which is also personalized per machine.
18:57 Gpio Swd on Ace3: The speaker attempts to use the same GPIO-based SWD attack used on Ace2 to dump the firmware on Ace3. After brute-forcing the correct GPIOs, he found the debug pins with a logic analyzer. The debug port was disabled.
20:52 Ace3 Flash Dump: The speaker proceeded to dump the SPI flash from the Ace3, but its contents were once again patches and not the full firmware.
21:38 CRC and Boot: By manipulating a bit and its CRC, the speaker was able to check the location in the boot sequence the check was performed.
22:39 Fault Injection: Due to the lack of access, the speaker turned to fault injection to introduce faults to the chip to cause undefined behavior.
24:50 EMFI: Instead of voltage fault injection, electromagnetic fault injection (EMFI) was chosen as it allows injecting precise current with less complex setups.
26:06 Side Channel Analysis: The speaker attempted to determine the precise timing for fault injection using side-channel analysis with a cheap SDR and EMFI coil to measure electromagnetic radiation from the chip and determine when to inject.
26:50 HackRF Trigger: The HackRF was used to record data, which was triggered by a chip select line low. The issue of the trigger not working in later versions required him to downgrade it.
28:20 Correlating Signal: It was found that the electromagnetic signal correlated with the flashing of the memory chip.
30:26 EMFI Location: The speaker used the largest probe available as an EMFI probe and a Chip Whisperer for the triggering. The location of the fault injection is critical.
31:28 Version Glitch: The speaker targeted a version string in the Ace3 firmware. They successfully glitched the chip, changing the version number, which was verified by the "Ace Tool", and thereby gaining code execution. The speaker used the status of the chip to confirm if a glitch was succesful.
33:27 Code Execution: The speaker was able to achieve code execution in the Ace3 through fault injection, and verified this by changing the version string.
33:53 USB W command handler: The speaker identified the USB W command handler in the Ace3 code, and based on what it did in Ace2, they theorized they could use it as a way to get data back.
35:00 Memory Read Payload: Leveraging the already present "m r m w" read/write functions from the A2, the speaker created a custom read payload that was injected into the A3 to extract memory.
36:05 Stack Pointer Test: After sending an address to the custom payload and receiving data, the data was reversed to find the stack pointer address, verifying that data was being properly read.
36:24 Memory Dump: It was then possible to dump memory using the custom payload. Due to the slow nature, this took a significant amount of time.
37:07 Conclusion: The speaker demonstrated code execution on undocumented silicon using fault injection and side-channel analysis.
37:36 Portable Fault Injection: The speaker is working to port their setup to a cheaper "Chip Shouter PEM" for easier access.