Android平臺惡意代碼檢測通用脫殼機的設計

黃燦， 邱衛東， 王力

(上海交通大學 電子信息與電氣工程學院，上海 200240)

Android平臺惡意代碼檢測通用脫殼機的設計

黃燦， 邱衛東， 王力

(上海交通大學 電子信息與電氣工程學院，上海 200240)

隨著移動互聯網的普及，以及Android平臺所占份額的逐步提高，Android平臺應用程序的安全性尤為重要。因此設計了一個基于Android平臺惡意代碼檢測的高效通用脫殼機，并輔以靜態惡意代碼的檢測。詳細介紹了Android平臺主流加固技術以及該通用脫殼機的實現原理和方法，結果表明，該脫殼機能夠應對市面上幾乎所有的主流加固廠商。

惡意代碼檢測； 脫殼機； 加固； 靜態分析

0 引言

近年來智能移動終端和移動互聯網的發展如火如荼，由于Android系統的開放性，現今越來越多的智能終端上都運行著Android系統，Android系統是當前占有市場份額最大的智能移動終端操作系統，安全研究人員亦逐漸聚焦到Android系統應用程序的安全研究上來。對于惡意代碼檢測而言，目前學術界將其分為靜態檢測和動態檢測兩個方向。在靜態檢測領域，安全研究人員開發出了基于代碼相似度檢測的ViewDroid[1]、基于組件的Chex[2]、基于數據流的SCanDroid[3]和基于控制流圖搜索和數據標記的DroidChecker[4]等工具；在動態檢測方面，也有TaintDroid[5]之類的基于污點跟蹤技術的隱私泄露監控系統和VetDroid[6]、DroidScope[7]、CopperDroid[8]之類的細粒度動態行為跟蹤系統等。

其中在Android平臺靜態惡意代碼檢測中最知名的就是Androguard[9]，很多優秀的惡意代碼檢測系統都是基于它進行開發的，同時提供了很多輔助分析模塊供分析人員使用。之后安全研究人員陸續開發了FlowDroid[10]、RiskRanker[11]、DroidMOSS[12]等等靜態分析系統。這些靜態分析系統都利用了Android平臺使用的Java代碼較為容易反編譯的特點，從代碼片段入手進行高效快速的惡意代碼檢測。但是隨著Android平臺軟件保護技術的發展和普及，越來越多的惡意代碼對自身的加固保護進一步增強，且同時由于混淆、花指令和代碼加密等加固技術的不斷加強，導致靜態工具檢測面臨諸多困難，難以實現大規模部署的應用，所以當前的靜態分析系統往往需要一個功能強大的通用脫殼機加以輔助。

本文結合當前Android平臺主流加固技術設計并實現了一個針對應用層的高效率通用脫殼機，本文的組織架構如下：

第二章詳細介紹了Android平臺應用層加固的背景知識，具體包括Android DEX文件的加載機制，應用層加固的主要類別以及編寫脫殼機所面臨的主要困難。

第三章設計并實現了該通用脫殼機，并詳細闡述了反-反模擬器模塊、DEX應用層脫殼的工程實現細節和相關原理等。

第四章對脫殼機的覆蓋面和時間效率方面進行了全方位的測試，對實驗結果進行分析，驗證系統性能。

本文最后指出了當前脫殼機的優缺點，提出了改進方法，并說明了下一步的研究方向。

1 加固背景知識

Android應用程序是APK文件，本質是一個ZIP的壓縮文件，開發人員編寫的應用層代碼會被編譯成Dex文件并打包進APK文件中。由于Java應用層代碼容易被反編譯，被攻擊者破解，所以開發者為了保護應用程序，對抗逆向分析，而對應用進行加固混淆等處理，后文的分析均是基于Android 4.1.2的Android源碼。

1.1 Android文件加載機制

在Android系統中加載APK一般有兩種方式，一種是通過文件的方式加載，另一種是通過字節流的方式加載，這兩種方式本質上是一致的，只是數據的存儲方式不同。在Android系統中，每個類加載創建進程時都會通過類PathClassLoader進行加載，同時開發者也可以通過DexClassLoader動態加載額外的dex文件。PathClassLoader和DexClassLoader都繼承自BaseDexClassLoader這個基類，二者會生成一個DexPathList對象，在DexPathList的構造函數中調用makeDexElements()函數，繼而在makeDexElement()函數中調用LoadDexFile()對dex文件進行處理 ，LoadDexFile()最終返回DexFile對象。LoadDexFile()函數的執行細節是通過JNI進入原生層，調用原生層的相關函數進行處理的。

