面向動態(tài)加載的Android惡意行為動靜態(tài)檢測方法

鄭曉梅 楊宇飛 程 碩 潘正東

1(南京中醫(yī)藥大學(xué)信息技術(shù)學(xué)院 江蘇 南京 210023)2(南京大學(xué)計算機(jī)科學(xué)與技術(shù)系 江蘇 南京 210023)3(南京大學(xué)計算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室 江蘇 南京 210023)

0 引 言

隨著移動智能終端的普及，Android系統(tǒng)的市場范圍在不斷擴(kuò)大，Android應(yīng)用程序的規(guī)模也在逐年擴(kuò)大。數(shù)據(jù)顯示，目前僅在Google Play就有373萬應(yīng)用，并且以每個月數(shù)萬個的速度增加。然而，其中約13%為低品質(zhì)應(yīng)用，大部分包含惡意代碼，顯示出不同的惡意行為，例如盜取用戶短信內(nèi)容、盜取用戶通信錄信息、自動訂購付費(fèi)業(yè)務(wù)、泄漏用戶位置信息等行為，用戶往往很難鑒別[1]。此外，由于國內(nèi)第三方市場往往缺乏嚴(yán)格的審查制度，讓大量垃圾應(yīng)用擁入，用戶的隱私安全和正常使用都得不到保障[2]，因此針對Android平臺的惡意軟件檢測技術(shù)顯得格外重要。

此外，Android新推出的動態(tài)加載技術(shù)支持分離執(zhí)行體的方式實(shí)現(xiàn)運(yùn)行時的動態(tài)程序加載，這雖然可以實(shí)現(xiàn)熱更新、快速修復(fù)bug等功能[3]，但同時也給惡意行為檢測帶來了新的挑戰(zhàn)。開發(fā)者可以在執(zhí)行過程中通過動態(tài)加載方式下載并運(yùn)行惡意行為程序[4]，而傳統(tǒng)的靜態(tài)代碼分析技術(shù)無法有效檢測[5]。

針對該問題，提出了一種動靜態(tài)相結(jié)合的Android程序惡意行為檢測技術(shù)，先針對宿主App采用靜態(tài)分析技術(shù)，提取程序的控制流圖，通過分析動態(tài)加載點(diǎn)的位置進(jìn)行路徑制導(dǎo)的動態(tài)執(zhí)行，以獲得動態(tài)加載的APK。然后，再針對其進(jìn)行靜態(tài)分析獲得控制流圖[6]，通過對宿主App和被加載APK的控制流組合，得到整個系統(tǒng)的完整控制流圖。針對該控制流圖進(jìn)行遍歷和惡意行為模式的匹配，就可以完成對完整App的檢測。本文基于所提出的惡意代碼檢測方法，開發(fā)了相應(yīng)的原型工具、構(gòu)造了實(shí)例，并且進(jìn)行了實(shí)例研究。

1 相關(guān)工作及背景

現(xiàn)有的惡意代碼檢測技術(shù)主要分為靜態(tài)分析和動態(tài)分析。靜態(tài)分析是在獲取源碼或編譯體的情況下不運(yùn)行程序直接進(jìn)行程序分析；動態(tài)分析主要是通過運(yùn)行程序，在運(yùn)行時收集相應(yīng)的上下文環(huán)境、虛擬機(jī)及操作系統(tǒng)等信息，進(jìn)而完成分析。

常用的靜態(tài)分析技術(shù)包括抽象語法樹分析、語義分析、控制流分析、數(shù)據(jù)流分析[7]、污點(diǎn)分析[8]、程序切片[9]等，目的是驗(yàn)證代碼是否規(guī)范、安全、可靠、便于維護(hù)。靜態(tài)分析能夠提供程序所有可能執(zhí)行的情況，其執(zhí)行速度快、效率高，但相對于動態(tài)分析，靜態(tài)分析采用了很多推斷機(jī)制，因此誤報率也較高。同時，靜態(tài)分析需要在進(jìn)行分析前獲得程序的所有源碼或編譯體，對于執(zhí)行體分離的運(yùn)行時加載程序難以實(shí)施靜態(tài)分析。相比之下，動態(tài)分析因?yàn)槭窃趫?zhí)行過程中收集信息，因此準(zhǔn)確，誤報率較低。而且對于動態(tài)加載的執(zhí)行體，也可以非常方便地在運(yùn)行時完成加載和執(zhí)行。但動態(tài)分析的缺點(diǎn)也非常明顯，那就是環(huán)境配置和執(zhí)行過程的時間成本太高，而且難以保證覆蓋程序的所有路徑[13]。

