摘要

Android Root 是一個自願、合法獲取裝置最高許可權和完全使用者控制裝置的過程，為了滿足大眾需求，一個獨一無二的Android Root生態系統已經形成，也促使各種各樣的Root提供商提供Root服務。儘管合法，以及許多通過Android系統漏洞的一鍵root方法，但假如沒有控制好，這些利用會被惡意軟體作者使用來獲取未授權的特權。

為了理解這些風險，我們對許多流行且神祕的Android root提供商做了一項研究，主要關注：1）他們的利用是否被充分的保護.2）他們自己的利用和公開的利用之間的關係。我們發現儘管採用了保護措施和努力，但這些措施會被被我們發現的弱點破壞。從一個大的提供商我們提取了160多個利用二進位制，而且還在不停的更新，對應於50多個漏洞族，超過了我們能夠找到的公開的利用數量。我們能夠確定至少10個裝置驅動利用是沒有被公開報道過的，除此之外，提供商還改造了一個流行的核心漏洞（futex bug）的89個變異體來覆蓋不同版本的Android裝置和配置。更糟糕的是，只有很少一些利用程式能夠被防毒軟體檢測到。

分類和主題描述

D.4.6【作業系統】：安全和保護—攻擊性軟體。

概述

Security、Measurement

關鍵字

Android root exploit，root provider

1 介紹

在我們這個時代，使用者並沒有充分的控制個人智慧手機和平板電腦等移動裝置。由於使用者的越來越多的需求，提供root和越獄服務形成一個獨一無二的生態系統。Root和越獄是獲取Android和IOS裝置上完整特權的一個過程。他們允許使用者繞開運營商、作業系統和硬體製造商的限制，隨著完全的裝置控制，使用者可以解除安裝臃腫軟體、享受額外的需要root許可權的專業應用提供的功能，或者執行免費或付費應用。

根據裝置是否被flash，分為兩種root方法：1）軟root。2）硬root。前者指的是通過直接執行一個軟體來獲取root（即，root利用），後者指的是通過更新包或者刷ROM的方式刷入一個su二進位制程式。取決於裝置型別和作業系統版本，採用不同的root方法，例如，由於許多裝置取消了bootloaders，這些裝置不能使用硬root方法，類似的的，假如一個特殊的裝置沒有任何軟體或硬體漏洞，則軟root也是不可能的。在實踐中，像許多其他系統一樣，Android裝置也有各種各樣的漏洞存在於各種元件：核心，驅動，和應用，會在&2做總結。

在本文中，我們將會專注於軟root方式，因為一些利用可能被惡意軟體使用，因此軟root比硬root更加危險。在Android中，這樣的root 服務被一些團體提供。個人開發者或黑客經常挖掘漏洞，開發和釋出利用工具來會獲得名聲。然而，由於Android裝置的硬體多樣性，分散的軟體系統版本，以及提供商的定製【34】，對個人來說不大可能為漏洞設計大量的利用來覆蓋大範圍的裝置。因此，出現了提供root的業務【10，8，13】。

有趣的是，大多數商業root提供者都是免費使用的。在Android裝置上執行利用來root是使用者的自願行為，例如，通過一鍵root應用（oneclick app）[10，8，13].不幸的是，攻擊者也很容易通過偽裝普通使用者來獲得這樣的利用。更糟糕的是，一些大的root 提供商擁有大量的利用方法庫，且發明新的利用方法來保持其領先地位。這可能讓攻擊者有強烈的動機瞄準這些提供商。

在本文中，我們將檢查root生態系統來理解下面的高階問題：1）有多少Android漏洞型別和變種是公開存在的，他們和商業提供商的區別。2）究竟有多難濫用root提供商提供的利用。我們將會通過一系列的測量和特徵化公開的root利用以及提供商提供的。

論文的貢獻如下：

• 我們通過全面的測量研究android的軟root來總結它們的原因和趨勢。我們發現：1）大多數公共的Android應用層利用隻影響特定型別的裝置。2）雖然核心漏洞被認為是最危險的，但在一個裝置上開發的利用可能需要通過適配才能工作在另一個裝置上。3）隨著核心漏洞變得越來越少，裝置驅動程式成為發現root利用的主要目標。

• 我們分析了root提供商為他們利用新增的保護措施。儘管大的提供商會使用更多的保護措施，但我們仍可以識別到系統的弱點和缺陷，這些將會大大的破壞他們的努力。這個結果顯示了他們需要更好的安全措施來保護這種危險的行為。

• 我們利用網上線上利用多樣性調查，調查範圍涵蓋從大的安全公司到個人開發者。我們報告了大的提供商不僅保持“祕密”的利用，同時還花費大量的努力來改造現有的利用。

2 公開的有效的Android Root利用

在本節中，我們試圖詳盡的收集所有公開已知的android root利用或者漏洞，理解他們的特徵。儘管根據報道，root利用已經被惡意軟體使用[43，28，19]，我們仍然缺乏一個完整的最新的關於他們的資訊，在最近的兩年，我們沒有找到系統性的研究惡意軟體是如何使用root利用相關的資訊，目前還不清楚哪些利用是目前正在被使用的，哪些更容易被惡意軟體使用，哪些可能在將來出現，我們的目標就是通過當前和公開可用的資源來理解這個問題。

資料來源和收集方法。我們調查了大量的公共資源包括學術論文[30]，研究專案[1]，出版書籍[26]，以及線上知識庫（eg,CVE資料庫或論壇帖子，如XDA）[9、6、2、5].搜尋條件包括“Android root”，“root exploit”，和“特權提升(privilege escalation)”。基於我們專業的知識，我們嘗試收集一個詳盡的清單，這個清單是我們最好的努力成果，最終我們收集了一個包含73個利用和漏洞的清單。

在大多數情況下，一個漏洞(CVE編號)對映到一個相應的利用。然而，將在2.2節中描述，我們公開的可用的利用中無法找到一些小的CVEs子集，在許多情況下，相反的情況也是可能的—沒有CVE編號但利用是可用的，可能是因為其只針對很少的裝置型別。

我們也觀察到許多利用需要多個漏洞配合來獲取root。例如，主鍵漏洞(e.g, ANDROID-8219321)只會拿到系統使用者特權，所以還需要額外的漏洞來完成root利用[16]。在這種情況下我們認為是兩個漏洞。在調查中，我們還發現5個漏洞僅可以獲取系統特權，3個漏洞可以從系統特權中獲取root許可權(我們仍然算他們8個)。此外，一些利用是相互關聯，相互轉化。當利用可以通過技術細節定位到CVE編號或漏洞時，我們也考慮他們是不同的利用，這種包容性策略更能發現完整的利用和漏洞。

