黑暗危害：基於學習，大規模發現Android應用中的隱藏敏感操作(HSO)
摘要
隱藏敏感操作（HSO），例如：在接收SMS消息時竊取隱私用戶數據正越來越多地被移動惡意軟件和其他潛在危害應用（PHA）用來逃避檢測，由於在應用程序運行時觸發它們是一個挑戰，所以識別此類行爲很難；當前的靜態方法依賴於事先已知的觸發條件或隱藏行爲，因此無法捕獲先前未知的HSO活動；此外，這些技術往往是計算密集型的，所以不太適合分析大量應用程序，因此，我們對當今真實HSO的理解仍然有限，更不用說減輕這種威脅的有效手段了。
在本文中，我們介紹了HSOMINER，這是一種創新的基於機器學習的程序分析技術，可以大規模發現未知的HSO活動。我們的方法是利用一組程序功能來表徵HSO分支，並且可以相對容易地從應用程序（app）中提取，這些特徵總結了一組關於HSO條件，其路徑以及它們之間關係的獨特觀察，並且旨在用於發現隱藏的可疑行爲；特別地，我們發現與合法分支相比，觸發條件不太可能通過數據流或共享資源與其分支的路徑相關；此外，HSO分支的兩條路徑所表現出的行爲往往明顯不同（一邊是清白的，另一邊是險惡的），最重要的是，即使這些單獨的特徵對於自己捕獲HSO來說還不夠準確，但總的來說它們在識別這些行爲方面非常有效。
HSOMINER利用這種差異化的功能對Android應用進行分類，實現了高精度（> 98％）和覆蓋率（> 94％），並且在我們的實驗中發現效率也很高，新工具進一步用於涉及338,354個真實世界應用程序的測量研究，這是有史以來針對可疑隱藏操作進行的最大規模的應用程序，我們的研究揭示了HSO活動的普遍性，這些HSO活動存在於我們分析的18.7％的應用程序中，令人驚訝的觸發條件（例如，點擊視圖的某個區域）和行爲（例如，在動態生成的接收器中隱藏操作），這有助於更好地理解問題，並有助於更有效地防禦這種對移動平臺的新威脅。
1 介紹
如今，移動技術的滲透也使用戶面臨新的安全和隱私風險。值得注意的是，據谷歌報道，在過去幾年中，移動威脅不斷增加，不僅來自惡意軟件和其他可能有害的應用程序（PHA），如後門，欺詐應用程序，勒索軟件，間諜軟件等，但有時即使是大型組織的產品也會出現意外行爲，例如未經同意收集私人信息（如精確位置），安裝有害程序，有侵略性的廣告等。爲了抵消這些威脅，今天的主要應用程序商店加強了他們的安全審查，並進行了各種惡意軟件掃描。特別是谷歌Play和其他大型商店在短時間內運行提交的應用程序，以捕捉他們的可疑行爲。雖然這種保護適用於不太複雜的PHA，但它會導致攻擊技術的進一步發展，引入一組新的應用程序，故意將其敏感行爲隱藏在僅在目標情況下觸發的事件背後。例如，當PHA在物理設備（不是模擬器）上運行並與人交互時（第II部分），PHA僅彈出廣告並收集用戶的聯繫人。理解和有效檢測這些隱藏敏感操作（HSO，包括隱藏行爲及其觸發條件）正在成爲抗擊移動惡意的新前沿。
HSO in mobile apps.
實際上，HSO已經在桌面惡意軟件中進行了廣泛的研究，例如，嘗試識別虛擬機（VM）的存在並改變行爲以逃避檢測。移動PHA也有類似的技巧，在某些情況下，也是合法的應用程序。一個例子是遊戲應用程序，它們在模擬器中運行時停止提供服務。另一方面，移動設備上獨特的軟件和硬件資源使應用程序能夠通過更廣泛的觸發器來覆蓋其行爲，即執行隱藏操作的條件；案例包括位置或SMS消息（例如，僅在特定位置收集個人信息），如先前研究所報告的，以及用戶輸入模式，系統服務器和其他系統事件，如我們的研究中新發現的（第IV部分）。總的來說，雖然人們認爲HSO確實存在於移動生態系統中，但到目前爲止還很少有人對其安全影響和技術趨勢有深入的瞭解，以及已經出現的意外手段。
這種缺乏理解主要歸因於在大規模上發現隱藏操作（特別是以前未知的操作）的挑戰。如今大多數桌面HSO惡意軟件都是使用某種級別的動態分析捕獲的，這是從二進制代碼中查找逃避行爲的唯一可行解決方案。 然而，分析受到其覆蓋範圍和可擴展性的限制。對於Android應用程序，它們的字節碼更易於訪問，因此可以使用靜態分析進行檢查；問題在於確定觸發器的存在是非常困難的：基本上，觸發器只是一個分支條件（在我們的研究中也稱爲檢查），這是最常見的程序結構之一；很難將這種情況與隱藏可疑活動的意圖聯繫起來。 當前的解決方案依賴於仔細指定的安全敏感行爲（例如，受許可保護的方法，從敏感的內容提供者讀取）或明確定義的觸發條件以避免誤報。一個突出的例子是TriggerScope，它利用符號執行支持的一組狹窄條件來識別可疑觸發器；問題是這裏的條件需要精確，因此需要限制（例如，時間值和常數之間的比較），這僅限於已知類型的觸發器（文章中的時間，位置和SMS）。同樣，用於檢測的特定行爲僅適用於觸發器涵蓋的一組已知可疑活動。結果，現有技術都沒有能夠找到未知的HSO。此外，使用重量級技術（如符號執行）使得像TriggerScope這樣的方法不太適合大規模研究。
Our approach.
在本文中，我們提出了一種新技術，可以在Android應用程序中大規模發現和分析以前未知的HSO，我們的方法稱爲HSOMINER，它基於一組在不同類型的HSO中共享的獨特功能。更具體地，HSO傾向於僅檢查系統輸入（例如，時間，SMS，用戶輸入的密鑰等），而不是其託管應用的內部輸入，以觸發隱藏的行爲。此外，由觸發條件的隱藏路徑執行的這種行爲與用於在未觸發敏感活動時覆蓋敏感活動的另一路徑上的操作非常不同（例如，發送SMS而不是簡單地退出當前方法）。最有趣的是，除了它們的控制依賴性之外，觸發器和隱藏行爲往往是不相關的：例如，考慮使用時間來確定何時執行惡意活動（例如，竊取私人數據）；時間很少也可以作爲活動的輸入。從根本上說，觸發器用於檢查應用程序是否在目標情況下運行（正確的時刻，位置或設備），這通常與應用程序在該情況下打算做的正交（數據竊取，SMS發送等）。這與正常分支不同，在正常分支中，任一路徑上的操作通常通過數據流或共享資源連接到條件（例如，如果攝像機準備就緒，則通過攝像機拍照）。
這些功能都不依賴於特定的觸發條件或敏感行爲，這可能允許它們用於查找以前未知的HSO。 同樣重要的是，它們相對容易從程序中提取，即使它們中的每個個體可能都不夠準確以便檢測（產生誤報），但它們共同提供了對可疑隱藏活動的更精確描述。在我們的研究中，我們利用輕量級程序分析技術從Android應用程序中的分支結構中恢復這些功能，並運行機器學習算法來識別涉及HSO的那些。 我們的評估顯示，HSOMINER的精度超過98％，召回率高於94％，每個應用程序的速度爲13分鐘，而應用程序的尺寸（通常約爲8.43 MB）比以前的研究中的應用程序大得多。這種性能水平使我們能夠以前所未有的規模對HSO進行測量研究：我們掃描了超過338354個Android應用程序（包括來自Google Play的124,207個和來自VirusTotal的214,147個），並發現了包含HSO的63,372個; 其中，1773涉及從未報告過的HSO技術（第IV部分）。
Findings.
我們對同類中最大的HSO的測量揭示了整個Android生態系統中隱藏活動的普遍性：大約18.7％的應用程序被發現涉及他們試圖掩蓋的一些可疑行爲。 除了已知的觸發器，例如時間，位置和SMS，我們發現可疑行爲（如發送SMS）受到監控各種系統事件的保護，包括傳入的Intent，添加的新軟件包，屏幕鎖定等，以及通過檢測存在人類用戶：例如，設置屏幕上兩次連續點擊之間的間隔的閾值。即使對於舊技巧，例如識別仿真器，也已採用新技術，例如檢查/ system / bin / linker的某些位以確定應用程序是否在X86系統上運行。此外，HSO技術似乎隨着Android的發展，利用操作系統中添加的新功能及其支持的新服務：一個示例是PHA使用設備管理器來隱藏竊取用戶數據的行爲。我們的研究表明，HSO代碼具有通過GitHub和pudn等技術論壇/存儲庫共享的庫傳播。PHA作者也迅速提出了學術界提出的新技術。例如，HITCON 2013上提出的反仿真技術被發現用於現實世界的PHA。
Contributions.
該文件的貢獻概述如下：
（1）New technique.
我們開發了HSOMINER，這是一種新穎的基於機器學習的程序分析技術，用於大規模自動檢測隱藏的敏感操作，包括以前未知的操作。HSOMINER建立在一系列簡單但突出的程序功能之上，利用它們的集體差異化能力來識別HSO。通過這種方式，我們保持功能一般，從而允許該技術處理新類型的觸發條件和可疑行爲。此外，使用輕量級程序功能和機器學習來避免複雜代碼分析的高級想法可以在其他安全域中找到它的應用程序。
（2）New discoveries.
使用HSOMINER，我們進行了迄今爲止最大規模的HSO研究。在該研究中，掃描了超過330K的最新應用程序，這導致發現了超過60K具有隱藏行爲的應用程序。對這些應用程序的分析進一步揭示了新的HSO技術及其不斷髮展的趨勢。這對於更好地瞭解移動HSO風險以及加強我們對這一新興威脅的防禦是非常寶貴的。
Roadmap.
本文的其餘部分安排如下：第二部分介紹了我們的研究背景；第三節闡述了我們對HSOMINER的設計，實施和評估；第四節描述了我們的大規模測量研究和發現；第五節調查了相關的先前研究；第六節討論了我們的技術和未來潛在研究的侷限性，第七節總結了論文。
2 研究背景
在本節中，我們闡述了在我們的研究和現有HSO技術中研究的HSO活動，特別是在Android應用程序中使用的那些，我們還介紹了我們研究中的假設。
HSO and Android.
如前所述，我們使用術語“隱藏敏感操作”（HSO）來描述隱藏安全敏感行爲的分支條件（觸發器）以及觸發器的一條路徑上的行爲，只有在條件滿足時才能調用。惡意軟件作者長期以來一直利用這種HSO技巧來逃避動態分析。這裏，觸發條件用於確定惡意軟件是否在其目標環境中運行，這通常通過一組啓發式方法找到：例如，查找某些API的輸出中的差異，虛擬機（VM）的存在系統文件或與虛擬化等相關的可觀察的性能降級。此外，人類交互的檢測和各種分析引擎（例如，FireEye多向量虛擬執行引擎）的使用在桌面HSO中也變得流行。在沒有觸發此類行爲的情況下，複雜的惡意軟件甚至可以顯示消息以掩蓋其服務的中斷作爲配置問題。
同樣，用於檢測模擬器的技巧構成了Android應用程序所採用的HSO技術的支柱。這些方法傾向於利用QEMU和VirtualBox上的信息泄漏，包括其獨特的系統文件和某些API調用結果中的常量值，如getDeviceId，IMEI，Build.FINGERPRIN，getLine1Number。此外，如今的移動設備的特點是其豐富的內置傳感器和對用戶交互的強大支持，這也開闢了隱藏敏感代碼的新途徑：例如，檢查相機的存在，以確定應用程序是否確實運行在 電話或屏幕上的點擊模式，以確定是否確實是人（而不是自動測試儀）正在使用該設備（第IV-C節）。
爲了避免HSO逃避模擬器和其他分析環境，已經提出了用於覆蓋這些環境的痕跡的技術。例如，在沒有保護的情況下，對android.os.Build.MODEl的調用會立即在Android模擬器中返回google_sdk；爲了避免這種暴露，可以通過掛鉤這些API並強制它們輸出模仿真實世界設備的假值來增強模擬器：例如，SM-G920F。或者，流行的應用程序可以安裝在真正的手機上並進行分析。一個問題是，這種anti-HSO措施完全依賴於特定HSO行爲的知識，因此對未知的HSO往往效果較差。因此，發現和理解新的HSO行爲對於緩解這種潛在的安全威脅非常重要。
Assumptions.
我們考慮應用程序開發人員利用各種系統事件來確定何時觸發隱藏敏感操作的情況。請注意，只要觸發器涉及系統（設備構建信息，傳感器狀態等），我們不會假設任何特定形式的觸發條件（例如，時間值和常量之間的比較，如先前的研究中所做的那樣）或用戶輸入（第III-B節）；我們也不會將隱藏操作限制爲一組手動選擇的安全敏感行爲，只要這些操作確實涉及至少一個曾經被濫用的API，就會對應用程序用戶造成傷害（第III-C節）。Android官方安全文檔提供了此類敏感API的示例。此外，就像之前所有關於HSO靜態分析的努力一樣，我們不考慮其分支條件已被深深混淆的應用程序。最後，正如之前的研究中所發現的那樣，合法應用程序也可能表現出一些迴避行爲。一個突出的例子是遊戲應用程序，其中許多停止在模擬器中運行。因此，重要的是要注意本研究旨在瞭解此類行爲，而不是直接檢測PHA，儘管HSO的發現通常表明存在潛在危害行爲。
我們考慮應用程序開發人員利用各種系統事件來確定何時觸發隱藏敏感操作的情況。請注意，只要觸發器涉及系統（設備構建信息，傳感器狀態等）或用戶輸入（第III-B節），我們不會假設任何特定形式的觸發條件（例如，時間值和常量之間的比較，如先前的研究中所做的那樣）；我們也不會將隱藏操作限制爲一組手動選擇的安全敏感行爲，只要這些操作確實涉及至少一個曾經被濫用的API，就會對應用程序用戶造成傷害（第III-C節）。Android官方安全文檔提供了此類敏感API的示例。此外，就像之前所有關於HSO靜態分析的努力一樣，我們不考慮其分支條件已被深深混淆的應用程序。最後，正如之前的研究中所發現的那樣，合法應用程序也可能表現出一些迴避行爲。一個突出的例子是遊戲應用程序，其中許多停止在模擬器中運行。因此，重要的是要注意本研究旨在瞭解此類行爲，而不是直接檢測PHA，儘管HSO的發現通常表明存在潛在危害行爲。
3 FINDING HSO
在這裏，我們詳細說明了我們技術的設計，實施和評估。
A. Overview
HSOMINER的設計側重於分支的結構，當涉及隱藏行爲時，無論操作的細節如何，它都具有獨特的特徵。可以從分支的各個組件之間的關係（包括其條件和路徑）以及組件和系統事件之間的關係來觀察這些特徵。更具體地說，觸發條件總是與系統輸入（時間，位置，屏幕觸摸等）相關，而非HSO分支可能僅依賴於應用程序的本地數據（例如，循環變量與常量之間的比較）。進一步比較觸發器控制的路徑，一個是敏感操作，另一個不是（作爲前者的封面），我們可以看到它們的行爲之間存在顯着差異（例如，在一條路徑上檢索準確的位置數據和顯示UI元素） 另一方面，後者的行爲不那麼令人擔憂，以避免對整個分支的任何懷疑；同樣有趣的是，觸發器比合法條件更不可能與敏感操作共享資源：例如，對於合法的Intent處理程序，在檢查傳入的Intent的內容之後，後續操作也將發生在Intent；然而，在分支僅作爲HSO的僞裝的情況下，操作可以與Intent完全無關（數據竊取，發送SMS等）。從這三類關係中，我們的方法提取了7個特徵（參見第III-B節），這些特徵描述了條件和系統事件之間以及條件與其安全敏感路徑之間的關係，以及兩條路徑之間的行爲距離。然後，通過它們的區分能力（第III-B節）證明的這些顯着特徵被共同用於捕獲HSO分支。
Architecture
圖1說明了HSOMINER的體系結構，包括預處理器，特徵提取器和分類器。預處理器解壓縮應用程序的APK，然後將其代碼反編譯並轉換爲中間語言，最終轉換爲全局控制流圖（CFG）。建立在Soot之上的CFG根據應用程序的入口點包含一組子圖。子圖進一步與異步任務，Android組件的生命週期和過程間調用相關聯。HSOMINER自動處理這些子圖，識別潛在的條件分支，並輸出它們以進行特徵提取。爲了完全理解條件語句中涉及的觸發器，爲語句中出現的變量構造了反向數據依賴圖（DDG），而在構造CFG期間直接識別路徑的行爲。預處理器還在應用程序中對程序包進行集羣（第III-C節），這有助於最小化要分析的入口點集。
特徵提取器將觸發條件及其相應的路徑作爲其輸入，並輸出從它們收集的一組特徵（第III-B節），這些功能以及一組已確認的HSO或非HSO培訓實例用於學習分類模型，該模型用於檢測其他HSO應用程序。
Example
這裏我們使用圖2中的示例來解釋HSOMINER的工作原理。圖中突出顯示的分支條件 !containsAV，檢查當前設備上是否存在任何防病毒掃描程序。 如果沒有，該應用程序會收集用戶的電話號碼和準確位置（稍後發送）；否則，它只是將空白內容附加到郵件中。
在分析分支時，HSOMINER會追溯到定義布爾變量containsAV的程序位置，並發現它已由getInstalledPackage返回的系統輸入確定，其中包含所有已安裝包的列表。同時查看兩個路徑之間的差異，我們的方法發現敏感API getPhoneNumber和getLatitude存在於一條路徑上，而不會出現在另一條路徑上。 最後，與包列表相關的條件與安全敏感路徑上的語句沒有任何數據依賴性或其他資源共享（例如，通過公共對象）。 結果，我們的分類器將分支標記爲可疑，下面我們將介紹所選功能和各個系統組件的詳細信息。
B. Features
如前所述，HSOMINER依賴於一組獨特的程序功能來識別HSO活動，包括表徵觸發條件約束，不同路徑的行爲差異和觸發行爲關係的活動。在這裏，我們展示了這些功能，並使用213個已確認包含HSO活動的VirusTotal應用程序和213個被認爲合法的隨機選擇的GooglePlay應用程序展示了它們的差異化功能。Virustotal應用程序與已知Android惡意軟件的簽名相匹配，例如，Android.HeHe，RCSAndroid和先前研究報告的那些，並且GooglePlay應用程序已被VirusTotal清除並手動雙重檢查。
Triggle condition
HSO的觸發器用於識別調用隱藏活動的情況。對於文獻中討論的幾乎所有HSO實例，這種情況的特徵在於一些系統屬性（例如，移動設備的OS或硬件跟蹤）或環境參數（時間，位置，用戶輸入等），這些僅是通過系統界面暴露給應用程序。結果，期望HSO條件直接或間接地涉及用於與OS交互的一個或多個API調用。例如，Android定時炸彈傾向於直接將當前時間（由java.util.Calendar返回）與常量進行比較，常量通常直接嵌入觸發條件中。 另一個例子，布爾變量containsAV，如圖2所示，與調用getInstalledPackages有關。
值得注意的是，與HSO無關的普通條件也可能涉及系統輸入。但是，在大多數情況下，它們僅使用局部變量，例如，在每次迭代期間比較循環變量。有趣的是，我們發現一個簡單的二進制特徵，關於是否有任何系統輸入涉及條件，用SI（系統輸入）表示，可以很好地指示HSO的存在。如表I所示，當在我們的地面實況數據集上識別HSO實例時，SI的F分數爲0.85（精度爲0.812）。第III-C節提供了從應用程序的字節碼中提取功能的詳細信息。
Behavior differences
在不滿足HSO條件的情況下，將採取沒有隱藏活動的“暴露”路徑。直觀地說，這條路徑上的應用程序行爲和隱藏路徑上的應用程序行爲應該有很大不同：如圖2所示，隱藏路徑涉及一組敏感的API調用（getPhoneNumber和getLatitude），而暴露的路徑則沒有。顯然在這個例子中，Jaccard距離：
其中Ol和Or是分支語句的兩個路徑上的敏感操作集，描述了隱藏路徑和暴露路徑之間的不同行爲。這些行爲由被認爲具有安全和隱私影響的API指定，如Android官方文檔和一些其他列表（PScout和DroidSIFT）以及其他系統屬性和Android設置所提供的。請注意，我們選擇的API集比以前的研究中採用的更爲通用。同樣重要的是，我們對不同類型API的關係（例如，數據檢索API和接收器之間的順序）的限制較少，這使得它更有可能捕獲未知的HSO活動。
然而，在實踐中，情況可能更復雜。圖3說明了一個合法分支，其路徑涉及不同的敏感API，即使它們都執行類似的操作，即查詢設備的MAC地址。有趣的是，如果我們關注不同類似的API和其他系統屬性，交叉路徑行爲看起來並沒有那麼不同：例如，NetworkInterface和WifiInfo都可以用來收集網絡信息；其他示例包括系統或Android屬性，如“https.proxyHost”和“android_id”，其內容也可以通過API獲取，如Proxy.getDefaultHost()和TelehonyManager.getDeviceId()。爲解決此問題，我們根據功能的相似性對API或系統密鑰進行分組。我們跨不同路徑的距離D是根據各個API或系統屬性的組標識計算的，我們稱之爲AD（活動距離）。表III顯示了圖中所示分支的AD。
此外，即使兩個路徑都涉及不同的API組，它們仍可能執行類似的操作。 圖4顯示了另一個示例：兩個路徑上的API組完全不同。條件“operatorCode equals 01”下的路徑包括SMS API，而另一條路徑則不包括。如果單獨使用AD進行檢測，則可以將此案例標記爲HSO。然而，事實證明這是完全合法的：該分支實際上位於俄羅斯網絡提供商的實用程序應用程序中，爲客戶提供通過SMS或非結構化補充服務數據（USSD）檢查其帳戶餘額的選項。識別路徑之間的這種微妙關係顯然是非常重要的。
然而，在我們的研究中，我們觀察到路徑中共享變量和常量的存在通常表明存在這種關係。 在上面的示例中，爲了更新帳戶餘額的值，跨越路徑顯示共享偏好鍵的內容。 直觀地說，合法分支在其路徑上比HSO分支更可能具有數據依賴性。基於這一觀察，我們利用我們研究中的另一個特徵，稱爲DD（數據距離）來補充AD。 具體地：
其中Vl和Vr是變量集（不包括在當前路徑上本地定義的那些），並且F1和Fr是分支語句的兩個路徑上的引用類字段的集合。 表I顯示了我們的地面實況數據集中AD和DD的F分數。
Conditon-path relation
此外，我們觀察到，對於涉及隱藏行爲的分支，其條件與沿其路徑的操作之間的鏈接通常非常薄。實際上，前者正好位於後者的控制流程中。但是，除了這種關係之外，觸發器通常不會將任何數據流傳播到其路徑，也不會與其中的操作共享其他資源。從根本上說，雖然HSO條件是爲了確定運行其隱藏代碼的正確情況，但代碼本身並不意味着處理條件提供的任何輸入。例如，當HSO應用程序從寄存器中讀取以查明它是否在仿真器內運行時，由條件調用的用於竊取私有用戶數據的代碼不應該將OS指紋作爲其輸入。爲了利用這個屬性，我們提出了兩個獨特的功能，如下所述：
具體來說，我們試圖找出路徑上的任何操作或變量是否與條件中的任何變量具有數據依賴性。這是通過對每條路徑上的每個變量執行的定義 - 使用分析來完成的（詳見第III-C節）。在我們的研究中還分析了隱式條件路徑關係：我們從每個路徑上的變量中恢復與系統相關的對象實例，以便檢查這些資源對象（例如：LocationManager）是否也與變量、API或系統密鑰相關（例如：'location_providers_allowed'）在條件內。例如，隱式關係可以是在條件內檢查關鍵location_providers_allowed（是否可以訪問位置信息），以及對路徑中的LocationManager的訪問（使用位置數據）。在共享對象實例的情況下，可以通過程序分析找到一些關係（例如，通過getSimState（）使用TelephonyManager實例檢查默認SIM卡的狀態，並通過getLine1Number（）獲取相同實例的電話號碼。路徑）。在其他情況下，我們需要領域知識來確定密鑰是否與API相關或兩個API是否相關。在我們的研究中，我們使用從其分支機構觀察到的最普遍的API-API或密鑰-API對從合法應用程序收集此類關係。詳情見第III-C節。
描述這種觸發器 - 行爲關係的特徵包括DF（數據依賴性），它是通過數據流連接到條件的路徑上的變量的比率，以及IR（隱式關係），它是隱含的變量，密鑰和API的數量。 與病情有關。在我們的地面實況集上測量的兩個特徵的F分數如表I所示。
C. Detection
所有功能的選擇不僅基於它們的差異化功能，還基於它們從應用程序代碼中收集的相對便利性。下面我們將闡述如何運行輕量級本地化程序分析以恢復這些功能以及如何使用它們來檢測HSO活動：
Pre-processing 給定一個應用程序，預處理器首先運行Apktool來解壓縮它並從其apk文件中提取字節碼。然後，我們的分析工具，建立在Soot之上，尋找不同包的入口點，包括生命週期回調（例如onCreate），用戶交互式回調（例如onClick）和廣播接收器回調（即onReceive），正如先前的研究所做的。從每個入口點開始，HSOMINER探索所有可到達的代碼以創建控制流圖（CFG），我們將其稱爲關於條目的全局子圖或簡稱爲全局子圖。爲了提高此分析的性能，我們使用一種技術來自動識別之前分析的包，基於一組功能（例如，一組Android API的調用頻率，API調用的總數以及元中的其他統計功能） -data）指紋他們。對於那些幾乎總是共享庫的包，我們的方法會跳過它們的入口點，而不會構建它們的全局子圖。
全局子圖模擬Android活動/服務生命週期並處理組件間通信（ICC）和異步任務：在我們的實現中使用Epicc（一種開源ICC映射系統）分析ICC，並且Android框架內的異步類是使用DroidSIFT提供的調用約定表進行描述。我們的方法還支持對所選變量進行上下文敏感，流量敏感和過程間的後向數據流分析，以構建其數據依賴圖（DDG）。該技術的目的是在導致敏感API的條件下發現所選變量的來源（第III-B節），這對於諸如建立分支條件和系統輸入之間的鏈接等任務非常重要。
在每個子圖上，HSOMINER首先找到包含敏感活動的所有基本塊（一個不涉及任何分支的語句塊），這些活動由Android文檔定義的一組廣泛的API表示。請注意，與其他應用程序行爲描述的先前工作不同，這裏我們打算採用更通用的列表，除了Java / Android中的基本類（例如，java.lang。*）之外，幾乎所有重要的API都在板上，實用程序類（例如，android.util.Log）和與數據格式相關的其他類（例如，JSONObject），因爲它們幾乎不能鏈接到任何有害操作。一旦發現了這樣的敏感塊，預處理器就會在CFG上向後轉，以找到所有分支語句（例如，if-then，switch-case等）來預測該塊。一旦找到，通過探索分支的不同路徑直到路徑收斂的程序位置，在子圖上確定這種分支的範圍。此外，對每個分支執行反向數據流分析，爲其條件攜帶的變量生成DDG。DDG和分支的範圍形成一個新圖形，稱爲條件路徑圖（CPG），用於後續特徵提取。圖5中顯示了一個示例CPG。從圖中我們可以看到，與子圖一樣，CPG是跨程序的，完全保留了用於精確分支分析的信息。
Feature extraction 在CPG上，特徵提取器自動識別HSO查找的分支特徵，如下所述。
SI 如第III-B節所述，SI用於確定分支條件是否與系統輸入相關，這在觸發條件中比無害條件分支（不涉及任何HSO的分支）更普遍。要從給定分支中提取此功能，HSOMINER會檢查分支條件中的所有變量，以確定它們是否受到任何從系統資源（例如：geo-locations,，IMEI）接收輸入的API的影響（通過對後向DDG的可訪問性分析）等）或來自用戶界面的影響。此類API的示例包括<Date getTime（）>，<Locale getCountry（）>和<Settings $ Secure getInt（…）>。在我們的研究中，這些API的列表是使用SuSi獲得的，它自動將Android API分類爲sources和sinks。我們的實現包括由SuSi識別爲系統輸入的sources，具有18,076個用於Android 4.2的API。請注意，系統輸入並非始終來自API。實際上，應用程序可以直接從系統屬性（如android.os.Build）讀取，並從Intents或其他系統事件接收數據。因此，我們還將這些屬性和事件添加到列表中（因此，與這些屬性和事件相關的條件被視爲接收系統輸入）。
給定系統輸入列表，我們的特徵提取器會自動遍歷分支的CPG，以查找分支條件變量的DDG上是否存在輸入。鏈接到任何此類輸入的分支的SI設置爲1。 否則，它變爲0。值得注意的是，對條件的這種約束（與系統輸入的關係）比Triggerscope 更寬鬆，後者利用特定約束，例如當前時間是否在'2016-12-22'之後。通過這種方式，我們期望該功能與其他功能一起可以幫助找到未知類型的HSO。
AD and DD AD（活動距離）和DD（數據距離）用於測量同一分支的兩個路徑之間的行爲差異。如前所述，我們的研究表明，與真正的HSO相關的路徑往往與附加到正常分支（Section III-B）的路徑不同，由於隱藏的活動（例如訪問位置數據，發送SMS和修改系統設置）明顯不同於，並且通常完全獨立於那些被暴露的活動。爲了提取AD，我們的方法只是通過附加到其CPG上的分支的路徑來識別所有敏感API和涉及敏感系統屬性的操作（Section III-B）沿着路徑將它們映射到它們對應的行爲組，然後計算這兩組行爲組之間的Jaccard距離（分別在兩條路徑上）。
爲了發現路徑之間的數據依賴性，一般的方法是回溯路徑上每個變量的數據流，以確定它是否確實與另一條路徑上的某些變量相關：也就是說，它們都被追溯到相同的賦值或定義語句或所有引用相同的對象。這種分析顯然是重量級的，並且似乎沒有必要：對於在我們的研究中發現的所有具有此類關係的合法分支，我們觀察到相關變量都與分支的CPG內的共同聲明（賦值或定義）相關聯或通過過程間調用傳遞給託管分支的方法的對象。因此，我們可以通過簡單地分析它們在分支的CPG和當前方法上的數據流來建立跨越路徑的變量之間的數據依賴性。這使我們能夠方便地計算DD，如Section III-B所述。
DF and IR 與其他特徵一樣，DF和IR都描述了顯式數據流和分支條件與其路徑之間的隱式關係，也從分支的CPG中提取。具體而言，DF通過數據流測量路徑上的變量如何受條件影響。此特徵是通過define-use分析從分支中提取的：即，路徑上使用的任何變量是否實際上已在條件中定義。這裏“define”表示變量是定義或賦值語句（即變量獲取新值的位置）執行的操作的目標。給定路徑上的一組變量v1，...，vn，我們的方法只是檢查CPG上的每個變量，以確定它是否已在條件中定義，DF計算爲k / n，k是與條件相關的數量。
同樣如Section III-B所述，分支條件可以通過共享資源隱式鏈接到路徑，特別是公共對象實例（例如，java.net.Socket，在條件中檢查其isConnected（）屬性並且 getInputStream（）方法用於路徑），相關的API（例如，<Environment getExternalStorageState（）>和<OutputStream write（...）>），相關的系統key-API對（例如“ACCESS_FINE_LOCATION”和<LocationManager requestLocationUpdates（...）>）。在我們的研究中，我們通過檢查1500個流行的合法應用程序中的11,463個分支機構系統地收集了一組此類相關資源，並從分支機構中挑選了前50個普遍的API-API和密鑰-API對（參見表II中的示例）。在操作期間，HSOMINER自動檢查分支的CPG，查找與條件和路徑之間的相同資源對象和相關API或密鑰-API對相關聯的變量。 然後將路徑的IR計算爲其相關API，變量和鍵的數量。
值得注意的是，所有這些特徵，SI，AD，DD，DF和IR都是通過局部分析來識別的，該分析側重於分支的CPG。通過這種方式，我們使特徵提取變得輕量化，這對於實現HSO分析的可擴展性至關重要。
Classification 如表I所示，這些輕量級特徵確實有助於單獨檢測HSO活動。然而，這種貢獻是有限的，帶來顯著的誤報和否定：這些特徵的精確度從56.4％到84.6％不等，其覆蓋率從51.4％到84.3％。顯然，它們都不是完美的，它們都不能單獨工作。這主要是由這些特徵保留的一般性引起的，這對於找到未知的HSO很重要：例如，不是精確地指定觸發條件應該是什麼樣的（例如，時間變量與常數相比），我們只期望條件涉及系統輸入。HSOMINER的關鍵思想是集體使用這些不完美但輕量級的功能，以提高其發現隱藏活動的效率。爲此，我們採用機器學習技術，使用分類模型來預測分支是否確實是HSO。我們的研究表明，這種方法顯着提高了HSO檢測的質量，將精確度提高到98％，覆蓋率提高到94.4％（Section III-D）。
具體地，我們構造特徵向量v =（SI; AD; DD; DF1; DFr; IRl; IRr），其中l和r分別表示分支的左和右路徑。爲簡單起見，此處的向量僅描述具有兩個路徑的分支。當涉及多個路徑時，我們可以使用AD和DD來表示所有路徑對的最大距離，併爲每個路徑添加DF和IR到特徵向量v。表III顯示了一些特徵向量的例子，包括在某一天觸發隱藏行爲的定時炸彈（觸發器使用日曆連續檢查當前日期），在啓動網絡過程之前檢查INTERNET權限的良性實例，以及在章節中描述的另外兩個實例（訪問MAC和檢查帳戶餘額）Section III-B。
然後使用該矢量，在地面實況數據集上訓練分類模型。我們研究中的數據集包括已確認的HSO應用程序，如Android.HeHe 和合法的應用程序（Section III-D）。在HSOMINER中實現的機器學習算法是支持向量機（SVM），由於其過度擬合的特性而在我們的研究中被選擇。與其他基於學習的方法一樣，我們使用交叉驗證對SVM模型進行了訓練，然後對其進行了評估，然後再針對330K真實應用程序運行。Section III-D節提供了本研究的細節。
D. Evaluation
在本節中，我們報告了我們對HSOMINER的評估，包括HSOMINER識別HSO活動及其性能的能力。
Settings 我們的實現是通過標記的壞集，標記的好集和未知集來評估的。爲了避免由不平衡數據引起的過度擬合，我們製作了相同大小的好集和壞集。壞集包含已確認的213個PHA，每個PHA都有一個HSO分支。好的集合涉及213個谷歌播放應用程序，這些應用程序從未被VirusTotal上託管的任何反病毒（AV）服務標記。爲了克服由小訓練集引起的潛在過度擬合併使我們的分類器更通用，我們通過使用手動確認的分類樣本作爲訓練樣本進行了兩輪重新訓練。未知集有338,354個應用程序，其中124,207個從Google Play收集，其餘214,147從VirusTotal隨機下載。表IV中描述了我們的數據源的詳細信息。請注意，雖然大量應用程序至少被一個VirusTotal掃描程序標記，但由於這57個掃描程序引入的誤報，其中許多應用程序實際上是無辜的，這些掃描程序對具有豐富功能的應用程序（如集合）特別敏感位置信息。VirusTotal託管的許多應用程序也是合法的。
對於性能評估，我們從Google Play中隨機選擇了3000個熱門應用，其大小從36KB到90MB不等。此外，還測試了先前研究使用的35個相對較小的應用程序，以便讓我們瞭解我們的系統與前一個系統相比的表現。這些實驗是在配備3.3GHz Intel Core i5處理器和16GB RAM的戴爾臺式機上進行的。分析的超時設定爲60分鐘，與先前的研究一致。
Effectiveness 爲了理解HSOMINER的有效性，我們首先使用基於多項式核的SVM在標記集上訓練分類器。我們的4倍交叉驗證表明，HSOMINER在HSO檢測中的精度達到98％，召回率爲94.4％。詳細結果見表V。
然後，我們運行經過訓練的模型來預測所有338,354個應用程序中的未知實例。總共有63,372個應用程序和70,660個分支被標記爲可疑的HSO。其中，我們隨機抽樣了125個應用程序（每個都有一個標記的分支）進行手動驗證。除了兩個實例之外的所有實例都被認爲是真陽性，精確度爲98.4％，與我們從標記集中發現的一致。在兩個可能的誤報中，應用程序首先嚐試檢索設備ID，如果不成功，請嘗試讀取當前設備的MAC地址。我們沒有看到具體的證據表明應用程序打算通過一些狹窄的觸發條件隱藏這些活動。我們也沒有發現敏感的用戶數據被泄露。因此，我們並未將其視爲真正的積極因素。在所有其他情況下，我們清楚地發現了HSO行爲，例如基於時間觸發隱藏活動，UI輸入，環境類型（模擬器與否）等。表VI列出了從這些實例中發現的觸發條件的類型。列表中的頂部是“時間”，“設備信息”和“系統事件”。我們的方法還揭示了一些鮮爲人知的觸發器，如“進度條”，“客戶經理”，以及獨特的隱藏行爲，如廣播中繼和系統版本推斷。我們在未知組中的發現詳情見第四節。
Performance 爲了理解HSOMINER的性能，我們在來自Google Play的3000個隨機選擇的應用程序中運行了我們的原型，平均大小爲8.43 MB。平均而言，HSOMINER在每個應用程序上花費了765.3秒（除了8.4％的應用程序，在超時之前進行了部分分析）。此外，我們試圖將我們的方法與TriggerScope [34]（一種邏輯炸彈探測器）進行比較。如果不訪問其代碼，我們唯一能做的就是在用於評估TriggerScope的應用程序上測試HSOMINER。總而言之，我們有35個這樣的應用程序，其大小從14KB到461KB不等。所有其他應用程序顯然過於陳舊，無法在線找到。將分析超時設置爲60分鐘後，HSOMINER平均在42秒內成功處理了這些應用程序，最差情況下爲255秒，79.2％的應用程序不到60秒。請注意，之前的研究報告平均每個應用程序的性能爲219.21秒，比我們的方法慢約5.2倍，但這種比較可能不完全公平，因爲缺少Triggerscope代碼和評估環境的不確定性。至少，該研究確實表明HSOMINER確實有效。
4 MEASUREMENT AND DISCOVERIES
HSOMINER的效率使我們能夠以前所未有的規模研究HSO。通過對超過330K應用程序的系統分析，包括來自Google Play的熱門應用程序，我們的研究揭示了HSO活動的普遍性，這些活動在18.7％的應用程序中找到，並且觸發器的多樣性（基於UI事件的模式，狀態系統服務器等）和隱藏活動（動態代碼加載，視頻錄製等）。同樣重要的是，HSOMINER發現之前從未報道的新HSO活動。示例包括用戶數據收集僅在視頻播放10毫秒後發生，並且僅當點擊屏幕上的特定區域時才調用敏感活動。此外，我們的研究揭示了HSO活動如何演變以及HSO技術的傳播。下面我們詳細說明這些發現。
A. Landscape
我們的測量研究共計338,354個Android應用程序，其中214,147個是從VirusTotal緩存的內容和Google Play的124,207箇中隨機選擇的。根據SHA256刪除了重複的應用程序。應用程序發佈時間的分佈表明：儘管多年前發佈了應用程序，但大多數（約70.9％）是2015年之後新提交的應用程序。此外，我們將說明如何在圖6中選擇VirusTotal緩存的應用程序。下載的應用程序 從那裏隨機選擇了標記它們的反病毒（AV）掃描儀的數量（其中約三分之一被認爲是合法的）。平均而言，這些應用程序的大小爲5.98 MB，在從它們中提取的所有2,245,235個軟件包中，94％被HSOMINER成功處理，沒有造成任何超時。
Pervasiveness 從338,354個應用程序中，HSOMINER報告其中63,372個（18.7％）包含HSO分支機構。但是，對於大多數這些應用程序，它們的隱藏行爲來自共享庫。總而言之，我們從這些應用程序中找到了3,491個獨特的HSO實例。這些實例在所有標記的應用程序中的分佈如圖7所示。具體來說，60.9％的這些實例存在於不超過2個應用程序中（因此顯然與庫無關），而剩餘的39.1％存在於由數十個文檔在庫中廣泛的被分享在成千上萬的應用程序。另請注意，12.6％的VirusTotal應用程序包含此類non-library HSO分支，而只有8.0％的Google Play應用程序包含此類分支。例如，com.baidu.kirin庫中的定時炸彈被9710個應用程序共享；HSO涉及僅在由常量kirin_open_period指定的時間間隔期間訪問設備信息並啓動網絡更新過程。
此外，我們在圖8中顯示了這些HSO應用程序在不同國家/地區的分佈（從開發人員證書的“C（國家/地區）”屬性中恢復）。從圖中可以看出，其中包括託管大多數HSO應用的15個國家，俄羅斯，以色列和中國位居榜首。同樣有趣的是，顯然一個國家的HSO實例數與那裏的每次安裝成本（CPI）之間存在相關性。使用AppBrain提供的CPI數據，我們發現CPI越高，應用程序參與HSO活動的可能性就越小。
HSO and PHA 我們還發現HSO確實與可能有害的應用（PHA）有關。圖9顯示了VirusTotal標記的non-HSO應用程序（HSOMINER未報告的應用程序）與HSO應用程序之間的比率。我們的研究表明，前者的69.71％至少被一臺AV掃描儀檢測到，而後者的93.08％觸發了警報。當我們將警報閾值設置爲至少9個掃描儀時，這兩組應用程序之間的差距變得更大。在這種情況下，59.01％的non-HSO應用程序被報告，88.22％的HSO應用程序被發現是PHA。該發現表明HSO可以作爲檢測PHA的指標。
Triggers 我們將從檢測到的應用程序中觀察到的HSO觸發條件總結爲7個類別，如圖10所示，包括時間，位置，設備信息，設備設置，用戶界面，系統事件和系統服務。具體地，在特定時間，特定經度和緯度範圍內，或者當設備由特定網絡運營商服務時，調用敏感行爲。此外，發現設備特定信息被廣泛用於檢測仿真器：例如，設備ID“9774d56d682e549c”的存在可能表明該應用正由Bouncer進行分析。此外，我們觀察到移動設備的設置用於監視設備的狀態並確定運行敏感代碼的情況。例如，如果isDebuggerConnected爲True，則停止解密可執行文件或從資源文件加載隱藏代碼的打包程序，以及在設置adb_enabled時靜默安裝/卸載應用程序的PHA。
除了前面提到的觸發器之外，這些觸發器或多或少地被先前的研究所提及。我們的方法也確定了以前從未報道的一系列條件。特別是，發現UI小部件以巧妙的方式保護敏感操作。還可以利用重啓或日期更改等系統事件來激活隱藏的行爲。甚至Android系統服務也用於觸發HSO操作：例如，當電話帳戶在AccountManager中可用時，PHA竊取設備所有者的隱私，如電話號碼，網絡運營商和區域設置。特別感興趣的是將多個觸發條件組合在一起以涵蓋HSO活動的發現。例如，com.feicong包只在某天收到短信時纔在後臺發送短信。
Hidden behaviors 此外，我們研究了觸發器隱藏的HSO行爲。表VII列出了我們研究中發現的10類活動。正如我們從表中看到的那樣，網絡操作是最普遍的操作，在我們研究中研究的所有HSO實例中佔近70％。其他常見活動包括訪問設備信息（例如，電話號碼）（15.27％），發送SMS（12.32％）和讀取位置數據（7.02％），這些都被認爲是安全敏感的。此外，HSOMINER確定了十幾個應用程序，這些應用程序可以動態加載代碼，修改系統設置，錄製音頻/視頻，拍照並在觸發後訪問用戶帳戶。顯然，這些行爲可能對設備用戶有害。
B. Understanding HSO
在本節中，我們將重點關注我們研究中最有趣的發現，包括新類型的HSO，這種隱藏行爲的演變以及跨應用程序開發人員傳播HSO技術的渠道。
New HSO 正如Section IV-A所述，HSOMINER不僅揭示了已知HSO觸發器的普遍性，如時間和位置，還揭示了幾種不太知名的觸發條件，包括UI，系統事件和系統服務。具體來說，我們發現51個應用程序的敏感行爲只能由一些獨特的UI事件調用。其中一些HSO令人驚訝地複雜，利用了各種UI小部件的狀態。例如，只需單擊其小部件就無法觸發包com.jackeey的隱藏行爲。相反，HSO條件需要通過fling事件的正確距離和速度來滿足：僅當屏幕上的擦除速度超過20.0（以像素爲單位）時才激活網絡操作。作爲另一示例，com.FREE APPS 237包在點擊特定視圖的預定義區域之前不表現出任何敏感行爲。所有這些HSO都可以輕鬆逃避動態分析，即使使用最先進的UI自動化工具也是如此。在我們的研究中還發現了多種傳統觸發器的組合。
例如，jp.co.benesse.maitama中的HSO只能通過在給定日期之前單擊視圖來激活。其他有趣的案例包括在應用程序的進度條或視頻視圖中隱藏行爲，我們將在Section IV-C中詳細說明。
我們還發現在HSO活動中使用了Android系統服務。這種系統服務（也稱爲系統服務器）包括大量接口，供設備用戶訪問和管理系統配置。例如，AccountManager用作管理用戶帳戶的集中註冊表。在我們的研究中，HSOMINER檢測到20個利用這些服務來覆蓋其敏感操作的應用程序。作爲一個突出的例子，帶有com.nrs包的應用程序首先檢查AccountManager中是否存在org.telegram.account，如果存在，它會繼續禁用當前設備的Wi-Fi狀態並更新用戶信息（如IMEI，移動國家代碼）通過移動數據連接到服務器。另一個例子涉及DeviceManager：當沒有爲當前用戶激活服務時，app包com.example.comandroid不會出現任何可疑行爲（僅顯示其主要活動）；然而，一旦服務啓動，應用程序立即通過禁用其主要活動隱藏自己並啓動服務以在後臺竊取傳入的SMS消息。
Evolution 我們的研究也揭示了HSO活動的趨勢。具體來說，我們從每個應用的APK文件中收集元數據，包括其ZipModifyDate（當文件已被更改時）和證書信息，並分析這些技術隨時間的流行度。圖11顯示了HSO應用程序從2008年到2016年的演變，基於其託管應用程序的時間戳。我們發現包括HSO在內的應用程序的百分比在大多數情況下都會上升。這一發現表明HSO近年來越來越受歡迎，並且在反擊程序分析方面變得越來越突出。
此外，我們根據應用程序的常用軟件包名稱確定了軟件包中的變體。從這些軟件包中，我們發現其中355個實際上包含了HSO版本。 例如，在2014-05-13標記的應用程序中的包net.daum.adam尚未發現任何HSO行爲，而同一個包的變體在不同的應用程序中具有時間戳2015-06-26 使用多個因素（例如，設備ID，構建模型，構建平臺）來確定它是否在模擬器內運行，而當它不是時，包上傳用戶信息並從服務器請求廣告。
Propagation 我們的研究還提供了關於HSO技術如何傳播的新線索。我們發現HSO實例顯然是通過在線論壇傳播的。例如，旨在隱藏其360安全性行爲的com.feicong軟件包已在網上發佈（即pudn），後來出現在我們樣本中的四個應用程序中。有趣的是，這些應用程序在2015年6月首次由VirusTotal掃描，儘管它最早於2012年10月發佈。另一個觀察結果是，學術界提出的一些新的HSO技術很快被應用程序開發人員採用。例如，在HITCON 2013上發佈的一些反仿真/污點/猴子技術在com.uc108庫中被發現，該庫在2014年全部集成到我們樣本中的6個應用程序中。
C. Case Study
在這裏，我們詳細闡述了我們研究中發現的一些真實的HSO案例。
Video trigger 圖12顯示了在我們的研究中發現的應用程序，該應用程序在其HSO觸發條件下使用VideoView。具體來說，應用程序通過getCurrentPosition監視播放視頻的狀態：如果視頻播放了100毫秒，它將開始收集設備ID和位置數據。雖然100毫秒是一個非常短的時間框架，但對於像monkeyrunner這樣的UI探索工具來說，這個技巧非常有效，因爲這些工具通常不會等到視頻完全加載以生成另一個用戶事件。我們的研究發現，在我們的數據集中的27個HSO實例中使用了類似的技術。
Trapdoor on view 普通應用程序的UI的設計方式是特定功能與單個窗口小部件/子視圖相關聯。但是，我們觀察到一些HSO應用程序將其操作隱藏在視圖上的特定區域後面。對於圖13中所示的應用程序，每次單擊其視圖時，應用程序都會檢查觸摸的座標是否位於視圖中間的矩形內，高度爲50像素，寬度爲整個視圖的一半；只有當這個“陷門”被擊中時，該應用纔會調用其隱藏的活動，包括髮送短信。雖然這些應用程序是否實際上是惡意的並不完全清楚，但這種技巧確實使UI自動化工具更難以觸發敏感的HSO操作。
Click interval
在我們的研究中發現的另一種UI-based的觸發技術是用於檢測人類用戶的存在。該方法利用了這些自動工具旨在積極探索用戶界面的觀察，而人類在與應用程序的連續交互之間始終存在延遲。因此，app（com.unjiaoyou.mm）監視兩次點擊之間的時間間隔，如圖14所示，在unFastDoubleClick（）函數下：它開始收集用戶信息（電話號碼，SIM卡和IMSI的序列號）間隔大於0.5秒，否則只退出OnClickListener。
Platform-specific attribute 用於檢測仿真器的大多數已知HSO技術依賴於設備ID或構建信息。但是，HSOMINER發現了一種新方法，可將移動和桌面系統與可執行文件的特定平臺內容區分開來。具體來說，播放此技巧的應用程序從/system/bin/linker讀取以ELF格式檢查其e_machine字段（第19和第20字節）。對於ARM，該字段爲0，對於X86，該字段爲3，其中公開了系統是在真實移動設備上還是在仿真器中運行。在app中還發現了一個類，它讀取內存映射以確定/system/bin/linker64的存在。這些條件（無論是在模擬器上運行還是在當前系統上運行是64位）都可以作爲隱藏行爲的觸發器，包括解壓縮和動態加載隱藏代碼。
Broadcast relay. 除了新穎的觸發條件外，我們還觀察到一些有趣的隱藏行爲，爲可疑活動提供了額外的保護層。具體來說，我們發現應用程序通過註冊BroadcastReceiver receiver1來持續監控電話狀態的變化。有趣的是，這個接收器進一步定義了另一個BroadcastReceiver receiver2，從應用程序的資源文件加載其代碼並通過反射調用它。此外，在標記了receiver2時，receiver1沒有對VirusTotal造成任何警報。這種方法可能使隱藏的活動更難以檢測。
Version inference. 我們的研究還表明，掩護下的行爲可能比他們看起來更微妙。作爲一個突出的例子，我們發現一個應用程序，一旦觸發其隱藏路徑，調用setMobileDataEnabled，比較調用前後的移動狀態（使用getMobileDataEnabled獲取），並將比較結果發送到其服務器。仔細查看應用程序的代碼可以發現，這種不尋常的操作實際上是爲了推斷當前操作系統的版本：API setMobileDataEnabled在Android L之前可用但之後不再支持；這可以通過調用該API的嘗試是否可以通過來揭示。實際上，我們發現應用程序將推斷的版本ID放在它發出的消息中。顯然，它不想直接調用Build.Version來獲取版本號，而是使用推理來隱藏其意圖。
5 Related Work
Trigger conditions 從二進制可執行文件開始，最近轉向Android應用程序，已經研究了用各種觸發條件隱藏敏感行爲十年。大多數先前的工作是檢測虛擬機（或Android的模擬器）和規避動態分析。作爲一個突出的例子，RCSAndroid是HackingTeam的監控套件，它通過靜態屬性（如'ro.kernel.qumu'）檢測仿真器。在另一示例中，識別傳感器的存在（基於諸如虛擬程序計數器和高速緩存的使用的特徵）以區分真實移動設備和仿真器。 槓桿作爲觸發條件也是平臺之間的性能差異。甚至可以自動發現這種啓發式方法，如先前的工作所證明的那樣。
除了VM或仿真器檢測之外，其他觸發條件還利用時間，位置和SMS來識別移動設備上運行敏感代碼的正確情況。最近的一項研究通過提議區分人類用戶和自動UI探索工具來擴展HSO觸發器的範圍，因此安全敏感操作僅在人類存在的情況下發生。
這些先前研究的一個問題是它們適用於相對較小的一組應用程序，通常只有幾千個。結果，人們對野外發生的事情知之甚少。在我們的研究中，我們對超過330K的真實應用程序進行了測量研究，並發現了大量的HSO實例，包括之前從未報告過的實例，擴大了對該主題研究的關注。作爲一個例子，最近提出的基於UI的方法已經證明已經在野外，與其他複雜的，令人驚訝的技巧（Section IV）一樣，如利用視頻播放的狀態。
Detection 還提出了許多新技術來自動檢測HSO活動，二進制可執行文件或移動代碼。一些研究建議捕捉不同環境中可能有害的應用程序的行爲偏差。該想法基於以下觀察：反模擬器HSO在分析環境中運行以及在未經檢測的設備上運行時很可能採取不同的行爲。由於這種行爲比較需要使用相同的執行跟蹤來完成，因此這些方法通常記錄應用程序在一個環境中與系統的交互，並將它們重播到另一個環境中的同一個應用程序。正如我們在這裏看到的，這些方法針對的是反模擬器，而HSOMINER則是針對更一般的目的而設計的，針對不同類型的HSO活動。此外，這些基於動態分析的技術往往是重量級的，不太全面。相比之下，我們的方法使用靜態分析，因此可以擴展到數十萬個應用程序的級別。
另一項研究重點是觸發分析，基於以下觀察：觸發條件通常依賴於對手感興趣的一些獨特輸入（例如，時間，網絡），並且敏感操作僅在滿足狹窄的要求（例如，當前日期等於預定義的觸發日期;移動設備位於特定區域中）。爲了自動識別這種基於觸發器的行爲，這些方法通常利用符號執行，動態檢測和形式驗證等技術。其中，與我們的工作最相關的是TriggerScope，其目的是探測某些類型的邏輯炸彈（時間，位置和SMS觸發的HSO）。與HSOMINER相比，一個主要區別是TriggerScope旨在捕獲已知的HSO案例，其預期的觸發條件非常具體。相反，HSOMINER僅假設觸發條件應該接收某些系統輸入，這使得識別未知HSO成爲可能。另一個重要的區別是TriggerScope建立在重量級技術（如符號執行）之上，而HSOMINER利用高效的特徵提取，使其更適合大規模分析。
與我們的研究相關的還有AppContext，一種基於監督機器學習的PHA檢測系統。它利用了可以將良性和惡意行爲與其上下文區分開的觀察結果，例如UI事件，系統事件和環境屬性方法。雖然在使用學習技術方面類似於HSOMINER，但AppContext更多地關注PHA檢測而不是HSO行爲發現。
Defense 除了試圖檢測HSO之外，還努力使HSO技術效率降低。例如，Ether利用硬件虛擬化擴展來保持對惡意軟件的透明度。另一種技術動態地修改整個系統仿真器的執行，以在面對反仿真惡意軟件時模仿真實設備。 類似地，在Android中，已經提出了通過運行時掛鉤和Android源修改使模擬器透明的實現。
6 Discussion
憑藉其在理解並最終擊敗隱藏敏感操作方面邁出的重要一步，目前HSOMINER的設計和實施仍處於初步階段，還有許多不足之處。在這裏，我們討論了我們的方法和潛在的未來方向的一些限制。
Accuracy and completeness HSOMINER建立在現有靜態分析技術的基礎之上，已知這些技術不太準確，特別是在處理Android的組件間通信（ICC）時。例如，我們採用的定義 - 使用分析可能會產生不準確的結果。如我們的研究中所觀察到的，更有可能的是，某些應用程序太複雜而無法分析。雖然提高基礎靜態分析技術的精度和完整性超出了本研究的範圍，但重要的是要指出HSOMINER的設計較少依賴於各個特徵的準確性。相反，我們嘗試利用從程序中提取的一組屬性來識別HSO行爲，即使個別屬性受到一定程度的噪聲污染。我們堅信，利用不太準確但差異化的程序功能的集體力量，可以爲更具成本效益的安全分析開闢一個充滿希望的新方向。
此外，儘管HSOMINER的設計比現有方法更通用，這使得它能夠捕獲新的HSO實例，但它仍然基於一組未能涵蓋某些HSO案例的假設。例如，理論上，觸發條件不需要涉及任何系統輸入：一旦活動被訪問了一定次數，就可以激活隱藏行爲。然而，在實踐中，之前從未觀察到這種類型的技巧。最重要的是，HSOMINER基於一組特徵對分支結構進行分類，這限制了單個特徵的影響，並且仍然可以捕獲上述情況。這需要在未來的研究中進一步研究。
Evasion 就像所有現有方法一樣，HSOMINER可以通過精心設計的HSO技術來回避。HSO分支總是可以以模仿合法分支的方式構建，以使我們的技術效率降低。另一方面，我們認爲HSOMINER的設計理念將使這種攻擊更難以成功：對手可能無法通過簡單地避免一兩個特徵來繞過我們的防禦;她需要考慮多種功能組合的識別能力，仔細提出欺騙我們的分類器的策略。即使爲我們的實現選擇的功能在出現新攻擊時變得不那麼明顯，HSOMINER的框架也可以輕鬆容納其他功能，進一步提高了逃避嘗試的門檻。因此，我們有理由相信像HSOMINER這樣的技術比基於單一功能的方法（如TriggerScope）更強大。與此同時，未來的研究肯定需要更好地瞭解我們的方法下的逃稅成本，並找到新的方法來增強我們的技術來對付這種威脅。
此外，我們當前的實現無法處理本機代碼中嵌入的HSO。但是，我們的設計可以擴展到幫助識別那裏隱藏的行爲。此外，HSO觸發器可以部署在服務器端，我們的靜態分析器無法直接觀察到。另一方面，這種技術需要服務器嚮應用程序發送命令，這也需要在應用程序內進行檢查。這只是提供了使用我們的技術識別隱藏操作的機會。此外，攻擊者可以使用反射和其他技術來混淆代碼以破壞HSOMINER的有效性。然而，這種嘗試可以通過現有技術檢測，使PHA更少隱身。基於UI的HSO活動也很難捕獲，因爲將它們與合法的UI相關操作區分開來存在挑戰。通過利用UI文本和應用程序行爲之間的語義關係，使用AutoCog和現有的自然語言處理工具來提取此功能，可以解決該問題。但是，對於僅基於回調而不是傳統分支結構的UI相關行爲，需要開發新技術來檢測它們。
Further optimization. 如前所述，HSOMINER意味着高效，僅對特徵提取執行輕量級代碼分析。然而，我們目前的實施仍然涉及一些重量級技術。特別是，建立需要分析ICC的全局子圖是昂貴的。然而，在實踐中，我們發現在大多數情況下，本地識別的特徵（沒有ICC映射）足以捕獲HSO分支。未來的研究可能會研究從Intent構造和ICC組件中提取特徵以進行行爲分類的潛力，以避免昂貴的ICC映射，以及其他替代方案以進一步提高我們方法的可擴展性。
7.Conclusion
惡意軟件長期以來一直使用隱藏敏感操作（HSO）來逃避檢測。今天，這種技術在移動PHA社區中獲得了新的吸引力。隨着針對應用程序市場和其他HSO策略審查過程的各種反仿真應用程序的報告，對威脅的普遍性及其技術趨勢和影響知之甚少，主要是由於系統地發現和分析現實世界的挑戰 HSO實例。儘管已經努力靜態地檢測這些活動，但是現有技術被調整爲特定觸發條件或隱藏行爲，並且還非常重量級，使得它們在大規模檢測先前未知的HSO應用程序方面效率較低。
在本文中，我們報告了一種創新技術，可以在大量真實的Android應用程序中分析和發現未知的HSO實例。我們的方法HSOMINER建立在一系列關於HSO條件，路徑和它們之間關係的獨特觀察之上。特別是，我們發現這種情況往往涉及系統輸入，但不太可能通過數據流或共享資源鏈接到其分支路徑。此外，隱藏路徑與覆蓋它的對應物之間的行爲通常是非常不同的。發現在這些觀察中總結的特徵在集體使用時易於提取並且非常有效。在我們的研究中，我們實現了一個原型系統，該系統運行分類器來檢測具有這些功能的HSO實例。它被設計爲通用的，裝備精良，可以捕獲以前未知的HSO實例。我們的研究表明，這項新技術的精度達到98％以上，覆蓋率達到94％以上。它也很有效，使我們能夠對330K以上的應用程序進行大規模的測量研究。本研究揭示了野外Android HSO活動的新亮點，揭示了HSO作者所採用的HSO行爲和新技術的普遍性，包括廣泛使用UI，系統事件和服務作爲觸發條件和令人驚訝的隱藏行爲。我們的新技術以及新的理解有助於更好地防範這種對移動生態系統的新威脅。