目前主要的Android分析工具有Soot(Java字節(jié)碼分析工具)、IntelliDroid(該工具為動態(tài)分析Android惡意軟件提供目標(biāo)輸入)、FlowDroid(基于污點(diǎn)分析的靜態(tài)分析工具)。Soot是加拿大麥吉爾大學(xué)的Sable課題組研發(fā)的Java字節(jié)碼分析工具，主要用于對字節(jié)碼的分析、插樁、優(yōu)化等，是Java和Android靜態(tài)分析方面應(yīng)用最廣泛的工具之一。Soot工具支持Call-graph 構(gòu)造、定義/調(diào)用鏈、模板驅(qū)動的程序內(nèi)數(shù)據(jù)流分析、污點(diǎn)分析等。IntelliDroid是一個為動態(tài)分析Android 惡意軟件提供目標(biāo)輸入的工具。由于Android應(yīng)用程序的入口點(diǎn)很多，包含很多的事件，僅僅觸發(fā)包含敏感API的Handler是不足的，有可能需要按照一定的順序觸發(fā)多個Handler，才會觸發(fā)真正的惡意行為，而IntelliDroid能做到觸發(fā)事件及其順序。利用IntelliDroid，可以有目的性地去觸發(fā)所期望的目標(biāo)函數(shù)，而不是傳統(tǒng)的fuzzing方式。FlowDroid是Sable小組開發(fā)的，以Soot為基礎(chǔ)，基于污點(diǎn)分析的靜態(tài)分析工具，目的是檢測Android 應(yīng)用程序中是否存在從source到sink的數(shù)據(jù)流[10]，其中source是用戶的敏感數(shù)據(jù)(如短信、聯(lián)系人、數(shù)據(jù)庫等)，sink是泄露方式(如短信發(fā)送、因特網(wǎng)等)。

靜態(tài)方法和動態(tài)執(zhí)行方法單獨(dú)使用在檢測動態(tài)加載的Android應(yīng)用上時往往不能取得充分的結(jié)果。惡意代碼的靜態(tài)分析方法容易被開發(fā)者繞過，開發(fā)者可以選擇先開發(fā)正常應(yīng)用通過靜態(tài)檢測，后期加入惡意的動態(tài)加載文件實(shí)現(xiàn)惡意行為。而單獨(dú)使用動態(tài)方法難以覆蓋所有的執(zhí)行路徑，也無法充分檢測出惡意行為。

2 檢測方法的設(shè)計及實(shí)現(xiàn)

工作基于IntelliDroid將動態(tài)加載API(DexClassLoader)作為目標(biāo)函數(shù)，從而獲得加載的程序，用作進(jìn)一步分析和檢測。此外，采用source & sink的方式進(jìn)行污點(diǎn)分析檢測。使用FlowDroid以APK文件作為靜態(tài)污點(diǎn)分析的輸入，模擬了完整的Android應(yīng)用生命周期來處理回調(diào)，source、sink的檢測通過解析從APK文件中抽取的manifest文件、Dalvik虛擬機(jī)字節(jié)碼文件和xml布局文件，生成一種dummy main函數(shù)，模擬activity生命周期，建立函數(shù)調(diào)用控制流圖CFG。

在上述研究的基礎(chǔ)上，本文提出面向動態(tài)加載的Android應(yīng)用惡意代碼檢測方法。

2.1 方法概述

惡意代碼檢測方法整體框架如圖1所示，在整個框架中，分為三個模塊：宿主App檢測模塊、動態(tài)加載文件分析模塊和完整惡意行為分析模塊。

圖1 惡意代碼檢測方法整體框架

