ART虛擬機(jī)中的DEX文件脫殼技術(shù)

蔣鐘慶，周安民，賈 鵬

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

ART虛擬機(jī)中的DEX文件脫殼技術(shù)

蔣鐘慶，周安民*，賈 鵬

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

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

ART；DEX脫殼；解釋器；模擬運(yùn)行；DEX重組

0 引言

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

本文提出了一個(gè)基于ART虛擬機(jī)的通用脫殼方案，該方案不需要理解加固服務(wù)使用的加固算法和策略，也不需要尋找加固后的APK中存在的特征文件，便可實(shí)現(xiàn)DEX的自動(dòng)化脫殼。

1 ART虛擬機(jī)和Dalvik虛擬機(jī)

和Dalvik虛擬機(jī)一致，ART虛擬機(jī)也是由Zygote進(jìn)程創(chuàng)建的，區(qū)別是Dalvik虛擬機(jī)在libdvm.so庫(kù)中實(shí)現(xiàn)，而ART虛擬機(jī)在libart.so庫(kù)中實(shí)現(xiàn)。Android系統(tǒng)以系統(tǒng)屬性persist.sys.dalvik.vm.lib的值來(lái)決定運(yùn)行應(yīng)用時(shí)使用的虛擬機(jī)。如果值等于libdvm.so，則在Dalvik虛擬機(jī)中運(yùn)行應(yīng)用；如果值等于libart.so，則在ART虛擬機(jī)中運(yùn)行應(yīng)用。

圖1 Android虛擬機(jī)的啟動(dòng)過(guò)程Fig. 1 Android VM start process

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

2 加固與脫殼技術(shù)簡(jiǎn)介

加固技術(shù)經(jīng)歷了從最初的整包加密，到字節(jié)碼變形，再到VMProtect的演變過(guò)程[9]；脫殼技術(shù)也從最初的人工分析，逐漸發(fā)展到內(nèi)存dump[10]，進(jìn)一步再到現(xiàn)在的基于Android源碼插樁的方式[11]，源碼插樁是迄今為止最高效、最通用的脫殼方式。本文對(duì)每種加固與脫殼技術(shù)的優(yōu)缺點(diǎn)進(jìn)行了總結(jié)，如表1、表2所示。

表1 加固技術(shù)優(yōu)缺點(diǎn)Tab. 1 Advantages and disadvantages of packing techniques

表2 脫殼技術(shù)優(yōu)缺點(diǎn)Tab. 2 Advantages and disadvantages of unpacking techniques

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

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

3 脫殼模型構(gòu)建和實(shí)現(xiàn)

由第2章的分析可以看出，目前實(shí)現(xiàn)自動(dòng)化脫殼面臨的主要問(wèn)題有3個(gè)方面：

1)通用脫殼點(diǎn)的定位。不同的加固服務(wù)會(huì)有不同的特征文件和特征函數(shù)，如何準(zhǔn)確找到一個(gè)通用的脫殼位置是一個(gè)需要解決的問(wèn)題，在該脫殼點(diǎn)上能夠?qū)缀跛蓄愋偷募庸谭?wù)進(jìn)行脫殼，該脫殼點(diǎn)不會(huì)隨加固服務(wù)的變化而變化。

2)繞過(guò)Anti-debugging技術(shù)。許多Anti-debugging技術(shù)會(huì)檢測(cè)脫殼行為，在檢測(cè)到脫殼行為后會(huì)終止程序的運(yùn)行，從而導(dǎo)致脫殼失敗。

3)解密還未運(yùn)行的代碼。運(yùn)行時(shí)解密策略會(huì)導(dǎo)致傳統(tǒng)的脫殼技術(shù)不能還原出還未運(yùn)行的代碼，從而無(wú)法還原出完整的原始DEX文件。

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

圖2 系統(tǒng)整體架構(gòu)Fig. 2 Overall architecture of the system

3.1 通用脫殼點(diǎn)的選擇

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

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

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

對(duì)于加固技術(shù)來(lái)說(shuō)，不管是Dalvik還是ART，都選擇使用動(dòng)態(tài)加載和反射調(diào)用的方式啟動(dòng)應(yīng)用的DEX文件。這是因?yàn)橛捎贏ndroid系統(tǒng)存在碎片化問(wèn)題，目前還無(wú)法做到在保持良好兼容性的同時(shí)對(duì)本地機(jī)器碼進(jìn)行動(dòng)態(tài)修改[3]。也就是說(shuō)目前的加殼服務(wù)對(duì)于應(yīng)用的加固還是選擇修改Dalvik字節(jié)碼，這樣加固程序運(yùn)行時(shí)就必然會(huì)使用ART的解釋器了，因?yàn)樾薷暮蟮淖止?jié)碼要經(jīng)過(guò)解釋后才能運(yùn)行，這就必然會(huì)經(jīng)過(guò)Execute函數(shù)。綜上所述，該系統(tǒng)選用Execute函數(shù)作為關(guān)鍵函數(shù)，插入脫殼代碼。

