ACE：Apple Type-C端口控制器的秘密

在我们的团队成功将checkm8漏洞移植到AppleSilicon T2芯片后，我们开始探索在其他iDevices上发现的封闭式硬件调试或CCD的方法。在此类设备上，可以通过Lightning连接器将串行线调试协议多路复用，我们认为该协议可在USB Type-C连接器上复制。在我们的MacBook型号易于获得的原理图的帮助下，我们确定混合是由Apple / TI共同设计的USB Type-C端口控制器处理的，俗称＆＃34; ACE＆＃34;。以下详细介绍了我们的发现以及Apple所定义的供应商定义的协议AppleVDM，该协议已通过USB Power Delivery标准实现，用于混合各种内部外围设备。

我们团队的成员@ h0m3us3r通过将SWD探针连接到MacBook Pro逻辑板上的裸露测试点上来丢弃ACE固件。由于这一点，我们能够获得ROM和应用在其上的固件有效负载补丁，并发现ACE芯片包含Cortex-M0 r0p1 ARM内核。大部分静态分析随后由@mrarm进行。

通过ID为0x0BC11477DPIDR的SWDFound SW-DP连接到目标：0x0BC11477扫描AP映射以查找所有可用的AP AP [1]：到达AP映射结束时已停止AP扫描AP [0]：AHB-AP（IDR：0x04770031）通过AP进行迭代映射以找到要使用AP [0]的AHB-AP：核心foundAP [0]：AHB-AP ROM基址：0xE00FF000CPUID寄存器：0x410CC601。实施者代码：0x41（ARM）找到的Cortex-M0 r0p1，Little endian.FPUnit：4个代码（BP）插槽和0个立即数插槽CoreSight组件：ROMTbl [0] @ E00FF000ROMTbl [0] [0]：E000E000，CID：B105E00D，PID ：000BB008 SCSROMTbl [0] [1]：E0001000，CID：B105E00D，PID：000BB00A DWTROMTbl [0] [2]：E0002000，CID：B105E00D，PID：000BB00B FPBCortex-M0。

连接到ACE2（CD3217）时，Segger J-Link探针输出。为了更好地了解ACE的内部工作原理，我们开始在转储的固件中寻找标识信息。我们找到了字符串CD3217 HW0022 FW002.032.00 ZACE2-J213，并在网上搜索CD3217时得到了类似的TI TPS65986。基于上述TI USB Type-C控制器的功能描述与ACE的相似程度，并考虑到TI与Apple共同设计了ACE，因此可以合理地假设大多数技术信息都适用于ACE。

TI的USB Type-C控制器公开了用于主机管理的I²C接口，为此我们找到了出色的《主机接口技术参考手册》，其中记录了大量公共I²C寄存器和命令。

基于上面的框图，重点关注的主要部分是数字核心，它与主机直接通信并运行我们先前转储的固件。如前所述，核心基于Cortex-M0 r0p1。不幸的是，由于TI并未在内核本身上发布公共信息，因此我们无法与外围设备创建完整的内存映射。无论如何，我们的基本内存布局如下：

由于我们不确定用于混合处理内容的代码是驻留在ACE还是其他地方（有用于接收供应商消息并在另一芯片上处理它们的寄存器），因此我们还研究了可以直接与之通信的芯片的固件。 ACE，SMC，T2 SoC的一部分以及Thunderbolt控制器。虽然我们获得并分析了SMC固件中的I2C使用情况，但没有发现任何可疑代码，但在分析Thunderbolt控制器固件时遇到了问题，因此决定只能对其进行逆向工程。最初，我们认为可以与Mac OS（Intel）上的ACE进行通讯的唯一方法是修改SMC固件以将命令中继到ACE。虽然我们已经成功地编辑了SMC固件并与ACE进行了对话，但事实证明，不需要这样做。后来，我们偶然发现了以下项目：https://github.com/osy/ThunderboltPatcher，该项目使用AppleHPM kext与ACE通信。

AppleHPM KEXT允许以root用户身份运行的用户空间程序读取和写入ACE寄存器。它还有几种有趣的方法，这些方法似乎旨在读写使用USB Type-C电缆连接到DUT的ACE上的寄存器。不幸的是，当我们尝试调用它们时，我们并没有设法使这些方法起作用，这表明它们已在生产硬件上被禁用，或者需要更多准备工作才能起作用。我们还发现，存在用于ACE的EFI模式固件更新程序HPMUtil.efi，我们也对其进行了部分反向工程。根据硬件版本，似乎有几种更新ACE的方法。 EFI程序似乎也有一个参数，使其可以更新外部连接的ACE，但是至少对于最近的ACE而言，它似乎已损坏。我们从Mac（基于可用命令）获得的固件转储上唯一可行的更新途径似乎是在一些地方进行了硬编码，以便在本地ACE上运行命令。

ACE芯片至少有3个已知版本。根据我们可用的硬件，已知第一个变体ACE1将在2018年和较旧的T2机型中使用，第二个变体ACE2在2019年和较新的T2机型中使用，第三个变体将在2020年启用M1的笔记本电脑中使用。 ACE1和ACE2之间的软件更新方法差异很大。在撰写本文时，我们仅成功转储了一个ACE固件（ACE2），此处的所有分析均基于该版本。