進入原生層之后，針對DEX文件和二進制字節流，系統分別提供了DvmDexFileOpenFromFd和DvmDexFileOpenFromPartial這兩個函數進行處理，這兩個函數的最終目的都是構造一個DexOrJar結構體，并通過JNI把該結構體的地址保存到DexFile的私有成員變量mCookie中，這一過程結束之后退回到應用層，基本上完成了一個Android類的加載過程，后續系統模塊中的Dex監控模塊和DexDump模塊都是基于此加載流程實現的。

1.2 加固技術

應用層加固一般采用采取自保護變形技術[13]對自身進行保護，目前加固變形技術包括文件整體加密、字節流加密、關鍵信息破壞、字節碼抽取、字節碼變形和混合方案等。

文件整體加密是針對classes.dex文件進行加密，并以資源文件的方式保存在系統的某處，當進程加完載殼程序后，殼程序會從資源文件處解密dex文件，再將解密后的dex文件保存在文件系統某處，最終動態加載進內存。

字節流加密所通過二進制字節流的方式加載dex文件，其解密過程是在內存中完成，原始的dex文件不會保留在文件系統。

關鍵信息破壞則是同時使用上面兩種加殼方案，解壓后的dex文件最終會完整的存放于內存的某個連續區域，因此只要找到其起始地址和長度，分析人員就能從內存中完整的dump出classes.dex。但對于Dalvik虛擬機而言，要正確執行一個dex文件并不需要該文件的結構信息，所以可對dex文件的結構信息進行破壞，從而影響分析人員對dump下來的文件進行靜態分析。

字節碼抽取是關鍵信息破壞方案的進一步發展，主要是把classes.dex的內容分散存放。這個技術利用了dex文件的數據是使用偏移值進行讀取的原理，針對這種情況，分析人員必須對當前進程中分布在不同區域的數據進行重建，重新構造出一個連續存儲的dex文件，并保存到文件系統。

字節碼變形的主要目的有兩個，一個是隱藏字節碼，二是提高靜態分析的難度。各家加固服務技術實現細節千差萬別，但技術原理類似，其一是修改Encode Method結構的access_flags和code_off字段，使原來的方法變成native方法。當該方法被執行時，通過JNI機制，就會先執行殼的邏輯，殼會還原Method屬性，然后通過JNI所提供的接口，重新執行原來的字節碼。對于這種方式，如果用靜態分析工具分析，會發現那些被標記為native的方法只剩下方法聲明，從而達到隱藏字節碼的目的。

其二是在加固時，先為選中的方法添加一個跳轉方法，這個跳轉方法的DexCode和原方法完全相同，而原方法按方式一處理成native方法。當執行到殼邏輯時，殼再通過JNI所提供的接口，調用跳轉方法。這種方式改變了原程序邏輯流程，增加了分析的困難。

混合類型是以上所述方法的綜合體，文件結構更加碎片化、字節碼變形更加多樣化、加密更加精細化，因此分析難度更高。

1.3 脫殼機面臨的困難

目前加固服務提供商一般還會結合其他防御手段，比如防注入、反調試、反模擬器、防dump等，這些防御手段的混合使用，進一步提高了脫殼的難度。

1) 防注入技術[14]可以有效避免內存dump，關鍵函數被掛鉤等，比如Apkprotect[15]會遍歷檢查/proc/self/maps的加載列表，如果發現未知的dex文件被加載，則直接退出進程。

2) 反調試[16]可以勘察出當前進程是否被調試，一旦發現被調試則直接退出進程。主要分為：對調試器監測，進程運行狀態檢測以及多個進程相互ptrace[17]實現反調試。

3) 反dump技術主要有如下兩種方法。一種是利用Inotify機制，該機制提供了監視文件系統的事件機制，可用于監視個別文件，或者監控目錄。二是對read函數等進行hook，檢測read函數當前讀取的數據是否屬于關鍵內存區域，從而阻止內存dump。

