ART虛擬機中的DEX文件脫殼技術

蔣鐘慶，周安民，賈 鵬

(四川大學 電子信息學院，成都 610065)

ART虛擬機中的DEX文件脫殼技術

蔣鐘慶，周安民*，賈 鵬

(四川大學 電子信息學院，成都 610065)

在對現有的DEX加固技術和脫殼技術進行系統學習和研究的基礎上，提出和實現了一種基于Android ART虛擬機(VM)的DEX脫殼方案。該方案能夠從加固的Android應用中還原出原始DEX文件，其核心思想是將靜態插樁和模擬運行技術相結合，以通用的方式實現零知識有效脫殼。首先, 在ART虛擬機的解釋器里插入監測代碼來定位脫殼點; 然后, 在內存中進行模擬運行，解析相應的結構體指針,得到原始DEX文件數據在內存中的位置; 最后, 收集這些數據，并按照DEX文件的格式對這些數據進行重組，恢復出應用程序的原始DEX文件，實現脫殼。實驗結果表明，所提出的基于ART虛擬機的DEX自動化脫殼方案在引入較小啟動延遲的情況下，能夠很好地實現對加殼的DEX文件的零知識脫殼。

ART；DEX脫殼；解釋器；模擬運行；DEX重組

0 引言

Android系統自誕生以來的短短幾年時間，便迅速占領了智能手機市場。在這個過程中，Android系統不斷地進行優化和改進，底層虛擬機也從Dalvik換成了ART(Android Runtime)[1]。在ART虛擬機(Virtual Machine, VM)出現之前，Android系統使用Dalvik作為解釋執行Android應用的虛擬機，雖然Dalvik使用了JIT(Just In Time)技術[2]，但是在效率上還是遠不及iOS(iPhone Operating System)和Windows phone系統。這是因為Dalvik在運行時需要動態地將DEX字節碼翻譯成本地機器碼執行，而對于運行在iOS和Windows phone上的應用程序來說，其本身就保存了可直接運行的機器碼，運行時不再需要任何編譯，這樣在執行效率上就比Dalvik高很多。為了提高運行效率，Google公司提出ART虛擬機來改進Dalvik虛擬機的不足。ART虛擬機使用的是AOT(Ahead-Of-Time)技術[3]，每次運行時不再需要編譯任何代碼，這樣就提高了應用的執行效率，系統也更加流暢。由此，很多應用加固服務也開始將自身升級為針對ART環境的加固。加固服務的初衷是保護正常應用不被惡意反編譯、篡改和重打包，但是一些惡意應用也常常使用加固技術[4]對自己進行加固，以躲避安全軟件的查殺。雖然每個加固服務廠商都會在加固之前對應用進行安全檢測，但還是能找到大量的被這些加固服務加固的惡意應用樣本。迄今為止，移動平臺的安全檢測軟件都是基于源碼的檢測[5]，因此無法檢測出被加固的惡意應用[6]。所以在強調加固[3,7]保護研究的同時，也需要對脫殼技術進行研究，這樣才能在保護正常應用程序的同時也能夠防止惡意程序利用加固技術逃避檢測。

本文提出了一個基于ART虛擬機的通用脫殼方案，該方案不需要理解加固服務使用的加固算法和策略，也不需要尋找加固后的APK中存在的特征文件，便可實現DEX的自動化脫殼。

1 ART虛擬機和Dalvik虛擬機

和Dalvik虛擬機一致，ART虛擬機也是由Zygote進程創建的，區別是Dalvik虛擬機在libdvm.so庫中實現，而ART虛擬機在libart.so庫中實現。Android系統以系統屬性persist.sys.dalvik.vm.lib的值來決定運行應用時使用的虛擬機。如果值等于libdvm.so，則在Dalvik虛擬機中運行應用；如果值等于libart.so，則在ART虛擬機中運行應用。

圖1 Android虛擬機的啟動過程Fig. 1 Android VM start process

