作者：此彼@螞蟻安全實驗室
原文鏈接：https://mp.weixin.qq.com/s/CjWMFtPpl5YutgdP2LctKQ

在今年的Black Hat Asia上，螞蟻安全實驗室共入選了5個議題和3個工具。本期分享的是螞蟻天穹實驗室的議題《從算法到寄存器探索蘋果神經網絡引擎》。

1 引言

自 iPhone X 面世以來，越來越多的智能設備開始采用面容識別作為生物特征驗證手段。然而對這些智能設備端的神經網絡計算可靠性和安全性的研究少有報道，已有的技術文章也沒有深入到代碼操作硬件的實現層面。從iPhone X上市已過去3年半，仍然沒有公開的對面容ID實現層面的研究資料。

為了驗證 iPhone面容識別的安全性，探索端設備生物特征識別的安全防護技術，更好的幫助移動設備的安全提升，本文將首次展示我對iPhone設備神經網絡計算安全實現方式的一手研究成果，并分析其原理和可能存在的安全風險。

1.1 內容簡介

本分享包含4個主要內容。

第一部分：逆向分析面容ID和安全神經網絡引擎，并分析面容ID在軟件層面上的實現方法。

第二部分：逆向找到“機器學習算法”轉化為“寄存器操作”的過程中涉及所有組件。

第三部分：提取獨立ANE編譯器、開發ANE反匯編器。反匯編器可以解析內核驅動加載的內部神經網絡文件。

第四部分：總結出6個可能的攻擊面，介紹已經獲得蘋果致謝的bug。

1.2 名詞解釋

ANE: Apple Neural Engine 蘋果神經網絡引擎

AP: Application Processor 應用處理器

SEP: Secure Enclave Processor 安全隔區處理器

SEP APP: Application for SEP 運行在SEP中的應用程序

FaceID: 面容ID

2 面容ID和安全神經網絡引擎

本章節著重介紹3個最受關心的逆向成果：1.面容ID的軟件架構 2. 面容ID的神經網絡參數解密 3. 安全神經網絡引擎硬件如何被操作的。

2.1 FaceID的實現架構

上圖用一些圖框和箭頭表示不同特權空間和交互方法。以人臉解鎖為例，一些守護進程會通過XPC通知進程biometrickitd。biometrickitd通過IOKit調用內核中的驅動。內核驅動通過IOP調用協處理器SEP，SEPAPP sprl會處理一些攝像頭調用等行為，最終交給SEPAPP esipAppl去執行真正的神經網絡計算。

由于SEP的固件和啟動鏈有著嚴格的加密驗簽機制，過去很長的一段時間里我們完全不知道里面發生了什么。

2.2 SEP從AP加載加密神經網絡參數并解密

操作系統啟動后，FaceID會從文件系統加載名為DCNKernel.bin的文件。此文件可能是神經網絡的訓練好的權重，但被AES加密過的，解密用的iv和key被硬編碼在SEP的固件里。且SEP會檢查文件的SHA384數字摘要，摘要也是硬編碼在代碼中。

這就意味著SEP固件版本和系統版本需要基本一致，否則FaceID可能不可用。這也解釋了 checkm8 越獄的手機如果系統降級但sep不降級導致FaceID不可用的原因。

2.3 FaceID在SEP中直接操作硬件寄存器

偽代碼：
[(addr, value), …] = InterpreterLikeProduce(DmaBaseSetup, Setup, StaticCfg)

for (addr,value) in [(addr, value), …]

    ffwCommon_writeReg32(addr, value)

左右滑動查看完整代碼

FaceID直接操作硬件寄存器實現神經網絡的計算過程。代碼會從靜態硬編碼的數據中提取信息，計算出需要寫入的寄存器地址和數值，然后調用函數寫入。

本質上FaceID在SEP中實現了一種像解釋器的程序，它將3種不同的設置信息轉化為寄存器地址和需要向這些地址寫入的數值。可惜這些寄存器地址和數值的含義我們是不知道的。寄存器被寫入后，到底進行了哪些運算我們也是不知道的。

3 蘋果神經網絡引擎框架

在A11處理器上只有安全神經網絡引擎，沒有給AP開放接口使用。自A12處理器起，蘋果將神經網絡引擎分為，專門為SEP使用的“安全神經網絡引擎”和為AP使用的“神經網絡引擎”。

安全和非安全的神經網絡引擎存在軟硬件隔離。本章將展示逆向AP使用的“神經網絡引擎”的成果。

3.1 開放給App使用的架構

蘋果從A12芯片起開放了ANE給App使用。雖然蘋果公司的白皮書上說Application Processor Neural Engine和Secure Neural Engine有硬件級別的隔離，但是他們對寄存器的使用上可能有相似之處。

同樣的，我用一些圖框和箭頭表示不同特權空間和交互方法。與Secure Neural Engine不同的是App可以直接訪問幾個內核驅動接口。ANE的編譯會在獨立的隔離的進程里。且ANE的固件是不加密的。

