一種跨APP組件間隱私泄露自動檢測方法

李 振 湯戰勇 李政橋 王 海 龔曉慶 陳 峰 陳曉江 房鼎益

1(西北大學信息科學與技術學院 西安 710075)2(陜西省無源物聯網國際聯合研究中心 西安 710075)

隨著Android移動市場份額的不斷擴大，越來越多的惡意攻擊者將目標瞄向Android設備.騰訊社會研究中心最新一期發布的互聯網安全報告[1]顯示：在所選取的852個Android APP(Android application)中，約有98.5%的APP都需要獲取用戶隱私權限.Felt等人[2]研究發現，以獲取并泄露用戶隱私信息為目標的惡意軟件占據很大的比例，這一結果很好地解釋了近年來國內外個人信息泄露事件頻發的問題.

學術界和工業界一般將隱私權限等級劃分為高危隱私權限、核心隱私權限、重要隱私權限和普通隱私權限[3-4].不同層面的權限濫用會對用戶造成不同程度的影響，如何在權限安全控制和用戶的體驗之間抉擇是一個相互制約的話題，使用權限定義復雜的控制手段能夠在一定程度上保護用戶隱私數據，但卻以犧牲用戶體驗為代價.為了娛樂性和實用性，目前移動設備僅使用粗粒度的訪問權限控制手段.Android系統自身實現了一套用于保護敏感信息資源安全性的應用程序編程接口(application programming interface, API)訪問權限控制機制，用于保護敏感信息資源的安全性.其要求在程序安裝時向用戶顯式地申請使用權限.然而中國互聯網數據中心[4](Data Center of China Internet, DCCI)調研發現，有72%的用戶不清楚APP獲取隱私權限的用途.所以大多數用戶為了追求良好的用戶體驗，不惜將該程序自身功能不必需的隱私權限授權給該APP，因此這種API權限控制機制并不能有效控制第三方應用程序對隱私數據的訪問和使用.

軟件泄露隱私的主要途徑分為組件內隱私泄露、組件間隱私泄露和跨APP組件間隱私泄露.組件內隱私泄露是指在Android APP內部，某組件能夠獨立完成隱私的獲取和泄露[5]；而組件間隱私泄露是指Android APP內部的2個組件通過合作完成獲取和泄露隱私[6]；跨APP組件間隱私泄露是指某個惡意軟件利用存在組件間通信(inter-component communication, ICC)漏洞[7-8]通過第三方APP來泄露隱私；據ComDroid[8]研究表明，60%的應用程序至少存在1個以上的ICC漏洞.因此，跨APP組件間隱私泄露普遍存在并且不容忽視.

雖然目前存在很多隱私檢測的研究[9-16]，但是針對跨APP組件間隱私泄露問題的研究涉及較少.FlowDroid[5]提出一種新型按需算法的靜態污點分析技術檢測隱私泄露問題；LeakMiner[17]結合Android自身特有的安全機制以及編程模型，基于函數調用關系實現了對程序中隱私信息的識別、跟蹤和泄露檢測.上述隱私泄露檢測方法的精確度很高，但僅限于組件內隱私泄露問題；IccTA[6]和Amandroid[18]等方法針對組件間隱私泄露檢測.其中，IccTA結合Epicc[7]與FlowDroid方法，通過跟蹤組件間的隱私信息傳播達到檢測的目的.

跨APP組件間隱私泄露檢測的實現存在很大的挑戰.原因在于APP中組件數量龐大、依賴關系復雜，存在很多與跨APP組件間隱私泄露無關的組件序列路徑.因此，直接利用現有的隱私泄露檢測技術，會在構建控制流圖(control flow graph, CFG)時引發空間爆炸，嚴重影響檢測效率.而且，由于跨APP組件間隱私泄露往往涉及到多個應用程序的集合，APP間代碼不連續將導致在分析隱私泄露路徑時無法建立一個連續的CFG，而現有工作不能解決此問題.