該惡意代碼檢測方法大致的步驟如下：

(1) 對分析應(yīng)用程序進(jìn)行逆向工程。提取出APK(Android application package)中的dex字節(jié)碼文件、資源文件和配置文件，然后利用工具將Android的dex字節(jié)碼文件轉(zhuǎn)化為靜態(tài)分析工具能夠處理的Java的class字節(jié)碼文件(.class)。

(2) 進(jìn)行靜態(tài)分析。使用IntelliDroid工具，對逆向生成的Java字節(jié)碼文件進(jìn)行靜態(tài)分析，包括調(diào)用圖分析和控制流分析，檢測工程中是否使用了動態(tài)加載技術(shù)，生成到達(dá)動態(tài)加載點(diǎn)的路徑，抽取構(gòu)成路徑的事件序列，生成路徑上的條件約束，作為后續(xù)動態(tài)執(zhí)行過程中的依賴輸入。

(3) APK插樁。使用Soot工具對原始APK進(jìn)行插樁，在動態(tài)加載點(diǎn)插入記錄信息的代碼，使得當(dāng)App觸發(fā)動態(tài)加載時，能夠記錄下動態(tài)加載文件的存儲路徑、被加載的類信息、被調(diào)用的方法信息等，并輸出到文件中。

(4) 進(jìn)行約束求解和動態(tài)執(zhí)行事件序列。利用z3求解器對路徑上的約束進(jìn)行求解，然后利用Android模擬器的adb調(diào)試工具，執(zhí)行路徑上的事件序列，觸發(fā)動態(tài)加載，得到被動態(tài)加載的文件。

(5) 分析檢測被動態(tài)加載的文件。利用Soot工具，對被動態(tài)加載的文件進(jìn)行控制流分析，生成相關(guān)類的包含方法signature的控制流圖，得到外部文件的相關(guān)調(diào)用序列。

最后將步驟2中得到的調(diào)用方法序列與步驟5中得到的動態(tài)加載文件的調(diào)用序列拼接，形成完整的包含外部方法的序列。遍歷該序列，進(jìn)行惡意行為檢測，不僅可以檢測出動態(tài)加載文件中的惡意行為，還能檢測出宿主App和動態(tài)加載文件兩者組合產(chǎn)生的惡意行為。

在此框架方法的基礎(chǔ)上，部署整個工程成Web項(xiàng)目，通過前后端交互的方式，實(shí)現(xiàn)用戶在前端簡單操作上傳APK，等待后端分析檢測完成后，直接展示給用戶分析檢測報告。

2.2 宿主App檢測模塊

宿主App檢測模塊主要對宿主App進(jìn)行分析，目的是生成宿主App內(nèi)部的控制流信息，提取出動態(tài)加載文件、記錄下動態(tài)加載的相關(guān)參數(shù)信息，用于后續(xù)模塊分析。主要步驟如下：

(1) APK逆向階段，結(jié)合使用Apktool和dex2jar工具，將APK解包，把Android 字節(jié)碼文件(.dex)逆向轉(zhuǎn)化為靜態(tài)分析工具能夠處理的Java字節(jié)碼文件(.class)。

(2) 靜態(tài)分析階段，判斷宿主App是否采用動態(tài)加載技術(shù)和生成可以到達(dá)動態(tài)加載點(diǎn)的路徑，以及該路徑上的語句和約束。使用IntelliDroid工具，對逆向生成的Java字節(jié)碼文件進(jìn)行靜態(tài)分析，包括調(diào)用圖分析和控制流分析，檢測工程中是否使用了動態(tài)加載技術(shù)，生成到達(dá)動態(tài)加載點(diǎn)的路徑，抽取構(gòu)成路徑的事件序列，生成路徑上的條件約束，作為后續(xù)動態(tài)執(zhí)行過程中的依賴輸入。