Dalvik為了減少應用的啟動時間，在應用安裝時會使用Installer類的成員函數dexopt對APK(Android Package)里面的Dalvik字節碼進行優化，在/data/dalvik-cache目錄中生成一個odex[8]文件，這樣就可以避免在每次啟動應用時都要從應用的安裝包里解壓出DEX文件。雖然Dalvik使用了JIT技術，將使用頻率最高的字節碼編譯成本地指令執行，但是應用每次運行時還是需要編譯一部分字節碼。而ART虛擬機就不會存在這些問題，其使用AOT技術將編譯過程置于應用運行之前。ART模式并不要求開發者將自己的應用直接編譯成目標機器碼，而是在應用安裝時，使用dex2oat工具將Dalvik字節碼編譯成本地機器碼，保存為一個OAT文件(一個自定義的ELF文件)，這樣就不會影響原有成熟的Android應用開發方式，同時程序運行時也不需要再對字節碼進行編譯，提高了執行效率。ART機制存在的問題是，安裝應用時耗時較多，同時由于編譯生成的OAT文件比原有的DEX文件大很多，所以也會額外消耗許多存儲空間。

2 加固與脫殼技術簡介

加固技術經歷了從最初的整包加密，到字節碼變形，再到VMProtect的演變過程[9]；脫殼技術也從最初的人工分析，逐漸發展到內存dump[10]，進一步再到現在的基于Android源碼插樁的方式[11]，源碼插樁是迄今為止最高效、最通用的脫殼方式。本文對每種加固與脫殼技術的優缺點進行了總結，如表1、表2所示。

表1 加固技術優缺點Tab. 1 Advantages and disadvantages of packing techniques

表2 脫殼技術優缺點Tab. 2 Advantages and disadvantages of unpacking techniques

整包加密是將整個DEX文件加密保存在其他目錄，運行時通過加固者自己編寫的動態鏈接庫(*.so)將原始的DEX文件解密出來，重新映射到內存中，通過動態加載和反射調用的方式將應用真正的代碼運行起來。這樣能從一定程度上保護APP，同時將解密代碼寫到動態鏈接庫中，增加了人工分析的難度。但是在Android HOOK[12]技術出現后，這種方法就不再適用了，破解者可以通過直接dump應用程序內存的方式得到內存中解密出的DEX文件。于是字節碼變形的加固方式便應運而生[13]，該方法主要是對classes.dex文件的所有method部分的數據進行加密，以隨機的名稱存儲在隱蔽的文件夾中，應用運行時將這部分數據解密出來，映射到內存中，通過修改codeoff指針重新指向這些method，同時還采用各種復雜的Anti-debugging技術[14]來阻礙人工分析和調試，通過只解密恢復當前執行代碼的策略來防止內存dump。VMProtect是目前已知的加固效果最好的方式，但這種方式還停留在研究階段，是未來Android應用加固的發展方向。

脫殼技術的發展是隨著加固技術的發展而發展起來的，其中最通用也最耗時的脫殼方式是人工分析，這種方法在技術發展的早期很有效，其明顯缺點是需要分析人員有大量的分析經驗。基于HOOK技術的脫殼方法隨后出現，通過HOOK技術，脫殼程序可以附加到應用程序的進程中，通過在內存中搜索關鍵詞如dex035、dey036等，定位內存中解密后的DEX文件或者odex文件，直接dump這段內存即可得到應用真正的DEX文件。但是隨著加固技術的發展，加固者會將解密出的DEX文件的魔數(magic)值抹除，并且采用只解密恢復正在執行的method的策略[15]，在這種情況下直接dump內存的方法便不再通用。最近出現的源碼插樁方法可以解決內存dump方法無法解決的問題，該方法通過修改Android源碼，定制一個具有脫殼功能的ROM來實現脫殼。這種方式不受任何Anti-debugging的影響，也不會因為在內存中匹配不到關鍵字而無法脫殼。本文就是在源碼插樁技術的基礎上結合模擬運行技術，提出了一種通用的自動脫殼方法。

3 脫殼模型構建和實現

由第2章的分析可以看出，目前實現自動化脫殼面臨的主要問題有3個方面：

1)通用脫殼點的定位。不同的加固服務會有不同的特征文件和特征函數，如何準確找到一個通用的脫殼位置是一個需要解決的問題，在該脫殼點上能夠對幾乎所有類型的加固服務進行脫殼，該脫殼點不會隨加固服務的變化而變化。

