基于安卓系統的代碼隱藏類規避技術檢測框架

馬曉凱 楊哲慜

(復旦大學軟件學院 上海 201203)

基于安卓系統的代碼隱藏類規避技術檢測框架

馬曉凱 楊哲慜

(復旦大學軟件學院 上海 201203)

隨著惡意軟件檢測和分析技術的發展，大量惡意軟件采用規避技術來對抗安全分析。其中，代碼隱藏類規避技術將應用代碼對靜態分析隱藏起來，使分析結果錯誤或缺失。爆炸式增長的惡意軟件數量要求了對代碼隱藏類規避技術的自動化檢測。通過對142個惡意樣本進行人工分析，總結出一種代碼隱藏類規避技術的檢測方法，并實現了一個通用的自動化檢測框架。使用檢測框架在第三方應用市場2 278個樣本上進行了實驗，發現有34.9%的樣本使用了代碼隱藏類規避技術。

安卓 規避技術 靜態分析 動態分析

0 引 言

以移動操作系統為平臺，開發者可以開發應用來擴展移動設備的功能。在眾多移動操作系統中，安卓系統由于其開放性最受廠商和用戶的青睞，占據了移動操作系統86.8%的市場份額[1]。與此同時，基于安卓系統的第三方應用數量正呈飛速增長，僅以Google官方應用市場Google Play為例，其應用數量已超過260萬個[2]，且仍處于飛速增長中。

移動設備中含有大量的用戶隱私數據，出于保護用戶隱私的目的，安全分析人員利用程序分析方法來分析應用程序行為，識別惡意軟件。程序分析技術主要包含靜態和動態程序分析兩類。其中，靜態分析相較于動態分析有代碼覆蓋全、分析效率高的優點,是目前可用于大規模檢測分析的重要手段。

然而，無論是正常應用開發者還是惡意軟件作者都具有規避軟件檢測的需求。其中，正常應用需要對抗逆向工程，保護軟件核心代碼。而惡意軟件作者通過規避分析檢測，可以延長其惡意代碼的生命周期。此類規避分析技術的方法通常被稱為規避技術。其中，代碼隱藏類規避技術作為一類主要的規避分析方法，通過把代碼對靜態分析隱藏起來，使分析結果錯誤或缺失,降低了分析的準確度。

代碼隱藏類規避技術包括動態代碼加載技術、代碼自修復技術和垃圾代碼插入技術三種。動態代碼加載技術和代碼自修復技術由于將程序關鍵代碼隱藏起來，使得靜態分析在中間環節生成的圖不完整或錯誤，導致對樣本的誤判。垃圾代碼插入技術會在靜態分析的詞法、語法分析階段對分析工具產生干擾，如果分析工具的實現沒有完整地考慮垃圾代碼插入技術所帶來的威脅，就會有在運行時崩潰的風險。這三種規避分析的技術都具有隱藏程序關鍵代碼，從而使靜態程序分析方法無法完整分析應用程序邏輯的能力。

為了解決代碼隱藏類規避技術給靜態分析帶來的不利現狀，我們提出了通用的自動化檢測框架。該框架通過自動化識別規避檢測技術的應用，并以警報的方式提醒分析人員，以輔助分析人員早期發現具有規避行為的惡意軟件。

我們對142個惡意樣本進行了人工分析，歸納了其中代碼隱藏類規避技術的使用模式，并提出了一個通用的自動化檢測框架。我們的檢測框架利用安卓系統中Dalvik虛擬機代碼加載和執行的模型，使用主動觸發類加載和初始化的方法促使代碼的加載和修復。我們修改了安卓系統中Dalvik虛擬機和libc的源代碼，對樣本中加載和修復代碼的行為進行監控，可以有效地識別出樣本是否有隱藏代碼的行為。

我們從中國第三方應用市場應用寶[3]中收集了2 278個樣本，并對其進行了自動化分析。實驗表明，檢測框架成功分析了2 247個樣本，識別出794個使用了代碼隱藏類規避技術的樣本。

1 背景及相關工作

1.1 DEX文件

由Dalvik虛擬機解釋執行的字節碼也被稱作DEX字節碼(Dalvik Executable Bytecode)[4]，由DEX字節碼所組成的DEX文件是運行于安卓系統Dalvik虛擬機中的可執行文件，也是安卓應用程序的核心所在。在這一部分，我們簡要地介紹DEX文件。

