Android平臺(tái)惡意代碼檢測(cè)通用脫殼機(jī)的設(shè)計(jì)

黃燦， 邱衛(wèi)東， 王力

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

Android平臺(tái)惡意代碼檢測(cè)通用脫殼機(jī)的設(shè)計(jì)

黃燦， 邱衛(wèi)東， 王力

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

隨著移動(dòng)互聯(lián)網(wǎng)的普及，以及Android平臺(tái)所占份額的逐步提高，Android平臺(tái)應(yīng)用程序的安全性尤為重要。因此設(shè)計(jì)了一個(gè)基于Android平臺(tái)惡意代碼檢測(cè)的高效通用脫殼機(jī)，并輔以靜態(tài)惡意代碼的檢測(cè)。詳細(xì)介紹了Android平臺(tái)主流加固技術(shù)以及該通用脫殼機(jī)的實(shí)現(xiàn)原理和方法，結(jié)果表明，該脫殼機(jī)能夠應(yīng)對(duì)市面上幾乎所有的主流加固廠商。

惡意代碼檢測(cè)； 脫殼機(jī)； 加固； 靜態(tài)分析

0 引言

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

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

本文結(jié)合當(dāng)前Android平臺(tái)主流加固技術(shù)設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)針對(duì)應(yīng)用層的高效率通用脫殼機(jī)，本文的組織架構(gòu)如下：

第二章詳細(xì)介紹了Android平臺(tái)應(yīng)用層加固的背景知識(shí)，具體包括Android DEX文件的加載機(jī)制，應(yīng)用層加固的主要類別以及編寫脫殼機(jī)所面臨的主要困難。

第三章設(shè)計(jì)并實(shí)現(xiàn)了該通用脫殼機(jī)，并詳細(xì)闡述了反-反模擬器模塊、DEX應(yīng)用層脫殼的工程實(shí)現(xiàn)細(xì)節(jié)和相關(guān)原理等。

第四章對(duì)脫殼機(jī)的覆蓋面和時(shí)間效率方面進(jìn)行了全方位的測(cè)試，對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析，驗(yàn)證系統(tǒng)性能。

本文最后指出了當(dāng)前脫殼機(jī)的優(yōu)缺點(diǎn)，提出了改進(jìn)方法，并說明了下一步的研究方向。

1 加固背景知識(shí)

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

1.1 Android文件加載機(jī)制

在Android系統(tǒng)中加載APK一般有兩種方式，一種是通過文件的方式加載，另一種是通過字節(jié)流的方式加載，這兩種方式本質(zhì)上是一致的，只是數(shù)據(jù)的存儲(chǔ)方式不同。在Android系統(tǒng)中，每個(gè)類加載創(chuàng)建進(jìn)程時(shí)都會(huì)通過類PathClassLoader進(jìn)行加載，同時(shí)開發(fā)者也可以通過DexClassLoader動(dòng)態(tài)加載額外的dex文件。PathClassLoader和DexClassLoader都繼承自BaseDexClassLoader這個(gè)基類，二者會(huì)生成一個(gè)DexPathList對(duì)象，在DexPathList的構(gòu)造函數(shù)中調(diào)用makeDexElements()函數(shù)，繼而在makeDexElement()函數(shù)中調(diào)用LoadDexFile()對(duì)dex文件進(jìn)行處理 ，LoadDexFile()最終返回DexFile對(duì)象。LoadDexFile()函數(shù)的執(zhí)行細(xì)節(jié)是通過JNI進(jìn)入原生層，調(diào)用原生層的相關(guān)函數(shù)進(jìn)行處理的。

進(jìn)入原生層之后，針對(duì)DEX文件和二進(jìn)制字節(jié)流，系統(tǒng)分別提供了DvmDexFileOpenFromFd和DvmDexFileOpenFromPartial這兩個(gè)函數(shù)進(jìn)行處理，這兩個(gè)函數(shù)的最終目的都是構(gòu)造一個(gè)DexOrJar結(jié)構(gòu)體，并通過JNI把該結(jié)構(gòu)體的地址保存到DexFile的私有成員變量mCookie中，這一過程結(jié)束之后退回到應(yīng)用層，基本上完成了一個(gè)Android類的加載過程，后續(xù)系統(tǒng)模塊中的Dex監(jiān)控模塊和DexDump模塊都是基于此加載流程實(shí)現(xiàn)的。

