原文鏈接：http://people.csail.mit.edu/mjulia/publications/Covert_Communication_in_Mobile_Applications_2015.pdf

原文題目：Covert Communication in Mobile Applications

手機應用中的隱祕通信

Julia Rubin_, Michael I. Gordon_, Nguyen Nguyenx andMartin Rinard_

_Massachusetts Institute of Technology, USA, xGlobalInfoTek, Inc, USA

[email protected], [email protected], [email protected], [email protected]

摘要：這篇文章是研究手機應用中的通信模型。我們分析發現，在GooglePlay的最流行的免費的安卓應用中會產生63%的額外鏈接。爲了以一個有效的方式去檢測這些隱祕通信，我們提出了一個高精度和可擴展的靜態分析技術，它實現了91%的精確度和63%和以經驗爲主的判斷進行召回比較，並且能在幾分鐘之內運行完成。此外根據人們的評價，在47個案例中有42個，禁用通過我們分析出的隱祕通信，這些應用程序可以完好的運行，或者只有微不足道的接口受到了干擾。我們推斷我們的技術在識別和禁用隱祕通信上是有效的。我們又用這個技術來研究GooglePlay上前500個應用程序的通信模式。

簡介

移動應用程序享有幾乎永久的連接，並且它們能夠通過自己的後臺或者第三方服務器交換信息，這篇論文說明這些連接對於用戶來說並不能產生有形的價值：因爲禁用這些連接仍然能夠完整的使用程序的功能。但是，這些隱祕通信的產生會伴隨着其他的損失，比如隱私泄露，帶寬佔用，電量消耗等，並且還會存在一些不被懷疑的鏈接在設備和遠程組織機構當中。事實上，我們觀察這些比較流行的應用程序，比如沃爾瑪和推特，它們會產生大量的隱祕連接即使在不使用這些應用程序的情況下，在用戶無意識的情況下在後臺產生這些服務。

這篇論文主要在於區分對於用戶功能產生明顯影響的顯示連接和那些隱藏的或在用戶角度不希望產生的隱式連接。我們從分析GooglePlay應用市場中比較受歡迎的鏈接模型開始。我們發現這些應用程序中存在大量有動機的隱祕連接，我們開發了一個高精度可擴展的靜態分析算法來動態的識別這些連接。我們使用我們的算法來進一步的研究這一不好的現象並且報告的我們的發現。下面這些問題來推進我們的研究：

RQ1：這些隱祕連接的發送頻率怎麼樣？我們對GooglePaly前13名的應用程序（推特，沃爾瑪，Spotify，潘多拉等）進行了經驗式的研究主要是調查它們產生的自然連接。對於這些應用程序觸發的每一個連接，我們屏蔽掉這些連接之後動態執行原始的應用程序。

我們考慮應用程序產生的所有可視化內容，包括必要的廣告，避免任何與用戶信息相

關性的主觀判斷。也就是說，我們考慮應用程序執行的等價物，如果他們只有上下文

信息有區別，比如說廣告信息的內容或者社交網絡應用程序裏的信息如Twitter。

我們的研究顯示63%的鏈接內容是隱祕的-----禁止這些連接不會明顯的影響應用程序的實際功能。有意思的是，這些應用程序裏面少於一半的隱祕連接與發起已知的廣告和數據分析包一致。因此，只看數據包的信息去區別隱祕和非隱祕連接是不夠的。

RQ2：隱祕信息可以被靜態的檢測嗎？詳細調查隱祕連接的多種檢測案例啓發我們去開發一個新奇的靜態應用程序可以自動的去檢測這些連接。這個在我們分析之後的核心觀念就是我們尋找這種案例在連接的成功和失敗的結果的都被默默的忽視後，也就是說沒有任何信息呈送給用戶通知該連接是成功還是失敗。

對於一個連接聲明，我們分析程序的控制流圖的部分來對應直接處理的鏈接。這包括向前的堆棧處理和失敗處理。前者是連接聲明後可達成的非異常執行，但限於Android運行時事件觸發連接語句處理後。後者所有的遍歷方法是調用堆棧所有的鏈接語句，但是由於連接語句所引起的停靠點異常和所有相關重新拋出的異常除外。連接調用的直接處理是搜索方法調用裝置，可以針對一組預處理的API調用，影響用戶界面。如果發現一個調用，這個連接就被定義爲非隱祕連接。此外，如果這個連接被實時的傳送給安卓（引起應用程序的退出），這樣的鏈接調用也被定義爲非隱祕連接。除此之外，定義爲隱祕性連接。

把一個連接錯誤分類成隱祕連接的分析有兩個原因。第一，它確實不能考慮到由外部直接連接但是確實由本地或遠程連接語句引起的用戶界面的更新。第二，直接處理自身的語義被應用程序字節代碼單獨定義，也就是說它不包括本地代碼和中間應用程序執行。實驗表明這些情況是罕見的，加上該技術的高擴展性，證明是我們設計的合理選擇。

RQ3:靜態偵測的情況如何？爲了評價靜態分析技術的準確度，我們在深層次的全面的動態學習的已經制定的事實集合上進行描述。結果顯示我們的技術有很高的精確度：93%的隱祕連接被靜態分析通過動態學習精確的識別出來。而且即使這個技術被保守設計，偏向高精度超過高召回的，它仍然能在所研究的應用程序裏達到61%的精確度。

只有兩個連接被錯誤的識別成隱祕連接，都是由於上面提出的原因。第一個出現是由於用戶界面更新-----在這種情況下呈現出可以從GooglePaly下載的額外的應用程序的圖標---發生在直接處理的外部連接上。第二個是因爲爲了呈現通過安裝在設備上的Google Ads組件所產生的廣告材料，原因是由於直接處理安裝在設備上的谷歌服務器的不可延伸的異步的遠程掉用通信的鏈接。

