樂洪舟 張玉清,2 王文杰 劉奇旭

1(綜合業(yè)務網(wǎng)理論及關鍵技術國家重點實驗室(西安電子科技大學) 西安 710071)2(中國科學院大學國家計算機網(wǎng)絡入侵防范中心 北京 101408)3 (信息安全國家重點實驗室(中國科學院信息工程研究所) 北京 100093) (yuehz@nipc.org.cn)

Android動態(tài)加載與反射機制的靜態(tài)污點分析研究

樂洪舟1張玉清1,2王文杰2,3劉奇旭2,3

1(綜合業(yè)務網(wǎng)理論及關鍵技術國家重點實驗室(西安電子科技大學) 西安 710071)2(中國科學院大學國家計算機網(wǎng)絡入侵防范中心 北京 101408)3(信息安全國家重點實驗室(中國科學院信息工程研究所) 北京 100093) (yuehz@nipc.org.cn)

隱私泄露是當前Android安全中最為重要的問題之一，目前檢測隱私泄露的最主要方法是污點分析.Android靜態(tài)污點分析技術憑借其代碼覆蓋率高、漏報率低的特點而被廣泛應用在Android應用隱私泄露的檢測上.然而，現(xiàn)有的靜態(tài)污點分析工具卻不能對Android動態(tài)加載和反射機制進行有效污點分析.鑒于當前Android動態(tài)加載和反射機制被越來越廣泛地應用的現(xiàn)狀，對如何使Android靜態(tài)污點分析工具有效地處理Android應用的動態(tài)加載和反射機制的問題進行了研究.對Android源碼進行了修改，使Android系統(tǒng)能夠對Android應用實際運行中加載的dex文件和反射調(diào)用信息進行實時存儲，并利用這些信息對Android靜態(tài)污點分析過程進行引導.以當前領先的靜態(tài)污點分析工具FlowDroid為基礎，對其進行了改進，提出了使用非反射調(diào)用語句替換反射調(diào)用語句的策略，實現(xiàn)了一個能夠對Android動態(tài)加載和反射機制進行有效污點分析的工具——DyLoadDroid，并通過實驗驗證了其在處理Android動態(tài)加載和反射機制的污點分析問題上的有效性.

安卓；隱私泄露；污點分析；動態(tài)加載；反射

當前Android隱私泄露問題泛濫，不管是惡意應用還是非惡意應用，都存在隱私泄露問題[1].惡意應用常常以侵犯用戶的隱私作為目的[2]，為惡意應用制造者或傳播者提供非法利益[3].非惡意應用為了實現(xiàn)特定功能或提供更好的服務，也存在侵犯用戶隱私的問題，例如，手機地圖應用為了向用戶提供用戶所在地的地圖信息，會獲取用戶的地理位置等隱私信息[4]；嵌入Android應用(以下簡稱App)中的第三方廣告類庫可能會收集用戶的一些隱私信息，以了解用戶的喜好，提供更具針對性的廣告[5-6].然而，不管Android應用是否惡意，隱私泄露都是當前Android手機用戶面臨的最主要安全威脅之一[4]，對Android隱私泄露的檢測依然是當前移動安全領域研究的熱點.

對于隱私泄露的檢測，目前最主要的方法是污點分析，包括靜態(tài)污點分析和動態(tài)污點分析[7].動態(tài)污點分析方法是指在Android應用動態(tài)執(zhí)行的過程中對手機中的隱私數(shù)據(jù)進行追蹤，主要的動態(tài)污點分析工具有TaintDroid[8]，AppFence[9]，KynoidA[10]等.靜態(tài)污點分析是指在不運行Android應用的情況下直接采用靜態(tài)分析的方法對其進行污點分析，比較典型的靜態(tài)污點分析工具有FlowDroid[11]，LeakMiner[12]，AndroidLeaks[13]等.使用動態(tài)污點分析的方法檢測隱私泄露的優(yōu)點是隱私數(shù)據(jù)追蹤準確、誤報率低，缺點是代碼覆蓋率低，對于實際運行中未被觸發(fā)的隱私泄露，使用動態(tài)污點分析的方式將無法檢測，因此，其漏報率較高.而靜態(tài)污點分析則剛好相反，靜態(tài)污點分析的缺點是代碼覆蓋率高，可以檢測出比動態(tài)污點分析更多的隱私泄露問題；然而，其誤報率也較高.因此，在實際的隱私泄露檢測中，靜態(tài)污點分析和動態(tài)污點分析方法是互補的.

就靜態(tài)污點分析而言，當前靜態(tài)污點分析工具面臨的一個重要問題就是不能對Android動態(tài)加載和反射機制進行有效污點分析.而當前Android動態(tài)加載與反射機制被越來越廣泛地應用在Android開發(fā)中，文獻[14]對Google Play上的14 283個App進行統(tǒng)計發(fā)現(xiàn)，在這些App中有18.5%的App使用了動態(tài)加載技術，88%的App使用了反射調(diào)用機制.文獻[15]也指出，從2010—2014年，使用反射機制的Android惡意應用的比例從43.87%上升到78%，非惡意應用也從39.55%上升到93%.動態(tài)加載和反射調(diào)用技術的大量應用使當前的靜態(tài)污點分析工具越來越難以對Android應用的污點分析問題進行有效檢測[16].雖然動態(tài)污點分析工具作為靜態(tài)污點分析工具的一個重要補充，可以在不受動態(tài)加載和反射機制影響的情況下對Android應用進行污點分析，但由于它在代碼覆蓋率上的劣勢，使其無法取代靜態(tài)污點分析工具在Android污點分析中的作用.

鑒于動態(tài)加載和反射機制被廣泛使用的現(xiàn)狀，為了充分發(fā)揮靜態(tài)污點分析工具在Android隱私泄露檢測中的作用，就必須采取措施解決靜態(tài)污點分析工具處理Android動態(tài)加載和反射機制的缺陷.本文以此為出發(fā)點，對當前領先的靜態(tài)污點分析工具FlowDroid[11]進行改進，開發(fā)出能夠對Android動態(tài)加載和反射機制進行有效污點分析的工具DyLoadDroid，首先將被測App實際運行中被加載的dex文件下載到本地計算機，并將系統(tǒng)中所發(fā)生的反射調(diào)用信息記錄下來；然后在靜態(tài)分析的過程中，根據(jù)這些反射調(diào)用信息將相應的反射調(diào)用語句替換為非反射調(diào)用語句，再運行FlowDroid的靜態(tài)污點分析流程，使其能夠對使用Android動態(tài)加載和反射調(diào)用機制的Android應用進行有效的污點分析.

本文的主要貢獻包括：

1) 首次提出了使用非反射機制代替反射機制的解決方案，解決了靜態(tài)污點分析技術不能正確處理Android反射機制的問題.

2) 對當前領先的靜態(tài)污點分析工具Flow-Droid進行了改進，開發(fā)出能夠對Android動態(tài)加載和反射機制進行有效污點分析的工具DyLoad-Droid，并通過實驗驗證了其有效性.

3) 改寫了Android源碼，使Android系統(tǒng)能夠在系統(tǒng)中發(fā)生動態(tài)加載和反射調(diào)用行為時通過日志輸出的形式輸出相關信息，DyLoadDroid便可以根據(jù)這些信息及時下載被加載的dex文件，并提取反射調(diào)用信息，從而指引DyLoadDroid的靜態(tài)污點分析模塊對Android應用進行污點分析.

1 相關工作

