基于函數(shù)調(diào)用關(guān)系的Android應(yīng)用權(quán)限泄露漏洞挖掘技術(shù)研究

◆譚翠江 劉嘉勇

基于函數(shù)調(diào)用關(guān)系的Android應(yīng)用權(quán)限泄露漏洞挖掘技術(shù)研究

◆譚翠江 劉嘉勇

（四川大學(xué)電子信息學(xué)院 四川 610064）

自Google發(fā)布Android系統(tǒng)以來，各大Android應(yīng)用市場(chǎng)上APP的數(shù)量不斷增長(zhǎng)，Android應(yīng)用程序安全問題也日益突出。本文通過對(duì)Android 應(yīng)用程序中常見的權(quán)限泄露漏洞形成原理進(jìn)行研究，提出一種針對(duì)由暴露組件引起的權(quán)限泄露漏洞挖掘方法，旨在幫助開發(fā)者和用戶及時(shí)發(fā)現(xiàn)存在這種威脅的Android應(yīng)用程序，防止用戶的隱私泄露和財(cái)產(chǎn)損失。本文方法在對(duì)Android應(yīng)用程序進(jìn)行靜態(tài)分析得到可疑路徑的基礎(chǔ)上構(gòu)造測(cè)試用例進(jìn)行驗(yàn)證測(cè)試，具有更強(qiáng)的針對(duì)性，避免了進(jìn)行動(dòng)態(tài)測(cè)試時(shí)的盲目性，可有效地發(fā)現(xiàn)Android應(yīng)用中存在的權(quán)限泄露漏洞。

Android；函數(shù)調(diào)用；權(quán)限泄露；漏洞挖掘

0 前言

近幾年，移動(dòng)平臺(tái)發(fā)展迅速，逐漸成為人們上網(wǎng)的主要方式，其中Android平臺(tái)的發(fā)展最為顯著。根據(jù)市場(chǎng)研究公司Strategy Analytics發(fā)布的最新研究報(bào)告顯示，2016年第三季度Android手機(jī)目前的全球市場(chǎng)份額已經(jīng)高達(dá)87.5%，遠(yuǎn)遠(yuǎn)超過了其他手機(jī)系統(tǒng)，占據(jù)全球手機(jī)操作系統(tǒng)第一的位置[1]。隨著Android智能設(shè)備的普及，日益嚴(yán)峻的Android平臺(tái)安全問題變得越來越不可忽視。根據(jù)AVD Android漏洞庫(kù)顯示，目前該漏洞庫(kù)已收錄662條漏洞信息，其中來自第三方應(yīng)用軟件的漏洞數(shù)量為349個(gè)，占了52.72%。因此保證第三方應(yīng)用軟件的安全對(duì)保障Android平臺(tái)安全顯得尤為重要。而在第三方應(yīng)用軟件中，由于開發(fā)者的疏忽或安全意識(shí)不強(qiáng)，常導(dǎo)致應(yīng)用軟件中存在權(quán)限泄露漏洞，對(duì)用戶的隱私和財(cái)產(chǎn)安全造成極大的威脅。因此，本文就針對(duì)由Android組件暴露引起的Android權(quán)限泄露漏洞提出一種基于函數(shù)調(diào)用關(guān)系分析的漏洞挖掘方法，并通過實(shí)驗(yàn)的方式驗(yàn)證了該方法的有效性和實(shí)用性。

1 相關(guān)技術(shù)研究

1.1 Android安全機(jī)制

Android系統(tǒng)基于Linux內(nèi)核，在繼承了Linux固有安全機(jī)制的同時(shí)，還增加了沙箱機(jī)制、權(quán)限機(jī)制和數(shù)字簽名機(jī)制。Android權(quán)限機(jī)制采用了安裝時(shí)期權(quán)限機(jī)制，即要求開發(fā)者預(yù)先聲明他們的權(quán)限請(qǐng)求，使得用戶可以在安裝時(shí)期對(duì)這些權(quán)限請(qǐng)求進(jìn)行授權(quán)，這區(qū)別于iOS采用的實(shí)時(shí)權(quán)限機(jī)制[2]。Android權(quán)限機(jī)制對(duì)Android應(yīng)用程序可以執(zhí)行的某些具體操作進(jìn)行權(quán)限細(xì)分和訪問控制，以保證系統(tǒng)資源不被濫用。默認(rèn)情況下，應(yīng)用程序在使用如網(wǎng)絡(luò)、短信、通話、SDCard存儲(chǔ)等系統(tǒng)資源之前，都必須在程序的AndroidManifest.xml文件中通過標(biāo)簽來進(jìn)行申明。如果沒有聲明特定的訪問權(quán)限，就無法訪問這些資源。此外，Android系統(tǒng)為每個(gè)應(yīng)用程序創(chuàng)建了一個(gè)獨(dú)立的沙箱，不同的應(yīng)用程序運(yùn)行在各自的進(jìn)行空間中，各個(gè)應(yīng)用程序在默認(rèn)情況下只能訪問自身的資源，從而實(shí)現(xiàn)應(yīng)用程序之間的互不干擾[3]。