在高級別上，我們我們能夠找到足夠的有關漏洞和利用的技術描述，雖然他們在細節、清晰度和可利用的原始碼或二進位制上有顯著差異。也許在意料當中，我們發現大部分的利用資訊都不是來自學術研究。

很多問題需要回答。我們的目標是通過分析回答下面的問題：

1. 有多少一般VS特殊的利用存在？直觀的說，一些利用比其他更普遍，特別是那些核心漏洞利用。一些利用也許只可能是用於特定供應商。

2. 利用原始碼和二進位制是否公開可用？執行這些利用的要求是什麼？是否可以通過一個獨立的app來使利用工作，e.g,無須使用者干預或引導進入恢復模式？

3. 防毒軟體是否可以識別到這些利用？

2.1 Root利用的影響和覆蓋率

為了理解一個利用的影響和覆蓋率，我們首先嚐試確定目標層次，這是因為影響的不同取決於層次，例如，假如一個setuid漏洞程式(在應用程式層)被安裝在一個供應商的某款手機中，那麼它的影響是有限的，我們將基於Android的體系結構將層次劃分為四類：

Linux核心。由於其特權地位，針對Linux核心很自然的實現對一個Android裝置的完全控制。特別是，一個核心漏洞會影響所有運行了這個漏洞的核心的裝置，例如，TowelRoot(CVE-2014-3153)利用了futex系統呼叫BUG來獲取root訪問，這個漏洞影響所有3.14.5以前版本的裝置，在這個類別中，我們包含了所有執行在核心中的利用，但不包含下面的內容。

特定於供應商的核心或驅動。不同於執行在幾乎每臺裝置上的主要核心程式碼，供應商定製的核心(eg，高通Linux核心的定製分支)或者供應商為各種外圍裝置(eg，相機、聲音)提供的裝置驅動程式[42]，這樣的程式碼執行在核心空間裡，並且他們的漏洞也可以導致完全控制裝置，考慮到他們是由一個團體製造，可能沒有公開審計、有些閉源(eg,特別是裝置驅動程式)的特性，他們定製的部分產生漏洞的機會可能很大，我們的調查結果也印證了這一點。然而，由於不是所有的Android 裝置都執行相同的一組定製的核心或驅動程式，一個特定於定製裝置的利用僅能影響Android裝置的一個子集(eg,某些三星裝置)。

庫層。在庫層次的利用主要針對Android庫或者被用來支援不同應用的第三方庫。例如，在ZergRush利用(CVE-2011-3874)中,libsysutils所使用的卷管理器守護程式(作為root使用者執行)被發現有一個棧溢位漏洞，將會導致root許可權提升[26]。這樣的漏洞庫可能產生很大的影響，因為這個庫可能被很多個程式包含，只要其中的一個程式以root許可權執行，並且使用了漏洞程式碼，那麼一個root利用就可以被成功的構造。ObjectInputStream漏洞(cve-2014-7911)是另外一個例子。

應用程式和應用程式框架。應用層root利用主要包括被setuid使用程式引入漏洞邏輯、系統應用或服務引入。此類利用的影響取決於漏洞是否是第三方程式，到目前為止，大多數都是第三方情況，所以影響有限。一個例子是一個僅出現在XoomFe裝置上的漏洞setuid使用程式存在一個命令注入漏洞[21]。兩一個例子是某些中興裝置上附帶的一個backdoor-like setuid二進位制程式(CVE-2012-2949)。

一般來說，從高到低，利用的影響和普遍性的順序如下：1）核心利用。2）被系統程序使用的庫。3）系統程式或服務。4）特定於供應商的裝置驅動、應用和程式。

我們不能準確的預測每一個利用影響的裝置，因為核心程式碼和Android系統程式碼比運營商定製的程式碼使用的更廣泛。此外，核心漏洞的補丁更加難以迅速的推送到使用者終端進行更新。

層次分解圖。如圖1所示，在73個利用中，有54個利用是特定於運營商的（淺灰色），有19個一般利用（黑灰色）。特定於運營商的利用包括所有的裝置驅動利用和特定於運營商的應用和程式。應用層被發現的利用最多，並且他們中的大多數都是特定於運營商，外部驅動層數量僅次於應用層，但都是特定於供應商，預計核心層和庫層利用數量最少，但卻非常通用且極其危險。在我們的調查中發現，新核心層利用每年發現的數量也相對穩定—平均每年只有1～2個。

時間維度。另一個一個重要維度是時間。具體地說，漏洞的生命週期取決於補丁的版本日期。後來發現，漏洞的生命週期越長，影響越大。另一方面，發現的越早，root利用被開發的越快。圖2顯示了每年被發現的利用數量，正如我們雖見，在2013年左右，大量的供應商定製的外部驅動層和應用層漏洞被提出。其中一個關鍵問題是，在許多定製的Android系統上的裝置檔案的訪問許可權太弱[42]，沒有一個應用程序甚至不能開啟這些裝置檔案併發起攻擊（without which an app process cannot even open these device files and launch exploits.）。這個時期恰逢Android市場份額和參與的運營商增加。另一方面，核心和庫層有一個相對穩定的模式。

顯然，隨著運營商定製過程中常見錯誤被修改，特定於供應商的漏洞數量將會下降。然而，它總是很難預測新的趨勢和利用的種類，隨著使用者強烈的需求，我們相信root利用在將來仍將繼續存在，例如，在撰寫本文時，一個新的命名為PingPong[40]的核心級root利用被宣佈。

覆蓋範圍。從理論上講，一個核心漏洞將會影響所有在漏洞被引入和被修復之間的所有核心版本，因此最近發現的核心漏洞如TowelRoot(CVE-2014-3155)應該有一個有效的覆蓋範圍，然而，將會在第三章節中看到，事情通常並不是這樣，在實踐中，一個核心利用可能取決於系統配置、地址空間佈局、編譯選項等，因此，為了成功的root一個裝置，惡意軟體[43]和root提供者通常會試圖使用多個利用。

2.2 利用(二進位制和原始碼)的可用性

在本節中，我們的目標是瞭解現有的在網際網路上公開使用的利用原始碼或二進位制的可用性，特別是，可用性是惡意作者可以發現和利用這些利用程式的一個直接指標。眾所周知，惡意軟體已經開始開始嵌入root利用，這些root利用來自公共的資源[43]，目前還不清楚有多少這樣的利用被定位和濫用。

為了定位利用的原始碼和二進位制檔案，方法是簡單的使用相關的關鍵字包括CVE編號、google Bug ID（eg，ANDROID 3176774）、影響的裝置模型和利用的暱稱(eg，TowelRoot)。為了確保足夠的覆蓋率，我們會經過兩輪獨立的網路搜尋。