在Android應用動態(tài)加載和反射機制的研究方面， Poeplau等人[17]對Android動態(tài)加載執(zhí)行代碼的安全問題進行了研究，研究了惡意應用利用動態(tài)加載機制繞過安全檢查的問題，并對非惡意應用動態(tài)加載執(zhí)行代碼可能導致的安全漏洞進行了研究.Zhauniarovich等人[14]提出了StaDynA工具，能夠在Android應用運行過程中發(fā)生動態(tài)加載時，下載被動態(tài)加載的dex文件，并記錄Android應用的反射調(diào)用信息，結合AndroGuard生成函數(shù)調(diào)用關系圖.然而StaDynA是一個比較初步的工具，只能為分析者提供一種輔助，不能對Android應用中存在的安全問題進行自動化分析.

在Android靜態(tài)污點分析方面，Yang等人[12]提出了LeakMiner工具， LeakMiner將Android的生命周期考慮在內(nèi)，構建能夠覆蓋所有回調(diào)方法的函數(shù)調(diào)用圖;但LeakMiner對上下文不敏感，且不支持隱式信息流泄露，因此其污點分析準確率不高.Gibler等人[13]提出的AndroidLeaks工具具有上下文敏感的特性，但它不具有域敏感和對象敏感的特性，即當對象的某一個域存儲了污點數(shù)據(jù)，則AndroidLeaks將整個對象視為污點，因此其檢測準確性也不高.FlowDroid是當前較為先進的Android靜態(tài)污點分析工具，由Arzt等人[11]在PLDI 2014會議上提出，F(xiàn)lowDroid能夠構建準確的Android生命周期模型，并對Android的回調(diào)函數(shù)進行有效的處理.它使用IFDS算法進行準確和高效的污點傳播分析，具有上下文敏感、流敏感、域敏感和對象敏感的特性.為了解決FlowDroid在組件間數(shù)據(jù)流處理問題上的缺陷，Octeau等人[18]在FlowDroid的基礎上，提出了組件間污點分析工具Epicc，能夠對組件間的數(shù)據(jù)傳遞進行較為準確的污點分析.為了使FlowDroid能夠在多個應用之間進行污點傳播分析，Klieber等人[19]在FlowDroid和Epicc的基礎上提出DidFail工具，能夠正確處理多個應用之間的相互調(diào)用和數(shù)據(jù)傳輸，進而追蹤污點的傳播.

在Android動態(tài)污點分析方面，TaintDroid[8]將所有的隱私數(shù)據(jù)標記為污點，它在內(nèi)存中為系統(tǒng)中的每個對象多申請一倍的空間，用于存儲污點標記，在App動態(tài)執(zhí)行的過程中，根據(jù)污點標記追蹤污點在內(nèi)存中的傳播情況.Hornyack等人[9]提出的AppFence工具不僅可以檢測到系統(tǒng)中發(fā)生的隱私泄露問題，而且可以阻止隱私信息的泄露.它采取數(shù)據(jù)遮蔽和滲出阻塞技術，將隱私數(shù)據(jù)替換為影子數(shù)據(jù)傳遞到外部網(wǎng)絡來防止隱私數(shù)據(jù)的泄露，但其嚴格的安全控制也容易阻礙App的正常運行.Schreckling等人[10]提出的Kynoid工具是對TaintDroid的改進，能夠監(jiān)控更細粒度的污染源，并能夠使用戶以安全策略的方式定義污點傳播內(nèi)容，然而，Kynoid運行時的內(nèi)存消耗比TaintDroid更大，速度也更慢.

2 背景介紹

Android動態(tài)加載技術是指Android應用在動態(tài)執(zhí)行的過程中加載主應用以外的dex文件，并對該文件中的程序和資源進行訪問的技術[14]，被加載的dex文件包括“.apk”和“.jar”2種后綴的文件形式，該dex文件可以在沒有被安裝的情況下被其他Android應用通過反射機制訪問.

反射機制是Java語言的一個重要特性，它使程序在Java的運行狀態(tài)中，對于任意一個類，都能夠知道這個類的所有屬性和方法；對于任意一個對象，都能夠調(diào)用它的任意一個方法和屬性，這種動態(tài)獲取信息以及動態(tài)調(diào)用對象的方法的功能稱為Java語言的反射機制[20].Android應用基于Java語言開發(fā)，因此可以充分利用Java的反射機制.下面我們通過一個例子展示Android的動態(tài)加載和反射調(diào)用機制.

圖1所示為在Android反射調(diào)用中充當調(diào)用者的例子，該段代碼在第⑥行動態(tài)加載了位于SD卡中的apk文件DynamicLoadClient.apk;第⑦行加載了該apk文件中的類com.dynamicloadclient.SendMessage;在第⑨行對該類進行了實例化，并通過該類的構造方法傳入?yún)?shù)“MessageMark”；第⑩行取出該類的名為sendMSG的方法；第行對該方法進行了反射調(diào)用，傳入?yún)?shù)“123456”和deviceId.圖2所示的代碼展示了被調(diào)用者代碼，該段代碼的功能是向手機號為number的移動設備發(fā)送內(nèi)容為content的短信信息.結合調(diào)用者和被調(diào)用者的代碼我們可以看出，調(diào)用者通過反射調(diào)用向手機號為“123456”的設備發(fā)送了內(nèi)容為設備的IMEI號的短信.

① ②③④⑤⑥ ⑦ ⑧ ⑨ ⑩ TelephonyManagertm=(TelephonyManager)this.getSystemService(Context.TELEPHONY_SERVICE);StringdeviceId=tm.getDeviceId();try{Filefile=newFile("∕sdcard∕DynamicLoadClient.apk");if(file.exists()){DexClassLoadercl=newDexClassLoader(file.toString(),getFilesDir().getAbsolutePath(),null,ClassLoader.getSystemClassLoader().getParent());ClassmyClass=cl.loadClass("com.dynamicloadclient.SendMessage");Constructorconstructor=myClass.getConstructor(newClass[]{String.class});Objectobj=constructor.newInstance(newObject[]{"MessageMark"});Methodaction=myClass.getMethod("sendMSG",newClass[]{String.class,String.class});Stringreturn_value=(String)action.invoke(obj,"123456",deviceId);Log.i("return_value","return_value:"+return_value);}}catch(Exceptionex){ex.printStackTrace();}

Fig. 1 The caller in Java reflection invocation

圖1 Java反射調(diào)用中的調(diào)用者

①②③ ④ ⑤publicStringsendMSG(Stringnumber,Stringcontent){SmsManagersManager=SmsManager.getDefault();sManager.sendTextMessage(number,null,content,null,null);}Log.i(markStr,"Amessagehasbeensentto"+number+",content:"+content);return"OK";}

Fig. 2 The callee in Java reflection invocation

圖2 Java反射調(diào)用中的被調(diào)用者

圖1和圖2所示的例子演示了一個典型的隱私泄露問題，設備的IMEI號被以短信的形式發(fā)送給指定手機.隱私泄露問題也是當前污點分析重點關注的問題，然而，當前的靜態(tài)污點分析技術卻難以對存在動態(tài)加載和反射機制的程序進行正確的處理，因而不能進行有效的靜態(tài)污點分析.例如，若將該例中的設備IMEI號作為污染源(source)，將發(fā)送短信的API調(diào)用作為陷入點(sink)，則靜態(tài)污點分析不能構建從污染源到陷入點的有效路徑，因而不能檢測到這個隱私泄露問題.原因是靜態(tài)分析不能確定通過newInstance方法實例化的對象和通過invoke方法反射調(diào)用的目標方法.在該例子中，被反射調(diào)用的方法存在于被加載的dex文件中，實際上App也可以通過反射調(diào)用的方式調(diào)用Android系統(tǒng)中任何可達的Java方法，包括App本身包含的或Android系統(tǒng)類庫中包含的Java方法，這些反射調(diào)用都不能被當前的靜態(tài)污點分析工具正確的處理.

3 總體設計