安卓應用通常由Java語言寫成，從Java源代碼到DEX文件的基本映射關系如圖1所示。Java編譯器將Java源代碼編譯成.class文件，然后dx工具將.class文件轉換為.dex文件，.dex文件是.class文件在安卓系統中的優化。

圖1 從Java源文件到生成DEX文件的基本映射關系

DEX文件從整體上看是個索引結構，包含了文件頭、常量池、類屬性表、方法表、類定義表和數據段等部分。文件頭包含了魔數、校驗值、其他各部分的索引和長度等。常量池、類屬性表、方法表和類定義表描述了字符串常量、類的屬性、類的方法和類的定義等信息。類名、方法名、常量字符串等都存儲在非冗余的常量池中，這樣能夠充分地減少存儲空間。數據段包含了所有的類定義和字節碼。一段完整的類方法，其代碼必定包含了如表1所列的所有字段。

表1 類方法代碼的必含字段

代碼隱藏類規避技術通常會修改DEX文件，來對靜態分析產生干擾。較為高級的代碼隱藏類規避技術往往會修改表1中所描述的字段。例如：1) 將debugInfoOff的值修改為非法值，使分析工具運行錯誤；2) 向insns內填充一些空指令和非法指令，使分析工具無法處理該部分代碼。

1.2 代碼隱藏類規避技術

在安卓系統中，代碼隱藏類規避技術通過修改APK安裝包中的DEX文件，將程序的核心代碼對靜態分析隱藏起來，使靜態分析的結果錯誤或缺失，從而達到保護核心代碼、隱藏程序行為的目的。代碼隱藏類規避技術包括動態代碼加載技術、代碼自修復技術和垃圾代碼插入技術三種技術。

動態代碼加載技術是指進程在運行時額外加載代碼執行的技術。利用了額外加載的特性，開發者通常會將需要保護的代碼加密，在運行時解密，并通過隱蔽的手段來加載解密后的代碼。也就是說，動態代碼加載的過程可以分為獲取、解密、加載和執行四個階段。應用程序可以通過網絡或者讀取本地文件的方式來獲取加密后的代碼，而解密和加載的過程可以不接觸文件系統，完全在內存中執行，從而提高了安全分析的難度。更復雜的情況是，加載的代碼可以分為幾段，不同段代碼的加載可以以不同的方式觸發。

代碼自修復技術的程序會在進程執行的過程中動態修改內存中的代碼，這意味著即使分析人員在程序啟動和執行過程中所觀察到的是同一塊代碼，其內容也可能有所不同。對靜態分析來說，代碼自修復技術隱藏了部分“真實”的代碼，其分析結果會有所缺失。如果開發者將被隱藏的代碼替換為無關的程序行為，靜態分析還會被誤導。

圖2展示了一段字節碼在修改前與修改后的狀態。在該示例中，某個類的interceptSMS()方法被填充為空指令nop，即不做任何工作。當應用程序啟動后，在Application.oncreate()等程序入口處會修改interceptSMS()方法的代碼，將代碼替換為監聽短信接收通知的代碼。這樣，程序在運行過程中通過修改自身代碼的行為就可以將其惡意行為偽裝起來，從而導致靜態分析對樣本的誤判。

圖2 程序在運行過程中修改自己的代碼

垃圾代碼插入技術通過向代碼的特定位置插入垃圾字節，使反匯編工具生成錯誤信息，從而對靜態分析產生干擾。插入垃圾代碼的位置因不同分析工具所使用算法的不同而不同，而插入的代碼必然是不能執行的無效代碼，否則會導致未知的執行結果。通常的做法是在插入的垃圾代碼之前添加一條無條件跳轉指令。

總而言之，代碼隱藏類規避技術通常會給靜態分析帶來困擾，有時甚至使其失效。垃圾代碼插入技術會在靜態分析的詞法、語法分析階段對分析工具產生干擾，越是對DEX完整性和規范性有要求的工具越有可能會運行失敗。動態代碼加載技術和代碼自修復技術會使靜態分析生成不完整或錯誤的圖，從而導致分析結果不準確。較為高級的商用代碼保護方案會將原始安裝包中所有的DEX字節碼加密起來，而解密、加載和修復的邏輯則完全放在了使用混淆技術的本地代碼中。在這種情況下，靜態分析由于沒有實際運行程序，不可能接觸到被保護的代碼，從而完全無法得知程序的原始行為。