在73個樣例中，我們能定位到原始碼或二進位制的利用共計68個，僅5個沒有任何發現。其中一個因為僅在一個虛擬的研究中描述過所以是不可用的。其他的儘管關聯的CVE清楚的表明他們允許任意程式碼執行，但還是不能定位到資源，我們對於這個不確定問題的根源的一個合理解釋，是發現漏洞的人沒有公佈技術細節或任何概念驗證利用程式（POC）。也有可能這些漏洞沒有足夠的吸引力吸引黑客構建利用。

從理論上講，二進位制程式和原始碼對於惡意軟體作者來說都是有價值的。一個惡意軟體可以直接嵌入這個二進位制程式，只要這個二進位制檔案是獨立的塊(eg,可執行檔案或庫)，並具有清晰的介面。當然，原始碼有許多其他的優點，因為他可以自由的定製和改進。

總的來說，有46個利用的原始碼可用，其中18個利用了存在漏洞的檔案許可權和符號連結攻擊[14]，這些問題通常是被運營商引入，這些利用主要實現在shell指令碼中，其餘的都是用C語言編寫的(一個使用了java CVE-2014-7911)。另一方面，有22個利用帶有可用的二進位制檔案，主要是一下的格式：1）PC端的指令碼可能推送額外的二進位制檔案到裝置中。2）直接在裝置上執行的APK。數量分別是10和12個。

我們觀察到，儘管原始碼通常更有價值，但他也許沒有二進位制檔案健壯，特別是當原始碼被提供作為“third-party”概念證明，特別是，為了適應不同裝置和模型，需要相當大的迭代和設計工作，例如，僅towelroot二進位制檔案就需要做三個重大修改才能支援不同的裝置。可用的原始碼，但僅是概念證明，並且是被其他開發人員編寫[4]。總之，惡意軟體可能能夠整合更多的利用，即使這些利用只有有限的覆蓋範圍。

2.3 Exploit 需求

即使一個利用的原始碼或二進位制檔案被找到，仍需要理解執行他們的要求。例如，一個利用也許需要一個adb shell setup 通過一個PC連結—因為只有作為shell 使用者執行的程序可以執行這個利用。一個利用也許需要使用者互動(eg, 引導進入恢復模式至少觸發漏洞)。

為了理解利用的要求，我們執行了兩個步驟：1）定位利用作者或者其他相關的人發表的技術報告或教程[21]。2）假設1）不可用，我們嘗試閱讀利用的原始碼或指令碼，通常它們會包含這些資訊，事實證明這兩個步驟可以覆蓋大部分利用。

從利用的技術細節和原始碼，我們能夠確定以下主要的需求(從最嚴格到最寬鬆)：

• 需要使用者互動。這類情況不多，一個例子是要求使用者下載一個APP並且手動終止安裝[7]。一個是需要使用者至少一次引導進入恢復模式[18].另外一個要求使用者手動把裝置設定到”battery saving”模式[12]。最後一個要求使用者開啟一個運營商特定的app並且點選一個按鈕[15]。直觀的說，這類利用無法被惡意軟體用來自動化root。
• 需要使用adb shell通過PC連結。對於這類利用，需要adb shell連結，因為下面一些最常見的原因：1）利用可以成功修改local.prop中的一項設定，adb shell 可以通過這項設定獲取root.2）利用需要寫入一個檔案，這個檔案屬於shell組和group-writable（不是全域性可寫的）[14]。3）利用的目標是adb守護程序，這就需要攻擊繼承以shell使用者許可權執行。例如，Rage Against the Cage 利用[11]的目標是adb守護程序未檢測setuid()的返回值漏洞。
• Reboot。通常來說，許多root利用需要至少一次重啟。例如，一個動態連線符攻擊將允許攻擊者刪除一個弱許可權系統中的檔案，eg，/data/sensors/AMI304_Config.ini，目的是在同一位置的受保護檔案設定一個link,eg,/data/locat.prop。重啟後，關聯的初始化指令碼試圖改變原始檔案的許可權(i.e，/data/sensors/AMI304_Config.ini)，使之改變成全域性可寫，實際上就是改變了linked 檔案的許可權(i.e,/data/local.prop)。
• 無須任何許可權。這類利用沒有什麼硬性的要求，但是，其中一些需要某些Android許可權，比如READ_LOGS，目的是為了把擁有該許可權的程序放置到特定使用者組。如果利用有多個要求，我們只算最嚴格的那個(e.g,一個利用既需要abd shell 又需要重啟，我們將它歸為adb shell 類別)。總結的結果如圖3.其中6個需要和使用者互動，17個需要通過PC 連結的adb shell，6個需要使用者重啟裝置，其餘的44個沒有任何硬性的要求，其中5個需要特定的android許可權，大多數利用都是特定於運營商，而一般利用共計19個，其中有4個利用歸為“Adb shell”，15個歸為“無須任何許可權”。

聯想到共有68個利用有原始碼和二進位制檔案，其中39個有效利用僅需要reboot、許可權或無任何需求，這些利用可能被惡意軟體使用，在後臺靜默的獲取root許可權。

3 Root 利用的適配

Vspace0.03in Android 因碎片化而出名，這是由於運營商和供應商定製[34]。一方面大量定製的Android裝置的可用性，允許更大的市場佔有率，兩一方面，Android裝置的多樣性使之很難編寫出工作在不同應用/核心配置和設定的裝置上的健壯的root利用。

眾所周知，許多利用程式需要適配才能跨裝置執行。事實上，我們有理由相信正是由於需要適配，所以惡意軟體作者不能夠直接使用某些利用(e.g, zergrush 和 mempodroid)[28]。

通常，一個利用需要特定的環境才能執行。CPU、核心版本、OS版本的差異也許會導致執行失敗。基於利用的記憶體破壞，需要了解一些關鍵資料結構的相對和絕對記憶體地址，這正是為什麼需要進行適配的理由。例如，在CVE-2014-4322中，一個核心符號的地址被用來確定不同裝置上的不同。需要注意，暴力方法在這裡是行不通的，因為這可能會導致系統由於跳轉到不可預知的地址而崩潰，極少情況下，諸如Exynosabuse，改進也許不是必須的，這種利用可以通過一個漏洞裝置驅動訪問任意實體記憶體並覆蓋核心資料來獲取root許可權，這不像使用一個硬編碼的靜態地址那樣，利用可以從核心空間開始的位置搜尋來定位目標核心符號。當然，允許整個核心空間可訪問的特殊漏洞很難出現，並且即使出現可能也侷限於特定的裝置型別，一般情況下，核心利用需要大量的適配，下面通過案例的研究來證明。

3.1 CVE-2014-3153 (Futex bug)