本節(jié)開始將系統(tǒng)地介紹我們對FlowDroid進行改進后的工具——DyLoadDroid.

DyLoadDroid的總體結構和流程圖如圖3所示，為了方便下文描述，我們做出如下名詞定義.

1) 源方法.調(diào)用者所在的方法，用Sm表示，如圖1中所示代碼所在的Java方法.

2) 源類.源方法所在的類，用Sc表示.

3) 目標方法.被調(diào)用者所在的方法，用Tm表示，如圖2所示代碼所在的Java方法.

4) 目標類.被調(diào)用者所在的類，用Tc表示.

5) 反射方法.調(diào)用者實施反射機制所借助的方法，包括newInstance和invoke方法，用Rm表示，如圖1所示代碼第⑨行被調(diào)用的newInstance方法和第行被調(diào)用的invoke方法.

6) 反射類.反射方法所在的類，用Rc表示.

Fig. 3 Overall flow chart of DyLoadDroid圖3 DyLoadDroid總體流程圖

DyLoadDroid主要由2部分組成：動態(tài)執(zhí)行模塊和靜態(tài)分析模塊，為了便于下文的描述，我們把它們分別簡稱為DyLoadDroid-D和DyLoadDroid-S.DyLoadDroid首先運行DyLoadDroid-D，將待測App安裝進Android設備中，該Android設備中安裝的Android系統(tǒng)是由我們對Android源碼進行特定修改并重新編譯后生成的，它能夠在日志中輸出系統(tǒng)中發(fā)生的動態(tài)加載和反射調(diào)用的相關信息，針對Android源碼所做的修改我們將在4.1節(jié)中介紹.安裝完該App后，DyLoadDroid-D運行該App文件，并循環(huán)讀取系統(tǒng)的日志輸出，獲取App的動態(tài)加載和反射調(diào)用的相關信息.當捕獲到該App的動態(tài)加載行為時，DyLoadDroid-D便向Android設備發(fā)出adb下載命令，將被加載的dex文件下載到本地計算機.當捕獲到該App的反射調(diào)用行為時，DyLoadDroid-D將從日志中提取該反射調(diào)用所對應的源方法Sm、反射方法Rm和目標方法Tm等信息，并將這些信息以三元組Sm,Rm,Tm的形式存儲在本地計算機的文件中，我們稱該文件為SRT信息庫.這些被下載的dex文件和SRT信息庫將用于后續(xù)的靜態(tài)污點分析.

當動態(tài)分析模塊執(zhí)行結束以后，DyLoadDroid運行DyLoadDroid-S，DyLoadDroid-S實際上是對FlowDroid的改進，我們將動態(tài)分析模塊輸出的dex文件和SRT信息庫補充進FlowDroid的靜態(tài)污點分析流程，彌補FlowDroid不能處理動態(tài)加載和反射調(diào)用的缺陷.FlowDroid首先將待測APK和被加載的dex文件中的一些必需的Java Class文件加載進內(nèi)存，并轉換為Soot[21]的三地址中間語言Jimple;然后FlowDroid根據(jù)SRT信息庫對源方法的相應反射方法調(diào)用進行轉換，使FlowDroid能夠對反射方法調(diào)用構建正確的函數(shù)調(diào)用圖，指引FlowDroid進行靜態(tài)污點分析，最終輸出結果.

4 DyLoadDroid-D原理介紹

4.1 Android源碼修改

我們針對Android源碼的修改參考了文獻[14]的方法，所修改的Android版本為4.1.2，主要修改包括：

1) Android系統(tǒng)方法調(diào)用堆棧所存儲元素的修改.Android系統(tǒng)方法調(diào)用堆棧存儲著系統(tǒng)中發(fā)生的方法調(diào)用序列.源碼中方法調(diào)用堆棧只存儲類名和方法名，而不存儲方法的參數(shù).我們修改了Android源碼，使其能夠存儲方法的參數(shù)，這樣便可以通過方法調(diào)用堆棧獲得方法的完整信息.

2) 增加動態(tài)加載的日志輸出.為了監(jiān)控Android應用的動態(tài)加載行為，我們對Android源碼的DexFile.java文件的openDexFile方法進行了相應的修改，使當系統(tǒng)發(fā)生動態(tài)加載行為后，通過日志輸出被加載的dex文件的路徑，以便于DyLoadDroid-D能夠及時下載被加載的dex文件.

3) 增加newInstance方法調(diào)用的日志輸出.為了監(jiān)控Android應用通過newInstance方法進行對象實例化的行為，我們對Android源碼的Constructor.java和Method.java文件的newInstance方法進行了修改，使系統(tǒng)中發(fā)生了對newInstance方法的調(diào)用時，輸出被實例化的目標類的類名、初始化方法名和初始化參數(shù).

4) 增加invoke方法調(diào)用的日志輸出.為了監(jiān)控Android應用通過invoke方法進行反射調(diào)用的行為，我們對Method.java方法中的invoke方法進行了修改，使系統(tǒng)發(fā)生了invoke方法調(diào)用時，輸出目標類的類名、目標方法的方法名和參數(shù).

以上對源碼的修改的2～4這3項都對應日志輸出，除了其中所描述的日志輸出以外，還需要額外輸出日志標識、uid號、操作號、調(diào)用堆棧信息等.日志標識用于標識哪些日志信息是需要被DyLoadDroid-D解析的；uid號使DyLoadDroid-D能夠辨別哪些log輸出是由待測App產(chǎn)生的；操作號用于標識所監(jiān)控的程序行為的類型，根據(jù)被調(diào)用的方法的不同，我們設置newInstance，invoke，openDexFile方法所對應的操作號分別為1，2，3.此外，對于修改3，4這2項的日志輸出，我們還額外輸出當前線程在Android方法調(diào)用堆棧中的信息，這些信息將輔助DyLoadDroid-D獲得源方法信息和反射方法信息，具體內(nèi)容我們將在4.2節(jié)介紹.

4.2 日志解析

DyLoadDroid-D安裝并運行App后會取出該App所對應的uid號，App的運行需要實驗者對其進行實際使用，實驗者在使用App的過程中觸發(fā)盡可能多的動態(tài)加載和反射調(diào)用行為.DyLoadDroid-D會循環(huán)讀取手機的日志信息，提取uid號為待測App的日志記錄.當讀取到動態(tài)加載dex文件的記錄時，DyLoadDroid-D會根據(jù)日志中記錄的文件信息將該dex文件下載到本地電腦的指定文件夾，用于為DyLoadDroid-S的靜態(tài)污點分析提供類加載源.當捕獲到newInstance方法的輸出信息或invoke方法輸出的反射調(diào)用信息時，DyLoadDroid會從中提取出對應的源方法Sm、反射方法Rm和目標方法Tm的信息，并將這些信息以三元組Sm,Rm,Tm的形式存入SRT信息庫，用于為DyLoadDroid-S的靜態(tài)污點分析過程提供反射調(diào)用信息，圖4描述了該信息的提取原理.

Fig. 4 Schematic diagram of log analysis圖4 日志解析原理圖

我們以Cx，Mx，Px分別表示類名、方法名和方法的參數(shù)名，x取s，r，t分別表示源、反射和目標，例如Cs表示源類的類名，依此類推.根據(jù)4.1節(jié)中關于Android源碼的修改，當待測Android系統(tǒng)中發(fā)生newInstance或invoke反射方法調(diào)用時，我們可以從日志中直接獲取到Tm的信息Ct，Mt，Pt.對于Sm和Rm的信息，我們可以通過當前線程的Android方法調(diào)用堆棧獲得.Android方法調(diào)用堆棧存儲著從當前方法調(diào)用開始，按時間順序排列的方法調(diào)用序列，當前正在調(diào)用的方法信息存儲在堆棧的棧頂，距離當前方法調(diào)用最近的一次方法調(diào)用存儲在堆棧的第2個單元.因此，若發(fā)生反射方法調(diào)用時，處在堆棧最頂部的方法通常是反射方法Rm的信息，而處在堆棧中第2位的便是進行反射調(diào)用的源方法Sm的信息.根據(jù)4.1節(jié)中對Android系統(tǒng)方法調(diào)用堆棧所存儲元素的修改，我們便可以在反射方法調(diào)用發(fā)生時，通過輸出的堆棧信息，獲得Sm的信息Cs，Ms，Ps和Rm的信息Cr，Mr，Pr.DyLoadDroid-D會將解析產(chǎn)生的Sm，Rm，Tm以三元組的方式存儲在SRT信息庫中.