爲了進一步的觀察這個技術的質量，我們把它應用到附加的GooglePlay最受歡迎的應用程序上。對於這些應用程序，我們禁用通過分析所定義的所有隱祕鏈接。然後我們僱傭人員去完成可用的評價：我們提供兩臺完全相同的設備，一個運行原始的應用程序，第一個運行修改後的版本。我們要求他們跟蹤和報告在這兩臺設備上所運行的應用程序的任何可以觀察出來的區別。

這個評估結果是鼓舞人心的：有63.8%的應用程序沒有明顯區別（30種）。25.6%的應用程序（12種），區別與用戶功能性無關，比如說廣告和裝飾性圖片。只有10.6%的應用程序（5種）

缺少用戶需要的主要功能特性。這個結果表明我們輸出的靜態分析產品可以剔除很多隱祕通信。

RQ4：在實際的應用程序中隱祕連接所產生的頻率是多少，它們最主要的共同來源是什麼？我們應用這個分析方法在GooglePlay最後歡迎的500個應用程序上，這個實驗表明有46%的連接語句被定義爲隱祕連接。隱祕連接最主要的共同來源是Google服務器和各種各樣的A&A服務。然而，這不是隱祕連接獨有的來源，從這些包裏面產生的鏈接也並不都是隱祕連接。

這項工作的重要性：在[1][2][3]的參考文獻裏，作者表明“系統應該連續不斷的通知用戶它們正在做什麼”。通過這個原理的激發，我們的工作就是識別用戶對應用程序隱藏的功能。這篇文章的研究範圍是從受歡迎的應用市場下載應用程序並且被千萬用戶安裝開始。我們相信我們的發現有助於提高移動通信領域的透明性和可信性。

貢獻：這篇文章產生以下貢獻，

1）它在自動化方式識別隱祕和非隱祕連接中設置了一個新問題。

2）它提議了一個半自動的檢測方法用於檢測安卓程序中的隱祕連接。這個方法應用在交互式注入連接失敗的應用程序中，識別這些注入連接是否明顯的影響應用程序否功能。

3）它提供了一些在實際應用程序中比較流行的隱祕連接的經驗的證明。特別地，它顯示在GooglePlay前13的最流行的應用程序中有63%的鏈接企圖落入這一分類。

4）它提出一個二進制技術在應用程序二進制文件上識別隱祕連接。這項技術有高科擴展性和高精確度：在GooglePlay 47個受歡迎的應用程序中，當屏蔽掉通過該技術所定義的隱祕連接時，63.8%的工作沒有產生任何干擾，25.6%的工作產生了非常不重要的影響。這項技術在通過動態確定的真值集合中進行評估時仍然表現出93%的精確度和61%的召回。

5）它對GooglePlay前500的受歡迎的免費的應用程序提出了定量實證和識別它們的共同模型。

Android 裏的通信

這一節，我們對安卓程序最本質的通信表現的研究設計進行了描述。現在，我們開始

討論研究結果：

A．研究的設計

1）連接語句：

表1 列出了我們這篇文章需要考慮的鏈接語句的基本分類和方法，我們當然也包括了表中列出的子類。

當發生一個連接失敗，舉個例子，當所需的服務器沒能得到或者服務器斷開或手機處於飛行模式。這個方法就會拋出一個java.io.IOException異常。因此，爲了調查這個連接對於應用程序整體行爲的意義所在，我們通過替換連接語句否拋出異常的語句注入一個失敗的鏈接。這種方法通過關閉應用程序本地處理異常的進程，因此要儘可能的減少我們的操作所產生的副作用。

2）應用程序啓動

作爲我們研究的輸入，我們假定應用程序向我們提供apk文件。我們使用dex2jar工具套裝從apk中提取jar包文件。我們使用ASM框架實現兩個類型的替換。

l 對於產生原始應用程序記錄所有連接（表一中列出的）日誌的監控替換。

l 指定獲得連接語句失敗列表的額外輸入配置文件的阻塞替換。然後產生一個指定連接語句被拋出異常語句替換的原始應用程序版本。

這個jar文件通過dex2jar工具套被重新安裝回apk並且使用標準分佈式Java JDK的jarsigner工具寫上我們自己的簽名。由於我們都知道的重新簽名應用程序的副作用，它們的Google Plus APIs身份驗證可能會被破壞。因此，用戶可能不能註冊GooglePlus賬戶和執行程序內的購買操作。由於這個原因，在我們的分析中迴避這樣的操作。

TVBLE1CONSIDERED CONNECTION STATEMENTS.

Class or Interface

Method

java.net.URL

java.net.URLConnection org.apache.http.client.HttpClient java.net.Socket

openConnection

connect execute getOutputStream

3）自動的應用程序執行和比較

比較可觀察的用戶的行爲需要動態的執行所分析的應用程序。執行比較的最主要障礙是以可重複的方式複製程序執行的能力。爲了克服這一障礙，我們寫了一個腳本可以自動的執行每一個程序。

我們用Android’s Monkey tool進行試驗，但是由於它會通過應用程序外部所研究的應用程序不能被處理的手勢迅速的鎖死自身，它不能提供一個合理的詳盡的覆

蓋。

我們因此手動的記錄所期望的應用程序的執行情況，包括記錄用戶被應用程序要求輸入的任何語義，例如，用戶名和密碼。我們使用安卓getevent來捕獲用戶和核

心所有的輸入事件。我們確保用戶手勢之間的停頓，假定應用程序相應。我們通過getevent強化了腳本在每一個停頓和延長的序列之間加入了屏幕捕捉命令。

比較應用程序的執行，我們開始於兩個並行執行的應用程序的截屏，比較兩個圖片的外觀上的區別，如圖1.展示的是沃爾瑪應用程序的。我們使用ImageMagick工具去自動卻別兩張不同的圖片。然後我們手動的掃描產生的輸出忽略的小部件以動態方式產生的內容填充差異，因爲這些小部件將期望區別不同程序之間的運行。也就是說，我們忽視廣告信息的精確內容（但並不是它們的整體存在/缺失和位置信息），社交網絡的內容，比如推文，設備的狀態，比如精確的時間。因此圖片1（a）和圖片1（b）被視爲相似的：它們只有廣告信息和狀態欄的通知信息不一樣。