1.2 Intent機(jī)制

Android系統(tǒng)為支持不同應(yīng)用程序間的通信，提供了Intent機(jī)制來協(xié)助應(yīng)用程序組件間的交互。Intent是一種運(yùn)行時(shí)綁定機(jī)制，它能在程序運(yùn)行過程中連接兩個(gè)不同的組件，負(fù)責(zé)描述應(yīng)用中一次操作的動(dòng)作、動(dòng)作涉及數(shù)據(jù)以及附加數(shù)據(jù)。系統(tǒng)則根據(jù)此Intent的描述，找到對(duì)應(yīng)的組件，并將 Intent傳遞給調(diào)用的組件，從而完成組件的調(diào)用[4]。

Intent一般包含兩部分:目的和內(nèi)容，其中目的用來表示該Intent要傳遞給哪個(gè)組件，而內(nèi)容則表示向目的組件傳遞什么內(nèi)容。這些可以通過Intent的動(dòng)作（Action）、數(shù)據(jù)（Data）、類別（Category）、類型（Type）、組件名稱（Component）以及擴(kuò)展信息（Extra）等屬性來指定。Intent根據(jù)用法可以分為兩種:顯式Intent和隱式Intent。顯式Intent在構(gòu)造的時(shí)候需要指明接收對(duì)象，而隱式Intent在構(gòu)造時(shí)，并不知道明確的接收對(duì)象，需要用對(duì)接收對(duì)象進(jìn)行過濾，找到合適的接收對(duì)象。

1.3 權(quán)限泄露漏洞概述

一般情況下，Android應(yīng)用程序所使用的組件需要在AndroidManifest.xml文件中進(jìn)行聲明，如:Activity、Services等。在Android系統(tǒng)中，簽名相同且用戶ID相同的程序在執(zhí)行時(shí)共享同一個(gè)進(jìn)程空間，彼此之間沒有組件訪問限制。而簽名不同、用戶ID不同的程序之間只能訪問處于暴露狀態(tài)的組件。

組件是否處于暴露狀態(tài)一方面可以通過組件的android:expor ted屬性值來判斷，當(dāng)組件顯式地將android:exported的屬性值設(shè)為true時(shí)，組件處于暴露狀態(tài)；當(dāng)其值被設(shè)為false時(shí)，組件處于非暴露狀態(tài)。另一方面當(dāng)組件沒有顯式地設(shè)置android:exported的屬性值時(shí)，組件是否處于暴露狀態(tài)由其是否設(shè)置了Intent過濾器（intent-filter）決定。如果組件設(shè)置了過濾器，則表示該組件可以被外部隱式的Intent訪問調(diào)用，否則該組件則不能被外部程序訪問調(diào)用。此外，如果組件在注冊(cè)時(shí)設(shè)置了android:permission屬性，則該組件在被外部應(yīng)用調(diào)用時(shí)，系統(tǒng)會(huì)檢查調(diào)用者是否具有對(duì)應(yīng)的權(quán)限，若外部應(yīng)用沒具備該權(quán)限，系統(tǒng)則會(huì)拋出異常。權(quán)限泄露模型如圖1所示:

圖1 權(quán)限泄露模型

當(dāng)暴露的組件沒有設(shè)置android:permission屬性且在進(jìn)程中存在敏感權(quán)限的API操作時(shí)，就有可能被攻擊者通過調(diào)用暴露的組件來繞過Android系統(tǒng)的權(quán)限機(jī)制，將外部應(yīng)用的權(quán)限提升至暴露組件所具有的權(quán)限，進(jìn)行一些其本身無權(quán)進(jìn)行的敏感操作，如打電話、發(fā)短信等，從而造成了Android應(yīng)用權(quán)限泄露[5]。