2)繞過Anti-debugging技術。許多Anti-debugging技術會檢測脫殼行為，在檢測到脫殼行為后會終止程序的運行，從而導致脫殼失敗。

3)解密還未運行的代碼。運行時解密策略會導致傳統的脫殼技術不能還原出還未運行的代碼，從而無法還原出完整的原始DEX文件。

本文圍繞以上的3個問題，提出了一種通用的基于ART虛擬機的自動化脫殼方案，通過分析ART虛擬機中類的加載過程和方法的執行過程找到通用的脫殼點，通過源碼插樁技術隱藏脫殼行為，通過模擬運行技術還原出所有被加固的代碼。整個脫殼過程如圖2所示。將加固的APK安裝在修改了系統源碼(將開發的脫殼系統的代碼加入系統源碼)的Android手機中，然后點擊運行，運行時脫殼系統會先對通用脫殼點進行監測，如果監測到，就開啟模擬運行，得到應用的DEX文件數據并收集這些數據，最后再根據收集的這些數據進行DEX重組，完成脫殼，如果沒有，則不進行脫殼操作。

圖2 系統整體架構Fig. 2 Overall architecture of the system

3.1 通用脫殼點的選擇

通用脫殼點的選擇在脫殼過程中是非常關鍵的，目前為止，只有DexHunter[16]研究了基于ART虛擬機的脫殼，主要思路是通過對所有加固方式進行詳細的分析，為每個加固服務找出一個特征字符串來定位脫殼點，選擇的關鍵函數是類的三種加載方式(ClassLoader.loadClass、artAllocobjectFromCode 和Class.forName)共同調用的函數DefineClass，然后在這個函數里插入DexHunter的脫殼代碼在應用運行時進行脫殼。

本文對ART虛擬機的類加載過程以及類包含的method的執行過程進行了詳細研究。由于ART虛擬機在應用安裝時就將應用的Dalvik字節碼編譯成了本地機器碼，程序運行時直接執行應用編譯好的本地機器指令，所以ART虛擬機不像Dalvik虛擬機那樣一直需要解釋器來執行應用的代碼，只有在應用的字節碼沒有對應的本地代碼時才會使用解釋器執行應用的字節碼。如圖3所示，安裝時系統會首先根據ART_USE_PORTABLE_COMPILER的值來選擇編譯方式，如果該值為true，那么系統使用Portable后端將Dalvik字節碼編譯成本地機器指令，如果該值為false，則系統使用Quick后端進行編譯。使用哪種后端進行編譯只會影響應用的運行速度，不會影響到執行程序時是否使用解釋器。編譯好之后在ClassLinker里的NeedsInterpreter函數會判斷執行過程中是否使用解釋器執行應用代碼，如果虛擬機不是運行在解釋模式，而且執行的method不是本地method，也不是代理method，就直接執行編譯好的DEX本地機器碼。如果ART虛擬機啟動時使用了-Xint參數，運行在解釋模式，那么所有的method就都會使用解釋器執行，解釋執行的函數為Execute。

圖3 ART編譯及代碼執行流程Fig. 3 ART compilation and code execution flow chart

對于加固技術來說，不管是Dalvik還是ART，都選擇使用動態加載和反射調用的方式啟動應用的DEX文件。這是因為由于Android系統存在碎片化問題，目前還無法做到在保持良好兼容性的同時對本地機器碼進行動態修改[3]。也就是說目前的加殼服務對于應用的加固還是選擇修改Dalvik字節碼，這樣加固程序運行時就必然會使用ART的解釋器了，因為修改后的字節碼要經過解釋后才能運行，這就必然會經過Execute函數。綜上所述，該系統選用Execute函數作為關鍵函數，插入脫殼代碼。

找到關鍵函數后，本文不使用像DexHunter那樣的特征字符串來進行脫殼點定位，而是使用應用的MainActivity來作為脫殼定位點[15]。因為無論應用使用哪種加固服務，執行流程始終會轉到原始程序的MainActivity來實現程序的正常功能, 所以并不用尋找加固后的應用中與加固服務相關的特征文件或者執行函數，這些函數的功能只是在運行時將加密的DEX文件進行還原。只需確定應用原始的MainActivity執行開始執行，就可以判斷應用的DEX文件已經被還原到內存中了，因此MainActivity可以作為一個通用的脫殼標識。

