Android惡意軟件檢測技術分析和應用研究

文偉平，梅瑞，寧戈，汪亮亮

(北京大學 軟件與微電子學院，北京 102600)

1 引言

近幾年來，Android平臺已經成為了一個非常流行的手機操作系統平臺，并且占據了世界上超過一半的手機操作系統市場份額。隨著Android智能手機與Android平板電腦的普及，基于Android的惡意軟件也發展迅猛，因此基于Android平臺的惡意代碼檢測技術就開始被提出。盡管Android智能系統相比蘋果的iOS系統和諾基亞的Symbian系統更年輕，一些Android平臺上的安全檢測技術研究已經發布，如系統訪問控制機制[1,2]、惡意軟件檢測[3]、應用權限分析[4]、內核加固[5]等。大量的 Android系統安全方面的研究表明，Android平臺需要提出更加穩健的安全檢測技術。

對于惡意軟件檢測技術來說，應用程序的特征是非常重要的。根據文獻[6]，惡意軟件檢測存在2種通用技術：靜態檢測和動態檢測。2種技術各有優缺點[7]，在現實中，大量的方法都是同時包含動態和靜態檢測技術。靜態分析涉及到二進制相關的技術，其中包括反編譯、逆向分析、模式匹配和靜態系統調用分析等。靜態分析技術有一個共同的特點：應用程序不被執行。基于Android平臺手機端應用的掃描技術一般都采用簽名靜態比對。靜態分析的優點是簡單并且快速，但是它最大的缺點是掃描惡意軟件前需要知道已知惡意軟件信息，如簽名、行為模式、權限申請等，使得它不能實現自動掃描并適應未知惡意程序的功能。另外一種檢測技術是動態檢測技術，它的核心過程將應用程序運行在一個封閉的環境并進行監視，從而分析應用程序的行為特征。有很多的參數都可以被動態分析采集，如文件權限改變、進程和線程運行情況、系統調用情況、網絡訪問情況等。因為動態檢測需要應用程序實時運行，并且需要較長的時間采集應用程序的動態數據，所以它比靜態分析更復雜。

作者提出了一種基于permission組合的技術，幫助用戶及時發現潛在惡意應用程序。同時，提出了基于云端靜態分析和動態分析技術的方案，為惡意程序的分析奠定堅實的基礎。

2 檢測框架概述

本文提出的Android平臺惡意代碼檢測系統框架由手機客戶端和遠程服務端組成，手機客戶端是一款基于Android平臺的應用程序，遠程服務端收集了大量的資源和數據，以最快的速度檢測Android應用程序。首先，手機客戶端應用程序被發布到 Google市場或第三方市場，用戶可以從市場下載并安裝。此應用程序主要負責輕量級的靜態掃描和數據的收集工作，手機掃描確定性結果將會直接展示給用戶，不能確定的結果將會作為樣本上傳到遠程服務器，供進一步的分析。這里掃描的對象是基于Andorid平臺的第三方應用程序，它們可以從 Google市場或者第三方市場下載獲得，其中不包括Android系統自帶程序和廠商自帶程序。協作框架如圖1所示。

圖1 手機端和服務端協作框架

遠程服務端檢測系統將手機客戶端收集的樣本數據首先與惡意軟件數據庫進行比對，如存在相同記錄，則直接反饋給手機端，否則啟動服務端檢測分析系統。服務端檢測分析系統包括靜態分析和動態調試2個模塊，由于服務端系統具有豐富的軟硬件資源和龐大的特征數據庫，會及時針對待分析的樣本進行響應。測試若發現未知的惡意軟件，首先將該惡意軟件的樣本特征保存到惡意軟件數據庫中，然后反饋結果到手機端。服務端檢測系統中的靜態檢測模塊主要包括惡意軟件靜態行為模式分析和基于權限的檢測，模式分析檢測技術是基于字節碼的；動態檢測是在一個安全的沙盒中進行的。這個沙盒[8]可以定義為一個執行環境，此環境中所有的進程的行為都要經過安全策略的檢查。現實中，沙盒系統中的一個實例，它被系統隔離，不能進行任何惡意行為。