Fig.1.Visual differents

在所分析案例的一種情況下，我們不得不回覆到手工運行程序的執行和比較。這種情況涉及到需要迅速響應時間的視覺遊戲的交互，因此程序自動執行不能提供可靠的結果。

4）執行方法

我們分三個階段完成我們的研究。第一個階段，我們在Nexus 4，安卓版本爲4.4.4的移動設備上安裝我們所要分析的應用程序的原始版本。我們手動運行每一個應用程序大約十分鐘，探索它們對我們的可見功能。我們的目標是(a)實現足夠的覆蓋和(b)保持應用程序足夠的活躍時間允許任何一個背景數據提取顯示在程序交互界面。然而我們避免執行註冊Google Plus賬戶和程序內購買相關操作，原因是重新簽名限制了上述提到的操作。我們記錄所有捕獲觸發操作的執行腳本。然後我們重新安裝程序重新運行腳本來收集我們要作爲基線進行進一步比較的屏幕截圖。

第二階段，我們使用監控轉換產生一個新版本的應用程序，記錄現存的所有信息和觸發鏈接的聲明。我們運行這個使用記錄執行腳本和收集連接語句統計數據的版本。

最後一個階段，我們重複所有的觸發的連接語句，逐一的禁用它們，爲了評估每一個連接對於用戶可見功能的必要性。也就是說，我們在一個列表裏按字典順序排列所有的連接語句，然後使用阻塞轉換禁用列表裏的第一個連接語句。我們運行使用記錄執行腳本和獲取程序執行的屏幕截圖的改造版本的應用程序。如果禁用該連接語句不影響應用程序的行爲，我們就將其標識爲"隱祕"。並在隨後的迭代中禁用它，然後進行列表中的下一個連接。否則的話，我們標記這個執行的連接爲顯示的，使它在接下來的迭代序列中保持可用。我們繼續這一過程，直到列表中所有的連接都被測試過。

作爲最後的質量檢測，我們手動檢測所有隱式連接被阻塞後的版本程序的執行情況，去檢測自動分析每一個可能錯過的問題。

5）主題

關於我們研究的主題，我們下載了2014年11月Google Play前20名最受歡迎的可得到的應用程序。我們排除列表裏的聊天應用程序，因爲我們的評估方法不允許我們評估沒有可預測聊天對象的聊天應用程序。我們同樣排除基於ASM啓動失敗的應用程序，很有可能它們使用的語言設計不支持這種架構。剩下的13個應用程序在表二2的第一列列出；它們相應的歸檔的代碼字節碼大小在表格的第二列給出。

TABLE II. ANALYZEDAPPLICATION

B.結果

研究的定量結果在表格2呈現出。3,4列僅僅展示出小數量的重新編碼的事實上是動態觸發的連接語句。一些非觸發式的語句的相應的執行路徑通過我們的動態程序遍歷是檢測不到的。然而，大多數的連接語句包含在應用程序所引用的第三方庫中，例如，Google和Facebook提供給移動開發者的服務器，和各種各樣的A&A數據庫。這些數據庫經常被應用程序部分的使用，這可以解釋不完全覆蓋性。

一個有趣的案例是Facebook應用程序（表2的第5行），排除Facebook，因爲它大部分的應用程序代碼是在運行時態加載APK文件資源。我們的分析無法遍歷這些自定義的資源，因此我們排除了這一應用程序的進一步分析，並指出，在應用程序中唯一的三個連接語句並沒有被觸發。我們同樣排除Candy Crush Saga 應用程序（表2第8行）的進一步分析，因爲它沒有表現出任何隱祕連接。

1）觸發語句否分類

確定這些隱祕連接的原始目的是一個不平凡的任務，因爲它們的本質，它們不表現出任何可觀察的行爲。由於混淆，幾乎沒有語義表明可以從這些應用程序的二進制文件中手動分析出它們的目的。企圖查明這些隱祕連接的一點本質，我們檢測數據包和類名也執行堆棧跟蹤。我們也檢測這些連接相應的數據流量，通過通過使用代理的路由通信，嗅探數據，解密套接協議層的編碼，如果需要的話。

我們發現52個連接中有隻有22個（43%）來自於A&A數據庫，如表的最後一列所示。另外11個（21%）連接也是由於A&A內容需要產生的。然而，它們要麼來自於特殊的數據包，要麼來自於不能被立即連接到A&A的第三方數據庫。舉例，沃爾瑪應用程序從com/walmartlabs/analytics/數據包觸發一個隱式連接，這似乎是一個專有的分析服務。

收集關於應用程序性能的信息,分析服務崩潰和使用數據,以及應用程序內的用戶執行的操作。雖然這些信息對於開發人員有一個明確的價值，但是它卻沒有明顯的描述指定的性質和收集呈獻給用戶的頻繁數據。事實上，許多應用程序在在活動之前就開始蒐集數據信息。比如，推特，沃爾瑪，潘多拉在手機整個運行時間只要手機一啓動就開始定期收集信息，甚至在程序本身從來沒有被使用過的情況下。在大多數情況下，用戶除非卸載程序否則不能選擇停止這些數據的分享。

除了A&A，多種應用程序向自身或第三方服務器傳送數據，不會在應用程序上產生任何明顯的行爲。比如，Twitter使用隱祕鏈接手機視頻和伴隨用戶發送的推文的富媒體附件。GOKeyboard 應用程序通過隱祕連接向launchermsg.3g.cn發送大量的ID，它也會向nextbrowser.goforandroid.com發送一些我們不能破譯的加密數據。潘多拉和Spotify音樂播放器都使用Facebook的社交網絡服務，發送應用程序的使用信息。另一個例子，沃爾瑪應用程序合併Red Laser（一個專門比較價格的eBay公司）提供的條形碼掃描庫。這個庫可以使應用程序發送掃面的條形碼信息到data.redlaser.com服務器。然而阻塞這一信息的發送並不影響掃描功能。

