ACE: Apple Type-C Port Controller Secrets | Part 1

42 captures<br>30 Dec 2020 - 04 Sep 2025

Sep<br>OCT<br>Nov

23

2020<br>2021<br>2022

success

fail

About this capture

COLLECTED BY

Collection: Common Crawl

Web crawl data from Common Crawl.

TIMESTAMPS

The Wayback Machine - https://web.archive.org/web/20211023034503/https://blog.t8012.dev/ace-part-1/

Introduction<br>After our team successfully ported the checkm8 exploit to the AppleSilicon T2 chip, we began exploring methods for closed-case hardware debugging, or CCD, as found on other iDevices. On such devices, the Serial Wire Debug protocol can be muxed out across the Lightning connector, which we presumed was replicable across the USB Type-C connector. With some assistance from easily obtainable schematics for our MacBook models, we have determined that muxing is handled by an Apple/TI co-designed USB Type-C Port Controller, colloquially known as "ACE". The following details our findings and the vendor defined protocol, termed AppleVDM, Apple has implemented over the USB Power Delivery standard for muxing out various internal peripherals.<br>A member of our team, @h0m3us3r has dumped the ACE firmware by attaching a SWD probe onto exposed test points on the logic board of a MacBook Pro. Thanks to this we were able to obtain both the ROM and the firmware payload patch applied over it and discover that the ACE chip contains a Cortex-M0 r0p1 ARM core. Most of the static analysis was later conducted by @mrarm.<br>Connecting to target via SWD<br>Found SW-DP with ID 0x0BC11477<br>DPIDR: 0x0BC11477<br>Scanning AP map to find all available APs<br>AP[1]: Stopped AP scan as end of AP map has been reached<br>AP[0]: AHB-AP (IDR: 0x04770031)<br>Iterating through AP map to find AHB-AP to use<br>AP[0]: Core found<br>AP[0]: AHB-AP ROM base: 0xE00FF000<br>CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)<br>Found Cortex-M0 r0p1, Little endian.<br>FPUnit: 4 code (BP) slots and 0 literal slots<br>CoreSight components:<br>ROMTbl[0] @ E00FF000<br>ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS<br>ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT<br>ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB<br>Cortex-M0 identified.

Segger J-Link Probe output when attached to ACE2 (CD3217).ACE Overview<br>To better understand the inner-workings of ACE, we began looking for identifying information within the dumped firmware. We found the string CD3217   HW0022 FW002.032.00 ZACE2-J213 and upon searching CD3217 online resulted in the similar TI TPS65986. Based on how similar the functional description of the aforementioned TI USB Type-C Controller is to ACE, and considering that TI co-designed ACE with Apple, it was reasonable to assume most of the technical information applies to ACE.<br>TI's USB Type-C Controllers expose an I²C interface for host management, for which we found the excellent Host Interface Technical Reference Manual, documenting a multitude of public I²C registers and commands.<br>TPS65986 Functional Block DiagramThe primary component of focus based on the above block diagram is the digital core, which communicates directly with the host and runs the firmware we dumped previously. As mentioned, the core is based on a Cortex-M0 r0p1. Unfortunately, we were unable to create a complete memory map with peripherals as TI does not release public information on the core itself. Regardless, we have the basic memory layout as follows:<br>Since we weren't sure whether the code for muxing out things lives in the ACE or somewhere else (there are registers for receiving vendor messages and processing them on another chip), we also investigated the firmware of chips that can directly communicate with the ACE, the SMC, part of T2 SoC, and the Thunderbolt controller. While we obtained and analyzed the I2C usages in the SMC firmware and found no suspicious code whatsoever, we had issues with analyzing the Thunderbolt controller firmware and decided to only reverse engineer it as a last resort. We initially thought that the only way that we could talk with the ACE from Mac OS (Intel) was by modifying the SMC firmware to relay commands to the ACE. While we have successfully managed to edit the SMC firmware and talk with the ACE, it turned out that this effort wasn't needed. Later we stumbled upon the following project: https://github.com/osy/ThunderboltPatcher, which uses the AppleHPM kext in order to communicate with the ACE.<br>The AppleHPM KEXT allows a user space program running as root to read and write ACE registers. It also has several interesting methods that seem to be intended for reading and writing registers on ACEs connected using a USB Type-C cable to the DUT. Unfortunately, while we tried invoking them, we didn't manage to get these methods working, suggesting that either they have been disabled on production hardware or need some more preparation work in order to work. We also discovered that there exists an EFI mode firmware updater for the ACE called HPMUtil.efi, which we also partially reverse engineered. There seems...