據報道，futex漏洞會影響2014年6月3日之前所有的核心版本，並首次使用在TowelRoot中，它最初被設計用來root Verizon Galaxy S5，後來修改後可以覆蓋更多的裝置，包括ATT Galaxy S5，Galaxy S4 Active，Nexus5 。儘管它聲稱，使用一個核心漏洞可以使之工作在許多Android 裝置上，但一個硬體平臺和核心版本的輕微變動，都可能導致這種高精度利用的失敗。為了能夠覆蓋更多的裝置，它增加了一個額外的功能來修改圖5中不同的利用變數，我們將解釋其中的一個關鍵變數，系統呼叫，詳情如下。

系統呼叫變數使攻擊者可以在四種可能的可以利用的系統呼叫中，選擇一個來執行利用的一部分（The system call variable specifies one of the four possible system calls utilizable to carry out part of the exploit.）。過程是攻擊設定一個核心堆上的指標來指向一個核心棧地址，這個核心棧地址會被一個系統呼叫重寫。像圖5中顯示的，一個攻擊者需要向一個系統呼叫傳入惡意引數，這些引數將會被複制到核心中，並期望它們最終落在核心棧的目標地址。根據確定的核心版本的配置，有兩個難點：1）目標堆疊地址可能相對於棧基址是變化的。2）惡意函式呼叫的引數可以達到的深度也可能是變化的。我們在圖中展示了這些障礙。在第一種情況下，系統呼叫sendmmsg()的引數可以成功的覆蓋到目標堆疊地址上。第二種情況，由於選擇了錯誤的系統呼叫，引數無法命中目標地址。在第三種情況下，相同的系統呼叫sendmmsg，由於核心版本差異，到達的深度不同錯過了目標地址。由於上述困難，towelroot建議使用者嘗試不同的系統呼叫集合其他變數，希望命中目標地址。

4 Root提供商簡介

正如之前提到的，存在大量的root提供者，範圍涵蓋個人開發到大型企業。在本節中，我們的目標是研究他們的以下方面：1）調查不同型別的root提供商，並瞭解他們如何運作。2）描述他們對危險的root利用所提供的保護強度。3）評估所選取提供商的利用，並瞭解這些利用和對應的公開可用的利用之間的關係。

通常情況下，小型提供商和大型提供商在提供可用資源上的差異主要原因就是上述幾個方面。表1列出了很多受歡迎的root提供商，他們都包含了最新最大的利用方案。我們證實了大的提供商雖然提供了一套更全面的利用，但即使是現在，相應的保護措施卻遠遠不夠。事實上，我們已發現了嚴重的弱點，這允許我們可以從大的提供商提取和研究大部分利用的二進位制檔案。

我們深入的研究了9個提供商中的7個，為了安全考量我們不會公佈他們的名字，如表2所示。

收集方法和結果。我們收集了三個主要類別的資訊：1）關於每個提供商的公共資訊，e.g,他們聲稱支援的裝置數量，是一個PC端的程式或者是一個獨立的Android APP，結果已顯示在表1. 2）利用的資訊，包括二進位制的位置(e.g.,遠端伺服器端或本地)和他們的數量。3）root提供商為了利用不被逆向工程和被其他人濫用所採用的防禦措施。通過這些資訊可以粗略蘋果有價值的利用被用於惡意目的的提取難度。2）和3）中收集的資訊需要通過逆向過程來了解提供商的內部運作機制。

Root 提供商（指其產品）的架構。從我們研究的所有提供商中，我們得到了一個共性的架構，如圖6所示。Root服務通常是通過一個PC端的程式或一個獨立的一鍵root Android App提供。前者可以通過ADB介面控制一個裝置，這種方式既可以利用ADB-related的利用，像“rage against the cage”，還可以實用其它的利用直接在Android裝置上啟動。而後者—Android App可以獨立操作來執行root利用。

主要的程式邏輯包含了三個關鍵步驟：

STEP1:收集裝置資訊，如機型、核心和Android版本、硬體平臺等等。

STEP2:基於STEP1收集到的資訊，從遠端伺服器和本地儲存獲取適當的利用。

STEP3:在裝置上執行選擇的利用來獲取Root許可權。

利用的數量。這裡我們主要關注可以通過Android app 直接啟動的利用，因為他們一旦被攻擊者偷取，更可能被濫用。在表2中，我們列出了每個提供者可以被定位的利用二進位制檔案數量。令人驚訝的是，最大的提供商包含了上百個。另外，這個數量僅是一個保守數字，因為還有一些我們沒有找到的（章節5將會描述定位利用的詳細細節）。這樣的數量明顯高於我們可以在公共資源找到的數量，這也強調了被攻擊者攻擊的風險。注意，我們按照發現的利用數量對錶進行了排序，所以並不對應於表1，而且，我們也沒有提供供應商的名字。

我們意識到，不同的提供者可能採用不同的方式把它們的利用組織到二進位制檔案中。一個二進位制檔案可以對應一個利用或者利用的變體，因此，簡單的計算利用的數量可能是由誤差的。在章節6，我們提供了一個對利用更全面的分析，而且和公開可用的利用做了對比。

保護措施。正如我們預期的一樣，我們觀察到，擁有更多利用的大的root提供商更傾向於採用更強的保護措施來保護他們的產品，更小的提供商則通常沒有保護措施。例如，在表2中，提供商1和2不僅保護了Android 端的一鍵root APP，而且也引入了防探測和加密來保護他們的利用(通常是在native程式碼中)來防止利用被偷取和濫用。另外，也對從遠端儲存檢索利用的通道進行了加密。相比之下，提供者6和7只提供了一些基本的保護措施，這看上去很容易被繞過。在這項研究中我們還發現了一些大的提供商整合了小提供商的應用程式或者直接利用他們的二進位制檔案，這個發現再次反應了缺乏保護措施的小的提供者通常是個人愛好者。不幸的是，正如我們將要在5.1章節中展示的，大型提供商提供的看似強大的防禦措施，實際上基於我們發現的幾個嚴重弱點，這些防禦措施很快被我們瓦解。

PC-side VS Device-side 保護措施。要意識到PC-side程式和獨立的Android app包含了讀取裝置資訊和從遠端伺服器檢索利用的功能，這是很重要的，因為，只要有一個保護不力，程式邏輯可能被暴漏，利用程式被惡意檢索。

有趣的是，我們觀察到保護強度的確不一致。與PC相比，Android的歷史要短的多，這導致商用級別的保護方法很少，e.g.,VM-based 保護措施。我們調查發現大多數供應商提供的Android app保護措施比PC端弱的多，儘管他們會新增一些保護措施，並希望這些措施足夠強大(e.g., ProGuard)。另一方面，提供者3採用了一種更強大的叫做“梆梆”的保護方案來保護Android app，但確沒有任何保護措施保護他的PC程式。結果總結在表2. 其中“N/A”的情況表明我們並沒有研究它，因為我們從另一端已經成功的逆向。

