[轉] Android app保護及破解面面觀 [方法論]

Android app保護及破解面面觀

安卓逆向分析 by droidsec

做者：張躍騫

關鍵詞：Android，加固，脫殼；

原文連接：http://www.inforsec.org/wp/?p=581

 

1、保護技術的意義及現狀

Android平臺自發布以來受到了廣大消費者的歡迎，已經佔到81%的市場份額，也吸引了大量的開發者，帶來了巨大的收益。然而巨大的成功也使得Android系統成爲了黑客的一大戰場。因爲Android app自身的機制，使得其很容易遭到破解。經過使用簡單的反編譯工具，基本上可以達到閱讀源代碼的程度，進而再進行二次修改、從新打包併發布。因而可知，惡意軟件能夠很容易地附加在正常的app中假裝本身，競爭對手間能夠很容易地得到對方app中的技術信息，這種嚴峻的形勢催生了Android app保護技術的出現並不斷地提升完善。

在中國，出現了至關數量的一批Android app保護的廠商。它們一般採用多種手段來保護和隱藏原有的可執行文件（即dex文件），並使用反調試技術在運行的時候阻止對相關內存區域進行讀取而獲得有效的dex文件。同時也使用混淆技術如ProGuard、DexGuard等工具增長反編譯後的代碼的分析難度。

Android app保護技術也是一把雙刃劍，黑客也普遍使用它來保護惡意和重打包的app，使得難以被分析和斷定，在必定程度上提升了傳播的範圍。因此對於惡意程序分析人員來講，甚至對於軟件類似性檢測、代碼抄襲等相關電子取證技術，破除app的保護也是必不可少的第一步。

咱們主要研究了6中主流的Android app保護廠商的產品：梆梆、騰訊、愛加密、360、阿里和百度（截止2015年9月）。經過相關的一些分析，咱們來看一看這些廠商是如何來實現app的保護的：

360：將原有的dex文件加密後存儲在libjiagu.so/libjiagu_art.so，在運行時動態釋放並解密。

阿里：將原有的dex文件拆分爲兩部分，一部分主體保存爲libmobisecy.so，另外一部分包含了一部分class_data_item和code_item。在運行的時候將兩部分釋放在內存中，並修復相關的指針，恢復數據之間的鏈接關係。同時一些annotation_off被設置爲無效的值。

百度：將一些class_data_item存儲在dex文件的外部，在運行時恢復與主體的dex的鏈接關係。在dex文件加載後，其頭部的魔數，校驗和以及簽名值會被擦除。同時某些方法被改寫，使得其在執行前相關的指令纔會被恢復，在執行以後便當即擦除。

梆梆：提早準備了一個odex或oat文件，並加密保存爲外部的jar文件，運行時解密；同時hook了libc.so中的一些函數，如read,write, mmap等，監視其操做區域是否包含了dex的頭部，保證沒法使用這些函數對於dex文件進行操做。

愛加密：一樣是加密原有的dex文件，在運行時總體釋放並解密，只不過其釋放的處於固定路徑下的臨時文件的名字是隨機的。

騰訊：提供選項能夠指定須要保護的方法。若是某個方法被保護，則在dex文件中的相關class_data_item中沒法看到其數據，即爲一個假的class_data_item；在運行時釋放真正的class_data_item並鏈接到dex文件上，可是其code_item卻一直存在於原有的dex文件中。一樣地，一些annotation_off和debug_info_off被填充爲無效值來阻止靜態反編譯。只支持在DVM環境下運行。

這些產品都具有反調試的能力，也就是說經過使用ptrace或JWDP等調試接口動態附加調試比較困難。

2、相關研究介紹

App加固做爲一項技術熱點，以前的研究主要處於工業界，學術界對其關注很少。

比較著名的反編譯工具備backsmali/smali, Apktool , IDA Pro等，可是沒法克服app加固的保護。