修改IntelliDroid的配置文件，將目標(biāo)方法設(shè)置為動態(tài)加載相關(guān)的API。依據(jù)動態(tài)加載技術(shù)的使用方法，創(chuàng)建DexClassLoader或PathClassLoader類加載器后，都需要調(diào)用類加載器的loadClass方法來將目標(biāo)類加載進(jìn)來，因此將loadClass方法作為目標(biāo)方法，修改targeted-Methods.txt配置文件，填寫。這是Java方法的一種三地址碼表示形式，包含了方法的類信息、參數(shù)信息以及返回值信息，與普通的只包含方法名稱信息的表示方法相比，能明顯降低匹配錯誤，更加精確地定位目標(biāo)方法。

靜態(tài)分析完成后，將在指定的輸出目錄生成一些結(jié)果文件，包括appInfo.json(App靜態(tài)分析的文件結(jié)果：mainActivity，到達(dá)目標(biāo)方法路徑的起點(diǎn)和終點(diǎn)等)、constrainsM_N.py(約束文件，表示要觸發(fā)第M條路徑上第N個受約束的事件需要滿足的約束)和instrPath.json(到達(dá)動態(tài)加載點(diǎn)的所有路徑控制流文件，記錄了該路徑上的所有調(diào)用語句及其順序)。

(3) APK插樁階段，使用Soot工具對原始APK進(jìn)行插樁，在動態(tài)加載點(diǎn)插入記錄信息的代碼，當(dāng)App觸發(fā)動態(tài)加載時，能夠記錄下動態(tài)加載文件的存儲路徑、被加載的類信息、被調(diào)用的方法信息等，并輸出到文件中。DexClassLoader的構(gòu)造方法如下：

DexClassLoader (String dexPath,

String optimizedDirectory,

String librarySearchPath,

ClassLoader parent)

共有4個參數(shù)，其中：dexPath表示外部文件的路徑，optimizedDirectory表示外部文件釋放的路徑，librarySearchPath表示包含native libraries的文件目錄列表(一般設(shè)置為null)，parent表示父類加載器。主要關(guān)心參數(shù)dexPath，在DexClassLoader構(gòu)造完成后，只需將dexPath指向的文件拷貝到預(yù)先設(shè)定好的目錄下，就能得到被加載的文件而且不會被系統(tǒng)刪除，用于后續(xù)的外部文件分析。

此外，在應(yīng)用程序執(zhí)行l(wèi)oadClass和getMethod方法之后，插入代碼分別記錄下類的名稱和方法的名稱，并存儲在預(yù)先建立好的log文件中，用于后續(xù)的外部文件分析。插樁完成后，得到了經(jīng)過“改造”的APK文件，后續(xù)將該APK文件安裝在Android模擬器上，動態(tài)執(zhí)行該App，來獲取外部文件和動態(tài)加載調(diào)用的相關(guān)信息。

(4) 解析約束階段，使用z3求解器，對靜態(tài)分析生成的約束文件進(jìn)行求解，依次執(zhí)行時間序列，達(dá)到觸發(fā)動態(tài)加載的目的，并且在這個過程中執(zhí)行插樁的代碼，記錄輸出相應(yīng)的信息。執(zhí)行完成之后，將動態(tài)加載文件和記錄信息的log日志從Android 系統(tǒng)中提取到本地，作為后續(xù)動態(tài)加載文件分析的依賴。

2.3 動態(tài)加載文件分析模塊

動態(tài)加載文件分析模塊主要對動態(tài)加載文件進(jìn)行分析，目的是依據(jù)記錄的動態(tài)加載的相關(guān)參數(shù)信息，生成動態(tài)加載文件中的控制流信息。主要步驟如下：

(1) 外部文件預(yù)處理階段，根據(jù)Android開發(fā)者文檔的說明，動態(tài)加載的文件可以是dex文件、apk文件和jar文件三種類型，并且apk文件和jar文件必須包含classes.dex文件。依據(jù)動態(tài)加載的原理，無論被加載的文件是哪種格式，其本質(zhì)上都是先將包含的dex文件釋放到臨時目錄，然后再加載該dex文件。因此預(yù)處理的第一步是先將動態(tài)加載文件解包，將其中包含的dex文件拷貝到指定目錄再進(jìn)行處理。

