加固技術發展與對抗 虛機源碼保護的未來級別方案

傳統App加固技術，前後經歷了四代技術變更，保護級別在每一代都有所提升，但其固有的安全缺陷和兼容性問題始終未能得到解決。而下一代加固技術—虛機源碼保護，適用代碼類型更廣泛，App保護級別更高，兼容性更強，堪稱未來級別的保護方案。

（加固技術發展歷程）

第一代加固技術—動態載入。

第一代Android加固技術用於保護應用的邏輯不被逆向與分析，最早普遍在惡意軟體中使用，其主要基於Java虛擬機提供的動態載入技術。

其保護流程是：

開發階段中將程序切分成載入（Loader）與關鍵邏輯（Payload）兩部分，並分別打包；

（開發階段）

運行時載入部分（Loader）會先運行，釋放出關鍵邏輯（Payload），然後java的動態載入技術進行載入，並轉交控制權。

（啟動流程）

（核心代碼）

備註（multidex組件的加固原理）：

Android的DEX文件在設計之初程序普遍較小，所以在DEX文件設計時，只允許包含65535個函數引用。而隨著Android應用的發展，大量的應用的代碼已經超過了65535的限制，為了解決這個問題，Android5.0之後原生支持載入多個dex，而為了對舊版本的兼容，Android提供了multidex組件。該組件的實現原理與上面介紹的是一致的。

缺陷與對抗

第一代加固技術的缺陷是依賴Java的動態載入機制，而這個機制要求關鍵邏輯（Payload）部分必須解壓，並且釋放到文件系統，這就給了攻擊機會去獲取對應的文件。雖然可以通過關鍵邏輯（Payload）被載入後，被從文件系統刪除，用於防止被複制，但是攻擊者可以攔截對應的刪除函數，阻止刪除。

而關鍵邏輯（Payload）會被加密後保存，可用於對抗靜態分析，但是攻擊者可以通過自定義虛擬機，攔截動態載入機制所使用的關鍵函數，在這個函數內部，複製文件系統中的關鍵邏輯（Payload）文件。

第二代加固技術—不落地載入。

相對第一代加固技術，第二代加固技術在APK修改方面已經完善，能做到對開發的零干擾。開發過程中不需要對應用做特殊處理，只需要在最終發布前進行保護即可。而為了實現這個零干擾的流程，Loader需要處理好Android的組件的生命周期。

主要流程：

1）Loader被系統載入。

2）系統初始化Loader內的StubApplication。

3）StubApplication解密並且載入原始的DEX文件（Payload）。

4）StubApplication從原始的DEX文件（Payload）中找到原始的Application對象，創建並初始化。

5）將系統內所有對StubApplication對象的引用使用替換成原始Application，此步驟使用JAVA的反射機制實現。6）由Android系統進行其他組件的正常生命周期管理。

（對開發零干擾的加固後啟動流程）

另一方面，不落地載入技術是在第一代加固技術的基礎上改進，主要解決第一代技術中Payload必須釋放到文件系統（俗稱落地）的缺陷，其主要的技術方案有兩種：

A、攔截系統IO相關的函數（如read、write），在這些函數中提供透明加解密。具體的流程是：

1）關鍵邏輯（Payload）以加密的方式存儲在APK中。

2）運行時載入部分（Loader）將關鍵邏輯釋（Payload）放到文件系統，此時關鍵邏輯（Payload）還處於加密狀態。

3）載入部分攔截對應的系統IO函數（read，write等）。

4）載入部分（Loader）正常調用Java動態載入機制。由於虛擬機的IO部分被攔截，所以虛擬機讀取到已經解密的關鍵邏輯（Payload）.

（透明加解密方案流程）

B、直接調用虛擬機提供的函數進行不落地的載入，具體流程是：

1）關鍵邏輯（Payload）以加密的方式存儲在APK中。

2）運行時載入部分（Loader）將關鍵邏輯釋（Payload）放到內存。

3）載入部分調用虛擬機內部介面進行載入。

（不落地載入流程）

關鍵的系統函數如下：

兼容性

方案A透明加密方案由於其需要攔截系統的IO函數，這部分會使用inline hook或者got hook等技術，其會帶來一定的兼容性問題

方案B的不落地載入方案由於其調需要調用系統內部的介面，而這個介面並不導出，各個廠商在實現時又有各自的自定義修改，導致該方案存在兼容性問題。

缺陷與對抗

第二代加固技術在應用啟動時要處理大量的加解密載入操作，會造成應用長時間假死（黑屏），用戶體驗差。

在加固技術實現上沒有本質區別，雖然能防止第一代加固技術文件必須落地被複制的缺陷，但是也可以從以下方面進行對抗：

例如內存中的DEX文件頭會被清除，用於防止在dump文件中被找到； DEX文件結構被破壞，例如增加了一些錯誤的數據，提高恢復的成本。