5 DyLoadDroid-S原理介紹

DyLoadDroid-D的結束由人工進行控制，當實驗者充分使用App后，可以對DyLoadDroid輸入命令，終結DyLoadDroid-D的運行，并啟動DyLoadDroid-S對App進行靜態(tài)污點分析.DyLoadDroid-S實際上是一個改進版的FlowDroid，它將DyLoadDroid-D輸出的dex文件和SRT信息庫補充進FlowDroid的分析流程，使FlowDroid能夠正確處理App的動態(tài)加載和反射機制的程序代碼，進行更全面的污點分析.

5.1 類的加載

FlowDroid的靜態(tài)分析方法建立在Soot的Jimple語言基礎上，F(xiàn)lowDroid會將apk文件中包含的所有類加載進內(nèi)存，然后構建主方法，并構建函數(shù)調(diào)用圖.為了減小內(nèi)存的負擔，DyLoadDroid-S采取按需加載的方式對被加載的dex文件中相應的類進行加載.即DyLoadDroid-S只取SRT信息庫中的源類和目標類進行加載，在構建函數(shù)調(diào)用圖時，根據(jù)函數(shù)調(diào)用圖的擴展，Soot會自動按需加載額外需要的類.目標方法既可能存在于被加載的dex文件中，也可能存在于App本身具有的類中或Android系統(tǒng)庫android.jar中，這些可能存在的文件都將作為Soot的基類.

5.2 模糊匹配原則和條件轉移原則

DyLoadDroid-S對源方法的修改實際上是將源方法中相應的反射方法調(diào)用修改為FlowDroid能夠處理的目標方法調(diào)用，使FlowDroid的污點分析模塊能夠對反射方法調(diào)用進行正確的處理.在介紹源方法修改算法之前，我們先介紹源方法修改的2個原則——模糊匹配原則和條件轉移原則.

模糊匹配原則是指在對源方法進行修改時，DyLoadDroid-S根據(jù)SRT信息庫，搜索源方法中的反射方法調(diào)用，并根據(jù)反射方法的參數(shù)個數(shù)、參數(shù)類型、返回值類型近似確定反射方法調(diào)用的位置.例如，圖5是圖2所示源碼的第⑨行和第行代碼對應的Jimple代碼，DyLoadDroid-S從SRT信息庫中取出該段代碼所在源方法Sm對應的反射調(diào)用信息三元組Sm,Rm,Tm，若Rm為newInstance方法，且Tm具有的參數(shù)個數(shù)、參數(shù)類型與圖5第③行的$r14數(shù)組元素個數(shù)和元素類型對應，DyLoadDroid-S便認為圖5第③行的反射調(diào)用語句對應于這個反射調(diào)用信息三元組Sm,Rm,Tm.同理，若Rm為invoke方法，且Tm具有的參數(shù)個數(shù)、參數(shù)類型與圖5第⑧行的$r14數(shù)組元素個數(shù)和元素類型對應，且Tm的返回值類型與$r15對應，DyLoadDroid-S便認為圖5第⑧行的反射調(diào)用語句對應于反射調(diào)用信息三元組Sm,Rm,Tm.

①②③ ④⑤⑥⑦⑧ $r14=newarray(java.lang.Object)[1];$r14[0]="MessageMark";$r5=virtualinvoke$r13.java.lang.reflect.Constructor:ja-va.lang.ObjectnewInstance(java.lang.Object[])($r14);?$r14=newarray(java.lang.Object)[2];$r14[0]="123456";$r14[1]=$r7;$r5=virtualinvoke$r15.java.lang.reflect.Method:java.lang.Objectinvoke(java.lang.Object,java.lang.Object[])($r5,$r14);

Fig. 5 The Jimple code corresponding to newInstanceand invoke
圖5 newInstance和invoke調(diào)用對應的Jimple代碼

條件轉移原則是根據(jù)FlowDroid的污點分析特性設置的，由于FlowDroid不具有符號執(zhí)行的功能，因此對于“if…else…”的處理不會根據(jù)判斷標識的具體取值選擇程序流程，因此，DyLoadDroid-S對反射方法的修改采取增加“if…else…”語法的方法，首先設置一個判斷標識，當標識為某一數(shù)值時，DyLoadDroid根據(jù)SRT信息庫構造目標方法的調(diào)用，否則執(zhí)行原始反射方法調(diào)用.之所以構建“if…else…”而不是直接替換反射方法，主要原因有2點：

1) 防止同一源方法通過同一反射方法調(diào)用多種目標方法，這樣，DyLoadDroid-S可以方便地在反射方法調(diào)用上進行“if…else…”的嵌套，而不至于使FlowDroid發(fā)生漏報.

2) 防止模糊匹配的不準確性導致的污點分析錯誤，根據(jù)FlowDroid對“if…else…”不選擇執(zhí)行的特性，若發(fā)生匹配錯誤，F(xiàn)lowDroid也至少可以在原程序方向上正確地運行.此外，若同一源方法出現(xiàn)多個匹配，即對于某一三元組Sm,Rm,Tm，在Sm中存在多個反射調(diào)用與該三元組匹配，則“if…else…”原則能夠保證至少有一個匹配是正確的，而其他錯誤的匹配不會對FlowDroid的污點傳播結果造成影響.

5.3 源方法修改算法

為了方便算法的描述，我們補充如下定義.

1) 目標反射對象.使用反射機制對目標類進行實例化的對象，用Fo表示，如圖1所示代碼第⑨行的obj對象.

2) 目標對象.直接對目標類進行實例化后的對象，用To表示.

3) 目標反射參數(shù).使用反射機制向目標方法傳遞的參數(shù)，用Fp表示，如圖5所示代碼第③行和第⑧行對應的$r14數(shù)組.

4) 目標參數(shù).向目標方法傳遞的實際參數(shù)，用Tp表示，如圖5中第②行傳給目標類構造方法的參數(shù)“MessageMark”和第⑥，⑦行傳給目標方法的參數(shù)“123456”和$r7.

5) 反射對象.反射類被實例化后的對象，用Ro表示，如圖1所示代碼第⑨行的constructor對象和第行的action對象.

Fig. 6 Algorithm flow chart of source method modifying圖6 源方法修改算法流程圖

具體的源方法修改算法的算法流程圖如圖6所示，對于一條SRT映射，DyLoadDroid-S首先判斷反射方法為newInstance還是invoke方法.對于invoke方法，DyLoadDroid-S首先將目標反射參數(shù)Fp轉化為目標參數(shù)Tp；然后判斷目標反射對象是否為空，若為空，則說明目標方法為靜態(tài)方法，構建靜態(tài)目標方法調(diào)用；若不為空，則說明目標方法為非靜態(tài)方法，DyLoadDroid-S會定義目標類類型的對象To，并將目標反射對象Fo強制類型轉換并賦值給To，然后執(zhí)行非靜態(tài)方法調(diào)用.