預(yù)處理包括兩個步驟：一是逆向處理，同樣使用dex2jar工具，將動態(tài)加載的dex文件逆向轉(zhuǎn)化為Java字節(jié)碼文件，生成包含所有Java字節(jié)碼(.class)文件的文件夾，并且保證每層文件夾都以該層的包名稱來命名；二是對動態(tài)加載文件進(jìn)行簡單掃描，分析其中包含的類和方法，生成相應(yīng)文件的方法表，將classes.jar作為處理對象，使用"jar tf classes.jar grep.class"指令來獲取jar文件中的所有類信息，再使用"javap-cp classes.jar"指令以類名作為參數(shù)來獲取每個類中的方法信息，將結(jié)果存放在methods.txt文件中。

(2) 外部方法靜態(tài)分析階段，使用Soot工具，對逆向后的Java字節(jié)碼文件進(jìn)行靜態(tài)分析，生成目標(biāo)類的控制流，并依據(jù)生成的方法表，對控制流在JDK和Android SDK層面進(jìn)行方法的展開，將控制流對象序列化，保存在文件中。

生成控制流圖相關(guān)的main方法位于soot.tools.CFGViewer類中，只需要指定要分析的類的完整信息(即包含PackageName和ClassName，以“.”來分隔)以及相關(guān)CLASSPATH(一般指android.jar和jre/lib/rt.jar)，即可生成該類中所有方法的控制流信息。類信息從之前動態(tài)執(zhí)行之后保存在本地的log文件中讀取。

Soot在控制流分析的過程中，對每條指令做了簡化，僅包含調(diào)用方法的名稱而略去了所在類和返回值類型這兩個重要的信息，因此對Soot源碼進(jìn)行修改，使得生成的控制流中包含方法完整的signature，圖2是修改前后的比較。

圖2 Soot源碼修改前后生成的控制流語句對比

為了更好地記錄和利用控制流信息，定義了一個變量來在內(nèi)存中保存該控制流信息，其數(shù)據(jù)結(jié)構(gòu)為Map>>。其中Map的鍵key表示方法名稱，List表示控制流的一條路徑，Map的值value表示該方法所有的控制流路徑。除此之外，還使用第三方工具fastjson將該Map序列化存儲到文件中，方便后續(xù)對控制流的進(jìn)一步操作。

由于Soot控制流分析的局限性，分析得到的某個方法的控制流不能夠做到對方法調(diào)用的進(jìn)一步展開，因此需要解決這一問題。為了保證工作的正確性以及處理效率，將方法展開的范圍限定為整個動態(tài)加載文件的工程中，即只對預(yù)處理階段得到的方法表中的方法進(jìn)行展開，其余方法視為JDK級別、SDK級別以及第三方依賴方法不做展開處理。為了提高方法展開的效率，還定義了一個靜態(tài)變量AllControlFlow來存儲各個類的控制流信息，避免了對序列化后存儲的控制流文件的重復(fù)讀取，AllControlFlow是Map對象，以類名作為key鍵，以相對應(yīng)的控制流(即上文中提到的Map)作為value值。具體解決方案的偽代碼如算法1所示。

算法1控制流中的方法展開過程

輸入：原始、未做展開的方法控制流

過程：methodExpand

1.for 控制流中的每條路徑path do

2. for 每條路徑中的調(diào)用語句call do

3. if call調(diào)用的方法在方法表methodTable中then

4. if call調(diào)用的方法在AllContolFlow中能找到then

5. 直接從AllControlFlow中得到相應(yīng)的控制流controlFlow

6. 用controlFlow替換該調(diào)用語句

7. else

8. 利用Soot生成調(diào)用的方法所在類的控制流controlFlow

9. 將controlFlow更新到AllControlFlow

10.用controlFlow替換該調(diào)用語句

11.end if

12. end if

13. end for

14.end for

15.更新展開后的控制流到AllControlFlow中

16.更新序列化文件

在展開的過程中，為了兼顧效率和準(zhǔn)確性，設(shè)定了最大展開深度，避免出現(xiàn)因?yàn)檫f歸層數(shù)較深造成的長時間循環(huán)的現(xiàn)象。如果將最大展開深度設(shè)置為無窮大，那么最終得到的控制流可以認(rèn)為是僅包含Java和Android API調(diào)用的序列。至此，得到了動態(tài)加載文件的控制流信息。