回答RQ1：我們推斷隱祕連接在實際使用的應用程序中經常產生：有62.9%的觸發鏈接語句可以被定義爲隱祕連接。

2）經驗教訓

如表2的最後一列所示，只有43%的隱蔽連接起源於我們所知道的A&A數據庫。因此僅僅通過考慮包名的模式區別隱祕和非隱祕連接是無效的。而且，很多惡意的應用程序故意通過看起來合法和良性的包名隱藏它們的字節碼數據。我們推斷一個用於識別隱祕連接的更精緻的技術是急需的。

爲了對隱祕連接的實現模式獲得更多的見解，我們手動的研究所要分析的應用程序否的二進制文件。我們發現，無論這些連接成功或是失敗都不會對用戶產生視覺上的告知。對於失敗的鏈接所觸發的異常經常被捕獲或者被該問題連接悄悄忽略，或者更普遍的這個異常被向上傳播的調用堆棧然後被另一個調用方法忽略。在一些情況下，錯誤或警告的信息會被寫到Android日誌文件裏。然而這些信息基本上是被開發者使用而不是終端用戶。

回答RQ2：我們推測隱祕連接可以通過連接語句成功和失敗的用戶界面元素的更新的檢測中識別出來。這些用戶界面更新的確實象徵着用戶對於通信的成功失敗的結果是無意識的操作的連接是隱祕的。

靜態分析分類連接

在這一部分，我們將描述我們試圖分類連接的靜態分析算法。Android應用程序是JAVA作爲一系列的外部事件處理程序開發的，如按鈕點擊和應用程序退出。給定一個安卓應用程序，靜態分析分類每一個可能喚醒隱祕或非隱祕連接調用的語句。我們一通過分析假設的一個給定的精確的隱祕和非隱祕的連接開始。

定義（隱祕和非隱祕連接）

對於一個連接語句s,s滿足下述的至少一個條件就被定義爲非隱祕連接。

1) 連接失敗時用戶界面提示失敗： 當s觸發一個異常e,在進行故障處理s的e的期間，用戶會通過用戶界面得到失敗提示。

2) 連接失敗時程序退出：當s觸發一個異常e,由於傳播異常e恢復到安卓運行時，程序可能會停止執行。

3) 連接成功時用戶界面提示：當s連接成功時，它會在(a)應用程序處理下一個外部事件或者(b)除了失敗處理s外繼續處理之前，在用戶界面生成一個可能的修飾。

相反的，一個隱祕連接不滿足任何一種情況。

故障處理在段落Section III-B精確給出定義。直觀的，連接語句s的異常類型e的故障處理是處理e和任何通過處理e觸發的故障（通過再次拋出異常）的計算路徑。當e觸發是所有異常被處理完並回到正常的操作故障處理結束。

接下來，我們討論怎樣計算以安卓應用程序中每個調用表達式爲目標的表示可能的方法的靜態調用圖。然後我們在這張圖上討論我們的分析。對於每一個連接。分析由三部組成：故障處理器分析，成功前進分析和成功後退分析。

表1列出了被視爲連接調用的目標方法。被視爲影響用戶界面的目標方法在表3（也

包含所有的重載方法）中列出。

A.對安卓應用程序構建一個準確的調用圖

對安卓應用程序的靜態分析是出了名的困難，因爲安卓實時的動態和複雜性的本質和API；精確地，全面的分析有着錯失動態程序行爲的高風險而且不能擴展到現實世界真正使用的應用程序當中。靜態分析要麼模擬安卓執行環境要麼對可能的程序動態行爲做出解釋都是保守的分析選擇；否則的話，一些運行時的動態行爲就可能會被

忽視。

我們的分析比較接近應用程序運行時的行爲，不接近可能是隱祕的連接調用。這個分析的優先次序是高精確性超過高召回，原因是我們不想阻擋非隱蔽通信所執行的連接調用。我們的分析使用類層次結構分析（CHA）去建立一個通過內部程序，數據流實現的精緻的調用圖，作爲稍後討論。大量的高精度的實驗之後，雖然脆弱，但針對於分析技術而言，這個分析組合給了我們分析任務的最好性能。我們的分析在Soot分析框架中實現，使用DroidSafe提供的安卓API模型。我們的分析在應用程序是Jimple中間語言描述的程序上性能表現是較低的。

爲了計算調用圖，我們通過DroidSafe安卓設備接口（ADI）增加應用程序代碼。這個安卓設備接口是基於JAVA的安卓運行模型和API。它試圖表達運行時一般使用類的完整的運行環境語義。我們的調用圖從每一個可能成爲安卓運行時目標的應用程序方法開始構建，也就是，應用程序的事件處理器方法。調用圖形構建並不能遍歷安卓API方法。像這樣，這個調用圖實際上是一個樹形圖標，根節點是應用程序的事件處理器，每個圖表包含只有應用程序定義的方法。然而，我們發現說明API調用是直接調用迴應用程序的調用是必要的，舉例，Thread.start()。我們通過用API調用可能引起的直接調用應用程序的方法（比如Thread.run()）來替換API調用來實現。這個調用圖通過下面的方針來增強說明反射方法調用。當一個反射調用被發現，我們添加以所有相同包域作爲調用者的所有方法爲目標的圖標（例如，com.google, com .facebook）。這個邊緣被下述策略修剪：如果參數的數目和參數類型可以使用定義分析定義，我們限制邊緣僅僅以有相同數目或類型的參數爲目標。這種策略在實際中效果很好，並能積極地反映語義。

B.故障處理器分析

故障分析決定在一個連接異常時是否能改變UI或退出程序。我們組織靜態故障處理分析在調用圖上作爲一個循環遍歷。對所有應用程序調用迭代器分析分別每個可能成爲應用程序連接調用的目標的語句和通信失敗顯示的異常。