除了上面的觀察結果，還有一些軟體保護不一致的可能。首先，老版本和新版本的相同軟體可能實現了相同程式碼功能，但強保護措施可能只存在於新版本。例如，我們觀察到一個提供商的舊版本的Android 一鍵root app 明顯弱於新版本的保護。其次，在極少情況下，一些root提供者可能互相共享程式碼，然而其中的一個版本別的弱。我們觀察到的案例中兩個提供商是合作關係。

5 保護機制的案例研究

供應商彼此的競爭力純粹是由其包含的利用的多樣性和質量決定，他們應該是高度安全的，無論是個人黑客或者是大公司提供的產品。我們希望看到保護他們程式碼的最佳實踐。然而，即使的確採用了強大的保護措施，我們也識別了一些關鍵的(和一些明顯的)缺陷，這將大大的削弱起效能。最後，我們能夠抓取幾乎所有的提供者提供的二進位制檔案。在本節中，根據利用的數量，我們將供應商分為三類。從每一個類別中我們將選取一個具有代表性的供應商進行研究，旨在找到他們保護措施的缺點和弱點。

正像在章節4中描述的那樣，root過程分成三步。通過逆向可以知道每一步是怎麼執行的，這將很容易偷取所有利用檔案,並在任何獲取root許可權的惡意軟體中執行他們。即使是最困難的提供者只花了一個研究生，這個研究生並不是一個專業的黑客，大約一個月的兼職工作來完成，這遠遠低於每個高敏感root服務的預期。作為參考，專業的賽門鐵克研究小組花了大約6個月來分析出Stuxnet的基本結構和行為[27]，這個病毒是一個國家支援的惡意軟體用來攻擊工業控制系統。在剩下的部分，我們將描述不同的root提供商的保護方法和每一個階段的弱點的細節 。

5.1 大型root提供商

提供者P1(我們引用表2中的提供者n記為Pn)是當前最大的提供者，擁有超過一百對各利用二進位制。其root服務是由PC-side程式和Android app構成。P1架構的最關鍵部分是一個線上利用商店。為了更新服務，P1只需往商店中新增新的利用即可。對於一個給定的裝置，只嘗試下載一個選擇的子集。

保護方法.
STEP 1：提供裝置資訊。P1使用標準加密演算法在傳送到遠端伺服器前對收集的裝置資訊（Android裝置model和核心版本）進行加密。類似的保護措施也被其他大的root提供者使用來保護他們的線上利用商店。

STEP 2：獲取利用。接收到加密的裝置資訊後，P1伺服器首先返回一個檔案，其中包含了利用描述符的陣列，每個描述符中包含了關於一個特定利用的複雜資訊，包括一個內部利用的識別符號，一個下載連結和評論，如受影響的裝置。關聯的利用就可以基於他的描述符來獲取。同樣，描述符檔案也像STEP 1一樣進行加密。除此之外，每個檔案URL被編碼成一個隨機的字串來防止徹底的爬取。P2中也發現使用類似的“描述符檔案機制”，只是格式不同。

STEP 3：應用利用。P1把每一個利用封裝到一個獨立的Linux動態共享物件檔案(.so)中。這些庫檔案匯出來一個公共入口點介面，因此可以通過一個統一的方式一個接一個的被執行，每次當PC-side或Android app執行時，就會下載這些檔案。很明顯這些檔案必須被保護以防被偷取濫用我們遇到了以下一些防禦措施：1）通過冗餘指令混淆程式碼[33]，並且通過一個定製的過程重新佈置ELF檔案來破環檔案頭以防反彙編(加殼)。2）對實際的利用程式碼新增花指令。3）大多數常量字串被加密。4）每個利用檔案都有篡改檢測機制以確保利用盡可以被真正的P1產品(自己的Android app)啟動，防篡改機制是基於app的簽名和包名。

安全性缺陷。不幸的是，存在很多的缺陷大幅削弱了P1採用的強保護措施。我們強調如下：

• 通過不同渠道獲取的相同Android app採用了不一致的保護措施。在研究P1一段時間後，我們意識到實際上有兩種方法來獲取他們的Android app：1）從官方網站上下載或直接從其他第三方應用市場(Google play禁止此類app)。2）從PC-side程式的下載快取中獲取副本。這可能是因為PC-side如果什麼都沒有檢測到，就會自動下載和安裝app到連結的裝置。
  令人驚訝的是，兩種驅動獲取的app在移動裝置上的行為相同，但他們的保護措施卻有天壤之別。從官方網站下載的app對主要的“Classes.dex”進行了加密和加殼。這是一種有效的商業解決方案(如，梆梆)。通過電腦程式，相比之下不包含任何保護。考慮到Android傾向於只有小的變化也會進行程式更新，如果核心的加密邏輯在將來的版本中是相同的，攻擊者可以在很長一段時間內濫用它，不斷的提取提供者開發的新的利用。這個缺陷可以有效的暴露所有的在STEP 1和STEP 2中使用的加密演算法。

• Device-side和PC-side的保護強度差異。類似在章節4中所討論的，P1的不受保護的Android app 免於處理PC-side程式的保護措施，如anti-debug。與之相反的，在P3中不受保護的PC-side程式時我們忽略了其嚴密保護的Android app。

• 遺漏了關鍵功能的名字進行轉換。提供商通常採用標準的加密和壓縮演算法(e.g., AES)來保護他們的程式碼和資料。然而如果這樣的模糊邏輯遺漏了未轉換的函式和變數名(e.g.,一個函式被命名為”md5”或者一個變數被命名為”AESKey”),這將被立即識別出演算法和反向混淆。這種形式的洩漏即存在於P1的SMALI和AEM native程式碼中也存在於其他root提供者，這大大削弱了他們的保護措施。這個缺陷影響P1的所有三個步驟。

• 基於簽名和包名的篡改檢測機制在許多提供者的利用檔案都可以發現。但是，檢測僅在開始時檢測一次，這使得它很容易被繞過—修改條件跳轉指令就可以讓其工作在任何情況下。分散的重複的篡改檢測可以提高STEP 3中的保護水平。

為了驗證所有P1中的保護措施被成功的繞過，我們開發了一個概念驗證的Android 惡意軟體，它可以在一些測試機中獲取和執行root利用以及成功的獲取root許可權，裝置型別包括HTC One V和索尼愛立信ST18I。理論上，這個惡意軟體可以利用P1的所有能力，因為它可以使用所有當前以及將來被P1維護的利用，只要過程一樣。雖然我們不能涵蓋通過PC-side程式啟動的利用，但他們也可以使用同樣的方式被下載和使用。

5.2 中型root提供商

在本節，我們選擇研究P4，一個受歡迎的中型提供商。不同於P1, P4的所有利用儲存在本地。雖然有一些本地儲存保護措施，但整體上比P1的保護弱的多。我們只花了三天時間就獲取了P4所有的利用，並且繞過了保護措施，這將在下面描述。