遠程服務端檢測系統的檢測數據來源于Google標準市場以及國內市場，還有用戶手機端收集到的樣本數據。檢測系統包括靜態檢測和動態檢測。其中靜態檢測以縮小檢測范圍，發現具有疑似惡意行為特征的軟件為目標；動態檢測則通過動態行為跟蹤從而發現未知惡意軟件。檢測框架如圖2所示。

圖2 服務端檢測系統框架

3 檢測技術

3.1 基于permission檢測

3.1.1 方法步驟

對基于permission檢測技術的研究采取歸納，演繹推理的科學實驗方法。首先針對實際的惡意程序樣本進行分析，提取出它們對權限申請的共同特點，并根據惡意程序樣本的分類推理出初步的敏感permission組合分類；然后根據初步的敏感permission組合分類的規則來匹配海量的應用程序，這些應用程序大都來自android.market.com, 并將匹配的結果統計出來，結合應用程序的分類產生具體組合規則，這里的分類是 Google市場上的標準分類；最后使用具體組合規則對新產生的惡意程序進行匹配，觀察匹配結果，根據結果再次修正組合規則。流程圖如圖3所示。

圖3 基于permission檢測流程

3.1.2 檢測策略

3.1.2.1 樣本分析

惡意程序樣本是permission檢測技術的實驗依據。目前的惡意程序樣本庫中包括木馬遠程控制、竊取用戶隱私、發送扣費短信和root設備4大類。每個大類中又有更細的分類，其中木馬遠程控制包括Pjapps、Bgserv、Geinimi和Rootcager等幾種惡意程序；竊取用戶隱私包括 Adrd、Walkinwat、Ewallsh和Tapsnake等幾種惡意程序；發送扣費短信包括 FakePlayerA、FakePlayerB、Smstibook、SmsReplicator和Adsms等幾種惡意程序；root設備包括Zeahache惡意程序。每種惡意程序都會有特定的攻擊步驟，并申請了與其攻擊操作相對應的權限。

惡意程序樣本的權限提取可以通過 apktool工具和shell腳本完成。首先將所有的惡意程序文件放入一個惡意程序文件夾中，通過shell腳本完成遍歷所有文件并進行“apktool d”命令，從而獲取有效的AndroidManifest.xml文件；然后通過shell腳本將所有惡意程序的 AndroidManifest.xml文件中權限記錄導入到文本文件中；最后將文本文件轉化成excel格式并保存。

表1中列舉了幾種典型的惡意軟件[9]的申請重要權限列表和攻擊行為描述。

表 1中列舉出的 10種惡意軟件家族大都是2012年上半年報道出來的。在這些惡意軟件中，Geinimi、ADRD、Pjaaps 和 Bgserv類型的惡意程序一般都具木馬遠程控制的能力。這些類型的惡意程序都會網絡訪問功能，有些具有短信監聽或發送功能。

3.1.2.2 規則驗證

1) 單個危險權限

應用軟件中如果申請了Android系統中的危險權限，此應用具有較高的危險性。從統計學的角度分析，此類應用程序一般具有特殊的功能，而且應用市場的應用絕大多數都不會申請此類敏感權限，所以首先將具有此類權限申請的應用篩選出來。單個危險權限規則如表2所示。

以上權限都是敏感權限，都被標識為：dangerous，signature 或者signatureOrSystem。例如，在申請 SET_DEBUG_APP權限后，程序就具有配置一個程序用于調試的能力。Android SDK中有些API對開發者透明，這些API不能被第三方應用程序調用，僅能被系統程序調用。惡意程序的作者可以下載包含隱藏API的Android 源代碼，編譯，修改并且生成應用程序。因此，惡意程序通過申請SET_DEBUG_APP權限，有可能禁止一些反惡意程序軟件的運行。

