Android App加固原理與技術歷程

時間 2020-06-13

原文原文鏈接

App爲何會被破解入侵java

隨着黑客技術的普及化平民化，App，這個承載咱們移動數字工做和生活的重要工具，不只是黑客眼中的肥肉，也得到更多網友的關注。百度一下「App破解」就有5290萬條結果。ios

一旦App被破解，不只使用者的照片、身份證、手機號、聯繫住址、郵箱和支付密碼等敏感信息會泄露，還可能感染手機的操做系統，進而致使手機被入侵篡改，乃至成爲攻擊者操控的「僵屍網絡」中的一部分。編程

安卓App的開發除了部分功能採用C/C++編碼外，其他主要都是採用Java進行編碼開發功能。Java源碼最終編譯成smali字符碼，以classes.dex保存在App的APK中。安全

Java是一種解釋性語言，功能強大，易用性強。初學者能輕鬆地學習Java，並編寫簡單的應用程序。並且Java的基本類庫（JDK）是開源的，這就使不少Java開發的應用被逆向破解的門檻很低。目前市面上有大量的逆向破解工具，例如：Dex2Jar、JEB、JD-GUI等等。只要懂代碼編程，利用這些工具就能夠破解市面上那些防護薄弱、存在大量安全漏洞的App。這就很好理解爲何會有如此多人去搜索「App破解」了。性能優化

以前曾有媒體報道，有網絡黑產專門從各類渠道找到App的apk，而後將apk文件逆向破解，再植入廣告、病毒代碼，最後從新打包投入公開市場，當不明真相的網友將帶病毒廣告的App下載後，會帶來巨大經濟損失。網絡

加固技術發展歷程

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

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

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

保護流程

開發階段函數

開發階段中將程序切分紅加載（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相關的函數被攔截，因此沒法直接調用read/write等函數進行直接的讀寫，須要使用syscall函數進行繞過。

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

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

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

保護流程

發佈階段

發佈階段將原始DEX內的函數內容（Code Item）清除，單獨移除到一個文件中。

運行階段

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

A.加載以後恢復函數內容到DEX殼所在的內存區域

B.加載以後將函數內容恢復到虛擬機內部的結構體上：虛擬機讀取DEX文件後內部對每個函數有一個結構體，這個結構體上有一個指針指向函數內容（CodeItem），能夠經過修改這個指針修改對應的函數內容。

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

兼容性

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

缺陷與對抗

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

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