3.2 模擬運行

模擬運行主要是應對加固服務的運行時解密策略，即只解密恢復正在執行的method的代碼。通過對Android源碼的分析與類加載和類method執行過程的研究，找到可以實現模擬運行的方法。根據3.1節中找到的通用脫殼點，將模擬運行的實現放在Execute函數中。和Dalvik中一樣，在ART中，應用的所有method都存儲在class_defs結構中，class_defs結構中又存放著每一個class的指針，指向每一個class，而每個class都有一個class_data_item結構，method信息就保存在這個結構中。在每個method執行時都需要將整個class初始化，保證脫殼時，類的變量的初始化完成，特別是靜態method中的變量初始化，從而保證提取出的DEX文件的正確性。同時類加載時可能沒有執行Clinit函數，這個函數需要先于其他所有函數執行。

通過分析ART虛擬機中method的執行過程，本文提出了一種創新的方法，可以模擬執行所有的method，從而應對運行時解密策略。在每個method的執行過程中，ClassLinker里會調用LinkCode函數定位到method的代碼去執行，但是在執行前會使用NeedsInterpreter函數判斷是使用解釋器執行還是直接執行本地機器碼，如果該method沒有對應的機器碼，就使用解釋器執行。使用解釋器執行時會調用GetCompiledCodeToInterpreterBridge函數，該函數就是從執行本地機器碼的方式轉為使用解釋器執行。而在使用解釋器執行前，加密服務需要保證傳入解釋器的字節碼是應用被加殼前原始的字節碼，也即在調用該函數時，正確的字節碼必然已經被恢復在內存中。所以可以通過遍歷每個method，然后調用該函數實現對每個method的模擬運行，得到所有method的正確字節碼。整個過程如圖4所示。

圖4 模擬運行流程Fig. 4 Simulation execution flow chart

這里使用FindClass來查找DEX文件中所有的class，使用這個函數可以避免重復查找class、重復初始化相同的類。該函數會返回一個class對象，然后通過這個class對象調用IsInitialized函數，判斷該類是否初始化，如果初始化好了，就遍歷該類中每一個method，如果沒有初始化，就使用EnsureInitialized函數進行初始化，初始化完成之后得到一個kclass對象，然后在kclass中遍歷所有method，并調用GetCompiledCodeToInterpreterBridge函數實現每個method的執行，執行完成后使用UpdateMethodsCode函數更新method代碼，然后就可以將初始化后的類的數據從內存中dump下來。最后將這些收集好的class數據進行重組即可恢復出原始的DEX文件。

需要注意的是，在整個過程中，所有method的執行并不是應用主動進行的，而是在程序加載到內存中真正運行前，脫殼程序通過主動調用GetCompiledCodeToInterpreterBridge方法實現每個method的加載，因此稱之為模擬運行。

3.3 DEX重組

所有的數據收集完成之后，需要將它們根據標準DEX文件的格式進行重組，以恢復出加固前的原始DEX文件。重組時先將整個DEX文件dump出來，然后將所有收集好的數據放在這個文件的末尾?，F有的加固服務幾乎都是針對字節碼的，少部分加固服務為了防止內存dump，對DEX文件的magic值進行了修改，但是使用在ART虛擬機中插入脫殼代碼的方式，可以以結構體指針準確地dump整個DEX文件，而不會受此影響。對于不直接將類的數據分別還原到DEX文件里的原因是，class_data_item的成員是使用uleb128編碼的，修改這些值會導致許多偏移地址的改變，這樣修改起來就十分復雜。所以選擇將收集好的class數據放在末尾，這樣每個class數據都是固定大小的，每增加一個class數據，只需要將原有結構體中指向class數據的指針偏移這個class數據的大小就可以了，而不需要去修改其他指針的值。