表1 惡意軟件權限申請及攻擊行為描述

表2 單個危險權限規則

表3 危險權限組合規則

2) 多個危險權限組合

申請的權限越多，惡意程序發揮的空間越大，對用戶威脅越大。很多惡意程序在攻擊之前，向系統申請大量的權限，以便成功調用具有威脅的API。通過對上述惡意程序樣本攻擊特點的分析，列舉出多個危險權限組合的規則，如表3所示。

3.2 字節碼靜態檢測

3.2.1 方法步驟

本文的靜態分析技術是基于 ASM 字節碼處理框架的字節碼解析技術。它的目標是跟蹤惡意程序的靜態行為并標識。基本步驟是：首先解壓APK分組，并通過dex2jar工具將classes.dex 文件轉化為 jar分組，然后分析字節碼指令，通過ASM框架獲取到函數調用關系和JVM運行指令。在分析過程中，模擬JVM指令運行，得到函數的靜態參數值和函數之間的調用關系圖，通過靜態分析函數之間的調用關系以及相關度來確定惡意軟件的行為。字節碼的分析由shell腳本、Java分析以及一些python腳本組成。具體的操作步驟如圖4所示。

圖4 字節碼檢測流程

基于字節碼的靜態分析前期準備需要獲取到jar分組，其中包含了應用程序的class文件。Android應用程序中都包含AndroidManifest.xml文件，此文件中包含了應用程序的權限申請和 Activity、Broadcast以及Provider的聲明。字節碼分析的入口以Activity為基礎；對于Broadcast聲明，一般都由onreceive函數來接受廣播消息，因此onreceive也是一個分析入口。具體的工作是分析 jar分組中的class文件，分析內容包括查找敏感函數、跟蹤靜態參數和惡意軟件行為模式分析。

3.2.1.1 獲取jar分組

首先將APK文件后綴改為zip并解壓，得到其中的class.dex文件，它就是Java文件編譯再通過dx工具打包而成的。下載dex2jar工具，將class.dex復制到dex2jar.sh所在目錄，并在其目錄下運行 sh dex2jar.sh class.dex 命令，生成一個文件classes_dex2jar.jar。此時的jar分組就是靜態檢測需要的并分組文件。

3.2.1.2 查找敏感函數

應用程序申請特定權限后，是否調用了敏感函數有待于靜態代碼的分析。敏感函數跟蹤技術利用ASM基本框架，遍歷軟件中導入的系統庫函數，查找敏感函數，從而確定是否調用了敏感函數。從ASM框架提供的API中，可以獲取到所有的類及其函數的詳細信息，包括類名稱、函數名稱、參數等。注意用戶定義的類或者函數可能被混淆，但系統函數是不能混淆的，而跟蹤的敏感函數都為系統函數，所以混淆技術并不影響基于字節碼的跟蹤。

3.2.1.3 跟蹤靜態參數

由3.2.1.2節可知，惡意軟件通過調用敏感函數，實現了惡意行為。為了進一步跟蹤惡意軟件的行為，作者提出了一種跟蹤敏感函數中靜態參數的方法。一條字節碼指令由操作指令和固定參數組成。JVM操作堆棧的基本原則是：操作符對應這一個或者多個操作數，操作數如何執行由操作符安排。

3.2.2 行為模式分析

根據上文介紹的惡意軟件家族的行為模式，作者總結出具有惡意行為的基本路徑模式。惡意軟件行為模式分析可分為2個步驟：一是構建應用程序的全部路徑圖，路徑的入口從AndroidManifest.xml文件中獲取，主要是Activity聲明的類；二是將具有惡意行為的路徑集合與應用程序全部路徑圖進行比對，從而決定應用程序是否具有惡意行為。

