Okay, here's a summary of the provided transcript in the requested format:
Reverse Engineering Apple's USBC Controller
0:00-0:03 Introduction: The talk will cover hardware/firmware reverse engineering, side-channel analysis, fault injection, and gaining code execution on a custom chip, specifically Apple’s new USBC controller.
0:03-0:11 Speaker Introduction: Thomas Roth, a hardware/firmware security researcher and co-founder of Hexio.
0:11-0:17 Acknowledgments: Credits various individuals and teams for their prior work.
0:17-0:30 Background on Lightning: Older iPhones used a Lightning connector which provided charging, USB, video/audio, JTAG, and the sdq protocol for debugging.
0:30-0:40 Tamarind Cable: An open-source cable (Tamarind) was developed to access lightning buses for ~$10. Apple moved to USBC, rendering this obsolete.
0:40-0:56 Tamarind C: A new PCB was created (Tamarind C) to access the USB-C bus on the iPhone 15, enabling sideband use pins to do UART, SWD, and other internal buses such as SPMI.
0:56-1:01 Ace Controllers: The older lightning iPhones used the Triar/Hydra chip to manage debugging access. Newer iPhones with USBC use a chip called the ace3.
1:01-1:10 Ace2: The ace3's predecessor was ace2, a Thunderbolt/USB-C controller found in older MacBooks. The speaker mentions that the ace2 chip is a re-branded Texas Instrument chip.
1:10-1:18 Ace3 on iPhone 15: The ace3 sits between the main processor and the USB-C port, handling power delivery, charging, and vendor-defined messages (VDM) to reconfigure the port.
1:18-1:20 Port DFU: The iPhone 15 when plugged into a computer in DFU mode, it first enters "port dfu" which is a full USB stack running on the charging controller.
1:20-1:30 Research Goals: The speaker aims to access the firmware of the ace3 to see what commands are present and the potential for an exploit on the USB controller itself, to potentially gain persistence outside of the main processor.
1:30-1:45 Ace2 Data Sheet: The speaker was able to get a data sheet for the ace2, since it was just a relabeled Texas Instrument part. He had to dump the firmware from a MacBook of his own. The speaker discovered commands like memory read, memory write which could prove useful.
1:45-1:57 Apple HPM bus: Commands are sent to the ace2 via the Apple HPM bus, which is an API that talks over I2C. User space tools exist to interact with the controller.
1:57-2:01 Ace Tool: A tool called Ace Tool is developed based on Thunderbolt Patcher to communicate with the Ace chips and send commands.
2:01-2:10 SPI Flash: The ace2 has external flash containing patches to the read-only memory (ROM) of the chip. These patches make reversing difficult since each function goes to a Segway, and then a list to check for the patch, which complicates cross-references.
2:10-2:15 Firmware Flasher: The tool "USBC firmware flasher" exists on macOS to flash the chips. Updates are protected with RSA-3072, but there is no secure boot for code execution, meaning that code can run once flashed.
2:15-2:27 Software SWD via GPIO: Instead of using JTAG, he identifies GPIO pins from the main processor that control the debug port of the ace2 and uses these to bitbang SWD.
2:27-2:40 Kernel Tooling: He used a kernel extension sigas IO kernel read write to control the pins from user space. A tool is built to dump and debug the ace2.
2:40-2:50 Taming Kernel: An open-source OpenOCD driver is built (Taming Kernel) that allows bitbanging SWD on the Apple SOC's GPIO.
2:50-3:00 Ace2 Backdooring: It's now possible to back door the ace2 by patching the external flash, allowing for persistence across reboots, using the existing Apple tools.
3:00-3:10 Ace3 on MacBook Pro: The ace3 chip is also found on the new M3 MacBooks, and it is also a TI part. The main processor can debug it via SWD, but there is no public information on the part, and unlike the ace2, it is not re-branded and therefore considered a blackbox.
3:10-3:20 MacBook Pro vs iPhone: MacBook hardware is preferred for research due to debug ports and test points. iPhone hardware is more compact and harder to interact with.
3:20-3:30 Ace3 Updater: The ace3 uses a new “lip ace3” updater instead of the USBC firmware flasher, and they are personalized per machine, which complicates the situation.
3:30-3:40 GPIO SWD on Ace3: The speaker tries GPIO SWD on the ace3 similar to the ace2 but the schematics are unknown and it requires brute force which did not work.
3:40-3:50 Physical Debug on Ace3: Physical debug port pins on the ace3 are probed, but the debug port is disabled.
3:50-4:04 Flash Dump on Ace3: The flash is dumped, though this requires a lot of precision, the resulting dump contains only patches. The speaker discovers high entropy regions, indicating encryption keys. Attempts to modify the flash and boot it failed, though the computer still booted afterwards.
4:04-4:10 Multiple Ace3 Chips: Different Ace3 chips in the MacBook run different firmware and are personalized, meaning that the firmware of one chip can not be transplanted to another.
4:10-4:20 Attempted Attacks: Attempts to gain code execution through GPIO SWD, physical SWD, flash modification, fuzzing failed.
4:20-4:40 Fault Injection: The speaker resorts to fault injection, using EMFI to induce current at a precise time and location on the chip to skip instructions. A voltage drop is not chosen since it is more complex to implement in the design.
4:40-4:50 EMFI setup: An EMFI setup was created with a low-cost coil which is controlled by an SDR to measure electromagnetic radiation of the chip while booting. The speaker does not use a proper CNC setup, but a very large probe.
4:50-5:00 Side Channel Timing: A side channel was created to determine the timing of when the modified flash contents would fail by using a trigger signal from the chip select line of the flash.
5:00-5:10 Hacker F: A hacker F is used as a trigger input, and the proper firmware had to be installed for it to work. This was used for aligning the recordings for the side channel.
5:10-5:20 Signal Analysis: Once aligned, the signals with the valid firmware are compared to the modified firmware. The difference appears at the beginning of the recording, and the correct crc's on the firmware move this difference further in time.
5:20-5:30 EMFI Glitch: The chip shouter was used as the EMFI device. The MacBook started glitching and having issues with the various components since it was running the exploit on itself.
5:30-5:40 Test Version String Glitch: The speaker tries to change the version string and using a modified firmware. After many tries a successful glitch was performed, as indicated through the status of the controller indicating a successful boot.
5:40-5:50 Backdooring: The speaker wanted to do more than just a simple glitch and the goal was to now do arbitrary code execution.
5:50-6:05 Code Reuse: An existing memory read function from the ace2 was found with the appropriate functionality. The assembly for this is copied into a patch, allowing the speaker to read from memory by calling the USB W command handler.
6:05-6:10 Memory Read: With the use of the previously patched USB W command, the speaker is able to read memory from the ace3 and is able to verify that he has control.
6:10-6:20 Dumping Memory: The speaker can now read arbitrary memory, but since there is a limit on the read bytes, this had to be performed multiple times to dump the complete memory.
6:20-6:30 Summary: Code execution is gained on unknown silicon, with a mixture of persistence and luck, allowing for full control. The research was not about being incredibly smart, but rather the persistence to solve the problem.
6:30-6:40 Self-Contained Setup: The speaker ported his setup onto the chip shouter for ~60, bringing the cost to do this much cheaper.
6:40-6:50 Emulator: The ace3 has been emulated, and research can now commence.
6:50-7:00 Q&A: Audience questions regarding whether the MacBook was returned, the software stack used and the type of EMFI pulse used.
7:00-7:05 Hobby: The speaker states that the research is a healthy mix of hobby and a job. He then offers fault injection setups to people interested.