1.3 相關工作

在安卓平臺上，對規避技術的研究呈現方興未艾之勢。Strazzere在文獻[5]和文獻[6]中介紹了對抗靜態分析和動態分析的代碼保護技術。Vidas等[7]總結了一系列檢測安卓應用是否運行于虛擬環境的方法，即對抗模擬器或對抗虛擬機技術。

在代碼隱藏類規避技術方面，Yu[8]和Strazzere[9]等對商用代碼保護方案的特征做了一些假設，并以這些假設為基礎來定位DEX字節碼。然而隨著代碼保護方案的發展，這些方法已經失效。DexHunter[10]和AppSpear[11]分別針對商用代碼保護方案提出了提取隱藏代碼方法。DexHunter通過主動觸發類加載和初始化進而對代碼進行內存轉儲來提取被隱藏的代碼。這種提取隱藏代碼的方式只針對特定幾種商用代碼保護方案，無法全面有效地定位隱藏代碼，方法不夠通用。AppSpear修改了Dalvik虛擬機的解釋器，將解釋執行到的相關代碼轉儲到文件中，這種方法存在代碼覆蓋率不夠全的問題。Harvester[12]提出了通過在Dalvik虛擬機中對字節碼做切片運行來提取應用運行時信息的自動化分析方法，該方法可以在一定程度上對抗規避技術，但對本地代碼中的規避行為效果不明顯。

本文所提出的框架目的在于對安卓應用中的隱藏代碼進行檢測，可以準確全面地定位有效代碼，具有較強的通用性，并且能應用于自動化分析。

2 惡意樣本的人工分析

為了研究代碼隱藏類規避技術的使用模式，并提出針對隱藏代碼的檢測框架，我們人工分析了一批惡意樣本。樣本的收集時間為2015年08月01日至2015年08月03日，共計10 827個。經由第三方檢測引擎標注，這些樣本可以劃分到107個家族，170個變種中去。考慮到同一變種的樣本非常相似，我們在每個變種中隨機選取了1個樣本進行人工分析。

在170個樣本中：有7個樣本無法安裝，這包括6個沒有有效自簽名證書的樣本和1個為無效APK文件的樣本；有15個樣本沒有Activity或者Service等程序入口，無法啟動運行，以插件的形式存在；有6個樣本由于兼容性或其他問題，在程序啟動后崩潰或退出。這28個樣本均為無效樣本，所以沒有對其做進一步分析。對剩下的142個樣本的分析結果如表2所示。

表2 惡意樣本的人工分析

在剩下的142個樣本中，經人工分析，我們發現有42個樣本使用了動態代碼加載技術，有2個樣本使用了代碼自修復技術，有6個樣本使用了垃圾代碼插入技術。同時，使用代碼自修復技術的2個樣本也使用了垃圾代碼插入技術。剩下的94個樣本未發現使用本文所述的代碼隱藏類規避技術。我們對這142個樣本進行了標注，以用來在實驗環節驗證隱藏代碼檢測框架的準確性。

3 檢測框架

我們對142個樣本進行了人工分析，總結出一種代碼隱藏類規避技術的檢測方法，并實現了一個通用的自動化檢測框架。其架構如圖3所示，整個框架處理流程包括預處理、動態分析、后端處理三個階段。框架的輸入為APK樣本和日志，同時日志也是框架的產出結果。

圖3 檢測框架架構

3.1 預處理

在分析樣本之前，必須能在日志中唯一地確定樣本。我們把APK文件作為分析樣本，使用文件的MD5和SHA1值來唯一確定樣本文件。在安卓應用中，包(package)名和版本可以唯一確定其發布版本，因此我們也記錄APK文件的包名、版本號、版本名稱。

當對樣本進行動態分析時，需要將其安裝到安卓模擬器中并啟動它的Main Activity使其運行。因此，我們還需要提取樣本的Main Activity名稱。除此以外，使用同一代碼保護方案的樣本往往具有統一的Application名稱。因此，我們將這一字段記錄下來，以便于對日志做進一步分析。