全部路徑圖的構建是基于字節碼的分析結果。Class文件中都包含具體的方法和變量，在這里，為了簡化處理提高檢測效率，忽略成員變量的分析。Class文件中的方法包括系統 API以及用戶自定義的API，為了跟蹤具體的行為，路徑圖需要精確到系統的API，系統的API包括類名、函數名以及參數。如 android/telephony/TelephonyManager, get-DeviceId, ()Ljava/lang/String。其中getDeviceId是獲取用戶的IMEI號的函數，具有泄露用戶隱私的功能。惡意軟件的行為模式提取來自已知惡意程序的分析將取3.3節中介紹。以下算法說明了如何檢測惡意軟件行為。

在實驗環境中，相比較僅僅使用permission檢測技術，融合此算法后的檢測方法可以有效地提高惡意軟件的發現率，同時，通過機器學習和系統函數調用風險庫的逐漸積累，還可進一步提高惡意軟件的檢測率。

3.3 動態檢測

3.3.1 方法步驟

動態分析是一個長期且復雜的過程，因為它需要許多的準備工作，而且運行起來效率不高，一般都是通過沙盒進行檢測。動態分析的框架如圖 5所示。

作者對Android 市場上50 580個應用程序進行了分析，經過靜態檢測后，過濾到了1 300多個應用程序進行動態分析。為了實現動態分析 APK的需求，需要準備大量的APK程序、root后的設備、monkeyrunner相關的python腳本、tcpdump工具、wireshark數據分組分析工具以及trace工具。

圖5 動態分析框架

本文的動態分析通過trace工具記錄系統調用的行為并將所用行為寫入到日志文件中，同時跟蹤分析wireshark網絡數據分組發送情況，最后將日志文件和數據分組文件統一起來進行分析。基本步驟如下。

1) 準備工作。啟動模擬器，它運行在PC機的桌面上。當一個應用運行在模擬器上，它可以通過服務調用其他應用，訪問網絡，打開視頻或音頻，存儲或者遍歷文件等。模擬器包含大量的調試功能，如模擬打電話、發短信、adb日志等。

2) 安裝trace和wireshark工具。動態檢測的目標是監視應用運行時的動態行為，這些行為包括調用系統的API，發送網絡數據分組等。通過adb工具將trace安裝上，同時wireshark安裝在PC機端。這里，通過 trace工具產生的系統調用都被存入日志文件中。

3) 安裝應用并啟動 mokeyrunner工具。通過adb安裝應用程序，一旦應用程序安裝成功后，并自我運行。此時，mokeyrunner工具可以模擬用戶行為，點擊應用程序，使其運行起來。

4) 收集日志記錄和網絡數據記錄。當應用程序通過monkeyrunner點擊完成后，日志數據將會存儲在文件中，如果有網絡交互，將會有網絡數據被記錄在 wireshark中。通過對這些數據的分析以及惡意軟件的模式匹配可以確定應用程序是否為惡意軟件。

3.3.2 檢測Zero-Day惡意程序

下面將會介紹動態分析技術發現的 Zero-Day惡意程序。它們是Plankton和DoridKungFu惡意程序。經過permission和字節碼靜態分析后，作者收集了1 300多個可疑的應用程序。本節將會介紹分析發現Zero-Day惡意程序的詳細過程。

根據是否調用了動態加載對象，進一步經過靜態掃描1 300個可疑應用程序后，作者發現了1 024個應用程序調用了動態加載對象DexClassLoader并且加載了其他的應用程序。作者經過進一步的分析，發現1 024個應用程序中，大量的應用都使用了廣告庫，而有些廣告庫中包含了動態加載的代碼。為了排除廣告的影響，作者去除包含具有動態加載能力的廣告的應用程序，最終得到了204個可疑應用程序。下一步對這204個應用程序進行動態檢測。