1.2 加固技術(shù)

應(yīng)用層加固一般采用采取自保護(hù)變形技術(shù)[13]對(duì)自身進(jìn)行保護(hù)，目前加固變形技術(shù)包括文件整體加密、字節(jié)流加密、關(guān)鍵信息破壞、字節(jié)碼抽取、字節(jié)碼變形和混合方案等。

文件整體加密是針對(duì)classes.dex文件進(jìn)行加密，并以資源文件的方式保存在系統(tǒng)的某處，當(dāng)進(jìn)程加完載殼程序后，殼程序會(huì)從資源文件處解密dex文件，再將解密后的dex文件保存在文件系統(tǒng)某處，最終動(dòng)態(tài)加載進(jìn)內(nèi)存。

字節(jié)流加密所通過二進(jìn)制字節(jié)流的方式加載dex文件，其解密過程是在內(nèi)存中完成，原始的dex文件不會(huì)保留在文件系統(tǒng)。

關(guān)鍵信息破壞則是同時(shí)使用上面兩種加殼方案，解壓后的dex文件最終會(huì)完整的存放于內(nèi)存的某個(gè)連續(xù)區(qū)域，因此只要找到其起始地址和長(zhǎng)度，分析人員就能從內(nèi)存中完整的dump出classes.dex。但對(duì)于Dalvik虛擬機(jī)而言，要正確執(zhí)行一個(gè)dex文件并不需要該文件的結(jié)構(gòu)信息，所以可對(duì)dex文件的結(jié)構(gòu)信息進(jìn)行破壞，從而影響分析人員對(duì)dump下來的文件進(jìn)行靜態(tài)分析。

字節(jié)碼抽取是關(guān)鍵信息破壞方案的進(jìn)一步發(fā)展，主要是把classes.dex的內(nèi)容分散存放。這個(gè)技術(shù)利用了dex文件的數(shù)據(jù)是使用偏移值進(jìn)行讀取的原理，針對(duì)這種情況，分析人員必須對(duì)當(dāng)前進(jìn)程中分布在不同區(qū)域的數(shù)據(jù)進(jìn)行重建，重新構(gòu)造出一個(gè)連續(xù)存儲(chǔ)的dex文件，并保存到文件系統(tǒng)。

字節(jié)碼變形的主要目的有兩個(gè)，一個(gè)是隱藏字節(jié)碼，二是提高靜態(tài)分析的難度。各家加固服務(wù)技術(shù)實(shí)現(xiàn)細(xì)節(jié)千差萬別，但技術(shù)原理類似，其一是修改Encode Method結(jié)構(gòu)的access_flags和code_off字段，使原來的方法變成native方法。當(dāng)該方法被執(zhí)行時(shí)，通過JNI機(jī)制，就會(huì)先執(zhí)行殼的邏輯，殼會(huì)還原Method屬性，然后通過JNI所提供的接口，重新執(zhí)行原來的字節(jié)碼。對(duì)于這種方式，如果用靜態(tài)分析工具分析，會(huì)發(fā)現(xiàn)那些被標(biāo)記為native的方法只剩下方法聲明，從而達(dá)到隱藏字節(jié)碼的目的。

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

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

1.3 脫殼機(jī)面臨的困難

目前加固服務(wù)提供商一般還會(huì)結(jié)合其他防御手段，比如防注入、反調(diào)試、反模擬器、防dump等，這些防御手段的混合使用，進(jìn)一步提高了脫殼的難度。

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

2) 反調(diào)試[16]可以勘察出當(dāng)前進(jìn)程是否被調(diào)試，一旦發(fā)現(xiàn)被調(diào)試則直接退出進(jìn)程。主要分為：對(duì)調(diào)試器監(jiān)測(cè)，進(jìn)程運(yùn)行狀態(tài)檢測(cè)以及多個(gè)進(jìn)程相互ptrace[17]實(shí)現(xiàn)反調(diào)試。