4) 反模擬器技術主要用于檢測當前運行環境是否為模擬器，常見的模擬器檢測技術主要分為基于特殊文件的模擬器檢測技術以及基于系統特定屬性的模擬器檢測技術兩種。在Android模擬器中存在一些獨屬于模擬器的特殊文件，應用程序可以通過檢測當前系統中是否含有這些特殊文件來確定應用是否處于模擬器的運行環境，同時模擬器中Android系統的一些特定屬性與實體機不同，因此也可以利用系統中的這些特殊屬性進行檢測，詳細的特殊文件和屬性，如表1所示。

表1 模擬器檢測相關文件和屬性列表

2 脫殼機設計與實現

綜合之前所述，本文設計了一個針對應用層的通用脫殼機，從上而下分為DEX Dump應用層、反-反模擬器模塊和DEX加載監控模塊、API HOOK框架層和QEMU Android模擬器層五個層次，脫殼機的整體架構,如圖1所示。

圖1 脫殼機架構

對于DEX Dump應用層而言，當殼程序完整解固后，在當前進程中必然保存著完整的dex信息(或者部分信息被篡改，但依然可以推斷出原始信息)，因此只要成功注入到目標進程，通過收集運行時的關鍵信息，再利用Memory Dump或重建的技術手段，就可以把原始的dex數據提取出來。本文基于Cydia Substrate框架，在dex加載的合適時機添加監控點，收集脫殼所需的關鍵信息。同時考慮到某些加固方案可能會在加載后做一些內容恢復或替換的操作，因此脫殼機會在整個應用都正常運行起來，待“殼”的修復動作達到穩定之后再進行脫殼，這樣就完成了應用層的脫殼。

同時為了方便在模擬器上進行后續工業級大規模的部署，本文開發了反-反模擬器模塊，該模塊主要用于隱藏模擬器的特殊文件和屬性，以應對模擬器的檢測，整體基于API HOOK框架層而實現。

API HOOK框架層主要是為上層模塊提供服務，涉及Java Hook和Inline Hook等技術，該模塊整體基于Cydia Substrate框架實現。另外在這個模塊額外添加了過濾策略，過濾掉系統內置的應用，把作用范圍限制在本文關注的樣本進程中，該過濾策略作用于Hook Layer以上的所有模塊。

QEMU Android模擬器層主要是為后續大規模部署、反-反模擬器模塊等服務。

由于該脫殼機是面向海量樣本的，且要求達到完全自動化的并發執行任務，脫殼機采用Google原生Android模擬器作為工作環境，模擬器硬件配置，如表2所示。

表2 模擬器硬件配置

2.1 反-反模擬器模塊

加固軟件會檢測模擬器系統特殊文件和系統特殊屬性，而這些操作都需要通過調用libc.so庫中的fopen等API函數讀取系統文件屬性來做判斷，考慮到API函數執行的正常流程是先從API到ABI再到內核層，本模塊采取的方案是HOOK ABI層次，由于ABI是所有函數執行必須經過的層次，通過HOOK ABI調用接口，使其先執行自定義的系統函數，再返回正常的后續邏輯，這樣可以避免諸多限制和制約。

本模塊最后通過LKM實現對Linux內核功能的擴展，通過在ABI層面HOOK模擬器常用的系統庫函數而得以實現該模塊。

2.2 DEX應用層

針對DEX加載監控模塊，本系統主要是在APK加載流程中添加了兩個監控點：BaseDexClassLoader的構造函數和dvmDexFileOpenPartial函數。通過HOOK BaseDexClassLoader的構造函數，可以得到所有繼承于此類的BaseDexClassLoader以及子類實例引用。通過這些實例引用，可以獲得DexOrJar指針，為此本脫殼器設計了類ClassLoaderDumper，該類負責存儲這些實例引用對象。

正常的加載流程只能加載Dex文件，而通過dvmDexFileOpenPartial可以加載Dex二進制字節流，因此通過這個函數，可以獲取保存Dex數據的內存地址Addr，數據長度Len和構造DvmDex結構的地址，本脫殼器設計了類HookDexDumper負責存儲這些數據應用層脫殼所涉及到的幾個關鍵類之間的聯系，如圖3所示。

Dex Dump是應用層DEX脫殼機的核心部分，一共包含5個處理流程，并封裝成5類，它們分別是HookDexDumper、DexOrJarDumper、ClassLoaderDumper、DirectlyDumper和RebuildDexDumper，且都繼承自類BaseDexDumper。這5類所完成的流程互相依賴，而且每個流程都會有相應的輸出，當所有的流程運行完畢之后，會得到一個或多個dex文件，緊接著脫殼機會進行分組，并從每組中提取出最優的文件。

