面向動態加載的Android惡意行為動靜態檢測方法

鄭曉梅 楊宇飛 程 碩 潘正東

1(南京中醫藥大學信息技術學院 江蘇 南京 210023)2(南京大學計算機科學與技術系 江蘇 南京 210023)3(南京大學計算機軟件新技術國家重點實驗室 江蘇 南京 210023)

0 引 言

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

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

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

1 相關工作及背景

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

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

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

靜態方法和動態執行方法單獨使用在檢測動態加載的Android應用上時往往不能取得充分的結果。惡意代碼的靜態分析方法容易被開發者繞過，開發者可以選擇先開發正常應用通過靜態檢測，后期加入惡意的動態加載文件實現惡意行為。而單獨使用動態方法難以覆蓋所有的執行路徑，也無法充分檢測出惡意行為。

2 檢測方法的設計及實現

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

在上述研究的基礎上，本文提出面向動態加載的Android應用惡意代碼檢測方法。

2.1 方法概述

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

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

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

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

(2) 進行靜態分析。使用IntelliDroid工具，對逆向生成的Java字節碼文件進行靜態分析，包括調用圖分析和控制流分析，檢測工程中是否使用了動態加載技術，生成到達動態加載點的路徑，抽取構成路徑的事件序列，生成路徑上的條件約束，作為后續動態執行過程中的依賴輸入。

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

(4) 進行約束求解和動態執行事件序列。利用z3求解器對路徑上的約束進行求解，然后利用Android模擬器的adb調試工具，執行路徑上的事件序列，觸發動態加載，得到被動態加載的文件。

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

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

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

2.2 宿主App檢測模塊

宿主App檢測模塊主要對宿主App進行分析，目的是生成宿主App內部的控制流信息，提取出動態加載文件、記錄下動態加載的相關參數信息，用于后續模塊分析。主要步驟如下：

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

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

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

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

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

DexClassLoader (String dexPath,

String optimizedDirectory,

String librarySearchPath,

ClassLoader parent)

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

此外，在應用程序執行loadClass和getMethod方法之后，插入代碼分別記錄下類的名稱和方法的名稱，并存儲在預先建立好的log文件中，用于后續的外部文件分析。插樁完成后，得到了經過“改造”的APK文件，后續將該APK文件安裝在Android模擬器上，動態執行該App，來獲取外部文件和動態加載調用的相關信息。

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

2.3 動態加載文件分析模塊

動態加載文件分析模塊主要對動態加載文件進行分析，目的是依據記錄的動態加載的相關參數信息，生成動態加載文件中的控制流信息。主要步驟如下：

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

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

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

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

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

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

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

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

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

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

過程：methodExpand

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

2. for 每條路徑中的調用語句call do

3. if call調用的方法在方法表methodTable中then

4. if call調用的方法在AllContolFlow中能找到then

5. 直接從AllControlFlow中得到相應的控制流controlFlow

6. 用controlFlow替換該調用語句

7. else

8. 利用Soot生成調用的方法所在類的控制流controlFlow

9. 將controlFlow更新到AllControlFlow

10.用controlFlow替換該調用語句

11.end if

12. end if

13. end for

14.end for

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

16.更新序列化文件

在展開的過程中，為了兼顧效率和準確性，設定了最大展開深度，避免出現因為遞歸層數較深造成的長時間循環的現象。如果將最大展開深度設置為無窮大，那么最終得到的控制流可以認為是僅包含Java和Android API調用的序列。至此，得到了動態加載文件的控制流信息。

2.4 完整惡意行為分析模塊

將宿主App的控制流與動態加載文件的控制流進行合并，得到完整的控制流，逐個路徑進行掃描檢測敏感API，與預先設定的惡意行為模式進行匹配，得到最終的分析檢測結果。

2.4.1控制流合并

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

算法2控制流合并

輸入：內部控制流interCF、外部控制流outerCF

過程：controlFlowMerge

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

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

3. for 每個invokePoints中的插入點point do

4. 讀取log文件中point對應globalLoading Method信息

5. 根據global Loading Method信息，從outerCF中獲取相應方法的控制流methodControlFlow

6. 根據point，定位到相應的invoke調用語句

7. 用methodControlFlow替換該invoke語句

8. end for

9. end for

10.end for

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

2.4.2惡意代碼檢測階段

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

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

2.5 原型工具實現

根據提出的惡意代碼檢測方法，在現有工具的基礎上，實現了能夠完整執行惡意代碼檢測流程的原型工具，其簡要框架如圖3所示。

圖3 原型工具框架圖

主要依賴Soot和IntelliDroid工具，實現本文工作中的靜態分析和插樁工作，使用ApkTool工具對Android應用進行逆向工程，使用z3求解器求解約束實現動態執行。

3 實 驗

通過實驗對所提出的面向動態加載的Android應用惡意代碼檢測方法進行評估。

3.1 存在惡意行為的動態加載應用的檢測

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

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

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

圖4 faninxi方法的控制流圖

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

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

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

3.2 正常應用加入動態加載惡意行為的檢測

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

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

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

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

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

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

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

4 結 語

提出的基于控制流的動靜態結合檢測方法，針對Android動態加載機制進行惡意代碼檢測，并開發出了相關工具，能有效地檢測出應用中的惡意行為，可以作為Android第三方市場上架應用前對應用程序的檢測手段。

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