因此，本文提出了一種檢測跨APP組件間隱私泄露的方法PLDetect.PLDetect提出生成潛在泄露隱私的組件序列，精簡與跨APP組件間隱私泄露無關的組件序列的方法，有效地解決了在生成CFG時路徑爆炸問題；進一步地，PLDetect通過將生成虛擬主函數和插樁技術有效結合，解決跨APP組件間隱私泄露中的多種代碼不連續性問題；最后，生成基于精簡組件的控制流圖，并執行應用程序間靜態污點分析，輸出跨APP組件間隱私泄露的路徑.

本文的主要貢獻有3個方面:

1) 設計并實現1個采用靜態污點分析方法檢測跨APP組件間隱私泄露的系統PLDetect；

2) 在保證PLDetect覆蓋泄露隱私信息路徑的情況下，提出生成潛在泄露隱私的組件序列的方法，用以提高檢測效率；

3) 針對APP間代碼不連續造成無法構建完整的CFG，從而導致不能執行數據流分析的問題，通過移植改進IccTA中的插樁方法對此問題進行了有效解決.

1 跨APP組件間隱私泄露的攻擊模型

為了準確描述跨APP組件間隱私泄露攻擊模型，首先給出跨APP組件間隱私泄露的相關定義.

假定Appi為Android Market中應用程序，SandBoxi為其對應的運行沙箱環境，則表示為AppiinSandBoxi.假定fp為隱私信息獲取通道表征函數，Privacyi為App1能獲取的隱私信息，則表示為Privacyi=fp(Appi).假定lp為隱私信息泄露通道表征函數，若Appi不能泄露隱私信息，則表示為lp(App1)=false，否則，lp(App1)=true.

在App1inSandBox1&App2inSandBox2且SandBox1∩SandBox2=?的條件下，如果App1滿足Privacy1=fp(App1)≠?且lp(App1)=false,App2滿足Privacy2=fp(App2)≠?且lp(App1)=true,并且存在一種關聯關系函數R，使得Privacy2=fp(R(App2,App1))≠?且Privacy2∈Privacy1，那么App1和App2可能存在跨APP組件間隱私泄露的路徑.

根據定義，對跨APP組件間隱私泄露的攻擊模型進行實例化描述.

在圖1中，App1是獲取隱私信息的良性Android應用程序，App2是泄露隱私信息的惡意Android應用程序.App1中的組件A通過授權的API權限得到設備ID值(getDeviceId)，并通過ICC方法(startActivity)將ID值傳遞給App2中的組件B，并由B將ID值泄露.圖1右側的代碼分別是App1中組件A與App2中組件B的關鍵代碼簡略描述.另外，在實際用戶使用環境中，不排除2個惡意程序通過合作互通的形式更復雜更隱蔽地達到泄露隱私的目的.在上述實例中，App1可以利用惡意攻擊者所規定的某種數據拆分格式,如圖像格式或自定義文件等形式，將設備ID發送至App2，隨后由App2將接收到的信息經過一系列數據重組以及信息轉換手段寫出，最終以非授權分發方式發送至攻擊者.

上述中不論隱私信息以哪種形式組織，App1滿足Privacy1=fp(App1)≠?且lp(App1)=false，App2滿足Privacy2=fp(App2)≠?且lp(App2)=true.而且App1與App2存在關聯關系R函數(startActivity)，使得Privacy2=fp(R(App2,App1))≠?,因此，App1和App2間可能存在跨APP組件間隱私泄露的路徑.

2 PLDetect系統實現

