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

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

1 引言

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

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

作者提出了一種基于permission組合的技術(shù)，幫助用戶及時發(fā)現(xiàn)潛在惡意應(yīng)用程序。同時，提出了基于云端靜態(tài)分析和動態(tài)分析技術(shù)的方案，為惡意程序的分析奠定堅實的基礎(chǔ)。

2 檢測框架概述

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

圖1 手機端和服務(wù)端協(xié)作框架

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

遠(yuǎn)程服務(wù)端檢測系統(tǒng)的檢測數(shù)據(jù)來源于Google標(biāo)準(zhǔn)市場以及國內(nèi)市場，還有用戶手機端收集到的樣本數(shù)據(jù)。檢測系統(tǒng)包括靜態(tài)檢測和動態(tài)檢測。其中靜態(tài)檢測以縮小檢測范圍，發(fā)現(xiàn)具有疑似惡意行為特征的軟件為目標(biāo)；動態(tài)檢測則通過動態(tài)行為跟蹤從而發(fā)現(xiàn)未知惡意軟件。檢測框架如圖2所示。

圖2 服務(wù)端檢測系統(tǒng)框架

3 檢測技術(shù)

3.1 基于permission檢測

3.1.1 方法步驟

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

圖3 基于permission檢測流程

3.1.2 檢測策略

3.1.2.1 樣本分析

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

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

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

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

3.1.2.2 規(guī)則驗證

1) 單個危險權(quán)限

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

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

表1 惡意軟件權(quán)限申請及攻擊行為描述

表2 單個危險權(quán)限規(guī)則

表3 危險權(quán)限組合規(guī)則

2) 多個危險權(quán)限組合

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

3.2 字節(jié)碼靜態(tài)檢測

3.2.1 方法步驟

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

圖4 字節(jié)碼檢測流程

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

3.2.1.1 獲取jar分組

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

3.2.1.2 查找敏感函數(shù)

應(yīng)用程序申請?zhí)囟?quán)限后，是否調(diào)用了敏感函數(shù)有待于靜態(tài)代碼的分析。敏感函數(shù)跟蹤技術(shù)利用ASM基本框架，遍歷軟件中導(dǎo)入的系統(tǒng)庫函數(shù)，查找敏感函數(shù)，從而確定是否調(diào)用了敏感函數(shù)。從ASM框架提供的API中，可以獲取到所有的類及其函數(shù)的詳細(xì)信息，包括類名稱、函數(shù)名稱、參數(shù)等。注意用戶定義的類或者函數(shù)可能被混淆，但系統(tǒng)函數(shù)是不能混淆的，而跟蹤的敏感函數(shù)都為系統(tǒng)函數(shù)，所以混淆技術(shù)并不影響基于字節(jié)碼的跟蹤。

3.2.1.3 跟蹤靜態(tài)參數(shù)

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

3.2.2 行為模式分析

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

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

在實驗環(huán)境中，相比較僅僅使用permission檢測技術(shù)，融合此算法后的檢測方法可以有效地提高惡意軟件的發(fā)現(xiàn)率，同時，通過機器學(xué)習(xí)和系統(tǒng)函數(shù)調(diào)用風(fēng)險庫的逐漸積累，還可進一步提高惡意軟件的檢測率。

3.3 動態(tài)檢測

3.3.1 方法步驟

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

作者對Android 市場上50 580個應(yīng)用程序進行了分析，經(jīng)過靜態(tài)檢測后，過濾到了1 300多個應(yīng)用程序進行動態(tài)分析。為了實現(xiàn)動態(tài)分析 APK的需求，需要準(zhǔn)備大量的APK程序、root后的設(shè)備、monkeyrunner相關(guān)的python腳本、tcpdump工具、wireshark數(shù)據(jù)分組分析工具以及trace工具。

圖5 動態(tài)分析框架

本文的動態(tài)分析通過trace工具記錄系統(tǒng)調(diào)用的行為并將所用行為寫入到日志文件中，同時跟蹤分析wireshark網(wǎng)絡(luò)數(shù)據(jù)分組發(fā)送情況，最后將日志文件和數(shù)據(jù)分組文件統(tǒng)一起來進行分析?；静襟E如下。

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

2) 安裝trace和wireshark工具。動態(tài)檢測的目標(biāo)是監(jiān)視應(yīng)用運行時的動態(tài)行為，這些行為包括調(diào)用系統(tǒng)的API，發(fā)送網(wǎng)絡(luò)數(shù)據(jù)分組等。通過adb工具將trace安裝上，同時wireshark安裝在PC機端。這里，通過 trace工具產(chǎn)生的系統(tǒng)調(diào)用都被存入日志文件中。

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

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

3.3.2 檢測Zero-Day惡意程序

下面將會介紹動態(tài)分析技術(shù)發(fā)現(xiàn)的 Zero-Day惡意程序。它們是Plankton和DoridKungFu惡意程序。經(jīng)過permission和字節(jié)碼靜態(tài)分析后，作者收集了1 300多個可疑的應(yīng)用程序。本節(jié)將會介紹分析發(fā)現(xiàn)Zero-Day惡意程序的詳細(xì)過程。

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

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

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

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

4 實驗數(shù)據(jù)分析

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

服務(wù)端檢測是本文的重點內(nèi)容，它包括靜態(tài)檢測和動態(tài)檢測。靜態(tài)檢測運行速度快，可以迅速的縮小動態(tài)檢測的范圍。通過對50 580個應(yīng)用進行分析，靜態(tài)檢測的結(jié)果如表4所示。

表4 靜態(tài)分析后統(tǒng)計結(jié)果

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

從靜態(tài)分析的結(jié)果中，導(dǎo)出具有可疑傾向的應(yīng)用程序，將其放入動態(tài)分析系統(tǒng)中。本文對1 379個應(yīng)用程序進行了動態(tài)分析，最終的結(jié)果如表5所示。

表5 動態(tài)分析后統(tǒng)計結(jié)果

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

從最終的分析結(jié)果可知，服務(wù)端檢測系統(tǒng)檢測了50 580個應(yīng)用程序，發(fā)現(xiàn)了118個惡意程序。檢測比例為0.23%。檢測惡意簽名數(shù)目為108。通過服務(wù)端檢測系統(tǒng)，最終，作者發(fā)現(xiàn)了2款Zero-Day惡意程序，分別為 Plankton和DroidKungFu?？傊瑥腪ero-Day惡意程序的具體分析過程可以看出，一般情況下，Zero-Day惡意程序的發(fā)現(xiàn)需要人工分析。

5 結(jié)束語

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

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

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

[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.