3.2 ANE內部數據處理流程

上圖中的方框代表數據，圓圈代表處理，描述了ANE框架內部將預訓練模型加工成寄存器操作的完整過程。網絡上有很多訓練好的神經網絡，但依賴不同的機器學習框架運行。蘋果提供了coremltools將他們轉化成統一的mlmodel格式。

coremlcompiler會將mlmodel文件編譯成一些文件存放于特定文件夾下面，一般是mlmodelc為后綴名的文件夾。mlmodelc文件夾下面的一些文件會提供給ANE的與編譯器處理，產生包含net.plist文件在內的另一批文件。將net.plist等文件提供給ANE編譯器后，會編譯出model.hwx文件。

model.hwx文件會被內核驅動加載。內核驅動會解析文件提取寄存器操作信息傳遞給ANE協處理器。最終由ANE協處理器操作寄存器來執行實際的神經網絡運算。這處理流程比較長和復雜，其中很可能會出現bug。

3.3 內部處理流程所處空間的關系

為了方便研究安全風險，我把不同的過程按不同的特權空間進行劃分。因為在安全問題的研究上我們更關心特權提升的問題，這些過程恰恰可能提供這樣的機會。coremltools一般運行在開發者的主機電腦上，他會將其他機器學習框架的預訓練好的數據轉化為統一的mlmodel格式。

這一過程需要coremltools解析各種格式的文件，且這些文件可能是從不可信的渠道獲得的，比如網絡上公開的預訓練數據。coremlcompiler過程既可以在開發者電腦上進行也可以在App中運行，在App中運行時coremlcompiler與App的進程權限一致，同樣此時的App也可能加載的是不可信來源的mlmodel文件。

ANE預編譯和完整編譯過程發生在一個名為ANECompilerService的守護進程中，被編譯的文件直接來自于App。對ANECompilerService進程來說App提供的文件也是不可信的，所以蘋果也限制了ANECompilerService進程的權限。ANE內核驅動運行在內核空間，與前三個處理一樣的是他們都運行在application processor中。ANE固件則運行于獨立的協處理器中。

3.4 ANE內核驅動

ANE內核驅動為App和aned守護進程提供了不同的客戶端。App的客戶端只有打開、關閉和ProgramSendRequest三個接口。

aned守護進程有使用驅動所有接口的權利。aned進程也負責把編譯出的model.hwx文件傳遞給內核驅動解析加載，并把一些具柄傳遞給App。內核驅動會通過anecmdsend函數與ane固件交互。

3.5 ANE固件

Load Program:
    CSneTMDrv::ParseTD(void const*,ulong,ANERegs_t *,ane_TD_HEADER_t *,bool)

Execute:
    CSneTMDrv::AddTDList(void const*,ulong,ulong,ulong,uint,uint *,uint,ulong volatile*,_rtk_timer_call *,bool)

左右滑動查看完整代碼

ane固件運行于獨立的協處理器中，二進制代碼可以在刷機包中找到，且沒有被加密。這里主要介紹兩個函數，一個是對model.hwx中可執行數據段的內部數據進行解析的函數，另一個是涉及實際操作寄存器進行神經網絡運算的函數。在這里不分析固件的所有實現，因為這不是主要內容。

4 ANE工具集

為了方便各位研究，我把我寫的工具集全部開源。工具開源地址：https://github.com/antgroup-arclab/ANETools

工具集包含了我編寫的通過命令行直接調用蘋果內部組件的工具、我開發的反匯編ANE寄存器操作的工具和一些實用腳本。

4.1 所有算法與mlmodel文件

為了把其他機器學習框架轉化為統一的mlmodel文件，蘋果開發了一種模型中間語言。此中間語言支持一百幾十種元算法，所有其他機器學習框架中的算法必須都由元算法組合而成。你可直接使用這些元算法構造出自定義的機器學習算法。

4.2 編譯mlmodel文件的coremlcompiler

開發機上的工具路徑:
    /Applications/Xcode.app/Contents/Developer/usr/bin/coremlc
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/coremlcompiler
設備上的相關類名:
    CoreML

輸入: *.mlmodel 文件
輸出: *.mlmodelc/ 文件夾

左右滑動查看完整代碼

coreml編譯器不僅存在于主機上也存在于蘋果設備中。開發App時如果包含靜態mlmodel文件，Xcode會使用自帶的coreml編譯器，直接將編譯出的文件夾包含到App文件中。

App也可以遠程下載即時編譯mlmodel文件。幻燈片中也展示了一般mlmodelc文件夾包含的文件，mlmodel文件也可以包含多個機器學習模型。

4.3 Espresso預編譯coremlcompiler產出的文件