Apvrille ^[1]較早地提出了利用加密方法如異或操做、DES或AES算法來隱藏原始的指令。Strazzere在^[2]提出利用反射方法來調用一些關鍵的函數，並將真正地dex文件保存在資源中以及使用一些反調試的技術。Schulz在^[3,4]討論了利用變量名和字符串混淆，代碼動態加載，插入垃圾指令以及利用JNI來實現dalvik代碼自修改^[5]，這些技術如今仍在被普遍使用。Apvrille ^[6]經過修改encoded_method的數據實現了對相關方法的保護。Martin在^[7]描述了一種新的保護方法。從Android 4.0起提供了一個新的接口，能夠將一塊內存做爲dex文件打開，利用此特性能夠進一步保護dex文件的指令並實現動態指令修改。Nigam 在^[8]分析了當時的一些加固產品及其工做原理。 Strazzere 在^[9]介紹並分析了一些混淆工具如ProGuard, DexGuard和 ALLATORI和梆梆的加固產品。Apvrille 在^[10]中將dex文件利用AngeCryption^[11]處理爲一個resource文件從而進行隱藏，並且這個被加密的dex文件能夠被靜態打開顯示爲一個圖片，同時在運行的時候能夠進行解密並獲得執行。Apvrille 在^[12,13]也討論了一些混淆工具和加固產品的原理，並分析了一些能夠用於干擾靜態和動態分析的方法。YU ^[14]分析了一些Android加固產品的原理，並基於LiME^[15]構建了一個工具用於獲取目標內存區域的內容。

ZjDroid^[16]是基於Xposed的脫殼工具。它hook了BaseDexClassLoader對象來獲取包含dex文件的目標內存，它只支持DVM而且須要root權限。對於阿里等將原始dex文件拆分的作法，它也沒法克服。

Park在^[17]提出了一種方法：對apk進行從新打包，並插入一個調用了wait-for-debug 功能的方法，使得app在啓動後會暫停並等待用戶利用JWDP調試協議進行鏈接。這樣能夠調試目標app並讀取其內存。但此方法很容易被檢測繞過且沒法克服反調試的限制。

Jung 在^[18]提出了一個叫作DABiD的調試器。它能夠獲取到內存中有效的dex文件。它經過將本身的模塊注入到目標app的進程中，監視內存中的動態修改包括代碼自修改和動態類加載，並將相關信息反映到調試器中。一樣地，它不支持ART環境。而且因爲它只監視了dex文件的內存區域，因此針對於修改Android運行時所維護的對象的行爲沒法進行監視和捕獲。

3、破解思路及實現

以前對於各類app保護的破解方法，主要仍是處於和app自身一樣的運行級別，因此很容易被檢測到而且繞過，因此咱們的思路是直接提升脫殼模塊的等級，將其整合到Android的運行時中，並使得內存中的dex文件獲得盡大程度的恢復，這樣被運行時解釋和執行的app便很難繞過了，並且也輕易解決了反調試技術的限制。

根據此思路咱們設計了DexHunter^[19,20]，它整合進了DVM和ART兩個運行時。經過由用戶指定一個特徵字符串來定位到包含dex主體部分的內存區域。這個特徵字符串主要用來匹配運行時當前使用的dex文件是不是咱們須要的dex文件。一旦獲取了dex的主體部分，接下來便主動加載並初始化dex文件中的全部class，盡力使其恢復到正常運行的狀態。接下來咱們將整個區域分爲三部分，重點處理包含class數據的第二部分。咱們對於每個class進行解析，並觀察其中是否有數據位於主體dex範圍以外，及相關的信息是否與Android運行時所維護的數據一致，若是有所出入，則修改dex文件中的相關數據，並將外部的數據收集在一塊兒從新存儲在尾部，並修正相關的指針，這樣咱們便可以獲得一個完整的dex文件。總體的思路如圖1所示：

圖1. DexHunter工做原理

對於一些無效的字段，咱們能夠在獲得dex文件後將其所有抹除爲0，這樣便不會影響apktool等工具進行反編譯。對於百度所使用的抹除方法指令的手段，咱們也能夠監控DoInvoke (ART) 和dvmMterp_invokeMethod (DVM)方法實時的提取有效指令；也能夠修改還原的dex文件，去掉調用百度中抹除指令的JNI方法的指令，這樣的話一樣能夠從內存中獲取有效的指令。