2.4 完整惡意行為分析模塊

將宿主App的控制流與動態(tài)加載文件的控制流進(jìn)行合并，得到完整的控制流，逐個路徑進(jìn)行掃描檢測敏感API，與預(yù)先設(shè)定的惡意行為模式進(jìn)行匹配，得到最終的分析檢測結(jié)果。

2.4.1控制流合并

經(jīng)過宿主App的檢測與分析以及動態(tài)加載文件的檢測與分析，分別得到了APK內(nèi)部與外部的控制流信息。根據(jù)APK內(nèi)部的控制流中的動態(tài)加載點(diǎn)的信息，在不同的動態(tài)加載點(diǎn)插入相應(yīng)的外部方法的控制流，就得到了完整的控制流信息。在宿主App內(nèi)部的控制流中，對每一條控制流語句進(jìn)行了編號，作為確定位動態(tài)加載的依據(jù)。同時，每條路徑還定義了名為invokePoints的變量，記錄下動態(tài)加載方法調(diào)用語句相對應(yīng)的控制流語句的編號，結(jié)合log文件中記錄的global Loading Method，即可得知動態(tài)加載調(diào)用的方法和調(diào)用所在的位置，將外部的相應(yīng)方法的控制流插入該位置即可[11]?？刂屏骱喜⒌膫未a如算法2所示。

算法2控制流合并

輸入：內(nèi)部控制流interCF、外部控制流outerCF

過程：controlFlowMerge

1.for interCF中的每條路徑path do

2. for 每條路徑path中的invokePoints do

3. for 每個invokePoints中的插入點(diǎn)point do

4. 讀取log文件中point對應(yīng)globalLoading Method信息

5. 根據(jù)global Loading Method信息，從outerCF中獲取相應(yīng)方法的控制流methodControlFlow

6. 根據(jù)point，定位到相應(yīng)的invoke調(diào)用語句

7. 用methodControlFlow替換該invoke語句

8. end for

9. end for

10.end for

輸出：合并后的控制流mergedCF。

2.4.2惡意代碼檢測階段

定義一些典型的惡意行為模式，如竊取短信內(nèi)容、竊取通訊錄信息、竊取用戶位置信息等。將有關(guān)惡意行為的API稱之為敏感API，敏感API可以分為兩類：獲取用戶隱私信息的API，稱之為source-API；泄露用戶隱私信息的API，稱之為sink-API。主要依據(jù)FlowDroid的污點(diǎn)分析的配置文件，搜集了一些Android開發(fā)中會使用到的敏感API，并同樣使用配置文件的形式，使得敏感API可配置，能自行添加刪除[12]。

對敏感API 進(jìn)行簡單的語義分析，使得在執(zhí)行惡意代碼檢測之后，能夠給出較為準(zhǔn)確的檢測報告，反映出軟件的可能存在的具體惡意行為。例如，進(jìn)行控制流分析之后，其中一條路徑上調(diào)用了getLastKnownLocation()方法，可以分析出軟件獲取了用戶的定位信息；接著在該路徑上又調(diào)用了sendTextMessage()方法，可以分析出軟件將某些信息以SMS短信的形式發(fā)送出去，兩者結(jié)合可以判斷，軟件可能存在通過SMS短信泄露用戶位置信息的隱私泄露行為。類似地，對多種API組合進(jìn)行了惡意行為模式的定義，關(guān)鍵信息為隱私的種類和泄露的方式，即：該軟件可能存在獲取用戶XX隱私，并通過XX方式將其泄露的惡意行為。

2.5 原型工具實(shí)現(xiàn)

根據(jù)提出的惡意代碼檢測方法，在現(xiàn)有工具的基礎(chǔ)上，實(shí)現(xiàn)了能夠完整執(zhí)行惡意代碼檢測流程的原型工具，其簡要框架如圖3所示。

圖3 原型工具框架圖