PLDetect由5個執行步驟組成，如圖2所示，在Step1中，利用Epicc提取輸入中每個APP的組件屬性；在Step2中，利用Step1的組件屬性對待分析的多個APP進行分類；在Step3中，利用分類結果精簡與跨APP組件間隱私泄露無關的組件，生成潛在泄露隱私的組件序列，從而解決由于組件間依賴關系復雜而造成的路徑爆炸問題；在Step4中，在潛在泄露隱私組件的基礎上，利用虛擬主函數和插樁技術解決由于Android代碼不連續性造成無法進行靜態污點分析的問題，并構建基于精簡組件的CFG；在Step5中，PLDetect利用SuSi[19](一種采用機器學習方法收集Android 敏感API的工具)收集到的敏感源和泄露點，在CFG上執行應用程序間的靜態污點分析，最終輸出檢測到的跨APP組件間隱私泄露的路徑.

Fig. 2 Overall framework of PLDetect圖2 PLDetect系統整體框架

2.1 組件屬性提取

在圖2的Step1，PLDetect利用Epicc提取Dex和AndroidManifest文件中的相關信息.Epicc是一個基于Soot編譯框架[20]和Heros數據流分析工具[21]的ICC拓撲工具，能夠提取組件屬性、ICC方法和參數.

PLDetect提取組件屬性為:

1) 聲明的組件列表；

2) 每個組件的intent_filter標簽；

3) 每個組件的exported屬性值；

4) 每個組件的intent參數值.

算法1.計算組件的exported值.

輸入：Android應用程序的組件;

輸出：true或false.

ifexplicitExported(component)=true then

returngetTheValue(“exported”)；

end if

ifcomponentType(component)=ContentProvider

then

ifSDKversion≤16 then

return true;

else

return false;

end if

end if

ifComContainIntentFilter(component)=true

then

return true;

else

return false;

end if

通過屬性1得到應用程序中聲明的組件列表.當組件exported屬性值為true時，則表示允許第三方APP訪問當前組件；反之則拒絕任何來自第三方APP訪問.因此，PLDetect采用算法1計算組件的exported屬性值，并通過屬性2和屬性4得到組件的intent參數值和intent_filter屬性值，用于組件間的匹配.

2.2 APP分類

跨APP組件間隱私泄露是由2個APP組合完成的，但是，任意2個APP組合不一定能夠達到泄露隱私的目的.因此，針對所有的APP進行分類及相應的篩選處理是非常必要的.

1) 根據跨APP組件間隱私泄露的條件，PLDetect認為2種APP是良性的:

① 如果當前APP擁有獲取隱私信息的權限，并能夠獲取隱私信息，則不能將隱私信息傳遞給第三方應用程序.

② 如果當前APP擁有泄露隱私信息的權限，并能夠泄露隱私信息，則不能被第三方應用程序調用.

上述2種APP不能作為跨APP組件間隱私泄露集合中的APP.所以PLDetect對具有以上條件的APP進行剪枝，從而避免不必要的分析時間.

2) Android組件中是否擁有隱式intent決定該APP是否能夠調用第三方APP，因此，假設當前APP擁有隱式intent的組件，則將該APP歸類為SourceApp.Android組件的exported屬性值決定組件能否被第三方應用程序調用，假設當前APP擁有exported的值為true，則將該APP分為SinkApp類.假設應用程序同時滿足上述SourceApp和SinkApp的條件，則將該APP分為SourceOrSink類.

3) 根據2)中分類結果，本文得到可能實現跨APP組件間泄露隱私信息的APP組合有4種形式：(SourceApp,SinkApp),(SourceApp,SourceOrSink),(SourceOrSink,SinkApp),(SourceOrSink,Source-OrSink).

2.3 生成潛在泄露隱私的組件序列

為了能夠有效精簡組件間的依賴關系，構造真實存在的并能引發隱私泄露的組件序列，PLDetect根據2.2節中得到的潛在泄露隱私的APP組合，提出一種生成潛在泄露隱私的組件序列的方法，從而解決路徑爆炸的問題.PLDetect生成潛在泄露隱私的組件序列的方法步驟為

Step1. 根據潛在泄露隱私的APP組合中的2個應用程序，分別生成潛在泄露隱私的組件子序列SeqA，SeqB.

Step2. 利用潛在泄露隱私的組件子序列SeqA，SeqB，構建完整的潛在泄露隱私的組件序列.