保護方法。
STEP 1 : 提供的裝置資訊。因為所有的P4利用的都儲存在本地，不需要傳送裝置資訊到任何遠端伺服器。所有的裝置資訊在本地收集，然後被用於指導選擇適當的利用。

STEP 2: 獲取利用。當一個特定的利用被認定適合當前裝置，P4將從本地儲存中獲取它。在這個過程中有兩個層次的保護措施：首先，在Android app內部，app使用了基於MD5的名字轉換過程把一個內部的利用名字對映到相應的本地儲存中的模糊檔名。其次，實際的利用二進位制檔案使用了GZIP進行壓縮，所以沒有任何檔案字尾。

STEP 3：應用利用。P4的利用都是ELF可執行檔案。類似於P1，每個利用二進位制檔案也有基於包名的篡改檢測機制，此外，儘管沒有加殼和模糊技術，但所有的字串都進行了加密，並且沒有有意義的函式名。

安全性缺陷。

• 對device-side app疏於保護。不像P1，甚至從P4官網上下載的原始APK也只有很少的保護措施—僅對一些基本的類和函式名進行混淆。SMAIL程式碼的主體仍具有高度可讀性，並且給出了詳細的功能和STEP1和STEP2中加密/解密邏輯。例如，引用字串如“MD5”沒有被加密，這將大大加快逆向程序。

• ELF二進位制檔案打開了除錯輸出。二進位制檔案會把介面的字串(e.g.,漏洞裝置的驅動路徑)直接列印到控制檯。顯然，開發者不小心忘記關閉除錯選項，這個錯誤大幅簡化了定位字串解碼任何和篡改檢測程式。STEP3中的保護措施也大大的被削弱。不幸的是，除了P4，我們也在其他的提供商利用二進位制程式中發現了敏感的除錯輸出。

5.3 小型root提供商

小型提供商通常僅有device-side Android app。此外，他們通常包含一些高度專業化的的利用。在我們的調查中，P6和P7被歸為小型提供商，他們的Android app簡單的執行native利用二進位制檔案，並且整個過程沒有任何保護。對於二進位制檔案，雖然有些保護措施，如程式碼混淆和篡改檢測，但他們都是原始的很容易被發現和繞過。有趣的是，缺乏有效的防禦使得大的root提供商獲取小提供商的利用並直接繼承到自己的產品中，我們在兩個大的提供商中觀察到了這種情況。

6 利用的特徵和案例研究

如表2所示，一些頂級的root提供商提供了更寬泛的root利用選擇。在本節，我們會分析167個獨一無二的root利用，這些利用程式是通過一些方法論，從最大的root提供商P1收集來的。

利用程式收集方法論 。從P1的線上資料庫中下載利用程式，我們需要向P1的遠端伺服器提供足夠的不同種類裝置模型(參見圖6)。因為沒有大量的真實裝置，我們藉助於線上資源和公開可用的factory images[42] 。通過爬蟲抓取了一些類似的網站後，我們收集了5742套裝置資訊和2458個獨特的手機型號，這些手機的核心版本覆蓋了2.6.32.9到3.10.30，Android版本覆蓋了2.3.4到5.0.2 。收集到的列表涵蓋了所有的主流手機廠商，如三星、HTC和索尼。收集到的這些資訊可以幫助我們下載167個獨特的利用二進位制程式。注意到大的提供商宣告支援超過10000或20000個Android裝置模型，因此我們獲得的利用程式可能遠小於實際的數量。儘管如此，僅僅從2458個手機型號中就獲取了167個獨特的利用樣本仍然讓人印象深刻。

6.1 分析

利用程式家族。我們假設這些利用二進位制程式對於攻擊者來說有很高的價值，因為數量上遠大於可以從公開渠道獲取到的利用數量。然而，有一個重要的問題，很多二進位制程式可能只是添加了簡單的變化或者只是同一個核心利用程式的多個適配。為了進行公平的比較，我們需要一種方法將這些利用程式歸類到不同家族。幸運的是從P1伺服器返回的解密描述檔案，正如5.1節提到的，有一個內部命名方案來識別每個利用程式。內部命名的一個例子是exploit98-3.2-v1，其中“98”用來對利用型別進行編號，“3.2”是一個特定的核心版本，“v1”表示該利用的第一次迭代變化。在命名方案的基礎上，我們估計存在59個不同的家族，數量上仍超過37個公共可用的。從命名方案來看，我們可以估計當前P1的利用家族達到數百個。

基於我們從針對各個層次的公共利用獲得的知識的基礎上，我們分析了P1的利用二進位制程式和它們的邏輯，eg，系統呼叫和它們的引數，我們把大部分利用家族分成了2大類：20個家族屬於利用核心層漏洞，比較有代表性的就是類似futex(CVE-20147-3153)和perf_event_open(CVE-2013-2094)，它們使用存在漏洞的系統呼叫，37個家族屬於驅動層，特徵是操作存在漏洞的裝置檔案，例如像/dev/exynos men等。其餘的兩個很難去分類。在核心層，我們已經確定了17個家族是可以對映到公開可用的利用，但無法完全分析其餘3個。根據利用描述，我們無法從公共資源找到影響最嚴重的裝置。對於驅動層的利用，我們確認其中的22個家族已經公開，但令人驚訝的是，經過我們的討論，其餘的15個是潛在的新的利用。有趣的是，我們沒有遇到任何應用層的利用家族。

新的驅動層利用。我們確定了37個家族是驅動利用，所有的驅動層利用都有標準的行為，首先使用open()開啟一個以/dec/file形式的漏洞裝置檔案，接下來在裝置檔案上呼叫ioctl()或其他系統呼叫。我們以核心內建的驅動或特定的提供商裝置驅動對裝置檔案進行了區分，儘管其中許多利用可以匹配現存的利用，但我們發現15個利用家族，它們使用了10個存在漏洞的獨特裝置名。我們在P1的利用描述檔案描述的受影響裝置上，能夠找到獨特的裝置檔名。受影響的裝置包括流行的品牌如三星以及一些發售不到一年的新裝置。出於安全因素我們不公佈這些漏洞裝置檔名。有趣的是，最近的一次研究[42]，暗示了裝置提供商定製的Android裝置中引入了大量存在漏洞的驅動(至今還未發現root利用)。在我們的研究中，我們發現這樣的漏洞是可以導致root提權的。回顧一下，因為最新的OS安全技術，現在核心利用程式越來越難以實現，自然把目標瞄準驅動層來開發利用程式。