對于與安卓應用相關的信息，使用安卓SDK中的aapt工具進行提取。工具aapt的全名為Android Asset Packaging Tool，即安卓資源打包工具，在SDK的build-tools目錄下。該工具可以查看，創建，更新ZIP格式的文檔附件(zip， jar，apk)。這里使用aapt來提取樣本中的信息是因為aapt工具的代碼實現與安卓系統相同，因而能夠成功安裝并運行的應用都可以用aapt工具進行分析，aapt工具具有良好的兼容性。

在提取了安卓應用的相關信息后，還需要將樣本APK文件進行解壓縮，以用來在后端處理階段對安裝包中的文件進行處理。

3.2 動態分析

我們修改了安卓系統源碼中Dalvik虛擬機和libc部分的代碼，編譯成安卓模擬器作為動態分析的環境。考慮到APK版本的兼容性，我們使用了較低版本的安卓系統源碼，其版本號為4.4.4。為了保證樣本之間互不影響，每一次啟動的安卓模擬器鏡像都是預先配置好的鏡像的一份拷貝。我們修改的Dalvik虛擬機和libc會在分析時記錄下樣本的運行時信息，并將其寫入到日志中。

3.2.1 主動觸發類加載和初始化

動態分析可以分為以符號執行為代表的白盒測試和基于真實分析環境和虛擬分析環境的黑盒測試。一般來說，動態分析都期望被分析的程序盡可能多地執行代碼路徑來保證分析有足夠的代碼覆蓋率。在基于虛擬機環境的自動化分析環境中，一種較為流行的保證代碼覆蓋率的方法是以隨機模擬事件的方式來驅動代碼的執行，如AppsPlayground[13]。安卓SDK也提供了名為MonkeyRunner[14]的類似的自動化測試工具。

然而，在分析惡意樣本時我們發現，有大量樣本在啟動之后會直接退出用戶界面并駐留在后臺運行。在這種情況下，如果采用隨機模擬事件的方式來驅動程序的執行，可能會啟動系統內的其他應用，甚至導致內存不足，Activity Manager殺死當前需要分析的進程。與一般動態分析中行為分析不同的是，分析框架的目的是盡可能地觸發進程中代碼的加載和修復，而不是執行完所有的代碼路徑，我們使用了主動觸發類加載和初始化的方法來保證分析有足夠的代碼覆蓋率，這一方法由DexHunter[10]提出，我們做了部分改進。

我們的方法是：監控Dalvik虛擬機中加載DEX字節碼的過程，每當有一段DEX字節碼被加載時就啟動一個新的線程。圖11展示了該線程接下來的執行流程。新創建的線程會先睡眠一段時間，然后根據DEX文件的索引結構查找該DEX文件中所有類的名字，用類名作為參數調用相關API來觸發Dalvik虛擬機對類的加載。這里啟動一個新的線程并睡眠一段時間是為了保證程序不會運行崩潰。因為當類加載的順序與預先設定的執行順序不一致時，類的部分屬性會初始化為與預期不同的值，從而使主線程拋出未捕獲的異常，導致進程崩潰。而當起動一個新的線程并睡眠一段時間后，主線程的初始化工作已經完成，這時新啟動的線程就可以通過強制捕獲所有拋出異常的方式來保證類的加載，并不會對主線程的執行造成影響。

基于以下結論，該方法能夠起到良好的效果：1) Dalvik虛擬機對代碼的加載是以類為基本單位的，當虛擬機加載一個類的時候，會驗證該類所有方法的代碼，并將該類進行初始化，也就是創建一個類對象；2) 對隱藏代碼的加載和修復往往會出現在程序的入口和類的初始化方法()中。第2條結論由人工分析的惡意樣本得出。出現這種模式與Java語言要求的類在初始化前必須先加載并初始化其依賴的類的機制有關。這是因為隱藏代碼的加載和修復的行為如果不出現在()方法中，那么就必然出現在非靜態方法中。這就要求對代碼進行復雜的調用依賴分析，否則虛擬機可能會拋出ClassNotFoundException異常。而復雜的調用依賴分析會在代碼保護的離線處理中占用非常多的資源，對程序的性能也會造成影響。

3.2.2 修改的DVM

對Dalvik虛擬機的修改主要用來記錄進程中類對象的加載過程，以用來判斷樣本是否使用了動態代碼加載技術。