HookDexDumper類，當監控到dvmDexFileOpenPartial函數被調用時，脫殼機會馬上生成HookDexDumper對象，HookDexDumper根據傳入的addr和len，把dex的所有數據復制保存到copyData_，這樣做主要是考慮到后面dex數據有被篡改的可能，然后HookDexDumper會先把“殼”過濾掉，然后將copyData_寫入文件系統。

DexOrJarDumper類負責處理DexOrJar結構。其中dump的過程相比于其他的幾個流程會復雜一點，先通過pDvmDex獲取dex在內存的中開始地址addr和size。如果是dex文件，則檢查dex文件頭是否合法，主要是檢查是否被篡改，如果合法則啟用DirectlyDumper流程。考慮到有字節碼抽離的情況，因此緊接著再啟用RebuildDexDumper流程。如果是odex文件，過程與dex文件類似。

ClassLoaderDumper類。任何繼承自BaseDexClassLoader的子類在創建實例時都要觸發ClassLoaderDumper類的創建。該類主要保存Java實例的引用。ClassLoaderDumper的Dump的邏輯很簡單，先從classloader_成員變量中獲取所有DexOrJar的地址，然后調用DexOrJarDumper的Dump方法。

DirectlyDumper主要根據傳入的addr和size把dex寫入文件系統，其過程跟HookDexDumper流程相比 主要是多了dex和odex的判斷，影響最終寫入文件的命名后綴。RebuildDexDumper類比較復雜，除了解決字節碼抽離的情況，同時在重建的過程中能夠修正被某些刻意篡改的數值。

圖3 應用層關鍵類關系

這5類所完成的流程相互依賴，并且每個流程都會產生相應的輸出，當所有的流程運行完畢之后，便會得到多個dex文件，這邊是DEX應用層所輸出的結果，DEX應用層類協作脫殼的完整流程圖,如圖4所示。

圖4 應用層類協作脫殼流程

3 試驗與討論

3.1 脫殼機有效性分析

使用此脫殼機對市場上絕大部分加固廠商的普通版加固產品進行脫殼測試，測試結果，如表3所示。

表3 脫殼機效果展示

從上面的結果可以看出，本文設計的脫殼機能夠應對市面上所有主流的加固廠商。

3.2 脫殼機效率

脫殼機的效率主要參考單個加固樣本的平均脫殼時間。脫殼時間是指從脫殼機獲取樣本后開始準備脫殼任務開始，但脫殼完成輸出脫殼后樣本文件為止。中間主要包括啟動脫殼機時間，安裝待脫殼樣本事件以及脫殼時間。其中啟動脫殼機時間一般固定不變，而后兩者會根據具體樣本的不同變化而變化。通過對隨機抽取10個加固樣本，分別對它們進行脫殼處理，各個樣本的脫殼時間,如圖5所示。

圖5 脫殼時間

從圖5可以看出，每個樣本的脫殼時間并不相同，這主要跟樣本本身的大小有關。一般情況下，樣本越大，其安裝時間就越長，脫殼時間也越長，其最終所需要的脫殼時間就越大。估算出平均需要的脫殼時間為132.9秒，那么一臺模擬器一天可以脫殼650個樣本，假設每臺主機可同時運行6臺模擬器，共10臺主機，那么一天一共可以完成39 000的脫殼量，足夠覆蓋每天的新增樣本數。

4 總結

本文設計了一個基于Android平臺惡意代碼檢測靜態分析的通用脫殼機，以輔助靜態分析能夠分析加固后的應用程序，該脫殼機能夠應對市面上絕大部分代碼在應用層采取的加固技術，且脫殼迅速，從而極大的提高了靜態檢測的準確率和效率。

由于本系統未深入探討原生層的脫殼問題，但考慮到雙層協作脫殼是后續的主流，因此原生層的脫殼問題值得進一步研究和關注。后期可以借鑒Windows平臺PE文件格式的一些成熟檢測技術，拓寬對原生層脫殼的處理。

其次脫殼與惡意代碼檢測息息相關，未來可以考慮將本系統與惡意代碼檢測相結合，脫殼后運用大數據和機器學習的方法建立惡意代碼行為模式，進行漏洞探測等研究，以便建立更加智能化的惡意代碼檢測機制，提供更加精確的查殺結果。