2 權(quán)限泄露漏洞挖掘

2.1 APK文件預(yù)處理

由前面的分析可知，導(dǎo)致Android 應(yīng)用權(quán)限泄露漏洞的組件需要一定的條件，即組件必須是暴露的，沒設(shè)置android:permissio n屬性且進(jìn)行了敏感權(quán)限的API操作。因此在對(duì)APK進(jìn)一步分析前需要先對(duì)APK文件進(jìn)行預(yù)處理，提取后續(xù)分析所需的一些信息。整個(gè)預(yù)處理過程如圖2所示。首先對(duì)apk文件進(jìn)行解壓縮，獲取APK包中的dex文件、AndroidManifest.xml文件。然后使用xml解析工具對(duì)AndroidManifest.xml文件進(jìn)行解析，提取應(yīng)用程序申請(qǐng)的權(quán)限信息和程序注冊(cè)的組件信息，檢查各組件的andr oid:exported屬性值，以及android:permission屬性、Intent過濾器的設(shè)置情況，篩選出處于暴露狀態(tài)的組件。另一方面對(duì)dex文件進(jìn)行反編譯，得到細(xì)粒度的smali代碼，為后面構(gòu)建函數(shù)調(diào)用關(guān)系圖做準(zhǔn)備。

圖2 APK預(yù)處理過程

2.2 函數(shù)調(diào)用關(guān)系圖的建立

函數(shù)調(diào)用關(guān)系圖是一個(gè)有向圖，圖中的每個(gè)節(jié)點(diǎn)為應(yīng)用程序中的一個(gè)函數(shù)，圖中的邊為函數(shù)的一個(gè)調(diào)用點(diǎn)。目前生成Android應(yīng)用程序函數(shù)調(diào)用關(guān)系圖的方法，一般是利用開源的Flowdroid或Androguard工具來生成，但生成的函數(shù)調(diào)用關(guān)系圖中包含了很多的與本文分析內(nèi)容無關(guān)的節(jié)點(diǎn)，增加了后續(xù)分析的復(fù)雜度，因而本文不采用上述方法生成程序的函數(shù)調(diào)用關(guān)系圖。

本文根據(jù)后續(xù)分析的需要，在smali代碼級(jí)別上構(gòu)建Android應(yīng)用程序的函數(shù)調(diào)用關(guān)系圖。主要過程是對(duì)預(yù)處理過程中得到的smali代碼進(jìn)行搜索遍歷，提取程序中定義的方法以及各方法中調(diào)用的API函數(shù)，并通過回溯，得到各個(gè)函數(shù)間的調(diào)用關(guān)系。

因?yàn)楸疚氖轻槍?duì)由Intent機(jī)制調(diào)用Android暴露組件引起的權(quán)限泄露漏洞進(jìn)行研究，而Acitivity、Service、BroadCastReceiver組件可由Intent機(jī)制訪問調(diào)用，所以只需關(guān)注這三類暴露組件入口函數(shù)后的函數(shù)調(diào)用關(guān)系即可。因此，將Android應(yīng)用程序中上述三類暴露組件的入口函數(shù)設(shè)置為起始節(jié)點(diǎn)，其中這三類Android組件的入口函數(shù)如表1所示[6]。然后對(duì)Android應(yīng)用程序的函數(shù)調(diào)用關(guān)系圖進(jìn)一步優(yōu)化，去除其它與組件入口函數(shù)不連通的無關(guān)節(jié)點(diǎn)，由此可得到應(yīng)用程序中各個(gè)暴露組件對(duì)應(yīng)的函數(shù)調(diào)用關(guān)系圖。以Test.apk的MainActivity組件為例，得到的函數(shù)調(diào)用關(guān)系圖如圖3所示。

表1 Android組件入口函數(shù)

圖3 Test.apk的MainActivity組件函數(shù)調(diào)用關(guān)系圖

2.3 基于函數(shù)調(diào)用關(guān)系圖的分析

APK預(yù)處理階段得到了應(yīng)用程序所申請(qǐng)的權(quán)限信息，權(quán)限所對(duì)應(yīng)的API函數(shù)即為應(yīng)用程序中可能造成權(quán)限泄露的點(diǎn)。其中Android權(quán)限與API函數(shù)的對(duì)應(yīng)關(guān)系如表2所示，限于篇幅本文只列出了部分對(duì)應(yīng)關(guān)系。