找到關(guān)鍵函數(shù)后，本文不使用像DexHunter那樣的特征字符串來(lái)進(jìn)行脫殼點(diǎn)定位，而是使用應(yīng)用的MainActivity來(lái)作為脫殼定位點(diǎn)[15]。因?yàn)闊o(wú)論應(yīng)用使用哪種加固服務(wù)，執(zhí)行流程始終會(huì)轉(zhuǎn)到原始程序的MainActivity來(lái)實(shí)現(xiàn)程序的正常功能, 所以并不用尋找加固后的應(yīng)用中與加固服務(wù)相關(guān)的特征文件或者執(zhí)行函數(shù)，這些函數(shù)的功能只是在運(yùn)行時(shí)將加密的DEX文件進(jìn)行還原。只需確定應(yīng)用原始的MainActivity執(zhí)行開(kāi)始執(zhí)行，就可以判斷應(yīng)用的DEX文件已經(jīng)被還原到內(nèi)存中了，因此MainActivity可以作為一個(gè)通用的脫殼標(biāo)識(shí)。

3.2 模擬運(yùn)行

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

通過(guò)分析ART虛擬機(jī)中method的執(zhí)行過(guò)程，本文提出了一種創(chuàng)新的方法，可以模擬執(zhí)行所有的method，從而應(yīng)對(duì)運(yùn)行時(shí)解密策略。在每個(gè)method的執(zhí)行過(guò)程中，ClassLinker里會(huì)調(diào)用LinkCode函數(shù)定位到method的代碼去執(zhí)行，但是在執(zhí)行前會(huì)使用NeedsInterpreter函數(shù)判斷是使用解釋器執(zhí)行還是直接執(zhí)行本地機(jī)器碼，如果該method沒(méi)有對(duì)應(yīng)的機(jī)器碼，就使用解釋器執(zhí)行。使用解釋器執(zhí)行時(shí)會(huì)調(diào)用GetCompiledCodeToInterpreterBridge函數(shù)，該函數(shù)就是從執(zhí)行本地機(jī)器碼的方式轉(zhuǎn)為使用解釋器執(zhí)行。而在使用解釋器執(zhí)行前，加密服務(wù)需要保證傳入解釋器的字節(jié)碼是應(yīng)用被加殼前原始的字節(jié)碼，也即在調(diào)用該函數(shù)時(shí)，正確的字節(jié)碼必然已經(jīng)被恢復(fù)在內(nèi)存中。所以可以通過(guò)遍歷每個(gè)method，然后調(diào)用該函數(shù)實(shí)現(xiàn)對(duì)每個(gè)method的模擬運(yùn)行，得到所有method的正確字節(jié)碼。整個(gè)過(guò)程如圖4所示。

圖4 模擬運(yùn)行流程Fig. 4 Simulation execution flow chart

這里使用FindClass來(lái)查找DEX文件中所有的class，使用這個(gè)函數(shù)可以避免重復(fù)查找class、重復(fù)初始化相同的類。該函數(shù)會(huì)返回一個(gè)class對(duì)象，然后通過(guò)這個(gè)class對(duì)象調(diào)用IsInitialized函數(shù)，判斷該類是否初始化，如果初始化好了，就遍歷該類中每一個(gè)method，如果沒(méi)有初始化，就使用EnsureInitialized函數(shù)進(jìn)行初始化，初始化完成之后得到一個(gè)kclass對(duì)象，然后在kclass中遍歷所有method，并調(diào)用GetCompiledCodeToInterpreterBridge函數(shù)實(shí)現(xiàn)每個(gè)method的執(zhí)行，執(zhí)行完成后使用UpdateMethodsCode函數(shù)更新method代碼，然后就可以將初始化后的類的數(shù)據(jù)從內(nèi)存中dump下來(lái)。最后將這些收集好的class數(shù)據(jù)進(jìn)行重組即可恢復(fù)出原始的DEX文件。

需要注意的是，在整個(gè)過(guò)程中，所有method的執(zhí)行并不是應(yīng)用主動(dòng)進(jìn)行的，而是在程序加載到內(nèi)存中真正運(yùn)行前，脫殼程序通過(guò)主動(dòng)調(diào)用GetCompiledCodeToInterpreterBridge方法實(shí)現(xiàn)每個(gè)method的加載，因此稱之為模擬運(yùn)行。