主要依賴Soot和IntelliDroid工具，實(shí)現(xiàn)本文工作中的靜態(tài)分析和插樁工作，使用ApkTool工具對Android應(yīng)用進(jìn)行逆向工程，使用z3求解器求解約束實(shí)現(xiàn)動態(tài)執(zhí)行。

3 實(shí) 驗(yàn)

通過實(shí)驗(yàn)對所提出的面向動態(tài)加載的Android應(yīng)用惡意代碼檢測方法進(jìn)行評估。

3.1 存在惡意行為的動態(tài)加載應(yīng)用的檢測

(1) 本次實(shí)驗(yàn)采用的實(shí)例，是一款名為“閱讀神器”的App，來源于國內(nèi)知名移動安全論壇——看雪論壇，由論壇用戶上傳提供，并稱該應(yīng)用可能存在木馬行為。該應(yīng)用申請了SMS即短信權(quán)限，通過查看APK中的AndroidManifest.xml文件，可以得知主要是SEND_SMS和READ_SMS權(quán)限，這與應(yīng)用本身作為閱讀軟件的用途不相符。通過將該App安裝在Android虛擬機(jī)上并測試，卻發(fā)現(xiàn)該App在表面上并沒有明顯惡意行為。

(2) 宿主App的檢測與分析階段，首先將APK文件進(jìn)行逆向處理，生成相應(yīng)的Java字節(jié)碼文件，以及解包APK中的資源文件；對逆向處理后的應(yīng)用進(jìn)行靜態(tài)分析，生成宿主App內(nèi)部的控制流信息和觸發(fā)動態(tài)加載的事件序列及其約束。接著對原始APK read.apk進(jìn)行插樁，植入相關(guān)代碼，生成插樁完成之后的APK read-ins.apk；將read-ins.apk和靜態(tài)分析產(chǎn)生的事件序列及其約束作為輸入，進(jìn)行動態(tài)執(zhí)行操作，插樁后的Apk被安裝在Android模擬器上，解析約束，執(zhí)行事件序列。最終得到被動態(tài)加載的文件cao.apk和動態(tài)執(zhí)行記錄文件log.txt。結(jié)果顯示經(jīng)過逆向的APK的資源文件中同樣存在一個名為cao.apk的文件，位于/res/raw目錄下，經(jīng)過文件的MD5值計算和對比，可以判定兩者為同一文件，代表著該應(yīng)用動態(tài)加載的目標(biāo)文件位于工程內(nèi)部的資源文件中。

(3) 在動態(tài)加載文件的檢測與分析階段，得到動態(tài)加載文件cao.apk之后，對其進(jìn)行控制流分析，根據(jù)log.txt文件中的記錄，動態(tài)加載調(diào)用的xcvwreoipurew.zxcbwqioewr.xcvzmbnwerqoi.zxcvbnm類中的faxinxi方法。該方法的控制流圖，如圖4所示。

圖4 faninxi方法的控制流圖

該方法調(diào)用了sendMultipartTextMessage這一API，屬于敏感API，在后續(xù)過程中觀察是否能檢測出可能存在的惡意行為。

(4) 經(jīng)過合并和檢測，得出了檢測報告。根據(jù)檢測報告顯示，該應(yīng)用調(diào)用getMessageBody方法來讀取用戶短信內(nèi)容，獲取了用戶的隱私數(shù)據(jù)，然后調(diào)用了sendMultipartTextMessage方法將隱私數(shù)據(jù)以短信的形式發(fā)送出去，不但會泄露用戶的隱私，還會造成額外的短信費(fèi)用，可以將其作為一種惡意行為。檢測結(jié)果與之前通過人工查看控制流的預(yù)測相吻合。

此外，通過逆向原始APK，閱讀反編譯后的源碼，結(jié)合靜態(tài)分析生成的事件序列后發(fā)現(xiàn)，動態(tài)加載的調(diào)用位于短信服務(wù)的onReceive方法中，因此猜想該應(yīng)用會在用戶收到短信的情況下，讀取短信內(nèi)容，并將其發(fā)送給預(yù)設(shè)的收件人，造成隱私泄露和不知情扣費(fèi)。后續(xù)利用telnet向Android模擬器模擬發(fā)短信，確實(shí)觸發(fā)了該應(yīng)用的動態(tài)加載，進(jìn)一步證明了預(yù)測的正確性。