3) 反dump技術(shù)主要有如下兩種方法。一種是利用Inotify機(jī)制，該機(jī)制提供了監(jiān)視文件系統(tǒng)的事件機(jī)制，可用于監(jiān)視個(gè)別文件，或者監(jiān)控目錄。二是對(duì)read函數(shù)等進(jìn)行hook，檢測(cè)read函數(shù)當(dāng)前讀取的數(shù)據(jù)是否屬于關(guān)鍵內(nèi)存區(qū)域，從而阻止內(nèi)存dump。

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

表1 模擬器檢測(cè)相關(guān)文件和屬性列表

2 脫殼機(jī)設(shè)計(jì)與實(shí)現(xiàn)

綜合之前所述，本文設(shè)計(jì)了一個(gè)針對(duì)應(yīng)用層的通用脫殼機(jī)，從上而下分為DEX Dump應(yīng)用層、反-反模擬器模塊和DEX加載監(jiān)控模塊、API HOOK框架層和QEMU Android模擬器層五個(gè)層次，脫殼機(jī)的整體架構(gòu),如圖1所示。

圖1 脫殼機(jī)架構(gòu)

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

同時(shí)為了方便在模擬器上進(jìn)行后續(xù)工業(yè)級(jí)大規(guī)模的部署，本文開發(fā)了反-反模擬器模塊，該模塊主要用于隱藏模擬器的特殊文件和屬性，以應(yīng)對(duì)模擬器的檢測(cè)，整體基于API HOOK框架層而實(shí)現(xiàn)。

API HOOK框架層主要是為上層模塊提供服務(wù)，涉及Java Hook和Inline Hook等技術(shù)，該模塊整體基于Cydia Substrate框架實(shí)現(xiàn)。另外在這個(gè)模塊額外添加了過濾策略，過濾掉系統(tǒng)內(nèi)置的應(yīng)用，把作用范圍限制在本文關(guān)注的樣本進(jìn)程中，該過濾策略作用于Hook Layer以上的所有模塊。

QEMU Android模擬器層主要是為后續(xù)大規(guī)模部署、反-反模擬器模塊等服務(wù)。

由于該脫殼機(jī)是面向海量樣本的，且要求達(dá)到完全自動(dòng)化的并發(fā)執(zhí)行任務(wù)，脫殼機(jī)采用Google原生Android模擬器作為工作環(huán)境，模擬器硬件配置，如表2所示。

表2 模擬器硬件配置

2.1 反-反模擬器模塊

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

本模塊最后通過LKM實(shí)現(xiàn)對(duì)Linux內(nèi)核功能的擴(kuò)展，通過在ABI層面HOOK模擬器常用的系統(tǒng)庫函數(shù)而得以實(shí)現(xiàn)該模塊。

2.2 DEX應(yīng)用層

針對(duì)DEX加載監(jiān)控模塊，本系統(tǒng)主要是在APK加載流程中添加了兩個(gè)監(jiān)控點(diǎn)：BaseDexClassLoader的構(gòu)造函數(shù)和dvmDexFileOpenPartial函數(shù)。通過HOOK BaseDexClassLoader的構(gòu)造函數(shù)，可以得到所有繼承于此類的BaseDexClassLoader以及子類實(shí)例引用。通過這些實(shí)例引用，可以獲得DexOrJar指針，為此本脫殼器設(shè)計(jì)了類ClassLoaderDumper，該類負(fù)責(zé)存儲(chǔ)這些實(shí)例引用對(duì)象。

正常的加載流程只能加載Dex文件，而通過dvmDexFileOpenPartial可以加載Dex二進(jìn)制字節(jié)流，因此通過這個(gè)函數(shù)，可以獲取保存Dex數(shù)據(jù)的內(nèi)存地址Addr，數(shù)據(jù)長(zhǎng)度Len和構(gòu)造DvmDex結(jié)構(gòu)的地址，本脫殼器設(shè)計(jì)了類HookDexDumper負(fù)責(zé)存儲(chǔ)這些數(shù)據(jù)應(yīng)用層脫殼所涉及到的幾個(gè)關(guān)鍵類之間的聯(lián)系，如圖3所示。

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