生成潛在泄露隱私的組件子序列的具體方法是：首先，根據2.1節中得到的intent參數與intent_filter標簽，并利用組件間匹配規則生成圖3和圖4中的組件調用關系；然后，根據組件調用關系，生成應用程序運行時可能出現的組件執行序列；最后，PLDetect判斷組件執行序列中是否存在能夠構建完整的潛在泄露隱私的組件序列的組件子序列.

Fig. 3 Generation process of leakage sequence for element 1 in an APP combination圖3 APP組合中元素1泄露序列生成過程

Fig. 4 Generation process of leakage sequence for element 2 in an APP combination圖4 APP組合中元素2泄露序列生成過程

圖3表示的是2.2節中APP組合中第1個元素生成潛在泄露隱私的組件子序列的過程描述，PLDetect根據組件調用關系生成了2種組件執行序列：1)A→B1→C；2)A→B2.然后，PLDetect采用算法2判斷1), 2)中是否存在潛在泄露隱私的組件子序列.類似地，圖4表示的是2.2節中APP組合中第2個元素生成潛在泄露隱私的組件子序列的全過程.

因此，假定經過算法2處理之后生成的潛在泄露隱私的組件子序列分別為B1→C，E→F1.那么，最終由PLDetect生成的潛在泄露隱私的組件序列為B1→C→E→F1.其中，本序列中各個元素是與跨APP組件間隱私泄露問題的相關組件，同時也是需要構建CFG的組件.

算法2.判斷APP組合序列中第i個元素的執行序列是否存在潛在泄露隱私的組件子序列.

輸入：應用程序的執行序列;

輸出：潛在泄露隱私的組件子序列.

iffindLefttoRight(component_sequence)=false then*findLefttoRight方法在執行序列中尋找獲取隱私信息的組件*

return false;

else

component_first←findLefttoRight

(component_sequence);

end if

iffindRighttoLeft(component_sequence)=false then*findRighttoLeft方法在執行序列中尋找能夠調用第三方APP的組件*

return false;

else

component_second←findRighttoLeft

(component_sequence);

end if

m←component_sequence.indexOf(component_first);

n←component_sequence.indexOf(component_second);

ifm>nthen

return false;

else

returncomponent_sequence.substring(m,n+1);

end if

2.4 生成精確的控制流圖

Android的代碼不連續性將導致不能把多個獨立的APP構建成一個完整的CFG，因此，本節將詳細介紹如何解決由Android中生命周期、回調函數以及ICC方法而引入的代碼不連續性問題.

2.4.1 生命周期

Android應用程序沒有主函數，而是由組件生命周期函數組成的多個入口，即Android應用程序可以根據用戶事件或系統事件，調用組件的每個生命周期函數.如當Activity組件處于onPause狀態時，如果該Activity被重新啟動，則該Activity直接進入onResume狀態，而非onCreate狀態；如果該Activity由于內存不足被殺死而后重新啟動時，則該Activity進入onCreate狀態.因此，由于Android框架為每個組件定義了完整的生命周期，從而造成Android應用程序多入口的問題，只有通過精確的模擬生命周期的變化，才能保證下一步靜態分析時得到的隱私泄露路徑的精確性.

為了解決由于生命周期引入而帶來的的不連續性問題，根據2.3節中生成的潛在泄露隱私的組件序列，PLDetect為序列中的每個組件生成dummy-Main(虛擬主函數).按照Android開發文檔中生命周期的調用順序，PLDetect在dummyMain中精確地模擬生命周期的執行順序，即在dummyMain中插入調用生命周期函數的語句.

2.4.2 回調函數