整個重組方法如圖5所示，將模擬運行收集的class數據放在文件末尾，每個class數據又是由很多method的數據組成，統一放在一個class數據中，如圖中的code_item。重組時還需要注意修改class_data_item中的codeoff，通過實際脫殼分析，ART虛擬機脫殼時不需要修改method_id和field_id，這與Dalvik虛擬機在解釋器脫殼時的情況不一樣；并且ART虛擬機可直接恢復出DEX文件，沒有odex文件，不需要進行相應的轉換。

圖5 DEX文件重組示意圖Fig. 5 DEX file reassembling diagram

4 評估

修改Android4.4.4版本的源碼中ART虛擬機的部分代碼，加入基于本文提出的方法所開發的脫殼系統，然后將源碼重編譯后刷入搭載Qualcomm Snapdragon 800 2.3 GHz CPU和2 GB 內存的nexus 5智能手機上，作為實驗環境。

4.1 啟動延時測試

對于沒有進行任何加固的應用來說，使用ART虛擬機運行時啟動延時非常小，因為其在安裝時已經將Dalvik字節碼編譯成了本地機器碼。而對于加固的應用來說，在運行前需要先將加密的代碼進行還原，所以加固行為會造成一定的啟動延時。本文實現的脫殼系統需要通過模擬運行的方式得到原始的未經加密的方法，在模擬運行完成后程序才會正常執行，因此脫殼系統也會引入一定的啟動延時。本節圍繞該脫殼系統啟動延時的問題，進行實驗測試。

測試方式一 將不同大小的應用上傳到同一種加固服務中進行加固，加固完成后分別安裝到兩臺部署了該脫殼系統和沒有部署該脫殼系統的nexus 5手機中運行，每個樣本分別運行20次，啟動方式使用am命令：

am start-n 包名/.MainActivity

啟動延時Ti為從命令執行開始到應用界面啟動完成結束，分別記錄下兩個手機中加固應用的啟動時間，最后計算脫殼的時間延時T，為了減小誤差，脫殼延時定為20次的平均值，計算方法如下。

T=

加固服務為阿里加固，記錄結果如圖6所示。

圖6 脫殼延時測試結果Fig. 6 Results of unpacking time delay

表3列出了使用的10個測試應用，分別記錄下APK的大小(單位為MB)和該APK中包含的DEX文件的大小(單位為MB)。從圖6中可以清楚地看到，在APK大小為5.21 MB時，脫殼延時有小幅度的回落，根據表3中顯示該APK的DEX文件大小為2.4 MB，小于大小為4.56 MB和7.1 MB的APK的DEX文件。所以，根據測試結果可以看出，啟動延時和APK的大小無關，而和APK中DEX文件大小有關，DEX文件越大，其包含的代碼量也就越大，因此脫殼延時就越大。

表3 測試APKTab. 3 Test APK

測試方式二 與DexHunter作脫殼延時對比。迄今為止只有DexHunter實現了ART中DEX文件的自動脫殼，因此本文將該系統的脫殼延時與DexHunter作一個對比。

為了便于計時，這里選擇延時較明顯的測試應用，APK大小分別為20.78 MB、15.4 MB、10 MB，分別將該系統和DexHunter部署到兩臺nexus 5手機上，另外再取一臺沒有部署任何脫殼系統的nexus 5手機，安裝選擇的測試APK，使用測試一中的脫殼延時計算方法，得到測試結果如表4所示。

表4 與DexHunter脫殼延時對比結果Tab. 4 Comparison with DexHunter’s delay

從表4中可以看出，DexHunter的脫殼延時普遍比本文脫殼系統小，原因是本文脫殼系統引入了模擬運行方法，這樣會使得脫殼延時增加。

4.2 對比分析

DexHunter是一個非常著名的DEX脫殼系統，本節從脫殼方法、通用型等方面將本文提出的脫殼方法與DexHunter進行對比。