從概念上講，s上的異常e的故障處理被定義爲一片指令。在這一部分中，所有的語句可以從可以處理異常e的catch塊中獲得。然後，對於在這一部分內每一個可獲得的語句可以拋出一個f類型的異常，我們遞歸的向這部分中添加所有可以從可以動態的處理f catch塊中得到的語句。接下來，我們動態處理這些可以拋出一個異常的新添加的語句。在這個過程中，安卓API方法是不被考慮的，搜索處理器不會傳送到安卓實時環境中。

分析從圖片2列出的FINDCATCHES步驟開始。它使用了一些輔助步驟，及特別性的一個在圖片4中列出，完整的列表可以在參考文獻[19]中找到。FINDCATCHES分別被每一個連接語句和一對異常調用。進程參數也包括stmt的封閉方法（甲基）；當前的訪問語句和異常（正在訪問的）初始化清空；當向前搜索調用圖（堆棧）路徑的時候，調用堆棧建立，初始化清空。

對於stmt和ex，程序首先諮詢stmt正在包含的方法去找一個合適的catch（第四行）。如果ex並沒有在本地捕獲，meth是一個時間處理器（從安卓運行時調用的,然後我們保守計算，stmt可能造成應用程序退出，然後將其添加到非隱祕集合（6-9行）。否則的話這個分析方法就會遞歸訪問所有直接調用的方法去發現可以捕捉調用圖邊緣的catch塊（10-21行），正如稍後所討論的。

如果一個兼容的處理器在本地本發現（24-26行），這個分析調用步驟ANALYZEHANDLER，圖3，兼容塊的語句。這個步驟分析可獲得的處理器的語句。如果一個可以觸發UI方法的調用是也遇到的，這個語句自從故障處理影響用戶界面後開始被處理器分析爲非隱祕的（圖3 7-9行）。如果分析發現調用本地方法，我們假設這個方法會拋出定義拋出的所有異常，處理器會對每一個已經聲明拋出的異常產卵式的生成FINDCATCHES實例（10-13行）。當這個分析發現一個應用程序方法的調用，它會推進當前的語句和方法到一個堆棧上，爲這些新方法遞歸的調用自身去分析新方法的語句（14-20行）。

如果分析發現一個throw語句，它會產生一個新的FINDCATCHES分析去發現所有可能的每一個重新拋出異常的處理器（22-42行）。朝向這個的結束，它首先計算本地連鎖定義獲得的異常類型。在第23-34行，分析認爲所有本地達到被拋出價值的def。如果一個分配的語句到達throw，那麼就把這個類型添加到可能重新拋出異常的類型。若果捕獲到一個異常參考c，達到throw語句，然後與c catch塊有關的try塊，然後就會被所有可能被拋出的受檢測的異常分析。這個通過GETPOSSIBLETHROWNTYPES調用ANALYZEHANDLER的29行執行。如果只有配置和捕獲到的異常達到拋出價值，這個處理器分析就會排卵式產生FINDCATCHES實例去分析故障處理。

一個成對的方法調用語句的堆棧和目標方法是被保持的。這個方法使用堆棧在FINDCATCHES中在一個方法調用被處理器進一步執行到堆棧之後集中處理器搜索（圖2 的11-15行）。當我們初始化一個連接調用的分析，這個堆棧是空的，並且FINDCATCHES分析去搜索連接語句異常處理器所有可能的堆棧（包含方法的前身）。然而，一旦一個處理器被發現，這個處理器調用一個以可能重新拋出異常告終的方法序列，這個方法的序列定義了唯一可以尋找重新拋出異常處理器的堆棧（11行）。

這個堆棧爲了每一個可達成處理器代碼的方法調用在ANALYZEHANDLER的16行被推進。在處理器在FINDCATCHES中尋找執行堆棧期間，這個堆棧被諮詢去引導在11行中搜索，只訪問在最前面的堆棧的邊緣。當在FINDCATCHES 的15行的當前方法中訪問一個調用方法時，這個堆棧被取出。

C.成功度分析

對於連接語句stmt，在失敗處理和堆棧處理stmt的異常期間，沒有用戶界面調用被喚醒，這個分析就繼續沿着stmt的成功路徑。這個成功分析決定如果在連接成功之後，在控制回到安卓運行時環境之前，在控制合併之前有任何一個用戶界面修改，回到失敗處理路徑。

這裏我們總結了緊閉在方法meth內的連接調用stmt的成功分析通過呈現兩個高水平的在構思階段的描述：

1)成功正向分析

在stmt之後的語句可獲得的代碼被用來尋找一個連接調用。這是通過遍歷起始於stmt和跟隨方法通過調用圖表達式的過程控制流圖（CFG）中的所有路徑完成的。在分析CFG時，我們即跟隨正常的也跟隨異常的控制路徑。

2)成功逆向分析

對於所有的方法，調用，在調用圖中從調用到meth的一個路徑，在失敗處理分析中尋找的調用器，檢查所有影響用戶界面調用的調用器的語句。這個有從UI調用的stmt的meth上遍歷調用圖的效果，在事件處理器停止，在一個路徑上，一旦stmt的異常被處理就會停止。

如果成功定向和逆向分析都沒有發現任何一個影響用戶界面的調用，這個連接調用就被定義爲隱祕的。

D.設計討論

我們靜態分析的直覺是，非隱祕的連接無論成功與失敗都會影響用戶界面。從第二段的研究中得到的另一個觀察是，正常的連接過程經常在異常和非異常控制流路徑合併時結束。因此，成功逆向分析只能測試被失敗分析算法分析的方法。而且，我們使用執行時間處理程序去限制連接呼叫處理。

實驗

我們從評估我們的靜態分析質量的技術開始。然後我們使用這個技術去收集Google Play中前500個最受歡迎的應用程序的隱祕連接的普遍模型的信息。

A.靜態分析的質量

我們首先，在我們深層次的案例研究已經確定的真實集合中（見第二部分），評價我們技術的準確度，也就是查準率和查全率。然後，通過一個可用的評價，在運行一個當所有被定義爲隱祕的連接都被禁用的應用程序的版本時，我們評價用戶實驗。

1）準確度

對於準確度的評估，我們再一次看一下表2的應用程序列表，排除Facebook和