對于動態代碼加載技術，檢測方法的基本思想是：Dalvik虛擬機是一個解釋執行模型，其解釋器引用到的DEX字節碼一定是有效代碼。為了詳細地闡述這一思想，首先需要解釋一下Dalvik虛擬機中類對象和DEX文件在內存中的關聯關系，如圖4所示。

圖4 Dalvik虛擬機中類對象和DEX文件間的關聯

Dalvik虛擬機中維護著一張表，表里保存著當前所有已加載的類對象，即ClassObject。ClassObject對應于java.lang.Class的對象，每個類只有一個，只有當類被加載時才會創建。ClassObject中保存著該類所有方法的指針。DexFile是DEX文件在內存中的映射。由于DEX文件是索引結構，不能直接維護所有的類對象和方法對象，虛擬機會為每一個DexFile維護一個名為DvmDex的對象，ClassObject對其對應的DexFile的引用是間接的，即通過指向一個DvmDex對象來尋找其對應的DexFile對象。

Dalvik虛擬機維護這樣一種對象關系與其代碼加載機制有關，其對代碼的加載遵循Java虛擬機中類加載的默認委派機制。即啟動類加載器由虛擬機的本地代碼實現，負責對Java核心類的加載。擴展類加載器同樣由虛擬機實現，負責對虛擬機代碼庫中非核心代碼的加載。應用程序類加載器是虛擬機提供給應用的默認類加載器，負責加載開發者實現的代碼。除此之外，開發者還可以自行實現自定義類加載器，來加載私有的代碼。一個類的加載是從下到上以委派的模式加載的。即虛擬機先調用與當前類關聯的類加載器，查找所需要加載類的代碼，如果找不到則向上一級委派。上一級類加載器重復這一過程，直到執行到啟動類加載器。如果啟動類加載器也無法加載類的代碼，就會拋出ClassNotFoundException。在Dalvik虛擬機中，一個類加載器往往關聯著幾個DEX文件。

在Dalvik虛擬機中，當有一個DEX文件被加載時，就會創建一個DexFile對象來維護DEX文件的索引結構。然后，虛擬機會為該DexFile對象創建一個DvmDex對象以用來維護類、方法等內存中的對象。當虛擬機解釋執行時，它會通過全局表來來查找方法所在的類，即ClassObject。如果類不存在，則通過委派加載機制依次查找到途經類加載器所關聯的DexFile對象，直至找到所需的類。當把該類加載和初始化后，虛擬機通過ClassObject所引用的Method找到對應的字節碼，并開始解釋執行。

如果開發者想要對代碼進行保護，那么他們可以實現私有的類加載器，或者通過硬編碼等方式調用Dalvik虛擬機的代碼，從而繞過Dalvik虛擬機所提供的調用接口。更高級的規避方法是將代碼分段，在進程執行的過程中修改Dalvik虛擬機對象的引用指針，如將ClassObject的pDvmDex改為空指針，或將Method的pInstructions指向一塊堆內的地址，這時ClassObject與DvmDex所指向的Method對象必然不一致，從而對分析人員造成困擾。

然而，Dalvik虛擬機是一種解釋執行模型，其解釋器引用到的代碼一定是有效代碼，否則將導致程序行為異常。在解釋器運行的過程中，總是通過Dalvik虛擬機所維護的已加載類表來尋找對應的ClassObject，通過解引用其指向的方法代碼來解釋執行。由于進程的執行流程是無法預判的，所以可以認為ClassObject所引用的代碼是進程加載和恢復的原始代碼。我們將所有的ClassObject和與之相關的對象記錄到日志中，在后端處理階段對其進行分析。

3.2.3 修改的libc

通過對使用了代碼自修復技術的惡意樣本進行人工分析，我們發現了代碼自修復技術的使用模式：Dalvik虛擬機是一種解釋執行模型，其解釋執行的DEX文件映射在內存中的頁屬性是只讀的。進程為了修改DEX字節碼，會調用系統調用中的mprotect()函數來修改DEX字節碼在內存中的頁保護屬性，然后通過內存拷貝的方式來修改DEX字節碼，最后調用再mprotect()函數將其內存頁保護屬性改為原值。

為了分析樣本中代碼自修復技術的使用情況，我們在分析框架中對libc中mprotect()函數的調用情況進行了監控，每當進程調用mprotect()函數修改內存頁為可寫時，分析框架就將其調用參數的起始地址和終止地址記錄到日志中。同時，當進程執行一段時間后，分析框架將進程的內存布局從/proc/self/maps文件輸出到日志中。/proc/self/maps的內存布局如下所示：