根據動態檢測的記錄，作者不僅發現了動態加載的行為，而且收集到了其動態加載的文件（jar/apk）。在這些可疑應用中，作者發現了一個特例。它的應用名稱是憤怒的小鳥官方版本, 包名是經過憤怒的小鳥的分組名改裝而來，具體是com.crazyapps.angry.birds.cheater.trainer.helper。從動態檢測的日志中看出，它動態加載了 jar分組：plankton v0.0.4.jar，而這個jar分組下載的地址來自一個遠程服務器。更進一步的分析，發現它在下載jar之前，收集應用程序的permission，并把手機的結果上傳到遠程服務器。這樣做，估計是服務器要根據客戶端的permission來決定動態加載的jar分組。通過對plankton v0.0.4.jar的分析，作者發現其中包含的構建僵尸網絡的功能，并且具有監聽遠程服務端命令的特點。這些監聽命令包括BOOKMARKS,INSTALLATION, STATUSD等。具體命令如下。

發現Plankton惡意程序后，作者提取出它的簽名并將其報告給某反病毒廠商內部并掃描 50 580個應用程序，發現了 10款同樣簽名的應用。這些應用中都包含Plankton惡意程序的攻擊特點。

經過靜態掃描后，作者收集到了2 180個具有訪問native-code的應用。一般的情況下，native-code被存入libs/lib的目錄下面，有些帶有惡意行為的應用會將其存在其他的目錄中，如raw、assets目錄。根據目錄規則靜態掃描2 180個應用，作者發現在408個應用中，native-code被存入不正常的目錄中。對408個可疑應用動態分析后，根據記錄的日志，作者發現一些應用多次嘗試調用sys_mount系統函數并修改系統文件。這些應用具有極高的可疑性，因為這些系統調用的函數只有root權限才能滿足。對于第三方應用來說，它極有可能已經獲取了root權限。根據這個思路，作者發現了具有root漏洞利用的惡意程序：DroidKungFu。這個惡意程序包含了 2種 root漏洞利用的代碼：Rageagainstthecage和Exploid，并且對代碼進行了加密。當惡意程序啟動時，它會去判斷是否有root權限，如果有，就修改系統文件并安裝具有root權限的應用，否則啟動root漏洞利用程序，獲取root權限。

4 實驗數據分析

本文提出的檢測方案包括手機端和云端協作檢測和服務端的檢測系統。手機端輕量級檢測包括靜態掃描和上傳可疑應用。通過發布手機端的應用程序，作者收集15 895個應用。服務端檢測系統的數據大都來自市場。通過網絡爬蟲的收集，作者獲取了 34 685個應用。這些應用有些來自不同的市場，所以需要排除其中簽名相同的應用。經過同簽名應用的合并操作，最終的分析數據為45 820。

服務端檢測是本文的重點內容，它包括靜態檢測和動態檢測。靜態檢測運行速度快，可以迅速的縮小動態檢測的范圍。通過對50 580個應用進行分析，靜態檢測的結果如表4所示。

表4 靜態分析后統計結果

從表中數據可以看出，靜態掃描分析后，可以確定47個已知惡意軟件，其中包括45個不同的惡意軟件。由于靜態檢測的準確度有限，不能完全確定惡意程序，所以過濾后的軟件為具有惡意傾向的軟件。在50 580個應用程序中，靜態分析后，發現1 379（2.73%）個應用存在惡意傾向。從分析的比例中可以看出，靜態分析具有較好的分析效果，因為它大大地縮小了檢測的范圍，并且檢測速度相對較快。然而對具有惡意傾向應用程序的好壞的完全鑒定，需要動態分析或者人工分析的進一步工作。

從靜態分析的結果中，導出具有可疑傾向的應用程序，將其放入動態分析系統中。本文對1 379個應用程序進行了動態分析，最終的結果如表5所示。

表5 動態分析后統計結果

動態分析針對應用程序的動態行為進行分析，包括動態調用API的行為、網絡數據分組發送行為、硬件設備調用行為以及聯系人等隱私數據的操作行為。動態分析之前需要考慮第三方廣告申請的權限。例如，靜態分析從 Google市場下載的測試數據，得到有130個惡意傾向程序需要進一步分析，但是作者發現其中有不少應用都加載了廣告并申請了特殊權限，所以過濾掉這些帶有廣告的應用后，只剩下 43個應用程序需要進一步進行動態分析，從而減輕了動態分析的負擔。