Android操作系統允許注冊回調函數.如Button的監聽器，用戶觸發該按鈕的點擊事件后，由Android框架來自動調用onClick后的具體內容.PLDetect使用 FlowDroid處理回調函數的方法，在dummyMain中模擬回調函數的調用.然而，回調函數被調用的順序無法預測，只有當回調函數所在的組件運行時，回調函數才可能被調用執行.因此，為了考慮模擬的精確性，PLDetect建立了回調函數與組件間的對應關系，并利用FlowDroid收集的回調函數集合，判斷潛在泄露隱私組件序列中的每個組件是否存在回調函數，如若存在回調函數，則在dummyMain中模擬回調函數.即：在組件的dummyMain函數中的onResume與onPause調用語句之間，生成調用回調函數的語句，使得回調函數在dummyMain中可達，從而解決代碼不連續性問題.

2.4.3 ICC方法

Android應用程序中組件交互數據是通過Bundle對象和intent對象傳遞的，即ICC模型.但是，通過intent對象實現的代碼并沒有直接調用對應組件，在代碼層，2個組件是獨立的、不連續的.它是由Android框架通過匹配intent與intent_filter的參數，從而實現組件間的匹配以及數據傳遞.

因此，本文利用Soot[13]生成Jimple中間語言，并結合插樁技術修改潛在泄露隱私的組件序列中組件間的ICC方法，從而解決ICC帶來的組件間代碼的不連續性問題.

PLDetect的具體思路是：基于Jimple中間語言利用插樁技術修改ICC代碼，從潛在泄露隱私的組件序列的左側第1個組件開始，分別在前一個組件中實例化下一個組件，并調用helperIpc和dummyMain方法.如圖5所示:

Fig. 5 The modification method of startActivity圖5 startActivity的修改方法

在圖5中，以startActivity的修改方法為例對利用插樁技術解決ICC帶來的代碼不連續性問題進行說明.其中，圖5(a)表示App1中的Activity1組件，圖5(b)表示App2中的Activity2組件.而Activity1和Activity2組件符合組件匹配規則并能傳遞數據.PLDetect通過修改圖5中的代碼，使得Activity1和Activity2在代碼層上可達.

在圖5(b)中，PLDetect生成helperIpc(intent)和getIntent()方法.helperIpc方法將攜帶的intent對象賦值給_intent_ipc；getIntent的返回值為_intent_ipc.helperIpc和getIntent實現intent對象的傳遞過程，從而替換由Android框架完成的工作.其中，圖5(b)中dummyMain方法實現了2.4.1節和2.4.2節的思想.

在圖5(a)中，刪除了startActivity方法，并實例化Activity2對象，然后調用helperIpc方法傳遞intent對象，將intent對象的信息傳遞到Activity2對象，并且通過調用Activity2中dummyMain方法，使得Activity1和Activity2在代碼層徹底鏈接起來.

因此，在潛在泄露隱私的組件序列中，任意2個相鄰的組件都會采用上述相同的方法.

在Android系統中，Implicit Intent沒有以一個指定的組件命名，而是聲明需要執行的操作，該操作允許第三方應用程序的組件去處理它.例如：如果在地圖上展示用戶的位置，可以使用1個Implicit Intent去請求第三方應用程序在地圖上展示指定的位置.因此，基于跨APP組件間隱私泄露的問題，應用程序間的數據傳遞本質上是使用intent對象攜帶、ICC方法(如startActivity等)傳遞實現的，所以，針對APP間代碼的不連續性，本文采用上述方法處理.基于潛在泄露隱私組件序列的插樁技術，一方面有效解決了IccTA等方法存在的路徑爆炸、工作量龐大、分析效率低的問題，另一方面克服了現有方法作用域為單獨應用程序內部組件的局限性.

最后，在解決代碼不連續性問題后，PLDetect將這些APP之間與隱私泄露相關的組件構建成1個完整的CFG.并且利用SuSi收集Android API中的敏感源和泄露點方法集合，在構建的CFG上執行應用程序間的靜態污點分析，跟蹤隱私信息的數據流流向，得到并輸出檢測到的跨APP組件間隱私泄露的路徑.