4003a000-40049000 r-xp 00000000 b3:15 138 /system/bin/linker

40049000-4004a000 r-p 0000e000 b3:15 138 /system/bin/linker

4004a000-4004b000 rw-p 0000f000 b3:15 138 /system/bin/linker

...

40055000-40075000 r-xp 00000000 b3:15 749 /system/lib/libc.so

40075000-40077000 rwxp 00020000 b3:15 749 /system/lib/libc.so

40077000-4009c000 r-xp 00022000 b3:15 749 /system/lib/libc.so

...

41555000-41883000 rw-p 00000000 00:04 6911 /dev/ashmem/dalvik-zygote (deleted)

...

6eae7000-6ec54000 r-p 00000000 b3:17 185112 /data/dalvik-cache/system@framework.jar

...

747d7000-747d8000 r-s 00009000 b3:17 48292 /data/app/com.example-1.apk@classes.dex

...

如app_process、linker以及libc.so等可執行文件在內存中會映射為三段，分別具有可執行、只讀、讀寫的屬性，對應于.text、.rodata、.data/.bss字段。形如/dev/ashmem/xxxxxx (deleted)的是匿名共享內存Ashmem，經由Binder進行進程間通信后將內存銷毀。形如system@framework.jar為系統提供的Java代碼庫。/data/app/com.example-1.apk@classes.dex為第三方應用的DEX文件在內存中的映射，其屬性為只讀。我們需要監控的即是對/data/app/com.example-1.apk@classes.dex所要進行的修改。

3.3 后端處理

后端處理以動態分析輸出的日志為輸入，將代碼隱藏類規避技術的檢測結果作為輸出寫到日志中。

為了判斷樣本是否使用了動態代碼加載技術，一種取巧的做法是遍歷日志中記錄的所有的ClassObject，并統計其中不同的DvmDex的個數。如果DvmDex的個數超過1個，即使其值為空，也仍然使用了動態代碼加載技術。此外，我們還在日志中記錄了pDvmDex運行時的值，有效代碼是否在ClassObject間接引用的DexFile內存塊中等運行時數據來進行驗證。

通過比較日志中調用mprotect()函數修改的內存與內存布局中DEX文件映射區域是否有重合，即可得知進程在運行的過程中是否有修改DEX字節碼的意圖，從而可以判斷樣本是否使用了代碼自修復技術。

為了判斷樣本是否使用了垃圾代碼插入技術，最直觀的方法是使用反匯編工具直接對APK文件的DEX字節碼進行處理，通過分析工具輸出的日志來判斷樣本的代碼是否合乎規范。在這里，我們使用了baksmali[15]作為分析框架的反匯編的工具，版本號是2.1.2。當baksmali在處理DEX文件時，如果發現文件不符合規范或者代碼指令非法，即會輸出錯誤信息。

在表3中列出了經過后端處理階段后，對一個樣本的分析結果的所有字段。不符合規范或者代碼指令非法，即會輸出錯誤信息。

表3 檢測結果的所有字段

在動態分析的過程中，應用可能會在運行很長一段時間后仍然沒有記錄足夠的數據。比如樣本需要聯網下載文件，但是分析時的網絡狀況不是很好。這時，應將當前正在運行的安卓模擬器關閉，并將分析任務加入到任務隊列中等待重新分配。因此我們記錄了動態分析的起始時間和終止時間。除此以外，我們還記錄了樣本分析的最終狀態，這些狀態可能是：分析成功、安裝失敗、應用無法啟動、進程自動退出或崩潰，分析超時。導致安裝失敗的原因可能是APK文件不符合規范，沒有有效的自簽名證書，或者工具對樣本的信息提取不夠完整。應用無法啟動的原因可能是應用沒有Main Activity或者分析工具無法提取出樣本的Main Activity名稱。除此之外，我們還會以輪詢的方式查看進程是否在穩定運行，如果不是，則程序有可能已經退出或者運行崩潰。

4 實驗評估

為了評估分析方法的準確性，我們收集了兩組實驗樣本。

第一組樣本為第三節所述的人工標注的142個惡意樣本，收集時間為2015年08月01日至08月03日。