HookDexDumper類，當(dāng)監(jiān)控到dvmDexFileOpenPartial函數(shù)被調(diào)用時(shí)，脫殼機(jī)會(huì)馬上生成HookDexDumper對(duì)象，HookDexDumper根據(jù)傳入的addr和len，把dex的所有數(shù)據(jù)復(fù)制保存到copyData_，這樣做主要是考慮到后面dex數(shù)據(jù)有被篡改的可能，然后HookDexDumper會(huì)先把“殼”過濾掉，然后將copyData_寫入文件系統(tǒng)。

DexOrJarDumper類負(fù)責(zé)處理DexOrJar結(jié)構(gòu)。其中dump的過程相比于其他的幾個(gè)流程會(huì)復(fù)雜一點(diǎn)，先通過pDvmDex獲取dex在內(nèi)存的中開始地址addr和size。如果是dex文件，則檢查dex文件頭是否合法，主要是檢查是否被篡改，如果合法則啟用DirectlyDumper流程?？紤]到有字節(jié)碼抽離的情況，因此緊接著再啟用RebuildDexDumper流程。如果是odex文件，過程與dex文件類似。

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

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

圖3 應(yīng)用層關(guān)鍵類關(guān)系

這5類所完成的流程相互依賴，并且每個(gè)流程都會(huì)產(chǎn)生相應(yīng)的輸出，當(dāng)所有的流程運(yùn)行完畢之后，便會(huì)得到多個(gè)dex文件，這邊是DEX應(yīng)用層所輸出的結(jié)果，DEX應(yīng)用層類協(xié)作脫殼的完整流程圖,如圖4所示。

圖4 應(yīng)用層類協(xié)作脫殼流程

3 試驗(yàn)與討論

3.1 脫殼機(jī)有效性分析

使用此脫殼機(jī)對(duì)市場(chǎng)上絕大部分加固廠商的普通版加固產(chǎn)品進(jìn)行脫殼測(cè)試，測(cè)試結(jié)果，如表3所示。

表3 脫殼機(jī)效果展示

從上面的結(jié)果可以看出，本文設(shè)計(jì)的脫殼機(jī)能夠應(yīng)對(duì)市面上所有主流的加固廠商。

3.2 脫殼機(jī)效率

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

圖5 脫殼時(shí)間

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

4 總結(jié)

本文設(shè)計(jì)了一個(gè)基于Android平臺(tái)惡意代碼檢測(cè)靜態(tài)分析的通用脫殼機(jī)，以輔助靜態(tài)分析能夠分析加固后的應(yīng)用程序，該脫殼機(jī)能夠應(yīng)對(duì)市面上絕大部分代碼在應(yīng)用層采取的加固技術(shù)，且脫殼迅速，從而極大的提高了靜態(tài)檢測(cè)的準(zhǔn)確率和效率。

由于本系統(tǒng)未深入探討原生層的脫殼問題，但考慮到雙層協(xié)作脫殼是后續(xù)的主流，因此原生層的脫殼問題值得進(jìn)一步研究和關(guān)注。后期可以借鑒Windows平臺(tái)PE文件格式的一些成熟檢測(cè)技術(shù)，拓寬對(duì)原生層脫殼的處理。

其次脫殼與惡意代碼檢測(cè)息息相關(guān)，未來可以考慮將本系統(tǒng)與惡意代碼檢測(cè)相結(jié)合，脫殼后運(yùn)用大數(shù)據(jù)和機(jī)器學(xué)習(xí)的方法建立惡意代碼行為模式，進(jìn)行漏洞探測(cè)等研究，以便建立更加智能化的惡意代碼檢測(cè)機(jī)制，提供更加精確的查殺結(jié)果。

[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-)，男，碩士研究生, 研究方向：移動(dòng)安全。 邱衛(wèi)東(1973-)，男，教授，博士，研究方向：計(jì)算機(jī)取證、密碼分析破解、密鑰防護(hù)及電子信息對(duì)抗。 王 力(1993-)，男，碩士研究生，研究方向：移動(dòng)安全。

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

TP311

A

2016.09.06)