3.3 DEX重組

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

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

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

4 評(píng)估

修改Android4.4.4版本的源碼中ART虛擬機(jī)的部分代碼，加入基于本文提出的方法所開(kāi)發(fā)的脫殼系統(tǒng)，然后將源碼重編譯后刷入搭載Qualcomm Snapdragon 800 2.3 GHz CPU和2 GB 內(nèi)存的nexus 5智能手機(jī)上，作為實(shí)驗(yàn)環(huán)境。

4.1 啟動(dòng)延時(shí)測(cè)試

對(duì)于沒(méi)有進(jìn)行任何加固的應(yīng)用來(lái)說(shuō)，使用ART虛擬機(jī)運(yùn)行時(shí)啟動(dòng)延時(shí)非常小，因?yàn)槠湓诎惭b時(shí)已經(jīng)將Dalvik字節(jié)碼編譯成了本地機(jī)器碼。而對(duì)于加固的應(yīng)用來(lái)說(shuō)，在運(yùn)行前需要先將加密的代碼進(jìn)行還原，所以加固行為會(huì)造成一定的啟動(dòng)延時(shí)。本文實(shí)現(xiàn)的脫殼系統(tǒng)需要通過(guò)模擬運(yùn)行的方式得到原始的未經(jīng)加密的方法，在模擬運(yùn)行完成后程序才會(huì)正常執(zhí)行，因此脫殼系統(tǒng)也會(huì)引入一定的啟動(dòng)延時(shí)。本節(jié)圍繞該脫殼系統(tǒng)啟動(dòng)延時(shí)的問(wèn)題，進(jìn)行實(shí)驗(yàn)測(cè)試。

測(cè)試方式一 將不同大小的應(yīng)用上傳到同一種加固服務(wù)中進(jìn)行加固，加固完成后分別安裝到兩臺(tái)部署了該脫殼系統(tǒng)和沒(méi)有部署該脫殼系統(tǒng)的nexus 5手機(jī)中運(yùn)行，每個(gè)樣本分別運(yùn)行20次，啟動(dòng)方式使用am命令：

am start-n 包名/.MainActivity

啟動(dòng)延時(shí)Ti為從命令執(zhí)行開(kāi)始到應(yīng)用界面啟動(dòng)完成結(jié)束，分別記錄下兩個(gè)手機(jī)中加固應(yīng)用的啟動(dòng)時(shí)間，最后計(jì)算脫殼的時(shí)間延時(shí)T，為了減小誤差，脫殼延時(shí)定為20次的平均值，計(jì)算方法如下。

T=

加固服務(wù)為阿里加固，記錄結(jié)果如圖6所示。

圖6 脫殼延時(shí)測(cè)試結(jié)果Fig. 6 Results of unpacking time delay

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

表3 測(cè)試APKTab. 3 Test APK

測(cè)試方式二 與DexHunter作脫殼延時(shí)對(duì)比。迄今為止只有DexHunter實(shí)現(xiàn)了ART中DEX文件的自動(dòng)脫殼，因此本文將該系統(tǒng)的脫殼延時(shí)與DexHunter作一個(gè)對(duì)比。

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

表4 與DexHunter脫殼延時(shí)對(duì)比結(jié)果Tab. 4 Comparison with DexHunter’s delay

從表4中可以看出，DexHunter的脫殼延時(shí)普遍比本文脫殼系統(tǒng)小，原因是本文脫殼系統(tǒng)引入了模擬運(yùn)行方法，這樣會(huì)使得脫殼延時(shí)增加。

4.2 對(duì)比分析

DexHunter是一個(gè)非常著名的DEX脫殼系統(tǒng)，本節(jié)從脫殼方法、通用型等方面將本文提出的脫殼方法與DexHunter進(jìn)行對(duì)比。