PLDetect以非侵擾的方式工作在后臺，并將上述步驟中得到的隱私信息泄露路徑作為輸入，使用插樁技術來修改路徑中組件所在的Android應用程序.以此來保證隱私信息在被惡意應用泄露前被加密或替換為無效的數據，從而在不影響APP正常執行的情況下緩解隱私信息泄露造成的風險和危害.具體來講，因為Soot支持閱讀和重寫Davilk字節碼，因此PLDetect在上述Soot生成Jimple的基礎上，通過插樁修改相關Android程序來達到數據加密或替換的目的.假設APP1的Activity1與APP2的Activity2經檢測是2個符合跨APP間隱私泄露的組件并通過intent傳遞隱私信息.那么，PLDetect將在Activity1中插入1個字段，且該字段的作用是唯一標識Activity2所在的APK的包名.同時，在Activity2組件中，PLDetect會以Jimple形式插入一段功能代碼.這段代碼的主要作用是判斷從intent中獲取到的字段值是否與自身包名一致，若一致則加密或替換隱私信息的值,若不一致則不修改.因此，PLDetect采取了簡單有效的方法，在保證用戶良好體驗的前提下解決了隱私被泄露的隱患.

3 系統評測實驗與分析

為了驗證跨APP組件間隱私泄露的檢測模塊的檢測效果，本文主要從觸發程序和商業應用2方面進行驗證.其中，觸發程序是指實現跨APP組件間隱私泄露的6組APP集合，此類應用程序沒有多余干擾路徑，主要是為了驗證PLDetect功能而開發的應用程序.這些應用程序包含Activity, Service, Broadcast Receiver等不同的Android組件.如表1所示.商業應用是指在360 Market中隨機選擇的81個真實應用，部分應用程序信息如表2所示.

Table 1 The Sets of Triggered Program表1 觸發程序測試集

Table 2 The Sets of Business Application表2 商業應用測試集

3.1 觸發應用

如表1所示，為了驗證PLDetect系統功能的有效性，本文共構造了6組實現跨APP組件間隱私泄露的觸發程序，這些觸發程序中沒有設置多余干擾檢測的組件與路徑.我們通過人工對比PLDetect的檢測結果與預設的泄露隱私路徑，從而驗證PLDetect對跨APP組件間隱私泄露的檢測效果.

經過PLDetect分析，表1中6組(共8個)觸發程序的分類結果為：SourceApp類別的Android APP有G1和G2；SinkApp類別的Android APP有L1，L2，…，L6；SourceOrSink類別中沒有Android APP.在分類結果的基礎上，我們可以得到的潛在泄露隱私的APP組合序列共計12組，如圖6所示.

Fig. 6 The comparison of test results圖6 檢測結果對比

PLDetect分析得到，12組潛在泄露隱私的APP組合序列中存在6組Android APP能夠泄露隱私信息，并輸出泄露隱私的路徑.經過人工比較PLDetect的檢測結果與預設的泄露隱私的路徑，兩者完全一致，正確率達100%.

3.2 商業應用

在我們選取的實際商用Android APP中，平均每個應用程序包含組件高達134個，面對平均134個組件間錯綜復雜的關系，很容易影響PLDetect的檢測結果.因此，為了進一步驗證PLDetect的檢測效果，選取了81個真實應用作為實驗對象.

Fig. 7 The results of classification圖7 分類結果

根據2.2節的分類規則，PLDetect得到的分類數據如圖7所示，組件exported屬性值為true的數目為2 301個，占組件總數10 815的21.28%.其中，29個應用程序包含exported屬性值為true的組件，即此29個Android APP能夠被第三方應用程序調用；10個應用程序包含有隱式intent或顯式調用第三方應用程序的組件，即此10個Android APP能夠調用第三方應用程序；42個應用程序既包含exported屬性為true的組件，同時能夠調用第三方應用程序.實驗結果說明52%的應用程序同時具備SourceApp與SinkApp的特點，將成為泄露隱私信息的重要組成部分.