newInstance方法包括帶參數(shù)和不帶參數(shù)2種，對于帶參數(shù)的newInstance方法，DyLoadDroid-S定義并創(chuàng)建一個目標對象To，并將目標反射參數(shù)Fp轉化為目標參數(shù)Tp，并調(diào)用目標方法Tm(只會是init())對其進行初始化，然后DyLoadDroid-S將該To對象重新賦值給原目標反射對象Fo，以保證Fo在程序中向下正常傳遞.

圖7和圖8所示分別為對反射方法為有參newInstance方法和反射方法為invoke方法且目標方法為非靜態(tài)方法的反射調(diào)用進行源方法修改后的結果，其中左邊的Sc和Sm代表修改之前的源類和源方法，右邊的Sc和Sm代表修改之后的源類和源方法.圖9所示為對圖5中的Jimple代碼進行源方法修改后的結果.

5.4 污點傳播分析

在源方法修改之前，由于FlowDroid不能正確處理通過newInstance方法調(diào)用進行的對象實例化和通過invoke方法調(diào)用進行的反射調(diào)用，因此，在進行污點分析時，F(xiàn)lowDroid不能正確地分析出污點在源方法和目標方法之間的傳播.如圖7和圖8所示，修改前FlowDroid無法將Sm與Tc，Tm建立關系.

Fig. 7 Taint propagation analysis for newInstance圖7 newInstance方法的污點傳播分析

Fig. 8 Taint propagation analysis for invoke圖8 invoke方法的污點傳播分析

在源方法修改之后，對于newInstance方法調(diào)用，DyLoadDroid-S使用new關鍵字直接創(chuàng)建目標對象，并且將目標反射參數(shù)轉化為目標參數(shù)，所生成的目標對象To又賦值給目標反射對象Fo，F(xiàn)o能夠被FloDroid正確處理，并在源方法中向下傳遞.圖7和圖8中的實線橢圓和箭頭分別代表目標(反射)對象和目標(反射)對象的傳遞路線，從中可以看出，圖7中源方法修改后新增了一條目標反射對象Fo的向下傳遞路線，并且這個新增的路線能夠被FlowDroid正確處理.對于invoke方法調(diào)用，源方法修改過后的結果是，在源方法Sm和目標方法Tm之間建立了能夠被FlowDroid處理的調(diào)用關系，Sm向Tm傳遞的參數(shù)和接收的Tm的返回結果能夠被FlowDroid正確追蹤.目標對象的傳遞也具有連續(xù)性，例如圖8中的目標反射對象Fo被強制類型轉換后賦值給了目標對象To，接下來，對To的目標方法Tm進行了調(diào)用.

①②③④⑤⑥⑦⑧⑨⑩ $r14=newarray(java.lang.Object)[1];$r14[0]="SendMessage";$i1=0;if$i1==0gotolabel08;$r18=newcom.dynamicloadclient.SendMessage;specialinvoke$r18.com.dynamicloadclient.SendMessage:voidinit(java.lang.String)("SendMessage");$r5=$r18;gotolabel09;label08:$r5=virtualinvoke$r13.java.lang.reflect.Constructor:ja-va.lang.ObjectnewInstance(java.lang.Object[])($r14);label09:…$r14=newarray(java.lang.Object)[2];$r14[0]="123456";$r14[1]=$r7;$i0=0;if$i0==0gotolabel14;$r17=(com.dynamicloadclient.SendMessage)$r5;$r5=virtualinvoke$r17.com.dynamicloadclient.SendMes-sage:java.lang.StringsendMSG(java.lang.String,java.lang.String)("123456",$r7);gotolabel15;label14:$r5=virtualinvoke$r15.java.lang.reflect.Method:java.lang.Objectinvoke(java.lang.Object,java.lang.Object[])($r5,$r14);label15:

Fig. 9 The Jimple code after the transformation ofnewInstance and invoke

圖9 newInstance和invoke被轉換后的Jimple代碼

為了便于分析，我們不妨假設圖7中向下傳遞的目標反射對象Fo最終流向圖8中的Fo，那么從圖7到圖8，DyLoadDroid-S便形成了一條能被FlowDroid正確處理的目標對象傳遞路徑，即圖7的②到圖8的①②③.

圖7和圖8中的虛線橢圓和箭頭代表可能的污點傳播線路，在圖7中，若目標反射參數(shù)Fp攜帶有污點數(shù)據(jù)，則會沿著④轉換為目標參數(shù)Tp，并在對象初始化時傳給Tc的初始化方法init().同理，在圖8中，若目標反射參數(shù)Fp攜帶有污點數(shù)據(jù)，則會沿著路徑④⑤⑥進行污點傳播.若Tm的返回值re攜帶有污點數(shù)據(jù)，則會沿著路徑⑦傳回源方法Sm，Sm中接收返回值的Fr對象將在Sm中向下傳播污點數(shù)據(jù).

6 實驗與分析

本節(jié)我們將通過實驗驗證DyLoadDroid對使用Android動態(tài)加載和反射機制的App進行污點分析的有效性，并與FlowDroid的檢測效果進行對比，同時對一些典型App進行實例分析，最后，將DyLoadDroid與其他動態(tài)污點分析工具進行定性的對比.

6.1 實驗環(huán)境和實驗樣本

實驗的主要硬件設備為一個三星I9300手機(4核處理器)和一臺ThinkCentre計算機(8核CPU、8 GB內(nèi)存)，我們將4.1節(jié)介紹的修改后的Android 4.1.2系統(tǒng)制作成ROM并刷入三星I9300手機，DyLoadDroid-D所測試的所有App將在這個修改后的Android系統(tǒng)中運行.而ThinkCentre計算機則主要用來運行DyLoadDroid主程序.

實驗樣本包括：1)從Android應用市場豌豆莢[22]下載的11 428個App，我們把它們作為非惡意樣本(雖然可能有少數(shù)惡意App，但對實驗結果不會造成大的影響)；2)從惡意應用共享網(wǎng)站VirusShare[23]下載的1 132個App，我們將它們作為惡意樣本.實驗樣本的下載時間均為2015年6月，我們使用靜態(tài)分析的方法對它們使用動態(tài)加載和反射機制的情況進行統(tǒng)計，統(tǒng)計結果如表1所示:

Table 1 Number Statistics of Dynamic Loading and Reflection Invocation in Experiment Samples表1 實驗樣本中動態(tài)加載與反射方法調(diào)用的數(shù)目統(tǒng)計

從表1可以看出，動態(tài)加載和反射機制在Android應用中是普遍存在的，并且在非惡意應用中存在的比例高于惡意應用，這可能是由于惡意應用在功能上通常沒有非惡意應用豐富，代碼量小于非惡意應用.

6.2 實驗結果

我們根據(jù)6.1節(jié)中對樣本App使用動態(tài)加載和反射機制情況的統(tǒng)計，選取了動態(tài)加載和反射方法調(diào)用數(shù)量較多的App進行分析，表2所示的10個App為其中比較有代表性的Android應用，其中App編號為1～5的App為非惡意樣本，編號為6～10的App為惡意樣本，表2對App運行中下載的dex文件數(shù)、存在的newInstance反射方法調(diào)用數(shù)和運行中被觸發(fā)的反射方法調(diào)用數(shù)、存在的invoke反射方法調(diào)用數(shù)和運行中被觸發(fā)調(diào)用的反射方法調(diào)用數(shù)進行了統(tǒng)計.由于實驗中對App的具體操作依賴于實驗者，因此DyLoadDroid并不能保證反射方法被觸發(fā)的概率為100%.

Table 2 Information of Dynamic Loading and Reflection Invocation in 10 Samples表2 10個樣本的動態(tài)加載與反射方法調(diào)用情況