適配。在P1的資料庫中最顯著的利用家族是一個包含89個變體的家族。通過逆向工程，我們已經去認定這個家族實現了對CVE-2014-3153的利用，正是著名的futex核心漏洞。這也證實了§3小節中所述的利用需要進行適配。為了理解為什麼會有這麼多變體，我們分析了這89個利用對應的核心版本，共發現了14個不同的核心版本。即使對於相同的核心版本，P1會根據核心的“構建資訊”（e.g.[#1 SMP PREEMPT Wed May 15 23:25:44 KST 2013]）來應用不同的變體。這個結果在表3中進行了總結，P1已經覆蓋了絕大多數被Android使用的主要Linux核心版本。像“3.4.0”這樣流行的核心版本存在更多的變體。除了對核心版本的適配，從利用的描述中，我們也可以看到一些變體是專門為特定的裝置製造商設計例如三星和華為。其餘的利用記載沒有很多變體，e.g.，42的家族只有一個二進位制檔案。

總而言之，我們對P1的大規模利用工程印象深刻，這將是極其困難的工作並且個人是無法完成的這些資源和工程工作。我們相信類似CVE-2015-3636這樣的高危核心級漏洞也具有相同價值，並且也需要大量的適配工作。據報道，root利用影響最多的Android裝置例如三星Galaxy S6和HTC(M9)，這個列表仍然在增長。

增加新利用程式的時間線。正像前面說明的，大型商業root提供商的利用程式大部分和對應的利用程式公開時間點重合。一個重要的指標顯示供應商的競爭力是從原始利用被首次公佈到利用被納入到root工具的時間，儘管沒有全面的資料，但我們確實有一個獨特的關於PingPong root利用的資料，這個利用在2015年5月被首次公佈。兩到三個月後同樣的利用被納入到P1中。我們注意到PingPong在技術上是很複雜的。令人印象深刻的是供應商在短時間內就完成了利用程式的逆向工程、開發、測試和測試工作。事實上，該公司在全部相關的技術細節和任何可用的POC程式碼被公佈之前就已經完成了上述工作。這證明商業提供商完全有能力並且非常迅速，這也是他們可能成為攻擊者目標的另一個原因。

6.2 對抗先進的安全機制

從167個P1利用程式中的109個利用程式，我們觀察了對SELinux安全機制的處理，SELinux是基於先進的Android安全機制例如SEAndorid[37]和Knox[17]。為了支援細粒度的訪問控制，SELinux引進了“安全上下文”的概念，一個作為root使用者執行的程序仍然會受到“上下文”的策略影響。這有效的消除了傳統Linux上強大的root使用者能力。但是在AOSP中，SELinux策略在Android4.4及以下版本預設採取permissive模式（在permissive模式下，SELinux只會將違反策略的行為記錄下來，但不會阻止），除了一些定製的廠商如三星，這意味SELinux實際上是“禁用”狀態。此外，即使SELinux策略被配置為enforcing模式，直到Andorid 5.0（AOSP）才完全實現，核心層利用通過覆蓋相關的資料結構仍然可以很容易破環SELinux，SELinux有效運作是基於以下的假定：核心是完全無損的。具體的說，幾乎在所有的109個利用攻擊中，它們不僅會重寫uid，還會重寫sid和osid，這樣安全上下文的效果被修改成初始狀態（“init”），這種狀態很特殊可以訪問幾乎所有的系統資源。接下來，它們修改/proc/self/attr/current，把安全上下文的字串表述修改成“u:init:s0”。

同樣，我們也觀察了利用程式修改了Linux“程序的capability”相關的核心資料結構，比如，覆蓋為0xffffffff .因為Linux中的程序capabilities和SELinux共享相同的威脅模型，不難想象，它們可以以同樣的方式進行對抗。

對比公開的POC原始碼，我們很少能夠發現在這個級別上對抗額外的SELinux和程序capabilities安全設定。

6.3 反病毒測試

因為root利用非常敏感，可能會被Android惡意軟體利用，我們的期望是Android平臺的反病毒軟體可以識別大多數利用程式，包括root提供商實現的。我們先擇了4個反病毒產品作為代表來測試P1的167個利用程式。因為從P1線上資料庫中下載的原始利用程式對實際的程式碼進行了加殼，並添加了防篡改機制，我們為每個利用精心製作了三個不同版本：1）從P1伺服器上下載的原始利用程式帶有殼和防篡改。2）脫殼後的利用，這將會把實際的利用程式碼暴露給反病毒產品。3）去掉防篡改機制重新對利用加殼。最後一個版本是非常危險的，因為惡意軟體可以自由的利用，在執行時自己脫殼並執行。

為了測試防毒軟體，我們將一個版本的所有利用程式嵌入到自主開發的app中來觸發病毒掃描。每次測試一個防毒軟體。如果掃描後提示app可以安全開啟，證明這款防毒軟體沒能檢測到app中的利用程式，我們解除安裝這款防毒軟體，再安裝下一款進行測試。如果掃描後得到警告該app是惡意的，我們會通過一次嵌入一個利用檔案，來確定是哪一個利用的子集被檢測出來。

最後的結果如表4所示，令人失望的是沒有任何一款防毒軟體檢測出加殼後的利用程式。這可能是由於root提供商對利用程式添加了自定義混淆實現，所以沒有別識別出來。然而，即使是脫殼的利用，也只有趨勢科技可以識別出167個利用中的13個。值得一提的是，高危漏洞futex和PingPong的利用程式都沒有被防毒軟體檢測到。這和§2.4小節中的結果不一致，在§2.4小節中提到公開的PingPong利用程式使勁上是可以被趨勢科技探測到的。這表明：1）P1的PingPong root 利用完全不同於公開的。2）趨勢科技使用了某種基於特徵碼檢測方法，這種方法不能有效的檢測出相同利用的變種。總的來說，結果表明，Android平臺上的先進防毒軟體並不能有效的防護root利用。更糟糕的是，加殼和混淆更容易免殺。

7 相關工作

Android病毒分析。到目前為止，沒有證據表明，哪個單一的惡意軟體嵌入了大量的root利用，可能是因為實現工程上的挑戰，e.g.,許多利用程式需要適配後才能在特定的裝置模型上工作。在我們的研究中，提供了一個潛在的威脅警告，惡意軟體可以利用root提供商的邏輯來實現這一目標。

Android root利用和防禦。當缺少Android root利用的全面特徵時，尖端研究表明，root利用的確會被惡意軟體濫用[44 , 43]。正像Android 惡意軟體基因組計劃中描述的[43]，1260個惡意樣本中，有36.7%已經嵌入了至少一個root利用。

Root提供商在計算機歷史上處於一個獨特的位置，它們可以合法的收集和分發大量的root利用。在實踐中，理論上，所有的商業root提供商應該為他們的root利用程式提供足夠的保護，但在實踐中，不幸的是，只要其中一個提供商沒能做好防護，惡意攻擊之就可以成功的“偷取”完全的工程，進行適配，測試不同的Android裝置上進行測試。

隨著Android的發展安全性方面已經改善了很多。SeAdnroid被證明可以有效的防範使用者級應用的root利用[37]。研究建議使用類似系統呼叫等動態行為來檢測root利用[44,29,35]。不幸的是，沒有任何一種方法是可靠的。例如，想TowelRoot和PingPongRoot 都不會受到SeAndroid的影響，因為這些它們直接利用了核心層的漏洞。此外，更昂貴的動態分析技術需要root特權操作，這限制了他們的適用性，更不用說他們對電池壽命的影響。

8 討論和結論

結論。本文，第一次，解開了神祕的root提供商面紗。我們發現他們不僅努力的引進和適配利用來覆蓋更多的裝置，而且挖掘新的利用來保持競爭力。然而，這些完善的利用程式沒有被很好的保護，如果落入不懷好意的人手中，是極其危險的。這也可能引發公共政策/法律來討論是否應該監管這些公司生產免費分發的最新利用。

鳴謝
……

引用

[1] Android Vulnerabilities – All vulnerabilities. http://androidvulnerabilities.org/all.html.
[2] Beating up on Android. http://titanium.immunityinc.com/infiltrate/ archives/Android_Attacks.pdf.
[3] Contagio minidump. http://contagiominidump.blogspot.com.
[4] CVE-2014-3153 aka towelroot. https://github.com/timwr/CVE-2014-3153.
[5] Don’t Root Robots: Breaks in Google’s Android Platform. https://jon.oberheide.org/files/bsides11- dontrootrobots.pdf. [6] Exploit DB database. https://exploit-db.com/.
[7] How To Root An AT&T HTC One X. http://rootzwiki.com/topic/26320-how-to-rootan-att-htc-one-x-this-exploit-supports-185/.
[8] iRoot, Retrieved on May 10, 2015. http://www.mgyun.com/m/en.
[9] It’s Bugs All the Way Down. http://vulnfactory.org/.
[10] One Click Root for Android, Retrieved on May 10, 2015. http://www.oneclickroot.com/.
[11] Rage Against the Cage. http://stealth.openwall. net/xSports/RageAgainstTheCage.tgz.
[12] Razr Blade Root. http://vulnfactory.org/public/razr_blade.zip.
[13] Root Genius, Retrieved on May 10, 2015. http://www.shuame.com/en/root/.
[14] Root the Droid 3. http://vulnfactory.org/blog/ 2011/08/25/rooting-the-droid-3/.
[15] [Root] ZTE z990g Merit (An avail variant). http://forum.xdadevelopers.com/showthread.php?t=1714299.
[16] [Root/Write Protection Bypass] MotoX (no unlock needed). http://forum.xda-developers.com/motox/orig-development/root-write-protectionbypass-motox-t2444957.
[17] Samsung Knox. https://www.samsungknox.com/.
[18] TacoRoot. https://github.com/CunningLogic/TacoRoot.
[19] Virus Profile: Exploit/MempoDroid.B. http://home.mcafee.com/virusinfo/virusprofile. aspx?key=1003986.
[20] VirusTotal. https://www.virustotal.com/.
[21] Xoom FE: Stupid Bugs, and More Plagiarism. http://vulnfactory.org/blog/2012/02/18/xoomfe-stupid-bugs-and-more-plagiarism/.
[22] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, and K. Rieck. DREBIN: Effective and Explainable Detection of Android Malware in Your Pocket. In NDSS, 2014.
[23] A. Averbuch, M. Kiperberg, and N. Zaidenberg. Truly-Protect: An Efficient VM-Based Software Protection. Systems Journal, IEEE, 2013.
[24] C. Collberg, C. Thomborson, and D. Low. A Taxonomy of Obfuscating Transformations. Technical report, The University of Auckland, 1997.
[25] C. S. Collberg and C. Thomborson. Watermarking, Tamper-proffing, and Obfuscation: Tools for Software Protection. IEEE Trans. Softw. Eng., 2002.
[26] J. J. Drake, Z. Lanier, C. Mulliner, P. O. Fora, S. A. Ridley, and G. Wicherski. Android Hacker’s Handbook. Wiley, 2014.
[27] N. Falliere, L. O. Murchu, and E. Chien. W32.Stuxnet Dossier. Technical report, Symanetic, 2011.
[28] D. Guido and M. Arpaia. The Mobile Exploit Intelligence Project. Blackhat EU, 2012.
[29] Y. J. Ham, W.-B. Choi, and H.-W. Lee. Mobile Root Exploit Detection based on System Events Extracted from Android Platform. In SAM, 2013.
[30] X. Hei, X. Du, and S. Lin. Two Vulnerabilities in Android OS Kernel. In ICC, 2013.
[31] C. Kruegel, W. Robertson, F. Valeur, and G. Vigna. Static Disassembly of Obfuscated Binaries. In Proc. of USENIX Security Symposium, 2004.
[32] M. Lindorfer, M. Neugschwandtner, L. Weichselbaum, Y. Fratantonio, V. van der Veen, and C. Platzer. Andrubis - 1,000,000 Apps Later: A View on Current Android Malware Behaviors. In BADGERS, 2014.
[33] C. Linn and S. Debray. Obfuscation of Executable Code to Improve Resistance to Static Disassembly. In CCS, 2003.
[34] OpenSignal. Android Fragmentation Visualized. http://opensignal.com/reports/2015/08/androidfragmentation/, 2015.
[35] Y. Park, C. Lee, C. Lee, J. Lim, S. Han, M. Park, and S.-J. Cho. RGBDroid: A Novel Response-Based Approach to Android Privilege Escalation Attacks. In LEET, 2012.
[36] R. Rolles. Unpacking Virtualization Obfuscators. In WOOT, 2009.
[37] S. Smalley and R. Craig. Security Enhanced (SE) Android: Bringing Flexible MAC to Android. In NDSS, 2013.
[38] J. I. Torrey. HARES: Hardened Anti-Reverse Engineering System. Technical report, Assured Information Security, Inc., 2015.
[39] T. Wang, Y. Jang, Y. Chen, S. Chung, B. Lau, and W. Lee. On the Feasibility of Large-Scale Infections of iOS Devices. In Proc. of USENIX Security Symposium, 2014.
[40] W. Xu. Ah! Universal Android Rooting is Back. Blackhat, 2015.
[41] J. Zeng, Y. Fu, K. A. Miller, Z. Lin, X. Zhang, and D. Xu. Obfuscation Resilient Binary Code Reuse Through Trace-oriented Programming. In CCS, 2013.
[42] X. Zhou, Y. Lee, N. Zhang, M. Naveed, and X. Wang. The Peril of Fragmentation: Security Hazards in Android Device Driver Customizations. In IEEE Security and Privacy, 2014.
[43] Y. Zhou and X. Jiang. Dissecting Android Malware: Characterization and Evolution. In IEEE Security and Privacy, 2012.
[44] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official a