表2 Android權(quán)限與API對(duì)應(yīng)表（部分）

圖4 深度優(yōu)先搜索算法示例

為了簡(jiǎn)化分析，在生成的應(yīng)用程序暴露組件的函數(shù)調(diào)用關(guān)系圖中，將程序中可能導(dǎo)致用戶信息泄露的點(diǎn)，即權(quán)限所對(duì)應(yīng)的API函數(shù)標(biāo)記為終止節(jié)點(diǎn)。結(jié)合組件的入口函數(shù)，即函數(shù)調(diào)用關(guān)系圖的起始節(jié)點(diǎn)，所構(gòu)成的路徑即為存在權(quán)限泄露漏洞的可疑路徑。為了得到由暴露組件引發(fā)的權(quán)限泄露漏洞的全部可疑路徑，本文采用深度優(yōu)先搜索算法對(duì)暴露組件的函數(shù)調(diào)用關(guān)系圖進(jìn)行搜索遍歷。深度優(yōu)先搜索算法是按照深度優(yōu)先展開搜索樹的搜索算法[7]，可以有效地求出兩點(diǎn)間的所有路徑。以圖4為例，簡(jiǎn)要說明深度優(yōu)先搜索算法搜索從v0到v4節(jié)點(diǎn)所有路徑的過程。

（1）首先建立一個(gè)存儲(chǔ)節(jié)點(diǎn)的棧結(jié)構(gòu)，將起始節(jié)點(diǎn)v0入棧，并將其標(biāo)記為入棧狀態(tài)。

（2）從v0節(jié)點(diǎn)出發(fā)，找到下一個(gè)相鄰的非入棧節(jié)點(diǎn)v1、v2或v3，假設(shè)先訪問v1節(jié)點(diǎn)，將v1節(jié)點(diǎn)入棧，并標(biāo)記為入棧狀態(tài)。

（3）從v1節(jié)點(diǎn)出發(fā)，搜索下一個(gè)相鄰的非入棧節(jié)點(diǎn)。由于v1節(jié)點(diǎn)沒有下一個(gè)相鄰的節(jié)點(diǎn)，所以從棧頂彈出v1節(jié)點(diǎn)，并將v1節(jié)點(diǎn)標(biāo)記為非入棧狀態(tài)。此時(shí)棧頂是v0節(jié)點(diǎn)。

（4）從v0節(jié)點(diǎn)出發(fā)，找到下一個(gè)除v1節(jié)點(diǎn)外相鄰的非入棧節(jié)點(diǎn)v2或v3，假設(shè)先訪問v2節(jié)點(diǎn)，將v2節(jié)點(diǎn)入棧，并標(biāo)記為入棧狀態(tài)。

（5）從v2節(jié)點(diǎn)出發(fā)，找到v2節(jié)點(diǎn)的下一個(gè)相鄰的非入棧節(jié)點(diǎn)v4，將v4節(jié)點(diǎn)入棧，并標(biāo)記為入棧狀態(tài)。

（6）由于v4節(jié)點(diǎn)是終止節(jié)點(diǎn)，因此得到了一條從起始節(jié)點(diǎn)v0到終止節(jié)點(diǎn)v4的路徑:v0-> v2-> v4。

（7）從棧頂彈出v4節(jié)點(diǎn),并將v4節(jié)點(diǎn)標(biāo)記為非入棧狀態(tài)。

（8）此時(shí)棧頂是v2節(jié)點(diǎn),由于v2節(jié)點(diǎn)沒有除剛出棧的v4節(jié)點(diǎn)外的相鄰非入棧節(jié)點(diǎn),因此將v2節(jié)點(diǎn)出棧,并標(biāo)記為非入棧狀態(tài)。

（9）此時(shí)棧頂是v0節(jié)點(diǎn)，重復(fù)步驟（4）～（6）得到第二條從起始節(jié)點(diǎn)v0到終止節(jié)點(diǎn)v4的路徑:v0-> v3-> v4。

（10）重復(fù)步驟（7）（8），此時(shí)棧頂是v0節(jié)點(diǎn)，由于與v0節(jié)點(diǎn)相鄰的節(jié)點(diǎn)都已被訪問過，因此彈出v0節(jié)點(diǎn)，并標(biāo)記為非入棧狀態(tài)。此時(shí)棧結(jié)構(gòu)為空，結(jié)束整個(gè)路徑搜索過程。