CandyCrush因爲這些應用程序沒有顯示出任何隱祕連接。我們限制靜態分析對那些實際上是動態觸發的結果報告，因爲只有這些我們已經建立了比較正確的結果。我們評估這個結果，我們單獨的對每一個應用程序用下面的權值對所有的應用程序取平均值來評估這個結果：

l 查準率：通過技術被定義爲隱祕連接的分數

l 查全率：我們期望被定義爲隱蔽連接也就是說在動態的連接當中被標記爲隱祕的連接的分數。

l 執行時間：此處列出在什麼樣的設備配置上測出的執行時間。

這個實驗的結果總結概括在表4。表的第二列顯示我們分析的整體平均查準率爲93.2%。除了兩個隱祕連接分析都正確的識別出來了。第一個，在com.devuni.flashlight裏，負責呈現應用程序可以從Google Play下載的擴展標緻。這個失敗的原因在於這個標緻的用戶界面更新在成功和失敗的統一的路徑之後，因此被我們的研究錯過了。

第二個分類錯誤的連接在net.zedge.android裏，負責呈現廣告材料，屬於應用程序A&A服務包的com.mopub.mobileads。

這個數據庫依賴安裝在相同設備上的Google服務的RPC通信。我們的分析目的並不在於追蹤不同應用程序之間和設備上的服務之間的程序見的通信，因此這個結果是錯誤是積極的。

雖然我們的分析是保守設計的，它能正確識別在實證研究中被確定爲隱祕連接（表4的第三列）的61.5%。我們不能實現更高的查全率的主要原因是：（1）保守的，雖然分析切實可行，與連接調用有關的直接處理定義和（2）保守的調用圖形構建，特別的，w.r.t.反射。這樣的解決方案與我們提供可操作的結果的目標對準，雖然在近似的水平之下他們也是安全的。

最後，這個分析是高效率的，即使在大量的應用程序之下在幾分鐘內就能運行完，正如表4 的最後一列所展示的。

2）可用性評估

爲了檢測我們的技術是否能夠提供可靠的結果，我們挑選了2015年1月和5月GooglePlay前500的最受歡迎的免費的應用程序中都出現的100個應用程序。我們安裝每一個應用程序的原始版本在Nexus，安卓版本爲4.4.4的設備上。在另一個同樣的設備上，我們安裝使用塊替換（見第二部分）使通過我們的靜態分析定義爲隱祕連接失效的應用程序。

我們招募了兩名人工，他們都是經驗豐富的軟件開發人員，也是這篇論文的作者之一。每一個人給一個安裝原始版本的設備和一個安裝修改後版本的應用程序的設備。我們要求他們在10分鐘內在兩臺設備上同時執行同樣的應用程序，然後記錄在執行期間所能觀察到的不同。和第二部分的實驗描述相似，我們的目標是確保足夠的覆蓋範圍和應用程序界面呈現後臺提取的數據。我們避免參與者註冊Google Plus賬戶和在Google Play store執行程序內購買，因爲這些操作不被重簽名的應用程序支持（如第二部分討論的那樣）。

TABLEIV． COMPARISON WRTH THE MANUALLY ESTABLISHEDRESULTS

爲了以一個可靠的方式分析實驗結果，我們排除了不可操作的（不能以原始版本或必要的支付方式繼續運行）14個應用程序；基於ASM的17個應用程序啓動失敗或由於重簽名的問題不能運行；2個Google應用程序我們不能重新安裝在一個設備上；5個聊天應用程序；4個不包含連接語句或沒有檢測到隱祕連接語句的應用程序和11個在應用程序執行期間沒有觸發隱祕連接的應用程序。

其餘的47個應用程序的信息在下面列出。

相同的：30（63.8%）。我們的參與者沒有發現任何可觀察到的不同在這30個應用程序中，這表明通過靜態分析被定義爲隱祕連接語句對應用程序的用戶可見行爲不產生任何影響。

缺失廣告：9（19.2%）。在9個案例中廣告信息缺失，和上面描述的Zedge例的原因一樣。

缺少次要功能：3（6.4%）。參與者觀察被視爲次要功能的性能的缺失：兩個案例缺少圖標，Talkingben和我們之前討論過的Flashlight；一個案例不能爲殺毒軟件創建一個賬戶，但是應用程序核心的功能是完整無缺的。

缺少必要的功能：5（10.6%）。只有5個應用程序缺少必要的功能：Battery Saver,Spider-Man andMinion Rush games, Microsoft Office Mobileand PicsArt Photo Studio。我們推測最後一個案例與重簽名的問題有關。其他情況源於我們靜態分析技術的限制：在程序內執行分析，忽視狀態性的通信和僅尋找在成功和失敗路徑統一之前的產生的語句的頁面的更新。我們相信這些案例是小數量的，加上我們分析算法的高擴展性，證明是很好的選擇。

平均看來，每個應用程序在運行時觸發2.6個（最小1；最大9；中數：2）隱祕連接。由於每個語句可能被多次執行，我們也統計了這些語句動態調用的所有實例，得到每個應用程序隱祕連接調用的實例是299（最小1；最大4011；中數11）。這高的平均數字是由於應用程序一旦安裝就持續在後臺運行，並且事實證明企圖網絡通信。這些應用程序的例子有com.cleanmaster.mguard 和com.ijinshan.kbatterydoctoren.。

回答問題3：我們推斷這篇論文中提出的靜態分析方法可以應用於隱祕連接準確的檢測。這個技術是精確的，高可擴展性的並且提供在絕大多數情況下可以用來直接禁用隱祕連接的可操作的輸出。

B.在外部的隱祕連接

我們接下來把我們的技術應用到2015年1月從Google Play應用市場下載的500個最受歡迎的應用程序中。通過考慮大數據集合，我們的目標是調查隱祕連接產生的頻率和它們共同的來源。

我們的分析揭露了應用程序所有的連接中有46.2%的連接被視爲隱祕連接（8,539/18,480）。Z這些結果，被證實有93%的查準率和61%的查全率，和我們第二部分實驗研究所描述的一致。