[1] Zhang F, Huang H, Zhu S, et al. ViewDroid: towards obfuscation-resilient mobile application repackaging detection[C]//Proceedings of the 2014 ACM Conference on Security and Privacy in Wireless & Mobile Networks, 2014: 25-36.

[2] Lu L, Li Z, Wu Z, et al. Chex: statically vetting android apps for component hijack-ing vulnerabilities[C]//Proceedings of the 2012 ACM Conference on Computer and Communications Security, 2012: 229-240.

[3] Fuchs A P, Chaudhuri A, Foster J S. SCanDroid: Automated security certification of Android applications[R]. CS-TR-4991 of University of Maryland Tech, 2009:1-16.

[4] Chan P P F, Hui L C K, Yiu S M. Droidchecker: analyzing android applications for capability leak[C]//Proceedings of the Fifth ACM Conference on Security and Privacy in Wireless and Mobile Networks, 2012: 125-136.

[5] Enck W, Gilbert P, Han S, et al. TaintDroid: an information-flow tracking system for realtime privacy monitoring on smartphones[J]. ACM Transactions on Computer Systems (TOCS), 2014, 32(2): 5.

[6] Zhang Y, Yang M, Xu B, et al. Vetting undesirable behaviors in android apps with permission use analysis[C]//Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, 2013: 611-622.

[7] Yan L K, Yin H. Droidscope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis[C]//the 21st USE-NIX Security Symposium (USENIX Security 12), 2012: 569-584.

[8] Reina A, Fattori A, Cavallaro L. A system Call-centric Analysis and Stimulation Technique to Automatically Reconstruct Android Malware Behaviors[J]. EuroSec, 2013: 1-6.

[9] Desnos A. Androguard-Reverse Engineering, Malware and Goodware Analysis of Android Applications[EB/OL].http://code.google.com/p/androguard,2013-03-26/2016-12-22.

[10] Arzt S, Rasthofer S, Fritz C, et al. Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps[J]. ACM SIGPLAN Notices, 2014, 49(6): 259-269.

[11] Grace M, Zhou Y, Zhang Q, et al. Riskranker: Scalable and accurate zero-day an-droid malware detection[C]//Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services, 2012: 281-294.

[12] Huang H, Zhu S, Liu P, et al. A Framework for Evaluating Mobile APP Repackaging Detection Algorithms[C]//International Conference on Trust and Trustworthy Compu-ting. Springer Berlin Heidelberg, 2013: 169-186.

[13] Schlegel R, Zhang K, Zhou X, et al. Soundcomber: A Stealthy and Context-Aware Sound Trojan for Smartphones[C]//Proceedings of the 18th Annual Symposium on Network and Distributed System Security (NDSS), 2011, 11: 17-33.

[14] Lin J C, Chen J M. An automatic revised tool for anti-malicious injection[C]// Proceedings of the 6th IEEE International Conference on Computer and Information Technology, 2006: 164-164.

[15] Love R. Kernel korner: Intro to inotify[J]. Linux Journal, 2005, 2005(139): 8.

[16] Gagnon M N, Taylor S, Ghosh A K. Software protection through anti-debugging[J]. Security & Privacy, 2007, 5(3): 82-84.

[17] Dike J. A user-mode port of the Linux kernel[C]//Proceedings of the 2000 Linux Showcase and Conference. 2000, 2(1): 2.1.

Design of the Universal Unpacker for Malicious Code Detection on the Android Platform

Huang Can,Qiu Weidong,Wang Li

(Shanghai JiaoTong University， School of Electronic Information and Electrical Engineering, Shanghai 200240, China)

With the popularity of mobile Internet and the growing share of the Android platform, the safety of the application on the Android platform has become an important issue. Hence, this paper has designed an efficient universal unpacker for the malicious code detection based on the Android platform in aid of the static analysis. The mainstream reinforcement technologies for the Android as well as the principle and method of realizing the universal unpacker have been illustrated. It is found that the unpacker can satisfy the needs of almost all mainstream reinforcement companies in the market.

Malicious code detection; Unpacker; Reinforcement; Static analysis

黃 燦(1991-)，男，碩士研究生, 研究方向：移動安全。 邱衛東(1973-)，男，教授，博士，研究方向：計算機取證、密碼分析破解、密鑰防護及電子信息對抗。 王 力(1993-)，男，碩士研究生，研究方向：移動安全。

1007-757X(2017)04-0048-05

TP311

A

2016.09.06)