如圖3所示的Test.apk的MainActivity組件函數(shù)調(diào)用關(guān)系圖，以組件入口函數(shù)”MainActivity；onCreate（）”節(jié)點(diǎn)為起始節(jié)點(diǎn)，應(yīng)用的權(quán)限泄露點(diǎn)”SmsManager；sendTextMessage（）”節(jié)點(diǎn)為終止節(jié)點(diǎn)，使用深度優(yōu)先搜索算法進(jìn)行路徑搜索，得到由起始節(jié)點(diǎn)到終止節(jié)點(diǎn)的所有路徑為:

(1)”MainActivity；onCreate（）”->”MainActivity；fun1（）”->”MainActivity；fun2（）”->”SmsManager；sendTextMessage（）”；

(2)”MainActivity；onCreate（）”->”SmsManager；sendText Message（）”；

即Test.apk的MainActivity中存在權(quán)限泄露的可疑路徑集為{(1)(2)}。

然而在得到的可疑路徑集中，并非所有的路徑都能在程序運(yùn)行時(shí)得到執(zhí)行，大部分的路徑都需要滿足一定的條件才能執(zhí)行。因此需要對(duì)存在可疑路徑的危險(xiǎn)組件進(jìn)行動(dòng)態(tài)測(cè)試才能最終確認(rèn)應(yīng)用中是否存在權(quán)限泄露漏洞。

2.4 對(duì)可疑路徑進(jìn)行測(cè)試

為了對(duì)得到的可疑路徑集進(jìn)行測(cè)試，需要解決三個(gè)問題:

（1）構(gòu)造測(cè)試用例；

（2）將測(cè)試用例輸入到Android模擬器或真機(jī)中執(zhí)行；

（3）監(jiān)視測(cè)試用例運(yùn)行結(jié)果。

對(duì)于測(cè)試用例的構(gòu)造,由前面得到的可疑路徑集，分別取出每一條可疑路徑，結(jié)合預(yù)處理過程中得到的暴露狀態(tài)的組件信息，得出可疑路徑所在的組件名、組件所設(shè)置的Intent過濾器信息和組件接收的各參數(shù)的數(shù)據(jù)類型。由此可以構(gòu)造一個(gè)顯式的Intent或隱式的Intent來模擬攻擊者對(duì)該組件進(jìn)行訪問調(diào)用，其中需要傳遞的參數(shù)根據(jù)不同的數(shù)據(jù)類型分別設(shè)置默認(rèn)值來進(jìn)行測(cè)試。

為更加方便地解決第二個(gè)問題，本文采用Android系統(tǒng)提供的am命令將測(cè)試用例輸入Android模擬器進(jìn)行測(cè)試。am命令使用方法如下:

am [subcommand] [options]

即命令后面跟著一個(gè)子命令，本文主要用到start、startservice、broadcast三個(gè)子命令，它們分別可以啟動(dòng)Activity、Service組件和發(fā)送廣播。以start子命令為例，其后接一系列可選參數(shù)和選項(xiàng)。重點(diǎn)討論部分，這部分將構(gòu)造的顯式或隱式的Intent轉(zhuǎn)換成命令行的形式輸入android模擬器中。對(duì)于顯式的Intent，其轉(zhuǎn)換成命令行的規(guī)則為:

am start –n 包名/組件名。

對(duì)于隱式的Intent，其轉(zhuǎn)換成命令行的規(guī)則為: am start [-a ] [-d ] [-t ] [-c ] …

在向Android模擬器輸入測(cè)試用例后，需要監(jiān)測(cè)測(cè)試用例的運(yùn)行情況，本文采用修改系統(tǒng)源碼的方式，在系統(tǒng)源碼相應(yīng)的API函數(shù)中加入打印日志信息語(yǔ)句來監(jiān)視相關(guān)API函數(shù)被調(diào)用情況，進(jìn)而根據(jù)日志信息判斷漏洞是否存在。

3 實(shí)驗(yàn)測(cè)試結(jié)果

為了驗(yàn)證本方法的有效性，本文首先設(shè)計(jì)了一個(gè)存在兩處權(quán)限泄露漏洞的Android應(yīng)用來測(cè)試本方法對(duì)一個(gè)應(yīng)用中存在多處權(quán)限泄露的檢測(cè)效果。該應(yīng)用中包含了3個(gè)Activity、3個(gè)Servi ce。其中每類組件又分別設(shè)置為非暴露、暴露且設(shè)置了android: permission屬性、暴露沒設(shè)置android:permission屬性三種狀態(tài)，且每個(gè)組件都進(jìn)行了一次權(quán)限調(diào)用。實(shí)驗(yàn)結(jié)果如表3所示。