從最終的分析結果可知，服務端檢測系統檢測了50 580個應用程序，發現了118個惡意程序。檢測比例為0.23%。檢測惡意簽名數目為108。通過服務端檢測系統，最終，作者發現了2款Zero-Day惡意程序，分別為 Plankton和DroidKungFu。總之，從Zero-Day惡意程序的具體分析過程可以看出，一般情況下，Zero-Day惡意程序的發現需要人工分析。

5 結束語

本文提出了惡意軟件檢測的 3項基本技術：permission分析、字節碼分析和動態分析。Permission分析有效地縮小了檢測的范圍，字節碼檢測技術主要是通過ASM框架進行字節碼分析，從而實現關鍵函數查找和惡意程序行為分析的技術。這種基于字節碼的檢測技術不能完全解決惡意程序分析工作，因為它存在這樣的問題：如果一個惡意程序將靜態信息存儲在代碼中，基本上能檢測出來，但如果實現動態加載數據，此方法無效。

基于靜態檢測技術的不足，本文提出了實時監控應用程序行為的動態檢測技術。但由于 Android平臺本身安全機制的限制，動態監控需在root權限下工作。動態檢測技術解決了靜態檢測技術不能解決的問題。2種技術結合起來，為Android平臺上的惡意程序檢測工作提供了有力的保障。Android平臺上的動態檢測有其天生的弱點：分析時間長，工作量大。大量的實驗證明，這種技術能準確地檢測出惡意軟件，可以大大減輕后期人工分析惡意程序特征的工作。

從分析的準確度來看，3種技術的準確度逐步增加，從技術難度來看，3種技術難度逐步增加。3種技術是前后關聯的有機整體，基于permission檢測技術主要的目的是從海量的數據中分析出具有可疑的惡意軟件，基于字節碼的靜態檢測技術進一步從可疑的惡意軟件中去分析具體的靜態行為，基于root權限的動態檢測技術結合靜態分析技術來確定惡意軟件以及其攻擊特征。

[1] JESSE B. Developing secure mobile application for Android[EB/OL]https://www.isecpartners.com/files/iSEC_Securing_Android_Apps.pdf,2008.

[2] SCHMIDT A D, SCHMIDT H G, BATYUK L. Smartphone malware evolution revisited: Android next target[A]. Proceedings of the 4th IEEE International Conference on Malicious and Unwanted Software[C]. USA, 2009. 1-7.

[3] SCHMIDT A D, SCHMIDT H G, CLAUSEN J. Static analysis of executables for collaborative malware detection on android[A]. IEEE International Congress on Communication (ICC) 2009 - Communication and Information Systems Security Symposium[C]. 2009.

[4] ENCK W, ONGTANG M, MCDANIEL P. Understanding Android security[J]. IEEE Security and Privacy, 2009, 7(1):50-57.

[5] SHABTAI A, FLEDEL Y, ELOVICI Y. Securing android-powered mobile devices using selinux[A]. IEEE Security and Privacy[C]. 2009.10-15.

[6] BERGERON J, DEBBABI M, DESHARNAIS J. Static detection of malicious code in executable programs[A]. Proceedings of the Symposium on Requirements Engineering for Information Security[C].USA, 2001.20-24.

[7] MOSER A, KRUEGEL C, KIRDA E. Limits of static analysis for malware detection[A]. Proceedings of the 23rd Annual Computer Security Application Conference[C]. Seoul, Korea, 2007.421-430.

[8] BISHOP M A. The Art and Science of Computer Security[M]. Boston:Addison-Wesley Longman Publishing Co, 2002.213-217.

[9] http://www.symantec.com/security_response/writeup.jspdocid=2011-022303-3344-99[EB/OL].2001.