第二組樣本共計2 278個，于2016年05月12日在中國第三方應用市場應用寶中收集。我們在應用寶官方劃分的購物、閱讀、新聞、視頻、旅游、工具、社交、音樂、美化、攝影、理財、系統、生活、出行、安全、教育、健康、娛樂、兒童、辦公和通信21個分類中，將所有的推薦應用進行了抓取。這些應用在官方網站中按照下載量、打分等因素排序，是該應用市場中最流行的應用。考慮到游戲應用對安卓模擬器的兼容性較差，我們未對游戲類應用進行抓取。

我們的實驗平臺為64位Linux系統，內核版本3.16.0。處理器為40核，CPU頻率2.2 Hz，物理內存大小128 GB。動態分析采用的安卓系統源碼版本為4.4.4。

4.1 標注樣本的自動化分析

我們將檢測框架應用于人工標注的142個樣本中，以評估檢測方法的準確性。對人工標注樣本的自動化分析結果如表4所示。

表4 人工標注樣本的自動化分析結果

實驗結果顯示，在42個標注為使用了動態代碼加載技術的樣本中，檢測框架識別出了36個，使用了代碼自修復技術的2個樣本和垃圾代碼插入技術的6個樣本全部能識別出來。在未識別的6個樣本中，有1個樣本需要用戶登錄才能觸發對隱藏代碼的加載，其他5個樣本會在啟動階段判斷是否在安卓模擬器中運行，如果是，則立即退出。這5個樣本有對抗模擬器的意圖。

4.2 第三方市場應用的自動化分析

我們對2 278個第三方市場應用樣本進行了自動化分析，其結果如表5所示。

表5 第三方市場中樣本的自動化分析結果

在2 278個樣本中：有4個樣本無法安裝到安卓模擬器中，經分析發現這4個樣本依賴于Google Maps框架，而我們的定制版安卓模擬器中沒有Google 服務框架；有25個樣本使用了較新的安卓SDK，我們的工具在預處理階段無法提取其完整信息，動態分析不能繼續進行；有2個樣本由于兼容性問題在進程啟動后崩潰或退出。

在剩下的2 247個樣本中：有773個樣本使用了動態代碼加載技術；有0個樣本使用了代碼自修復技術；有23個樣本使用了垃圾代碼插入技術。其中，有2個樣本同時使用了動態代碼加載和垃圾代碼插入技術，剩下的1 453個樣本未發現使用本文所述的三種規避技術。

在2 247個樣本中未發現任何一個樣本使用了代碼自修復技術是出人意料的。在Going Native[16]中指出，調用mprotect()對DEX代碼做修改的樣本無一例外地使用了apkprotect這一早期代碼保護工具。我們對2 247個樣本中的文件進行了靜態掃描，發現確實沒有任何一個樣本使用了apkprotect工具，一個可能的原因是該工具已經不再對外提供服務了。判定樣本是否使用了apkprotect工具可以基于以下特征：1) 在APK文件中有libapkprotect.so這一本地代碼文件；2) DEX文件中有apkprotect這樣一個類，該類在初始化階段會加載libapkprotect.so。

如表6所示，我們在773個檢測為使用了動態代碼加載技術的樣本中隨機選取了50個樣本進行人工驗證，發現這50個樣本確實全部使用了動態代碼加載技術。檢測為使用了垃圾代碼插入技術的23個樣本全部進行了人工驗證，未發現有錯誤的檢測結果。在1 453個未檢出使用了代碼隱藏類規避技術的樣本中，選取了50個樣本進行人工驗證，發現有1個樣本由于安卓模擬器中地理位置信息不符合實際情況未觸發動態代碼加載的過程。

表6 第三方市場樣本分析結果的人工驗證

動態代碼加載技術在推薦應用中有33.9%的普及率，略高于人工分析的惡意樣本中29.6%的比率。雖然兩者的良惡性質、抓取時間皆不相同，但是比率較為接近，說明了動態代碼加載技術在良性、惡性樣本中都有著顯著的普及率。

通過對使用了動態代碼加載技術的樣本進行日志分析，我們發現有287個樣本的Dalvik虛擬機內存對象引用不正確，在使用動態代碼加載技術的樣本中比例達到了37.1%。這說明樣本有隱藏其規避行為的意圖，其動態代碼加載的過程具有隱蔽性。需要指出的是，這里所列的數據是真實情況的下界。