4、技術展望

破除app的保護，主要的手段就是從內存中拿到有效的執行數據，這樣關鍵點就在於時機的選擇或主動觸發，從而保證內存中存在有效的數據。因此app保護技術一個重要的關注點也就在於如何打亂時機，使破解者沒法找到一個關鍵點來獲取到有效的dex文件。下一步的發展趨勢是可能使用虛擬機殼的技術。雖然實現上並無太多障礙，可是因爲效率緣由，距離實用仍是有一些距離的。

此外，一個簡單的方法是能夠將關鍵的代碼編寫爲native指令，經過JNI來調用，增長逆向的難度。也能夠對dex中的dalvik指令進行控制流混淆。

對於ART下的保護，因爲設備依賴性的問題，其實仍是使用解釋執行的方式來運行。因爲ART下的dex文件須要編譯爲native指令，尤爲對於static方法的調用，使用的是肯定的地址進行調用的。若是想提早準備一個編譯好的oat文件，除去要繞過運行時對於oat文件和framework的匹配校驗，還須要對這些地址根據不一樣設備的framework進行動態patch。若是能處理好這些的限制，即可以直接提早準備好native指令的oat文件，一樣可以大幅度增長保護的力度。

最後，也能夠經過VMI的方法，監控全部內存寫指令，並輔以人工分析，也能夠逐步地恢復出加固工具的工做原理和流程，有助於自動化分析一些新的保護技術。

做者簡介

張躍騫，安全技術愛好者，看雪社區成員，長期從事系統及軟件安全研究，曾任香港理工大學研究助理，HITCON 2015 講師。

參考文獻：

[1] Axelle Apvrille, 「Cryptography for mobile malware obfuscation,」 http://goo.gl/jOiYHt.

[2] Timothy Strazzere, 「Dex education: Practicing safe dex,」 http://goo.gl/U84ja.

[3] P. Schulz, 「Code protection in android,」 Tech. Rep., 2012. https://net.cs.uni-bonn.de/fileadmin/user_upload/plohmann/2012-Schulz-Code_Protection_in_Android.pdf

[4] Patrick Schulz, Felix Matenaar, 「Android reverse engineering & defenses,」 https://goo.gl/nZEOGm, 2013.

[5] Patrick Schulz, 「Android security analysis challenge: Tampering dalvik bytecode during runtime,」 https://goo.gl/07QBou, 2013.

[6] Axelle Apvrille, 「Playing hide and seek with dalvik executables,」 https://goo.gl/LNIJcx.

[7] Xavier Martin, 「Nifty stuff that you can still do with android,」 http://goo.gl/vEPXsq.

[8] Ruchna Nigam, 「Android packers: Separating from the pack,」 http://goo.gl/FM0lzc.

[9] Tim Strazzere, Jon Sawyer, 「Android hacker protection level 0,」 https://goo.gl/agIEmb.

[10] 「Hide android applications in images,」 https://goo.gl/DDZUjA.

[11] 「Angecryption,」 http://goo.gl/tb6irJ.

[12] Axelle Apvrille, Ruchna Nigam, 「Obfuscation in android malware, and how to fight back,」 https://goo.gl/qw38un.

[13] 「How android malware fights,」 http://goo.gl/4zLoRK.

[14] Rowland YU, 「Android packer: facing the challenges, building solutions,」 https://goo.gl/xrC8xO.

[15] 「Lime-linux memory extractor,」 https://goo.gl/JyUopv.

[16] 「Zjdroid,」 http://goo.gl/xFxxNh, 2015.

[17] Yeongung Park, 「We can still crack you!」 https://goo.gl/7PMn0v.

[18] Jin-hyuk Jung, Jieun Lee, 「Dabid, the powerful interactive android debugger for android malware analysis,」https://goo.gl/KTbLyx.

[19] Y. Zhang, X. Luo, and H. Yin, 「Dexhunter: Toward extracting hidden code from packed android applications,」 in Proc. ESORICS, 2015.

[20] 「DexHunter」, https://github.com/zyq8709/DexHunter

 

android 脫殼 app加固

24 2016-02