我們分別使用DyLoadDroid和FlowDroid對這10個App進行了污點分析，并對它們的檢測效果進行了對比，分析結果如表3所示(表3中的App編號與表2的App編號對應).我們依據(jù)文獻[24]中的方法選擇污染源(source)和陷入點(sink).實驗中的污染源即手機中的隱私數(shù)據(jù)，我們主要考慮的隱私數(shù)據(jù)類型包括10種：1)手機標識，包括IMEI，IMSI，ICCID，MSISDN，ANDROID_ID等；2)地理位置信息；3)短信記錄；4)通訊錄；5)通話記錄；6)Google賬號；7)wifi信息；8)藍牙信息；9)基站信息，如基站編號、位置區(qū)域碼等；10)瀏覽器信息，如瀏覽器書簽、瀏覽歷史記錄等.實驗中的陷入點即可能的隱私泄露途徑，我們主要考慮4種隱私泄露途徑：1)網(wǎng)絡；2)短信；3)日志；4)文件.它們分別表示通過網(wǎng)絡或短信發(fā)送隱私信息，或通過日志輸出或寫文件的方式將隱私信息暴露在系統(tǒng)中.表3中的中括號中的內(nèi)容代表FlowDroid和DyLoadDroid共同檢測出的隱私泄露內(nèi)容或共同檢測出的隱私泄露路徑，表3中的大括號中的內(nèi)容代表DyLoadDroid檢測出、但FlowDroid未檢測出的隱私泄露內(nèi)容或隱私泄露途徑，從另一角度來看，大括號中的內(nèi)容實際上是App通過動態(tài)加載和反射機制所泄露的隱私內(nèi)容.

Table 3 Results Comparison of Taint Analysis表3 污點分析結果對比

Note:The numbers in column “Content of Privacy” represent the type of the private data that be leaked:1—mobile phone identification,2—geolocation information,3—message records,4—contacts,5—call records,6—google accounts,7—wifi information,8—bluetooth information,9—base station information,10—browser information. The marks in column “Ways of Privacy Leakage” represent the ways through which the private data be leaked:①—network,②—short message,③—log,④—file. The contents in the brackets mean the private data or ways of privacy leakage detected by FlowDroid and DyLoadDroid together,while contents in the braces mean the private data or ways of privacy leakage detected by DyLoadDroid,but not by FlowDroid.

6.3 實驗結果分析

從表3可以看出，由于DyLoadDroid能夠對Android動態(tài)加載和反射機制進行有效的污點分析，因此它能夠比FlowDroid檢測出更多的source、sink和污點傳播路徑數(shù)，檢測出更多的隱私泄露內(nèi)容和隱私泄露途徑.并且我們也能從表3中看出，非惡意應用通過動態(tài)加載和反射調(diào)用泄露的用戶隱私的惡意性并不大，通常不會泄露短信記錄、通訊錄、通話記錄等高度敏感內(nèi)容，而惡意應用泄露用戶隱私的行為則通常具有較高的惡意性，這可能是由于非惡意應用獲取用戶隱私信息的目的只是為了提供更好的服務，而并不是為了侵犯用戶的隱私，而惡意應用則具有明顯的竊取用戶隱私的目的.為了更好地了解它們的動態(tài)加載和反射調(diào)用行為，我們采用逆向分析的方法對其進行了實例分析.

6.3.1 對非惡意應用的實例分析

通過對非惡意應用的逆向分析，我們發(fā)現(xiàn)，一些非惡意應用利用動態(tài)加載和反射調(diào)用機制實現(xiàn)插件式管理，例如，App1(表3中編號為1的App，以后我們均這樣簡稱)使用大量的反射調(diào)用對被加載dex文件中組件的生命周期方法進行調(diào)用，并通過反射調(diào)用，對被加載dex文件中的資源進行加載和訪問，被加載的dex文件實際上是以插件的方式為App1提供界面和功能的擴展.此外，一些非惡意應用利用動態(tài)加載和反射機制進行動態(tài)升級或模塊更新，例如，App3啟動運行時會彈出對話框，提醒用戶是否更新應用，當點擊“是”時，App3會從網(wǎng)上下載一個名為component.jar的jar文件，并替換掉應用的數(shù)據(jù)目錄中同名的文件，App3在運行的過程中會使用反射機制對該jar文件進行訪問.我們也對非惡意應用獲取用戶隱私相關信息的原因進行了分析，發(fā)現(xiàn)它們主要還是正當?shù)哪康?，例如，App4是一款天氣預報軟件，它獲取位置信息是為了向用戶提供用戶所在地的天氣情況.App5具有展示廣告的功能，其內(nèi)部嵌入了廣告類庫，該廣告類庫具有閱讀瀏覽器瀏覽記錄并傳給網(wǎng)絡服務器的功能，該行為或許是為了根據(jù)用戶的喜好，提供更具針對性的廣告.

6.3.2 對惡意應用的實例分析

惡意應用泄露用戶隱私的行為通常具有較高的惡意性，通過對惡意應用的逆向分析，我們發(fā)現(xiàn)惡意應用的動態(tài)加載主要是為了隱藏自身和動態(tài)下載執(zhí)行一些惡意程序，反射機制的運用也能在一定程度上幫助惡意應用繞過一些安全檢測.例如，App6將惡意的dex文件隱藏在資源文件中，并偽裝其名稱為“l(fā)ogos.png”,實際上該文件并不是png文件，而是zip文件，程序運行時，通過“XOR”解密和其他一些處理將其轉換為dex文件，并通過反射調(diào)用對其進行調(diào)用.DyLoadDroid截獲了其加載命令，將這個轉換后的dex文件下載到本地電腦，并通過污點分析，成功發(fā)現(xiàn)它讀取短信記錄和通信錄并發(fā)送給外界的隱私泄露路徑.

App8安裝后會在后臺默默啟動一個服務，這個服務會獲取本應用在手機中被授予的權限信息，并將信息傳給一個HTTP服務器，該HTTP服務器收到信息時會返回一個URL，該URL是一個通往網(wǎng)絡上的jar包的路徑.然后App8會下載并加載和調(diào)用該jar文件，DyLoadDroid通過污點分析成功分析出該jar文件所具有的讀取通信錄、通話記錄并傳給HTTP服務器的行為.

App9將2個隱藏的App應用置于其assets文件夾，取名為“anservera.db”和“anserverb.db”.我們簡稱其為pa和pb，當App9運行時，會彈出一個對話框，誘惑用戶安裝pa，pa安裝完成后不顯示任何圖標，在后臺運行(這樣一來，即使App9被卸載了，pa也可以繼續(xù)執(zhí)行惡意操作).App9和pa都可以通過動態(tài)加載的方式執(zhí)行pb，pb會連接網(wǎng)絡服務器，向該服務器發(fā)送用戶的隱私數(shù)據(jù)，并接收網(wǎng)絡服務器的命令，DyLoadDroid成功追蹤到pb獲取短信記錄和通信錄并傳給網(wǎng)絡服務器的污點傳播路徑.

App10在運行時，會注冊2個服務，第一個服務動態(tài)地注冊一個具有最大權限的短信監(jiān)聽器，另一個服務會使用DES算法解密app_TYPE_JAR文件夾下的rt2.jar文件，當解密完成后，它能夠在app_sim_index文件夾下生成一個真正的jar格式文件appmgr.jar，然后App10動態(tài)加載并運行appmgr.jar，并使用反射機制調(diào)用其中的方法，DyLoadDroid成功追蹤到它泄露用戶通訊錄和通話記錄的程序路徑.

6.4 與其他工具的對比