相反地，代碼自修復技術粒度粗、隱蔽性弱，垃圾代碼插入技術只能稍微提高安全分析的門檻，相較于動態代碼加載技術，其使用比例較低。這體現了規避技術的發展是一個對抗的過程，其在技術實現上越來越復雜且隱蔽。

5 結 語

通過對142個惡意樣本進行人工分析，本文提出了一個通用的自動化檢測框架，可用于識別樣本是否使用了代碼隱藏類規避技術。該檢測框架將代碼隱藏類規避技術的模式統一起來，利用安卓系統中Dalvik虛擬機的代碼加載和執行模型，對樣本加載和修改代碼的行為進行監控，可以全面有效地定位隱藏代碼，可應用于自動化分析。實驗表明，該檢測框架有著較高的準確率。

[1] Smartphone OS market share[OL]. 2016. http://www.idc.com/promo/smartphone-market-share/os.

[2] Android statistics: number of android applications[OL]. 2016. https://www.appbrain.com/stats/number-of-android-apps.

[3] Myapp mobile application market[OL]. 2016. http://sj.qq.com.

[4] Dalvik Execuatble Format[OL]. 2016. https://source.android.com/devices/tech/dalvik/dex-format.html.

[5] Strazzere T. Dex education: Practicing safe dex[M]. Black Hat, USA, 2012.

[6] Strazzere T. Dex education 201: anti-emulation[M]. HITCON, 2013.

[7] Vidas T, Christin N. Evading android runtime analysis via sandbox detection[C]//Proceedings of the 9th ACM symposium on Information, computer and communications security. ACM, 2014:447-458.

[8] Rowland Yu. Android Packers: Facing the challenges, Building solutions[C]//Proc. of the 24th Virus Bulletin International Conference, 2014.

[9] Strazzere T, Sawyer J. Android Hacker Protection Level 0 DEF CON 22[Z].2014.

[10] Zhang Y, Luo X, Yin H. Dexhunter: toward extracting hidden code from packed android applications[M]//European Symposium on Research in Computer Security. Springer International Publishing, 2015:293-311.

[11] Yang W B, Zhang Y Y, Li J R, et al. AppSpear: Bytecode Decrypting and DEX Reassembling for Packed Android Malware[M]//Research in Attacks, Intrusions, and Defenses. Springer International Publishing, 2015.

[12] Rasthofer S, Arzt S, Miltenberger M, et al. Harvesting runtime values in android applications that feature anti-analysis techniques[C]//Proceedings of the Annual Symposium on Network and Distributed System Security (NDSS). 2016.

[13] Rastogi V, Chen Y, Enck W. AppsPlayground: automatic security analysis of smartphone applications[C]//Proceedings of the third ACM conference on Data and application security and privacy. ACM, 2013:209-220.

[14] MonkeyRunner[OL]. 2016. https://developer.android.com/studio/test/monkeyrunner/index.html.

[15] Smali and baksmali: Dalvik bytecode toolkit[OL]. 2016. https://github.com/JesusFreke/smali.

[16] Afonso V, Bianchi A, Fratantonio Y, et al. Going native: Using a large-scale analysis of android apps to create a practical native-code sandboxing policy[OL]//Proceedings of the Annual Symposium on Network and Distributed System Security (NDSS), 2016.

ADETECTIONFRAMEWORKOFCODE-HIDINGEVASIONTECHNIQUEBASEDONANDROIDSYSTEM

Ma Xiaokai Yang Zhemin

M(SoftwareSchool,FudanUniversity,Shanghai201203,China)

With the development of malware detection and analysis techniques, a large number of malwares use evasion techniques to fight against security analysis. Among these evasion techniques, code-hiding evasion techniques hide application code from static analysis, thus cause analysis results wrong or incomplete. The explosive growth of malware required automated detection of code-hiding evasion techniques. Through manual analysis of 142 malicious samples, this paper summarized an approach for detecting code-hiding evasion techniques and implemented a generic automated detection framework. We use the detection framework to do experiments on 2 278 samples in a third party applications market, and find that 34.9% samples use code-hiding evasion techniques.

Android Evasion technique Static analysis Dynamic analysis

2017-07-10。馬曉凱，碩士，主研領域：移動安全，規避技術。楊哲慜，博士。

TP311

A

10.3969/j.issn.1000-386x.2017.11.058