但是Payload被載入之後，在內存中是連續的，利用gdb等調試工具dump內存後可以直接找到Payload，進行簡單的處理之後可以恢復出100%的Payload文件。

和第一代加固技術的對抗方法一樣，不落地載入也無法對抗自定義虛擬機。只需對上述的關鍵函數進行攔截然後將對應的內存段寫出去，即可恢復Payload。注意，由於IO相關的函數被攔截，需要使用syscall函數進行繞過。

雖然廠商會自己實現可能上述函數，從而繞過上述函數的攔截。但是Android的類載入器必須能找到對於的結構體才能正常執行，攻擊者可以以類載入器做為起點，找到對應的Payload在內存中的位置。

第三代加固技術—指令抽離

由於第二代加固技術僅僅對文件級別進行加密，其帶來的問題是內存中的Payload是連續的，可以被攻擊者輕易獲取。第三代加固技術對這部分進行了改進，將保護級別降到了函數級別。

主要的流程是：發布階段將原始DEX內的函數內容（Code Item）清除，單獨移除到一個文件中。

（發布階段）

運行階段將函數內容重新恢復到對應的函數體。恢復的時間點有幾個方式：

A、載入之後恢複函數內容到DEX殼所在的內存區域。

（運行階段）

B、載入之後將函數內容恢復到虛擬機內部的結構體上：

虛擬機讀取DEX文件後內部對每一個函數有一個結構體，這個結構體上有一個指針指向函數內容（CodeItem），可以通過修改這個指針修改對應的函數內容。

C、攔截虛擬機內與查找執行代碼相關的函數，返回函數內容。

兼容性

指令抽離技術使用了大量的虛擬內部結構與未被文檔的特性，再加上Android複雜的廠商定製，帶來大量的兼容性問題。

缺陷與對抗

指令抽離技術的某些方案與虛擬機的JIT性能優化衝突，無法達到最佳的運行性能。依舊使用了java虛擬機進行函數內容的執行。攻擊者可以通過自定義Android虛擬機，在解釋器的代碼上做記錄一個函數的內容（CodeItem）。接下來遍歷觸發所有函數，從而獲取到全部的函數內容。最終重新組裝成一個完整的DEX文件。目前已經有自動化工具可以指令抽離技術中脫殼。

（第三代加固DEX文件脫殼流程）

第四代加固技術—指令轉換/VMP

第三代加固技術在函數級別的保護，使用Android虛擬機內的解釋器執行代碼，帶來可能被記錄的缺陷，第四代加固技術使用自己的解釋器來避免第三代的缺陷。而自定義的解釋器無法對Android系統內的其他函數進行直接調用，必須使用JAVA的JNI介面進行調用。其主要實現由兩種：

A、DEX文件內的函數被標記為native，內容被抽離並轉換成一個符合JNI要求的動態庫。 動態庫內通過JNI和Android系統進行交互。

B、DEX文件內的函數被標記為native，內容被抽離並轉換成自定義的指令格式，該格式使用自定義接收器執行，和A一樣需要使用JNI和Android系統進行調用。

兼容性

第四代VMP加固技術一般配合第三代加固技術使用，所以第三代的所有兼容性問題。

缺陷與對抗

其必須通過虛擬機提供的JNI介面與虛擬機進行交互，攻擊者可以直接將指令轉換/VMP加固方案當作黑盒，通過自定義的JNI介面對象，對黑盒內部進行探測、記錄和分析，進而得到完整DEX程序。

（第四代加固DEX文件恢復）

另外，第四代VMP加固技術只實現Java代碼保護，安全保護能力有所欠缺。

下一代加固技術—虛機源碼保護

跟第四代的VMP加固技術，虛機源碼保護加固是用虛機技術保護所有的代碼，包括Java，Kotlin，Swift等多種代碼，具備極高的兼容性；使App得到更高安全級別的保護，運行更加穩定。

虛機源碼保護為用戶提供一套完整的工具鏈，首先把用戶待保護的核心代碼編譯成中間的二進位文件，隨後生成獨特的虛機源碼保護執行環境和只能在該環境下執行的運行程序。

虛機源碼保護會在App內部隔離出獨立的執行環境，該核心代碼的運行程序在此獨立的執行環境里運行。即便App本身被破解，這部分核心代碼仍然不可見。

（虛機源碼保護加固流程）

生成的虛機源碼保護擁有獨特的可變指令集，極大的提高了指令跟蹤、逆向分析的難度。同時，虛機源碼保護還提供了反調試能力和監控能力。虛機源碼保護可以通過自身的探針感知到環境的變化，實時探測到外界對本環境的調試、注入等非正常執行流程變化，將調試動作引入程序陷阱，並發出警報，進而進行實時更新，提高安全強度。

加固技術發展及其攻防對抗的更迭，伴隨著互聯網技術發展不斷升級，我們深信邪不能勝正，而虛機源碼保護加固作為當前領先的加固技術，在未來很長一段時間，能夠為App提供足夠強度的保護，為企業和開發者的業務發展保駕護航。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！