進一步地，PLDetect對獲取隱私和泄露隱私的API進行了統計.結果顯示，在獲取隱私的API中，getLongitude和getLatitude被使用的次數最多，達到了1 834次，如表3所示；在泄露隱私的API中，Log被使用的次數最多，高達66 711次，如表4所示.根據上述數據推測，隨著位置探測設備和地理位置信息系統的開發、應用及推廣，使得基于位置信息服務(location-based service， LBS)的Android應用程序越來越多，百度地圖、微信、滴滴打車等常用Android應用程序都需要位置的支持.因此，Android應用程序中使用getLongitude和getLatitude次數非常多，同時導致位置信息泄露的威脅增大.Log能夠輸出程序的中間結果，是調試Android APP的一種常用手段，但是，上述數據顯示Log的使用次數過多，可能是由于程序員在調試后沒有刪除Log代碼，導致Log遺留在Andorid APP中，從而造成隱私信息泄露的威脅增大.

Table 3 The Sets of API to Get Privacy Information表3 獲取隱私的API

Table 4 The Sets of API to Leak Privacy Information表4 泄露隱私的API

其次，以PLDetect發現的1個具體實例來描述跨APP組件間隱私泄露的細節.PLDetect檢測發現com.pdswp.su.smartcalendar和com.xkfop.xhuioa能夠合作實現跨APP組件間隱私泄露.其中com.pdswp.su.smartcalendar中用戶輸入的備忘錄內容被com.xkfop.xhuioa劫持，導致備忘錄內容被com.xkfop.xhuioa泄露.具體分析為：1)通過com.pdswp.su.smartcalendar.bean.NoteItemBean類中的方法getNote得到備忘錄內容，并將備忘錄內容賦給putExtra方法的參數；2)通過startActivity傳遞出去，被com.xkfop.xhuioa中的類com.xkfop.sendService的getIntent方法得到參數android.intent.extra.TEXT的值，并通過sendTextMessage將備忘錄內容泄露.

PLDetect在這81個真實應用中共識別和檢測到5組跨APP組件間隱私泄露程序.通過統計PLDetect發現的這5組存在跨APP組件間隱私泄露情況的程序包發現其中通過Activity泄露隱私信息的為2個，通過Service泄露隱私信息的為3個，通過Broadcast Receiver泄露隱私信息的為0個.理論上Service組件隱藏在后臺運行，不會與用戶進行交互，相對來說難以引起用戶的注意.實驗數據顯示，Service組件更容易被惡意軟件利用而引發隱私泄露，與理論分析一致.

PLDetect檢測到僅有少量的APP組合存在跨APP組件間隱私泄露問題，主要原因在于：360 Market中的APP基本都屬于良性應用程序，即使在一般條件下存在ICC漏洞的良性應用程序較多，但是通過2個良性APP配合達到泄露隱私信息的可能性非常低.更多的情況是，APP組合中一個為惡意軟件，另外一個則是存在ICC漏洞的良性APP，而據ComDroid研究證明，60%的應用程序至少存在1個以上的ICC漏洞.因此，在真實的用戶使用環境中將存在更多的跨APP組件間隱私泄露攻擊情況.

4 結論與工作展望

本文設計并實現了一個檢測跨APP組件間隱私泄露的自動化工具PLDetect.PLDetect有效地去除了與跨組件間隱私泄露無關的組件，并將虛擬主函數和插樁技術進行了有效結合，解決了在構建CFG時出現的路徑爆炸以及代碼不連續性問題.最終PLDetect實現了通過靜態污點分析技術檢測和識別與跨APP組件間隱私泄露相關的路徑.實驗表明該系統能夠有效發現和阻止跨APP組件間隱私泄露問題.

本文重點研究了跨APP組件間隱私泄露的檢測和防護方法，實驗評估體現了該系統的有效性.其他相關問題，例如對復雜且較少用到的ICC方法的分析、用戶體驗與隱私泄露之間的權衡等，將在今后的工作中進一步探索.