表5顯示了產生隱祕連接的前10名的包。由於我們分析的免費的應用程序頻繁的使用第三方的數據包，然後合計這500個應用程序的數字，並不驚訝谷歌服務器，gaming，和A&A服務器在列表的頂部，應用程序使用這些包的數字在表5的第三列中展示出。比較令人驚訝的是com.gameloft包（表5第二行），雖然它只是相同公司發佈的17個不同的移動應用程序的一部分，這些遊戲軟件隱祕連接的數字是值得引人注意的。

TABLEV. TOP 10 COVERT COMMUNICATION CALLERS

表5的最後一列展示了在相應的包中隱祕連接佔所有連接的百分比。這些數字在24%到87%之間不等，再一次，我們在第二部分中初步觀察，連接的來源不能用來推斷對應用程序行爲的影響。

回答問題4，我們推斷隱祕連接在真實的應用程序中是普遍的。這些連接不是A&A包

所獨有，而且這個包所產生的連接並不都是隱祕的。

有效性的限制和威脅

1)實證研究

我們的實證研究有一個動態的本質，因此遭受衆所周知的動態分析的限制：它不能提供一個應用程序行爲的詳盡的探索。雖然我們努力覆蓋所有應用程序對我們可見的功能性，我們也有可能錯過一些行爲，舉例來說，這些系統之下是觸發設置與我們不同。爲了使結果的意外性最小化，我們在一臺相同的設備上執行我們所有的動態試驗，在相同的位置和時間接近對方。我們也會自動地執行我們的腳本去比較在相同的場景和設置下不同的版本的行爲的不同。我僅僅對這些相似運行的比較結果做報告。

然而，由於動態分析的限制，我們可能遭遇假陽性的結果：一個我們分類爲隱祕的連接語句可能會對程序的一個位置部分產生影響。同時，我們可能也會有假陰性的結果：改變用戶界面的可能起源於非確定性的應用程序自身而不是通信的缺少。而且，通過集中於個體的連接語句，我們不能區別在多個應用程序之間相同代碼形式的語句的通信。我們因此保守的認爲只要一個連接至少對一個用戶行爲是非隱祕的就視爲非隱祕連接。爲識別隱祕連接探索更精準的技術可能成爲我們未來工作的一個課題。

最後，我們的研究僅僅包含一些數量有限的科目，所以這些結果不能推廣到其他的應用程序中。我們試圖通過不偏執的選擇應用程序而是從GooglePlay中選擇最受歡迎的應用程序來減輕這一問題，然後保證在所有的應用程序中觀察相同的通信模型。

2)檢測隱祕連接的靜態技術

我們的技術認爲隱祕狀態的通信切換通信連接的狀態，但是不向用戶呈現任何信息。在很多情況下，靜態的檢測這些通信是不可能的，因爲代碼的執行目標是不可知和不可得的。因爲同樣的原因，在這項工作中，我們不考慮安裝在相同設備上的PRC通信。

而且，我尋找通信的分析算法是以直接的方式影響應用程序的UI而不是通過其他來源間接地影響。在這些情況中擴展分析算法，維護自身的可擴展性和精確度，是我們接下來工作的另一個主題。

我們靜態的定義的一些隱祕連接可能永遠不會被動態的觸發，這些連接的一大部分都是起源於第三方庫，它們包含在應用程序中，卻只有一部分被使用。因此，由於這些代碼可能會被其他的應用程序所使用，所以分析它們仍然是有意義的。

結論

隱祕通信會損害設備操作的透明性，默默地消耗設備資源，最後會破壞用戶對移動設備應用程序生態系統的信任度。我們的分析顯示隱祕連接在Google Play最流行的安卓應用程序中是很普遍的。我們的成果顯示我們的分析可有有效的識別和取出隱祕連接並且促進更加透明和可靠的應用程序的發展。

參考文獻

[1] J. Nielsen and R. Molich, “Heuristic Evaluation ofUser Interfaces,” inProc. of the International Conference on Human Factors in CmputingSystems (CHI’90), 1990, pp. 249–256.

[2] M. H. Blackmon, P. G. Polson, M. Kitajima, and C. H.Lewis,“Cognitive Walkthrough for the Web,” in Proc. of the International Conferenceon Human Factors in Computing Systems (CHI’02), 2002,pp. 463–470.

[3] A. J. Ko and X. Zhang, “FeedLack Detects MissingFeedback in Web Applications,” in Proc. of the International Conference onHuman Factors in Computing Systems (CHI’11), 2011, pp. 2177–2186.

[4] dex2jar, “https://code.google.com/p/dex2jar/.”

[5] ASM Java Bytecode Manipulation and AnalysisFramework,“http://asm.ow2.org/.”

[6] Google APIs Console Help,“https://developers.google.com/console/help.”

[7] Android’s UI/Application Exerciseronkey,“http://developer.android.com/tools/help/monkey.html.”

[8] Android Getevent Tool,“https://source.android.com/devices/input/getevent.html.”

[9] P. Hornyack, S. Han, J. Jung, S. Schechter, and D.Wetherall, “These Aren’t the Droids You’re Looking for: Retrofitting Android toProtect Data from Imperious Applications,” in Proc. of the 18th ACM Conference onComputer and Communications Security (CCS’11), 2011, pp.639–652.

[10] ImageMagick Compare Tool,“http://www.imagemagick.org/script/compare.php.”

[11] Charles – an HTTP proxy / HTTP monitor / ReverseProxy,“http://www.charlesproxy.com/.”

[12] Facebook’s Social Graph, https://developers.facebook.com/docs/graphapi.

[13] Red Laser – an eBay company, “http://redlaser.com/.”

[14] Y. Zhou and X. Jiang, “Dissecting Android Malware:Characterization and Evolution,” in Proc. of the IEEE Symposium on Security andPrivacy (SP’12), 2012, pp. 95–109.