由于FlowDroid是當前領先的Android靜態(tài)污點分析工具，而本文又是在FlowDroid的基礎上進行的改進，通過前面幾節(jié)的對比，DyLoadDroid已經(jīng)顯示出相對于FlowDroid的優(yōu)勢，因此，我們不需要將DyLoadDroid與其他類型的靜態(tài)污點分析工具進行對比.Epicc[18]和DidFail[19]雖然是對FlowDroid的擴展，但它們只是擴展了FlowDroid所能夠分析的數(shù)據(jù)傳播途徑，工具的主體還是FlowDroid，在污點分析效果上并沒有明顯改善，因此我們也沒有必要將DyLoadDroid與它們進行對比，而將它們作為DyLoadDroid的有效補充.本節(jié)內(nèi)容主要是將DyLoadDroid與一些動態(tài)污點分析工具進行對比，因為動態(tài)污點分析工具通常不會受到動態(tài)加載和反射機制的影響，能夠對其進行正常的污點分析.又由于靜態(tài)污點分析工具與動態(tài)污點分析工具各具優(yōu)勢和劣勢，難以進行定量比較，因此，我們不對靜態(tài)污點分析工具和動態(tài)污點分析工具進行定量比較，而是對他們進行定性比較.

1) 與TaintDroid的比較

TaintDroid是當前較為領先的Android動態(tài)污點分析工具，TaintDroid[8]將所有的隱私數(shù)據(jù)標記為污點，它在內(nèi)存中為系統(tǒng)中的每個對象多申請一倍的空間，用于存儲污點標記，在App動態(tài)執(zhí)行的過程中，根據(jù)污點標記追蹤污點在內(nèi)存中的傳播情況.當TaintDroid監(jiān)測到隱私數(shù)據(jù)被泄露出去時，會彈出提示框提醒用戶.TaintDroid可以對Android動態(tài)加載和反射機制進行正確的污點分析，并且具有污點分析準確、誤報率低的優(yōu)點.就準確性而言，F(xiàn)lowDroid和DyLoadDroid都無法和TaintDroid相比，然而，從程序覆蓋率方面來說，DyLoadDroid卻要高于TaintDroid，可以發(fā)現(xiàn)TaintDroid不能發(fā)現(xiàn)的污點傳播路徑.雖然在處理Android動態(tài)加載和反射機制的問題上，兩者都依賴App的實際運行，但DyLoadDroid依賴App的實際運行只是為了獲得App動態(tài)加載的dex文件和反射調(diào)用信息，以輔助靜態(tài)污點分析的過程，彌補靜態(tài)污點分析工具對動態(tài)加載和反射機制不能正確處理的缺陷.DyLoadDroid只需要監(jiān)測到Android的動態(tài)加載和反射調(diào)用的行為便可以對App進行更為全面的污點分析，而TaintDroid則需要App在動態(tài)運行的過程中走完從污染源到陷入點的完整的路徑才能確定是否發(fā)生隱私泄露，而若某條路徑上出現(xiàn)程序阻斷(例如網(wǎng)絡阻塞、用戶認證失敗等)時，TaintDroid便不能追蹤到這條路徑上存在的隱私泄露問題.此外，TainDroid只能在發(fā)生隱私泄露時向用戶彈窗提醒，而不能輸出從污染源到陷入點的完整的路徑，DyLoadDroid則可以輸出從污染源到陷入點的完整的路徑.

2) 與AppFence的比較

AppFence是一個隱私保護工具，不僅可以檢測到系統(tǒng)中發(fā)生的隱私泄露問題，而且可以阻止隱私信息的泄露.它采取數(shù)據(jù)遮蔽和滲出阻塞技術限制App泄露隱私數(shù)據(jù)，核心思想是將隱私數(shù)據(jù)替換為影子數(shù)據(jù)傳遞到外部網(wǎng)絡來防止隱私數(shù)據(jù)的泄露.與TaintDroid一樣，AppFence能準確地檢測出Android系統(tǒng)中發(fā)生的隱私數(shù)據(jù)泄露，誤報率低.然而，它在代碼覆蓋率和漏報率方面都存在和TaintDroid同樣的缺點，比DyLoadDroid弱.并且AppFence容易阻礙App的正常運行，因為App的正常運行可能需要向外部網(wǎng)絡發(fā)送一些隱私信息(如IMEI、位置信息等)，而AppFence的數(shù)據(jù)遮蔽策略可能導致App不能正常地向外發(fā)送數(shù)據(jù)，阻礙App的正常運行，因此無法順利地監(jiān)控到App中存在的其他隱私泄露問題.

7 討 論

雖然DyLoadDroid可以對Android的動態(tài)加載和反射機制進行有效的污點分析，但DyLoadDroid仍然有其自身的缺陷，主要包括：

1) 污點分析的準確性依賴于App實際運行中被加載的dex文件數(shù)和被觸發(fā)的反射調(diào)用的比例.通過表2可以看出，在App實際運行過程中，DyLoadDroid-D并不能保證能夠觸發(fā)到App中所有的反射調(diào)用行為，并且也不能保證能夠下載到所有能夠被加載的dex文件.因此，DyLoadDroid并不能保證對App的動態(tài)加載和反射調(diào)用機制進行完整的分析，它只能保證以最大的可能彌補靜態(tài)分析方法在處理動態(tài)加載和反射調(diào)用機制方面的缺陷.

2) 不能有效分析組件間和應用間的污點傳播.在第1節(jié)中我們提到過，Epicc和DidFail擴展了FlowDroid所能夠分析的數(shù)據(jù)傳播途徑，使FlowDroid能夠追蹤到組件間和應用間的污點傳播.然而DyLoadDroid并沒有將這2個工具對FlowDroid的擴展功能集成進來，因此DyLoadDroid并不能對組件間和應用間的污點傳播進行有效處理.原因是Epicc目前沒有開放源代碼，而DidFail目前還不完善，實用性較差，并且DidFail依賴于Epicc.因此，目前將Epicc和DidFail對FlowDroid的擴展功能集成進DyLoadDroid不易于實現(xiàn).可以認為，Epicc，DidFail與DyLoadDroid互為補充，三者對FlowDroid進行了不同方面的改進.我們也正在聯(lián)系Epicc和DidFail的作者，將Epicc、DidFail與DyLoadDroid進行有效集成，實現(xiàn)更為強大的靜態(tài)污點分析工具.

在以后的研究工作中，我們將重點研究如何使App觸發(fā)更多的動態(tài)加載行為和更多的反射調(diào)用行為，以提高DyLoadDroid的污點分析的準確性.同時，我們將對DyLoadDroid進行擴展，實現(xiàn)組件間和應用間的正確的污點分析.

8 結束語

本文針對當前Android靜態(tài)污點分析工具無法對包含Android動態(tài)加載和反射機制的Android應用進行正常污點分析的問題進行了研究，對當前領先的靜態(tài)污點分析工具FlowDroid進行了改進，提出了DyLoadDroid工具，并介紹了DyLoadDroid的2個主要模塊DyLoadDroid-D和DyLoadDroid-S的設計原理，提出了根據(jù)App在實際運行過程中輸出的動態(tài)加載和反射調(diào)用信息，下載被加載的dex文件，并將相應的反射方法調(diào)用修改為FlowDroid能夠處理的方法調(diào)用的解決方案，使FlowDroid能夠對Android動態(tài)加載和反射機制進行正常的污點分析.我們通過實驗驗證了DyLoadDroid的有效性，并和FlowDroid進行了對比，并對一些實驗樣本進行了實例分析，我們也將DyLoadDroid與其他動態(tài)污點分析工具進行了定性對比，說明了DyLoadDroid所具有的優(yōu)勢.

[1]Wei T E, Jeng A B, Lee H M, et al. Android privacy[C] //Proc of 2012 Int Conf on Machine Learning and Cybernetics. Piscataway, NJ: IEEE, 2012: 1830-1837

[2]Felt A P, Finifter M, Chin E, et al. A survey of mobile malware in the wild[C] //Proc of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. New York: ACM, 2011: 3-14