告诉Mac从芯片中除USB以外的东西的逻辑通道将是USB PD，因为ACE与外部设备的主要通信媒介是USB PD，并且因为使用USB PD控制数据线是一种普遍的做法（请参阅：MIPI调试接口，以及有关从三星手机获取UART的本文：https：//ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2632162/bookchapter.pdf）。默认情况下，可以将此TI派生的控制器配置为支持某种MIPI调试模式（并且Apple ACE固件中也存在MIPI调试ID），但是正如我们稍后发现的那样，在Apple的配置中已将其禁用并且不能使用。因此，我们决定寻找ACE可以理解的其他“供应商定义的消息”。

在USB PD协议中，进入供应商模式首先要发送SVID（标准ID或供应商ID，通常是供应商的USB VID）和对象位置（将其视为供应商可以定义的子模式）。通过分析ACE固件，我们发现Apple SVID下至少有3个可能的对象位置，但是它们的可用性是动态的，默认情况下只有一个SVID和对象位置可用。例如，当连接Apple的充电器时使用该主要模式。我们不确定何时激活其他模式，并计划做进一步的工作来弄清楚其他模式的目的。

既然对进入模式的命令做出答复是合乎逻辑的，并且因为对没有上下文的嵌入式固件进行反向工程很困难，我们决定研究VDMs命令，该命令可用于发送VDM PD。信息。这样一来，我们就可以收集有关固件内部运行情况的重要信息，还可以找到一些发送带有Apple供应商ID的消息的功能。我们研究了其中的几种，其中一些确实与充电器使用的协议有关（我们不确定目的是什么；但是从看来，它只能用于读取充电器中的某些存储部分外部设备），但我们还发现另一过程涉及三种情况，其中两种情况以与Discover SVID VDM类似的方式回复了16位值（从特定内存区域的信息中创建）。复杂并处理了其他逻辑。我们对其进行了进一步调查，最终设法将其从控制器中清除掉。

VDMs命令的另一种可能用法是在AppleHPM KEXT和HPLUtil.efi程序中，该程序正在从外部连接的设备读取寄存器。由于我们没有对其进行太多关注，因为这不是我们的目标，并且我们的实验是失败的，因此我们将不在本文中对其进行描述。

请注意，由于还可以从ACE中复用SWD，因此进一步进行反向工程ACE模式就没有那么有趣了。您应该能够使用ACE的SWD来触发您选择的任何多路复用器选择，并直接与ACE可以访问的所有外围设备进行对话。

通过@ h0m3us3r的ROM和RAM存储器转储，我们开始将ACE固件加载到IDA中。重置处理程序地址位于0x00000004，可用于获取入口点的地址。

通过查找4个字符代码可以轻松找到命令表。寄存器表需要付出更多的努力，但也不难找到（因为存在一个字符串寄存器，因此可以找到引用它的内容）。与TI公开文档相比，实际上有更多的命令和寄存器可用，其中一些是Apple特有的附加功能。由于固件几乎没有任何字符串或调试信息，因此命令列表非常有帮助。

最初探索固件后，我们很快发现了被诅咒的蹦床，如下所示：

ROM：000266C2 _Command_HRST;数据XREF：ROM：命令→oROM：000266C2ROM：000266C2ROM：000266C2 PUSH {R4-R6，LR} ROM：000266C4 MOV R4，R1ROM：000266C6 MOV R5，R0ROM：000266C8 BL sub_E4ROM：000266CC LDR R0，= dword_20041040ROM R1，R4ROM：000266D0 ADDS R0，＃0x40; ＆＃39; @＆＃39; ROM：000266D2 LDR R2，[R0] ROM：000266D4 MOV R0，R5ROM：000266D6 BLX R2ROM：000266D8 MOV R4，R0ROM：000266DA BL sub_E8ROM：000266DE MOV R0，R4ROM：000266E0 B loc_260E2ROM： 000266E0;函数_Command_HRST的结尾

由于IDA似乎不能很好地处理它们，因此我们编写了一个简单的脚本来注释BLX调用。不幸的是，这在IDA反编译器中不能很好地发挥作用，但足以用于进一步的固件研究。这些蹦床的目的是允许对固件中的功能进行选择性修补，因为主要固件似乎位于ROM中。

在分析了VDM（VDM发送）命令处理程序之后，我们迅速找到了负责发送任意PD消息的功能。从这里，我们查看了引用它的列表函数，找到了一些有趣的可能的调查候选对象，其中之一竟然是我们正在寻找的候选对象。另外，通过检查其起源的SOP是SOPDBG还是SOPDBG的函数调用它。

该图像中名为AppleVDM_0x12的功能特别有趣，因为DVEn命令也引用了该功能。不幸的是，只有4个字符，我们不能仅从名称中导出函数。我们决定分析从0x10开始的所有此函数调用的函数。

Warning: Can only detect less than 5000 characters