DexHunter脫殼過程中所使用的location_和fileName是其技術人員通過人工分析得到的，通過對每個加固服務的加固方式進行詳細的分析和研究，選擇每個加固服務的特征字符串作為脫殼開始的標志。采用這樣的方法有一個限制，如果加固者改變了原來的加固方法，修改了加固后的特征文件，那么DexHunter就不能再準確地定位出脫殼點。而本文提出的脫殼方法不存在這樣的缺點，該方法是在ART虛擬機的解釋器中進行插樁，脫殼點是以APP運行時啟動MainActivity作為定位，適合于所有的加固服務。本文方法通過解析APK中的配置來獲取應用的MainActivity，任何加固服務都不能改變該配置文件，因為程序的運行必須要以這個配置文件為基礎去注冊相應的權限和組件，如果加固服務修改了其中的一個權限和組件信息，都會使加固后的應用無法運行。同時本文還提出了模擬運行的方法，這樣就克服了只能恢復出部分正在執行的代碼的缺陷。就通用性和脫殼性能來說，本文方法都優于DexHunter。

測試時使用最新的阿里加固將APP加固之后放在DexHunter里進行脫殼，發現DexHunter并不能成功脫殼。這是因為DexHunter使用的是/data/data/com.example.seventyfour.tencenttest/files/libmobisecy1.zip作為脫殼開始的定位標志，而最新的阿里加固已不再采用原來的加固方式，導致DexHunter不能定位到脫殼點。DexHunter的開發人員必須對阿里加固進行持續地跟蹤分析，找出新的脫殼開始的標志，才能始終保證DexHunter兼容最新版的加固方式。而本文提出的方法不會受到這樣的影響，該脫殼系統是以應用的MainActivity作為脫殼開始的標志，只需要通過解析AndroidMenifest.xml文件獲取應用的MainActivity就可以了，不需要人工進行分析。

5 結語

本文系統是植入到ART虛擬機中的，運行在Android系統的RunTime層，所以可以繞過所有的Anti-debugging進行有效脫殼。系統直接在真機上運行，有很好的兼容性和通用性。隨著Android系統的發展，ART虛擬機必然完全替代Dalvik虛擬機，本文提出的脫殼方案可以實現ART虛擬機中的動態脫殼。但是所有的動態脫殼系統都有一個通病，在實現上會有某些特征，加固者可以通過這些特征加以對抗。加殼與脫殼技術是在不斷的博弈中持續進步的，此方面的研究存在一定的周期性，新型加殼方法的出現會導致新一輪的脫殼技術研究熱潮，如何針對最新的加殼方法進行通用性強的自動化脫殼是一個需要持續進行研究的內容。

References)

[1] 李霞. Android虛擬機運行時技術的分析與評測[D]. 南京: 東南大學, 2015.(LI X. Analysis and evaluation of runtime technology of Android virtual machine[D]. Nanjing: Southeast University, 2015.)

[2] ABSAR J, SHEKHAR D. Eliminating partially-redundant array-bounds check in the Android Dalvik JIT compiler[C]// Proceedings of the 9th International Conference on Principles and Practice of Programming in Java. New York: ACM, 2011:121-128.

[3] 張洪睿, 張亞騰. 一種ART模式下應用加固方案[J]. 軟件, 2015, 36(12):176-179.(ZHANG H R,ZHANG Y T. Application of packing scheme in ART mode[J]. Software, 2015, 36(12): 176-179.)

[4] LIAO Y, LI J, LI B, et al. Automated detection and classification for packed Android applications[C]// Proceedings of the 2016 IEEE International Conference on Mobile Services. Piscataway, NJ: IEEE, 2016: 200-203.

[5] FEREIDOONI H, CONTI M, YAO D, et al. ANASTASIA: ANdroid mAlware detection using STatic analySIs of Applications[C]// Proceedings of the 2016 8th IFIP International Conference on New Technologies, Mobility and Security. Piscataway, NJ: IEEE, 2016: 1-5.

[6] RASTOGI V, CHEN Y, JIANG X. DroidChameleon: evaluating Android anti-malware against transformation attacks[C]// Proceedings of the 8th ACM SIGSAC Symposium on Information, computer and Communications Security. New York: ACM, 2013:329-334.

[7] 朱洪軍, 陳耀光, 華保健,等. 一種Android應用加固方案[J]. 計算機應用與軟件, 2016, 33(11):297-300.(ZHU H J,CHEN Y G,HUA B J,et al. An Android application packing scheme[J]. Journal of Computer Applications and Software, 2016, 33(11): 297-300.)