[15] J. Dean, D. Grove, and C. Chambers, “Optimization ofObject-Oriented Programs Using Static Class Hierarchy Analysis,” in Proc. ofthe 9^th European Conference on Object-Oriented Programming(ECOOP’95), 1995.

[16] R. Vall´ee-Rai, E. Gagnon, L. J. Hendren, P. Lam, P.Pominville, and V. Sundaresan, “Optimizing Java Bytecode Using the Soot Framework:Is It Feasible?” in Proc. of the 9th International Conference on Compiler Construction(CC’00), 2000, pp. 18–34.

[17] M. I. Gordon, D. Kim, J. Perkins, L. Gilham, N.Nguyen, and M. Rinard, “Information Flow Analysis of Android Applications inDroidSafe,” in Proc. of the 22nd Annual Network and Distributed System SecuritySymposium (NDSS’15), 2015.

[18] A. Aho, M. Lam, R. Sethi, and J. Ullman, Compilers:Principles,Techniques, and Tools, 2nd ed. Addison Wesley, 2006.

[19] Helper Function Definitions for the ConnectionAnalysis,“http://people.csail.mit.edu/mjulia/covert-helpers.pdf.”

[20] J. Huang, X. Zhang, L. Tan, P. Wang, and B. Liang,“AsDroid: Detecting Stealthy Behaviors in Android Applications by UserInterface and Program Behavior Contradiction,” in Proc. of the 36thInternational Conference on Software Engineering (ICSE’14), 2014.

[21] A. Gorla, I. Tavecchia, F. Gross, and A. Zeller,“Checking App Behavior against App Descriptions,” in Proc. of the 36thInternational Conference on Software Engineering (ICSE’14), 2014.

[22] K. O. Elish, D. D. Yao, and B. G. Ryder,“User-Centric Dependence Analysis for Identifying Malicious Mobile Apps,” inProc. of the IEEE Mobile Security Technologies Workshop (MoST’12), 2012.

[23] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung,P. McDaniel, and A. N. Sheth, “TaintDroid: An Information-flow Tracking System forRealtime Privacy Monitoring on Smartphones,” in Proc. of the 9^th USENIXConference on Operating Systems Design and Implementation (OSDI’10), 2010, pp.1–6.

[24] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A.Bartel, J. Klein, Y. L. Traon, D. Octeau, and P. McDaniel, “FlowDroid: PreciseContext, Flow, Field, Object-sensitive and Lifecycle-aware Taint Analysis forAndroid Apps,” in Proc. of the ACM SIGPLAN Conference on Programming LanguageDesign and Implementation (PLDI’14), 2014.

[25] W. Klieber, L. Flynn, A. Bhosale, L. Jia, and L.Bauer, “Android Taint Flow Analysis for App Sets,” in Proc. of the 3rd ACMSIGPLAN International Workshop on the State of the Art in Java Program Analysis(SOAP’14), 2014.

[26] L. Li, A. Bartel, J. Klein, Y. L. Traon, S. Arzt, S.Rasthofer, E. Bodden, D. Octeau, and P. McDaniel, “I Know What Leaked in YourPocket: Uncovering Privacy Leaks on Android Apps with Static Taint Analysis,” arXivComputing Research Repository (CoRR), vol. abs/1404.7431,2014.

[27] V. Avdiienko, K. Kuznetsov, A. Gorla, A. Zeller, S.Arzt, S. Rasthofer, and E. Bodden, “Mining Apps for Abnormal Usage of SensitiveData,”in Proc. of the 37th International Conference on SoftwareEngineering(ICSE’15), 2015.

[28] W. Yang, X. Xiao, B. Andow, S. Li, T. Xie, and W.Enck, “AppContext:Differentiating Malicious and Benign Mobile App BehaviorUnderContexts,” in Proc. of the 37th International Conference on SoftwareEngineering(ICSE’15), 2015.

[29] F. Shen, N. Vishnubhotla, C. Todarka, M. Arora, B.Dhandapani, E. J.Lehner, S. Y. Ko, and L. Ziarek, “Information Flows as aPermission Mechanism,” in Proc. of the ACM/IEEE International ConferenceonAutomated Software Engineering (ASE’14), 2014.

[30] Byeong-Mo Chang, Jang-Wu Jo, and Soon Hee Her,“Visualization of Exception Propagation for Java Using Static Analysis,” inProc. ofthe 2nd IEEE International Workshop on Source Code Analysis and Manipulation,2002, pp. 173–182.

[31] B.-M. Chang, J.-W. Jo, K. Yi, and K.-M. Choe,“Interprocedural Exception Analysis for Java,” in Proc. of the 2001 ACMSymposium on Applied Computing (SAC’01), 2001, pp. 620–625.

[32] C. Fu, A. Milanova, B. G. Ryder, and D. G.Wonnacott, “Robustness Testing of Java Server Applications,” IEEE Transactionson Software Engineering, vol. 31, pp. 292–311, 2005.

[33] C. Fu and B. G. Ryder, “Exception-Chain Analysis:Revealing Exception Handling Architecture in Java Server Applications,” inProc. of the International Conference on Software Engineering (ICSE’07), 2007,pp.230–239.

[34] J. W. Jo, B. M. Chang, K. Yi, and K. M. Choe, “AnUncaught Exception Analysis for Java,” Journal of Systems and Software, vol.72, pp. 59–69, 2004.

[35] X. Qiu, L. Zhang, and X. Lian, “Static Analysis forJava Exception Propagation Structure,” in Proc. of the 2010 IEEE InternationalConference on Progress in Informatics and Computing (PIC’10), vol. 2, 2010, pp.1040–1046.

[36] G. Kastrinis and Y. Smaragdakis, “Efficient andEffective Handling of Exceptions in Java Points-to Analysis,” in Proc. of the22nd International Conference on Compiler Construction (CC’13), 2013, pp.41–60.

Ichimaru_Gin_

發佈了25 篇原創文章 · 獲贊 4 · 訪問量 5萬+

私信關注

Covert Communication in Mobile Applications 手機應用中的隱祕通信