表3 實(shí)驗(yàn)結(jié)果

為進(jìn)一步驗(yàn)證方法的實(shí)用性，本文在Android應(yīng)用市場(chǎng)上隨機(jī)下載了涵蓋金融類、系統(tǒng)工具類、社交類、多媒體類和生活服務(wù)類共100個(gè)Android應(yīng)用依次進(jìn)行測(cè)試。除了其中13個(gè)應(yīng)用程序由于進(jìn)行了加固處理，在預(yù)處理階段反編譯時(shí)出錯(cuò)，無法進(jìn)一步分析外，剩余的應(yīng)用程序經(jīng)過預(yù)處理階段共發(fā)現(xiàn)了1136個(gè)暴露組件。生成函數(shù)調(diào)用關(guān)系圖進(jìn)行分析后，共得到了9條造成權(quán)限泄露的可疑路徑。構(gòu)造Intent測(cè)試用例對(duì)可疑路徑進(jìn)行測(cè)試后，從日志信息中發(fā)現(xiàn)成功地執(zhí)行了其中的三條可疑路徑，其中兩條權(quán)限泄露路徑屬于同一應(yīng)用。這表明利用本文的方法成功地從實(shí)驗(yàn)隨機(jī)選取的100個(gè)Android應(yīng)用中挖掘出了兩個(gè)存在權(quán)限泄露漏洞的應(yīng)用。

通過上述實(shí)驗(yàn)結(jié)果可以看出，本文的方法能有效地挖掘出Android應(yīng)用中由暴露組件引起的權(quán)限泄露漏洞。

4 結(jié)束語(yǔ)

本文通過對(duì)Android應(yīng)用進(jìn)行預(yù)處理，獲取程序的暴露組件和申請(qǐng)的權(quán)限等信息后，結(jié)合暴露組件信息構(gòu)建程序的函數(shù)調(diào)用關(guān)系圖。再結(jié)合Android應(yīng)用權(quán)限與API函數(shù)的對(duì)應(yīng)表，以及Android組件的入口函數(shù)，采用深度優(yōu)先搜索算法對(duì)函數(shù)調(diào)用關(guān)系圖進(jìn)行搜索，得到應(yīng)用程序中存在權(quán)限泄露的可疑路徑集。最后再通過靜態(tài)分析的結(jié)果構(gòu)造測(cè)試用例對(duì)可疑路徑集進(jìn)行驗(yàn)證測(cè)試，大大改善了動(dòng)態(tài)測(cè)試的盲目性，有效地挖掘出了Android應(yīng)用中存在的權(quán)限泄露漏洞。該方法不足之處在于，在構(gòu)造測(cè)試用例時(shí)，對(duì)于組件接收的參數(shù)只是根據(jù)類型設(shè)定了固定的默認(rèn)值，這使得不能發(fā)現(xiàn)組件需要傳入特定數(shù)據(jù)才能觸發(fā)的漏洞，下一步研究工作將重點(diǎn)在這方面展開。

[1]手機(jī)中國(guó)2016年第三季度智能手機(jī)市場(chǎng)份額調(diào)研報(bào)告[R].http://www.cnmo.com/os/561651.html，2016.

[2]朱佳偉，喻梁文，關(guān)志.等.Android權(quán)限機(jī)制安全研究綜述[J].計(jì)算機(jī)應(yīng)用研究，2015.

[3]李淑民.Android智能手機(jī)隱私泄露機(jī)制及防范方法研究[D].北京交通大學(xué)，2015.

[4]Chen F.METHOD，DEVICE AND TERMINAL FO R STARTING APPLICATION PROGRAM:，WO/2014/16 1292[P]，2014.

[5]董國(guó)偉，王眉林，邵帥等.基于特征匹配的Android應(yīng)用漏洞分析框架[J].清華大學(xué)學(xué)報(bào)自然科學(xué)版，2016.

[6]李智，陳金威，陳世喆等.基于靜態(tài)污點(diǎn)分析法的Andr oid信息泄露研究[J].電子質(zhì)量，2015.

[7]龔建華.深度優(yōu)先搜索算法及其改進(jìn)[J].現(xiàn)代電子技術(shù)，2 007.