[8] 邱寅峰, 泮曉波. APK文件的快速加載方法: CN201510657289.9[P]. 2015- 10- 12.(QIU Y F,PAN X B. Fast loading method for APK files: CN201510657289.9[P]. 2015- 10- 12.)

[9] YU R. Android packers: facing the challenges, building solutions[EB/OL].[2016- 11- 20]. https://www.virusbulletin.com/uploads/pdf/conference/vb2014/VB2014-Yu.pdf.

[10] KANG M G, POOSANKAM P, YIN H. Renovo: a hidden code extractor for packed executables[C]// Proceedings of the 2007 ACM Workshop on Recurring Malcode. New York: ACM, 2007: 46-53.

[11] LI J, ZHANG Y, YANG W, et al. DIAS: Automated online analysis for Android applications[C]// Proceedings of the 2014 IEEE International Conference on Computer and Information Technology. Washington, DC: IEEE Computer Society, 2014:307-314.

[12] STRAZZERE T. Android-unpacker[EB/OL].[2016- 11- 20].https://github.com/strazzere/androidunpacker.

[13] 高琦, 劉克勝, 常超,等. 基于自修改字節碼的Android軟件保護技術研究[J]. 計算機應用與軟件, 2016, 33(4):230-234.(GAO Q, LIU K S, CHANG C, et al. Research on Android software protection technology based on self-modified bytecode[J]. Journal of Computer Applications and Software, 2016, 33(4): 230-234.)

[14] CHO H, LIM J, KIM H, et al. Anti-debugging scheme for protecting mobile apps on Android platform[J]. Journal of Supercomputing, 2016, 72(1):1-15.

[15] YANG W, ZHANG Y, LI J, et al. AppSpear: bytecode decrypting and DEX reassembling for packed Android malware[C]// Proceedings of the 18th International Symposium Research in Attacks, Intrusions, and Defenses. Berlin: Springer, 2015: 359-381.

[16] ZHANG Y, LUO X, YIN H. DexHunter: toward extracting hidden code from packed Android applications[C]// Proceedings of the 20th European Symposium on Research in Computer Security. Berlin: Springer, 2015: 293-311.

JIANGZhongqing, born in 1992, M. S. candidate. His research interests include mobile security.

ZHOUAnmin, born in 1963, research fellow. His research interests include security defense and management, mobile internet security, cloud computing security.

JIAPeng, born in 1988, Ph. D.. His research interests include complex network, mobile security, binary security.

DEXunpackingtechnologyinARTvirtualmachine

JIANG Zhongqing, ZHOU Anmin*, JIA Peng

(CollegeofElectronicsandInformation,SichuanUniversity,ChengduSichuan610065,China)

Based on the systematic study and research on the existing DEX packing and unpacking technologies, a DEX unpacking scheme based on Android ART Virtual Machine (VM) was proposed and implemented. The method could extract the original DEX file from the enhanced Android application. The core idea is to accomplish the zero-knowledge unpacking in a strong compatible way by combining simulation execution with static instrumentation. Firstly, the unpacking point was achieved by inserting monitoring codes into the interpreter of ART. Then, the memory location of the data belonging to original DEX file was obtained by performing simulation execution and analyzing related structs. Finally, the original DEX file was restored by collecting and reassembling the data according to the format of DEX file. The experimental results indicate that the proposed automatically unpacking method can well perform zero-knowledge unpacking by just bringing in little time delay when application launching.

Android Runtime (ART); DEX unpacking; interpreter; simulation execution; DEX recombination

2017- 05- 04;

2017- 06- 13。

蔣鐘慶(1992—)，男，貴州遵義人，碩士研究生，主要研究方向：移動安全； 周安民(1963—)，男，四川成都人，研究員，主要研究方向：安全防御管理、移動互聯網安全、云計算安全； 賈鵬(1988—)，男，河南鄭州人，博士，主要研究方向：復雜網絡、移動安全、二進制安全。

1001- 9081(2017)11- 3294- 05

10.11772/j.issn.1001- 9081.2017.11.3294

(*通信作者電子郵箱3106179032@qq.com)

TP393

A