3.2 正常應(yīng)用加入動態(tài)加載惡意行為的檢測

(1) 使用開源應(yīng)用Good Weather項(xiàng)目地址:https://github.com/qqq3/-good-weather。Good Weather作為一款天氣軟件，擁有獲取設(shè)備定位信息的權(quán)限，因此我們對其進(jìn)行改造，在原始代碼中獲取定位信息之后，插入執(zhí)行動態(tài)加載的代碼，達(dá)到將定位信息發(fā)送至預(yù)設(shè)服務(wù)器的目的，來模擬隱私信息的泄露。

(2) 為了保證實(shí)驗(yàn)的公正，使用惡意軟件在線檢測網(wǎng)站VirusTotal對樣本進(jìn)行檢測，并與結(jié)果進(jìn)行對比。先對未插入任何代碼的Good Weather應(yīng)用進(jìn)行檢測。63種不同公司的檢測方法均沒有檢測出Good Weather本身包含惡意代碼，因此認(rèn)為該樣本是純凈的。

接著對插入動態(tài)加載代碼之后的Good Weather應(yīng)用進(jìn)行檢測，63種不同公司的檢測方法中有62種沒有檢測出Good Weather本身包含惡意代碼，僅僅有一個公司給出了風(fēng)險告警，因此可以大致認(rèn)為經(jīng)過改造之后的包含惡意的Good Weather應(yīng)用不能被絕大部分檢測方法發(fā)現(xiàn)惡意代碼。下面將展示對該應(yīng)用的檢測結(jié)果，由于上文已經(jīng)對具體實(shí)現(xiàn)方法進(jìn)行了詳細(xì)介紹，因此該實(shí)例僅介紹檢測結(jié)果和分析。

第一條路徑存在隱患,從獲取隱私到泄漏的路徑如圖5所示。

圖5 插入代碼后的Good Weather的本文工作檢測結(jié)果

可以看出，工作實(shí)現(xiàn)的工具成功地檢測出了該隱私泄露，準(zhǔn)確定位到了隱私信息和泄露相關(guān)的API調(diào)用，即通過getLatitude()獲取用戶的位置信息，使用okhttp框架的post請求，將該隱私信息發(fā)送到預(yù)先啟動的服務(wù)器上。宿主App中本身就包含獲取定位信息的代碼，插入的僅有DexClassLoader的構(gòu)造和類加載、方法調(diào)用的簡單代碼，而在動態(tài)加載文件中實(shí)現(xiàn)了基于okhttp框架的post請求的發(fā)送的功能，兩者獨(dú)立的情況下不存在惡意行為，但兩者結(jié)合起來就是一種典型的通過post請求泄露用戶隱私的惡意行為。

通過以上的檢測、分析和對比，證明了利用動態(tài)加載技術(shù)可以躲避當(dāng)前大部分的惡意代碼檢測，實(shí)現(xiàn)對用戶隱私信息的盜取。而提出和實(shí)現(xiàn)的惡意代碼檢測方法，能夠有效針對這一情況，提高檢測的準(zhǔn)確率，減少惡意軟件的漏報。

4 結(jié) 語

提出的基于控制流的動靜態(tài)結(jié)合檢測方法，針對Android動態(tài)加載機(jī)制進(jìn)行惡意代碼檢測，并開發(fā)出了相關(guān)工具，能有效地檢測出應(yīng)用中的惡意行為，可以作為Android第三方市場上架應(yīng)用前對應(yīng)用程序的檢測手段。

接下來的工作中，擬將從以下幾個方面來進(jìn)一步改善目前所提出檢測方法:(1) 通過更加準(zhǔn)確的靜態(tài)分析、更高效率的約束求解以及更加高效的控制流分析方法，大幅度提高整個工程的惡意代碼的檢測效率。(2) 對敏感API的調(diào)研仍需要繼續(xù)進(jìn)行，通過搜集更多的惡意應(yīng)用，了解更多的惡意行為。(3) 形成完整的工具平臺。