DexHunter脫殼過(guò)程中所使用的location_和fileName是其技術(shù)人員通過(guò)人工分析得到的，通過(guò)對(duì)每個(gè)加固服務(wù)的加固方式進(jìn)行詳細(xì)的分析和研究，選擇每個(gè)加固服務(wù)的特征字符串作為脫殼開(kāi)始的標(biāo)志。采用這樣的方法有一個(gè)限制，如果加固者改變了原來(lái)的加固方法，修改了加固后的特征文件，那么DexHunter就不能再準(zhǔn)確地定位出脫殼點(diǎn)。而本文提出的脫殼方法不存在這樣的缺點(diǎn)，該方法是在ART虛擬機(jī)的解釋器中進(jìn)行插樁，脫殼點(diǎn)是以APP運(yùn)行時(shí)啟動(dòng)MainActivity作為定位，適合于所有的加固服務(wù)。本文方法通過(guò)解析APK中的配置來(lái)獲取應(yīng)用的MainActivity，任何加固服務(wù)都不能改變?cè)撆渲梦募驗(yàn)槌绦虻倪\(yùn)行必須要以這個(gè)配置文件為基礎(chǔ)去注冊(cè)相應(yīng)的權(quán)限和組件，如果加固服務(wù)修改了其中的一個(gè)權(quán)限和組件信息，都會(huì)使加固后的應(yīng)用無(wú)法運(yùn)行。同時(shí)本文還提出了模擬運(yùn)行的方法，這樣就克服了只能恢復(fù)出部分正在執(zhí)行的代碼的缺陷。就通用性和脫殼性能來(lái)說(shuō)，本文方法都優(yōu)于DexHunter。

測(cè)試時(shí)使用最新的阿里加固將APP加固之后放在DexHunter里進(jìn)行脫殼，發(fā)現(xiàn)DexHunter并不能成功脫殼。這是因?yàn)镈exHunter使用的是/data/data/com.example.seventyfour.tencenttest/files/libmobisecy1.zip作為脫殼開(kāi)始的定位標(biāo)志，而最新的阿里加固已不再采用原來(lái)的加固方式，導(dǎo)致DexHunter不能定位到脫殼點(diǎn)。DexHunter的開(kāi)發(fā)人員必須對(duì)阿里加固進(jìn)行持續(xù)地跟蹤分析，找出新的脫殼開(kāi)始的標(biāo)志，才能始終保證DexHunter兼容最新版的加固方式。而本文提出的方法不會(huì)受到這樣的影響，該脫殼系統(tǒng)是以應(yīng)用的MainActivity作為脫殼開(kāi)始的標(biāo)志，只需要通過(guò)解析AndroidMenifest.xml文件獲取應(yīng)用的MainActivity就可以了，不需要人工進(jìn)行分析。

5 結(jié)語(yǔ)

本文系統(tǒng)是植入到ART虛擬機(jī)中的，運(yùn)行在Android系統(tǒng)的RunTime層，所以可以繞過(guò)所有的Anti-debugging進(jìn)行有效脫殼。系統(tǒng)直接在真機(jī)上運(yùn)行，有很好的兼容性和通用性。隨著Android系統(tǒng)的發(fā)展，ART虛擬機(jī)必然完全替代Dalvik虛擬機(jī)，本文提出的脫殼方案可以實(shí)現(xiàn)ART虛擬機(jī)中的動(dòng)態(tài)脫殼。但是所有的動(dòng)態(tài)脫殼系統(tǒng)都有一個(gè)通病，在實(shí)現(xiàn)上會(huì)有某些特征，加固者可以通過(guò)這些特征加以對(duì)抗。加殼與脫殼技術(shù)是在不斷的博弈中持續(xù)進(jìn)步的，此方面的研究存在一定的周期性，新型加殼方法的出現(xiàn)會(huì)導(dǎo)致新一輪的脫殼技術(shù)研究熱潮，如何針對(duì)最新的加殼方法進(jìn)行通用性強(qiáng)的自動(dòng)化脫殼是一個(gè)需要持續(xù)進(jìn)行研究的內(nèi)容。

References)

[1] 李霞. Android虛擬機(jī)運(yùn)行時(shí)技術(shù)的分析與評(píng)測(cè)[D]. 南京: 東南大學(xué), 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模式下應(yīng)用加固方案[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應(yīng)用加固方案[J]. 計(jì)算機(jī)應(yīng)用與軟件, 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] 高琦, 劉克勝, 常超,等. 基于自修改字節(jié)碼的Android軟件保護(hù)技術(shù)研究[J]. 計(jì)算機(jī)應(yīng)用與軟件, 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—)，男，貴州遵義人，碩士研究生，主要研究方向：移動(dòng)安全； 周安民(1963—)，男，四川成都人，研究員，主要研究方向：安全防御管理、移動(dòng)互聯(lián)網(wǎng)安全、云計(jì)算安全； 賈鵬(1988—)，男，河南鄭州人，博士，主要研究方向：復(fù)雜網(wǎng)絡(luò)、移動(dòng)安全、二進(jìn)制安全。

1001- 9081(2017)11- 3294- 05

10.11772/j.issn.1001- 9081.2017.11.3294

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

TP393

A