[3]Zhou Y, Jiang X. Dissecting Android malware: Characterization and evolution[C] //Proc of 2012 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2012: 95-109

[4]Shu X, Du Z, Chen R. Research on mobile location service design based on Android[C] //Proc of the 5th Int Conf on Wireless Communications. Piscataway, NJ: IEEE, 2009: 1-4

[5]Grace M C, Zhou W, Jiang X, et al. Unsafe exposure analysis of mobile in-app advertisements[C] //Proc of the 5th ACM Conf on Security and Privacy in Wireless and Mobile Networks. New York: ACM, 2012: 101-112

[6]Book T, Wallach D S. A case of collusion: A study of the interface between ad libraries and their apps[C] //Proc of the 3rd ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. New York: ACM, 2013: 79-86

[7]Zhang Yuqing, Fang Zhejun, Wang Kai, et al. Survey of Android vulnerability detection[J]. Journal of Computer Research and Development, 2015, 52(10): 2167-2177 (in Chinese)(張玉清, 方喆君, 王凱, 等. Android安全漏洞挖掘技術綜述[J]. 計算機研究與發(fā)展, 2015, 52(10): 2167-2177)

[8]Enck W, Gilbert P, Han S, et al. TaintDroid: An information-flow tracking system for realtime privacy monitoring on smartphones[J]. ACM Trans on Computer Systems, 2014, 32(2): No.5

[9]Hornyack P, Han S, Jung J, et al. These aren’t the droids you’re looking for: Retrofitting Android to protect data from imperious applications[C] //Proc of the 18th ACM Conf on Computer and Communications Security. New York: ACM, 2011: 639-652

[10]Schreckling D, K?stler J, Schaff M. Kynoid: Real-time enforcement of fine-grained, user-defined, and data-centric security policies for Android[J]. Information Security Technical Report, 2013, 17(3): 71-80

[11]Arzt S, Rasthofer S, Fritz C, et al. Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps[J]. ACM SIGPLAN Notices, 2014, 49(6): 259-269

[12]Yang Z, Yang M. Leakminer: Detect information leakage on Android with static taint analysis[C] //Proc of the 3rd World Congress on Software Engineering. Piscataway, NJ: IEEE, 2012: 101-104

[13]Gibler C, Crussell J, Erickson J, et al. Androidleaks: Automatically detecting potential privacy leaks in Android applications on a large scale[J]. Trust and Trustworthy Computing, 2012, 73: 291-307

[14]Zhauniarovich Y, Ahmad M, Gadyatskaya O, et al. StaDynA: Addressing the problem of dynamic code updates in the security analysis of Android applications[C] //Proc of the 5th ACM Conf on Data and Application Security and Privacy. New York: ACM, 2015: 37-48

[15]Lindorfer M, Neugschwandtner M, Weichselbaum L, et al. ANDRUBIS-1 000 000 Apps later: A view on current Android malware behaviors[C/OL] //Proc of the 3rd Int Workshop on Building Analysis Datasets and Gathering Experience Returns for Security. 2014 [2015-09-20]. http://cs.ucsb.edu/～yanick/publications/2014_badgers_andrubis.pdf

[16]Rastogi V, Chen Y, Jiang X. Droidchameleon: Evaluating Android anti-malware against transformation attacks[C] //Proc of the 8th ACM SIGSAC Symp on Information, Computer and Communications Security. New York: ACM, 2013: 329-334

[17]Poeplau S, Fratantonio Y, Bianchi A, et al. Execute this! Analyzing unsafe and malicious dynamic code loading in Android applications[C/OL] //Proc of the 20th Annual Network & Distributed System Security Symp. 2014 [2015-09-20]. https://cs.ucsb.edu/～vigna/publications/2014_NDSS_ExecuteThis.pdf

[18]Octeau D, McDaniel P, Jha S, et al. Effective inter-component communication mapping in Android with epicc: An essential step towards holistic security analysis[C] //Proc of the 22nd USENIX Security Symp. Berkeley: USENIX Association, 2013: 543-558

[19]Klieber W, Flynn L, Bhosale A, et al. Android taint flow analysis for app sets[C] //Proc of the 3rd ACM SIGPLAN Int Workshop on the State of the Art in Java Program Analysis. New York: ACM, 2014: 1-6

[20]Chiba S. ECOOP 2000—Object-Oriented Programming[M]. Berlin: Springer, 2000: 313-336

[21]GitHub. Soot[EB/OL]. [2015-09-20]. http://sable.github.io/soot

[22]Wandou Lab. wandoujia[EB/OL]. [2015-09-20]. https://www.wandoujia.com

[23]VirusShare. Latest virus samples[EB/OL]. [2015-09-20]. http://virusshare.com

[24]Rasthofer S, Arzt S, Bodden E. A machine-learning approach for classifying and categorizing Android sources and sinks[C/OL] //Proc of the 20th Annual Network & Distributed System Security Symp. 2014 [2015-09-20]. http://www.bodden.de/pubs/rab14classifying.pdf

Yue Hongzhou, born in 1987. PhD candidate in the Department of Communication Engineering, Xidian University. His main research interests include Android security and Web security.

Zhang Yuqing, born in 1966. Professor in the Department of Computer and Control Engineering, University of Chinese Academy of Sciences. His main research interests include network and information system security.

Wang Wenjie, born in 1964. Associate professor in the Department of Computer and Control Engineering, University of Chinese Academy of Sciences. His main research interests include intelligent information processing and software reliability measurement.

Liu Qixu, born in 1984. Lecturer in the Department of Computer and Control Engineering, University of Chinese Academy of Sciences. His main research interests include system security, vulnerability assessment and Web security.

Android Static Taint Analysis of Dynamic Loading and Reflection Mechanism

Yue Hongzhou1, Zhang Yuqing1,2, Wang Wenjie2,3, and Liu Qixu2,3

1(StateKeyLaboratoryofIntegratedServicesNetworks(XidianUniversity),Xi’an710071)2(NationalComputerNetworkIntrusionProtectionCenter,UniversityofChineseAcademyofSciences,Beijing101408)3(StateKeyLaboratoryofInformationSecurity(InstituteofInformationEngineering,ChineseAcademyofSciences),Beijing100093)

Privacy leakage is one of the most important issues in the current Android security. The present most important method to detect privacy leakage is taint analysis. Because of its high code coverage and low false negative, the technique of static taint analysis is widely used in the detection of Android privacy leakage. However, the existing static taint analysis tools cannot do effective taint analysis for Android dynamic loading and reflection mechanism. Taking into account the present situation that Android dynamic loading and reflection mechanism are being used more and more widely, we focus on how to enable static taint analysis tools to effectively deal with Android dynamic loading and reflection mechanism. We modify the Android source code to enable the Android system to timely store the loaded dex files and reflection invocation information during the running process of an Android app. This information will be used to guide the static taint analysis process of the app and a policy that replacing the reflective method invocation with non-reflective method invocation is proposed. Based on these ideas, a taint analysis tool—DyLoadDroid is proposed, which has made some improvements of the state-of-the-art static taint analysis tool—FlowDroid and can do effective taint analysis for Android dynamic loading and reflection mechanism. Sufficient experimental results show that DyLoadDroid is very effective in tackling the problem of static taint analysis of Android dynamic loading and reflection mechanism.

Android privacy leakage; taint analysis; dynamic loading; reflection

2015-10-26；

2016-03-22

國家自然科學基金項目(61572460,61272481,61303239)；信息安全國家重點實驗室開放課題(2015-MS-06,2015-MS-04) This work was supported by the National Natural Science Foundation of China (61572460,61272481,61303239) and the Open Project of the State Key Laboratory of Information Security (2015-MS-06,2015-MS-04).

TP309