0x1b0009cb0 Foundation!-[NSDictionary(NSDictionary) writeToFile:atomically:]
0x1dd6316d0 Espresso!Espresso::ANECompilerEngine::compiler::dump_ir(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
0x1dd5a78dc Espresso!espresso_dump_ir
0x1047f1c0c ANECompilerService!0x9c0c +[_ANEEspressoIRTranslator translateModelAt:key:outputPath:error:]
0x1047f2ac0 ANECompilerService!0xaac0 +[_ANECoreMLModelCompiler compileModelAt:csIdentity:key:optionsFilename:tempDirectory:outputURL:ok:error:]

左右滑動查看完整代碼

如果此mlmodel文件需要通過ANE執行，App會跟aned守護進程通信，提供mlmodelc文件夾下面的文件信息。

如果文件沒有被ANE編譯器編譯過，aned會喚起ANECompilerService進程開始編譯。ANE實際編譯之前主要會把mlmodelc文件夾下的神經網絡描述文件預編譯成plist格式。

4.4 ANE編譯器

預編譯完成后就會進行實際編譯。實際編譯過程也在ANECompilerService進程中。代碼存在于ANECompiler模塊，并以一個函數ANECCompile()做為入口。此函數會將神經網絡描述文件、網絡權重等文件編譯成包含寄存器寫入在內的model.hwx文件。

我編寫的工具可以從命令行直接調用ANECCompile()函數，不經過ANECompilerService Daemon進程，方便測試研究。

ANE編譯器擁有很多編譯選項。可以參考ANETools的代碼。需要注意的是，除了輸入輸出路徑參數，至少還需要目標架構參數，才能正常編譯。其中還有叫DebugMask的flag可以設置成整型最大值，編譯后會產生很多中間文件。

4.5 ANE反匯編器

我通過逆向數據結構后獨立編寫了反匯編工具ANEDisassembler，用于反匯編model.hwx文件。我目前沒有發現蘋果有解析model.hwx文件的代碼。

——ANE反匯編器的部分代碼。

——ANE反匯編器的部分代碼。

通過分析model.hwx文件，并在ANECompiler模塊找到每個比特的含義，我編寫的反匯編器ANEDisassembler工具會詳細打印出寄存器的數值和對應的比特位，這樣能更方便的猜比特位的具體作用。

目前ANETools只實現了對ANE v5指令集的支持，還沒有兼容更高版本的ANE指令集。可能兼容的設備有：iPhone Xs, iPhone Xs Max , iPhone XR ,iPad Air3 ,iPad mini5 ,iPad8。希望ANETools這個工具能對各位有所幫助。

5 攻擊面分析與漏洞

本章包含了我總結的可能存在的6個攻擊面，并且通過漏洞挖掘驗證了部分攻擊面是真實存在的。

5.1 可能的攻擊面

我把ANE可能的攻擊面分為6種，每一種攻擊面都是一個特權空間到另一個特權空間的提升。

第一個可能的攻擊面是從遠程到本地電腦或遠程到App。如之前所述，mlmodel文件不僅可以在開發者電腦上被xcode的coremlcompiler處理，也可以在iOS設備上被App處理。mlmodel文件可以來自網絡或其他不可信的地方。

第二個可能的攻擊面是從App到aned守護進程。App會將幾乎所有跟ane相關的工作交給aned守護進程去做，他們交互過程中很可能有一些漏洞存在。

第三個可能的攻擊面是App到ANE編譯器。雖然App不直接與ANE編譯器交互，但文件會直接由aned守護進程轉交給ANE編譯器。ANE編譯器一定程度上對App是透明的。實現編譯器代碼安全是很困難的，比如針對瀏覽器javascript編譯器的攻擊總能被實現。一旦拿下ANE編譯器的權限，就意味著可以篡改任意ANE計算結果了。

第四個可能的攻擊面是App到內核驅動，這個攻擊面現在看起來有些難，因為內核驅動現在只開放了3個接口給App。但在較低版本的系統上存在App可以訪問所有ANE內核驅動接口的漏洞。

第五個可能的攻擊面是從aned守護進程到內核驅動。這個攻擊面需要攻擊者已獲取到aned守護進程的權限。aned守護進程有訪問ane內核驅動的所有接口權限。這些接口并不暴露給App，所以很可能存在各種檢查不嚴的情況。

第六個可能的攻擊面有關ANE內核驅動和ANE固件。他們之間也存在復雜的交互。使用這個攻擊面需要攻擊者已取得內核權限或已取得ANE固件權限。

5.2 已獲蘋果承認的ANE相關漏洞

蘋果已經在iOS14.5中修復了一個內核ANE內核驅動相關漏洞：https://support.apple.com/zh-cn/HT212317

另有3個ANE相關漏洞已被蘋果接受還在修復中。

6 總結

蘋果神經網絡引擎已是相當復雜且龐大，本文的介紹集中在框架、流程和ANE指令分析，雖然還沒有深入進入硬件，但把一些關鍵環節值得關注的要點做了總結，也獲得了不錯的產出。非常期待同行們能夠進一步深入研究與分享，如果有什么問題也歡迎交流。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1617/