新智元报说念kaiyun.com

　　裁剪：润 好困

　　【新智元导读】iPhone曝出「史上最复杂」硬件级别瑕玷！黑客只需一条iMessage即可拿到所有这个词敏锐数据，而用户不会有任何察觉。通盘瑕玷触及的链条极其复杂，让Karpathy都惊呼：不是世俗东说念主颖悟出来的事。

　　最近，卡巴斯基的说合东说念主员发现，有黑客在四年多的时候里给数千部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 = 0x23B700408command = 0x1F0023FFelif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)base = 0x23B7003C8command = 0x1F0023FFelif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)base = 0x23B7003D0command = 0x1F0023FFelif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)base = 0x23B080390command = 0x1F0003FFelif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)base = 0x23B080388command = 0x1F0003FFif ((~read_dword(base) & 0xF) != 0):write_dword(base, command)while(True):if ((~read_dword(base) & 0xF) == 0):break

　　瑕玷中GFX电源管制器约束代码的伪代码

　　在开拓树和Siguza开发的器用pmgr的扶植下，说合东说念主员发现所有这个词这些地址都对应于电源管制器中的GFX寄存器处所的MMIO（Memory-Mapped Input/Output）范围。

　　临了，当说合东说念主员尝试去走访这些未知区域的寄存器时，得到了第三个证实。

　　GPU的协处理器险些坐窝报错，涌现信息：「GFX SERROR Exception (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):returnwrite_qword(0x206040000, value | 0x80000000)while (True):if ((read_qword(0x206040000) & 0x10000000) != 0):breakdef ml_dbgwrap_unhalt_cpu():value = read_qword(0x206040000)value = (value & 0xFFFFFFFF2FFFFFFF) | 0x40000000write_qword(0x206040000, value)while (True):if ((read_qword(0x206040000) & 0x10000000) == 0):break

　　利用才智使用0x206040000寄存器的伪代码

　　顺利将之前伪代码中的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 = 0x206140108value = read_qword(ctrl)write_qword(ctrl, value | 0x8000000000000001)sleep(1)while ((~read_qword(ctrl) & 0x8000000000000001) != 0):sleep(1)def dma_ctrl_2(flag):ctrl = 0x206140008value = read_qword(ctrl)if (flag):if ((value & 0x1000000000000000) == 0):value = value | 0x1000000000000000write_qword(ctrl, value)else:if ((value & 0x1000000000000000) != 0):value = value & ~0x1000000000000000write_qword(ctrl, value)def dma_ctrl_3(value):ctrl = 0x206140108value = value | 0x8000000000000000write_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)

　　利用才智使用 0x206140008 和 0x206140108 寄存器的伪代码

　　寄存器0x206150020专门用于苹果的A15/A16 Bionic SoC。在瑕玷利用的启动阶段，此寄存器会被建设为1；而在瑕玷利用完成后，会收复为启动的数值。

　　寄存器0x206150040被用来保存一些气象标记和主见物理地址的低位部分。

　　临了的寄存器，0x206150048，则清雅存储待写入的数据以及主见物理地址的高位部分。这些数据会与数据的校验哈希值以及另外的数值（可能是提示）沿途打包。该硬件功能会将数据分块，每块大小为64（0x40）字节进行对皆写入，而且需要连结九次写操作将全部数据写入至0x206150048寄存器。

　　if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16)i = 8mask = 0x7FFFFFFelif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15)i = 8mask = 0x3FFFFFelif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14)i = 0x28mask = 0x3FFFFFelif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13)i = 0x28mask = 0x3FFFFFelif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12)i = 0x28mask = 0x3FFFFFdma_init(original_value_0x206140108)hash1 = calculate_hash(data)hash2 = calculate_hash(data+0x20)write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))pos = 0while (pos < 0x40):write_qword(0x206150048, read_qword(data + pos))pos += 8phys_addr_upper = ((((phys_addr >> 14) & mask) << 18) & 0x3FFFFFFFFFFFF)value = phys_addr_upper | (hash1 << i) | (hash2 << 50) | 0x1Fwrite_qword(0x206150048, value)dma_done(original_value_0x206140108)

　　利用瑕玷使用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, 0x380def calculate_hash(buffer):acc = 0for i in range(8):pos = i * 4value = read_dword(buffer + pos)for j in range(32):if (((value >> j) & 1) != 0):acc ^= sbox[32 * i + j]return acc

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

　　如你所见，这是一种定制的算法，其哈希值的盘算推算依赖于一个事先界说好的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），相较于软件来说，硬件更难逆向工程分析。

　　但这种方法自己是存在瑕玷的，因为所有这个词的奥妙终将有被揭露的一天。那些依赖于「恍惚式安全」来吝啬的系统，始终无法作念到简直的安全。

　　参考府上：

　　https://arstechnica.com/security/2023/12/exploit-used-in-mass-iphone-infection-campaign-targeted-secret-hardware-feature/

　　https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/