DroidSkynet：一種分析早期版本App漏洞的工具

Android 平臺的普及這導致開發商投入資源以維持需求的上升。不幸的是，隨著利潤潛力越來越大，這些App受到攻擊的機會也越來越大。因此，開發人員提高了他們App的安全性，這限制了攻擊者破壞App升級版本的能力。但是，開發人員無法增強已在 Play 商店中發布的早期版本的安全性。較早版本的App可能會受到逆向工程和其他攻擊。在本文中發現攻擊者可以將這些早期版本用作攻擊媒介，從而威脅到受到良好保護的升級版本。通過分析Facebook、Weibo和Cloud-Driven等一些流行應用的升級版本，展示了如何對其早期版本存在的漏洞進行攻擊。設計并實現了一個名為 DroidSkynet 的工具來分析和找出 Play 商店中存在漏洞的App。在從現實世界收集的1500個主流應用中，DroidSkynet顯示攻擊使用早期版本的應用的成功率為34%。還探索了可能的緩解解決方案，以在App更新過程的實用性和安全性之間取得平衡。

Introduction

隨著智能手機的迅速普及，Android 操作系統已經占據了總市場份額的重要組成部分。這是由于 Android 為開發人員和供應商提供了易于加入的App開發社區。現在，開發人員通過創建大量App將他們的服務擴展到移動領域。截至目前，GooglePlay上的App已超過 260 萬個，總下載量已超過 1970 億。

然而，Android App的流行使其成為主要攻擊目標，這可能會嚴重損害用戶的信息安全和隱私。例如，中間人攻擊 (MITM，Man-in-the-Middle attack) 可以在啟用網絡的App上啟動，這可以讓攻擊者在用戶不知情的情況下訪問云中的用戶信息。逆向工程允許攻擊者探索源代碼并提取與安全相關的算法，這有助于他們更輕松地設計攻擊向量。例如，攻擊者可以根據源代碼發起重新打包攻擊(repackage attack)。重新打包攻擊會使App受到嚴重威脅。在這種攻擊中，攻擊者向App注入負載以重新打包木馬版本，使良性App成為惡意App。

近年來，為了增強 Android App的安全性，開發人員和供應商采用了多種方法。為了防止 MITM 攻擊，開發人員/供應商通過使用 TLS/SSL 或訪問控制等技術來保護他們的App的網絡通信。為了保護他們的App被逆向，開發人員使用代碼保護方法來保護他們App的源代碼，例如Java本地接口 (JNI, Java-Native-Interface) 和布局混淆(layout obfuscation)。

老實說，這些對策使App難以妥協。但由于所有這些對策僅適用于“升級版本”，因此這些App的舊版本仍然容易受到攻擊。例如，著名的社交媒體 App facebook 有 200 多個版本，其中一些可能不像希望的那樣安全。較早版本和升級版本可能共享相似或完全相同的功能。例如，盡管一些游戲App（例如，憤怒的小鳥、2048 等）可能會不斷更新新功能，包括添加新角色或新場景以使其更有趣，但基本思想或規則如何玩游戲可能不會有太大變化。同時，為了保證開發效率，新版本的 App 可能根本就沒有那么“新”。它們可能建立在較早的基礎之上。因此，它們的源代碼也可能相似。

基于這一觀察，在本文中提出了不同的問題：與其分析最終安全的升級后的App，攻擊者還可以通過分析其以前的易受攻擊版本來做什么？早期版本中是否存在同樣適用于這些升級版本的漏洞？如果有，如何探索？

事實上，在游戲App的情況下，很容易將源代碼泄漏造成的威脅可視化，即使是早期版本也是如此。如果游戲公司的競爭對手可以通過逆向獲得較早版本的游戲App的源代碼和算法，他們可能會盜版新的App，從而威脅到原游戲公司的知識產權。在接下來的部分中，將展示攻擊者可以通過利用早期版本中存在的漏洞發起更嚴重的攻擊。

本文研究檢查了如何發起此類攻擊。在示例中，涉及兩種類型的攻擊向量。它們是弱接口分析和安全相關算法（或密鑰）分析。在弱接口分析中，探索了早期版本和升級版本中都存在的一些不安全的接口。演示了基于Cloud-Driven的這種類型的攻擊。通過對網絡請求的分析，發現早期版本存在一個不安全的Restful API，可以在其上啟動MITM并刪除Cloud Drive上的文件，這可能嚴重威脅到新版本的安全。在安全相關的算法（或密鑰）分析中，得到了在保護較差的App上進行App認證時使用的 HMAC 密鑰和算法。使用它，攻擊者可以構建一個木馬化版本。

為了更好地理解這個問題，介紹了工具 DroidSkynet，它可以判斷一個 App 是否受到早期版本帶來的威脅。工具接受給定App的多個版本，并在可能的情況下從中提取源代碼。可運行分析確定較早版本是否仍在正常運行，而相似性分析返回較早版本的 App 是否與其對應的升級版本相似。如果兩者都是肯定的，則漏洞分析會返回早期版本可用作攻擊向量的可能性。

Backround and Threat Model

A.逆向工程和程序代碼保護

Android 平臺上的以下逆向工程和程序代碼保護概念在工作環境中很重要。

（1）安卓逆向

Android 逆向是從 Android App中提取和重構原始 Java 源代碼的過程。一個App的功能和實現細節信息可以通過Android逆向獲得，這需要一些特定的工具，如APKTool、dex2jar和AXMLPrinter2。jar幫助從App或二進制可執行文件中獲取源代碼和資源文件。

（2）Android 程序代碼保護

Android 逆向工程的對立面是 Android 程序代碼保護。Android 程序保護是一種有效的技術，可以防止攻擊者解析源代碼。它通過使提取源代碼和資源文件變得困難來保護源代碼。實現Android程序代碼保護的方法有很多。例如，Java 本地接口是一種標準使用的代碼保護方法。它提供 Java 代碼和本地代碼之間的接口，并允許 Android App在 Java 代碼層執行 C/C++ 代碼。通過JNI技術，開發者將核心業務邏輯封裝在C/C++庫中，然后在Java代碼層調用。JNI 使逆向工程變得困難，因為 C/C++ 代碼比 Java 代碼更難逆向工程。作為另一種著名的代碼保護方法，布局混淆可以有效地阻礙逆向工程過程。具體來說，源代碼被一系列無意義的字符代替，這使得源代碼對人類不可讀，但對機器可讀。

B.威脅模型

為了發起攻擊，攻擊者需要找到一個早期版本，攻擊者可以利用它來攜帶惡意負載。這些攻擊從受保護較差的早期版本中提取特定代碼行或其他有用信息，然后可以將其用作其他攻擊的構建塊。

在本文中主要關注兩種類型的漏洞，它們對應于兩種攻擊。(i) 早期版本和升級版本都存在的弱接口。利用弱接口，攻擊者可以探查App的設計缺陷并發動攻擊。特別是專注于 MITM 攻擊。(ii) 揭示早期版本的安全相關算法或密鑰。作為攻擊者，他可以使用這些與安全相關的算法或密鑰來分析和破解 App 與其服務器之間的身份驗證協議。他還可以獲得源代碼的重要部分來構建木馬化版本。

Motivating Examples

A.弱接口

升級版本使用加密來保護網絡流量免受重放攻擊和竊聽攻擊，而其早期版本可能容易受到各種攻擊。此外，早期版本中使用的弱Restful API也可能可用，這可能對更新版本構成威脅。在 Web 安全中，如果探索了設計不佳的界面，黑客可以利用該界面破壞整個網站。

Cloud-Driven為用戶提供安全存儲服務，雖然加強了升級版本的安全性，但早期版本仍然面臨威脅。現在演示攻擊的工作流程，攻擊的目標是找到一個存在于早期版本中并且仍然有效的不安全的 Restful API，然后將其用作攻擊向量來發起 MITM 攻擊。在實驗中，使用“Fiddler”這個基于客戶端代理的工具來分析網絡流量并重放用戶的操作會話。該工具具有重放特定請求的即開即用功能，可幫助順利處理實驗。將該工具應用于Cloud-Driven的多個版本，并手動觸發每個操作，包括下載文件、刪除文件、重命名文件。在這樣的實驗比較的幫助下，暴露了一個不安全的 Rest ful API。這個 Restful API 旨在最初刪除用戶云存儲中不必要的文件。它可以在 1.2.2 版中找到，但已從 7.1.0 版中刪除。通過使用這個不安全的 Restful API，攻擊者可以刪除文件。個別地，當用戶嘗試刪除一個文件時，充當中間人并阻止請求。獲取請求后，通過不安全的Restful API對其進行篡改，導致用戶刪除其他文件。更嚴重的是，通過編輯和重放包，攻擊者即使在用戶不知情的情況下也可以輕松進行此類攻擊

B.揭示與安全相關的算法或密鑰

使用代碼保護的動機之一是避免泄露與安全相關的算法或密鑰。一旦攻擊者獲得了這樣的算法或密鑰，攻擊者就可以利用它們發起各種攻擊。盡管較早的版本可能與較新的版本有所不同，但攻擊者仍然可以從較早的協議中提取一些協議的設計思想。沒有公司愿意在每次發布新版本時從零重新啟動他們的App。如果攻擊者足夠幸運，他們甚至可能從早期版本中獲得一個密鑰，而這個密鑰仍在升級版本中使用。

用戶身份驗證對于App非常重要，而發目標App中存在身份驗證代碼片段的漏洞。通常，實現用戶身份驗證的代碼使用加鹽（salted）密碼哈希來增強安全性。加鹽密碼哈希是防止密碼猜測攻擊的首選方法。加鹽密碼哈希的實現過程描述如下：當用戶輸入密碼并按下登錄按鈕時，從硬編碼的源代碼文件中檢索salt并附加用戶輸入的密碼以創建一個新的哈希密碼使用以保護原始輸入密碼。鹽充當 HMAC 密鑰，避免修改散列密碼。此外，加鹽密碼哈希也是一種驗證客戶端身份的方法。例如，假設這個機制沒有保證；攻擊者可以僅通過網絡流提取身份驗證的所有特征。然后可以使用提取特征來偽造一個假客戶。目標是獲得早期版本中硬編碼的秘密鹽，可以用來發起上述攻擊。

Weibo是一個類似推特的信息共享和交流平臺。它是全球最受歡迎的社交網絡作品之一，它讓用戶盡情享受互聯網帶來的便利。在全球范圍內，Weibo擁有 2.22 億月活躍用戶，而日活躍用戶高達 1 億。通過觀察，發現Weibo客戶端嘗試連接自己的服務器時，服務器會收到來自客戶端的認證參數。需要三個認證參數，包括用戶名、密碼和一串字母和數字。通過分析，發現第三個參數在身份驗證中起著至關重要的作用。如果沒有它或在認證過程中用另一個替換它，登錄請求將被服務器拒絕。對于特定用戶，只要用戶不更改密碼，該參數就不會改變。

對于這些升級版的Weibo，由于使用了大量的代碼保護，逆向工程過程變得無能為力。這促使檢查它的早期版本。選擇運行正常的早期版本，運行正常表示升級版本使用的認證機制與早期版本相同。

經過人工檢測，發現Weibo早期版本（V2.4.0_1）的代碼保護很差。請注意，只有在用戶輸入身份憑證并按下登錄按鈕后，才會發送登錄請求。因此，將登錄按鈕按下操作作為突破點。為了捕捉這樣的動作，需要找到源代碼和用戶交互之間的關系。為此，首先搜索布局文件以找出預期登錄按鈕的位置。布局文件提供了一種人類可讀的結構來描述 UI 屏幕。每個布局文件對應一個Activity。Activity 包含一組函數，當特定事件發生在相應布局文件所描述的 UI 上時，這些函數可以執行。在找到按下登錄按鈕的動作觸發的函數后，將此函數作為入口點。從這個入口點開始，跟蹤這個函數調用的其他函數。按函數名和返回值拆分每個函數。函數名暴露了它們的功能，這可以幫助更快地鎖定目標函數。例如，函數“getLoginResponseContent”就是從服務器獲取響應。經過幾次失敗的嘗試，找到了用于生成上述第三個參數的算法。該算法將用戶名、密碼和常規鹽作為輸入，然后將這些輸入提供給 MD5 函數。下圖說明了該算法的詳細實現。可以觀察到，使用了一個名為“KEY”的靜態字符串作為 MD5 哈希函數的鹽。這個字符串可以通過逆向工程從類“Constants”中提取出來。

Facebook 是世界上最大的社交網絡之一，擁有龐大的用戶群。在全球范圍內，Facebook 每月有大約 17.9 億活躍用戶 (MAU)。擁有如此多的用戶，其客戶端的安全性變得尤為重要，這引起了研究人員的關注。Facebook 的認證機制類似于微博，需要幾個參數來構建一個有效的 URL。對升級后的版本（9.2版本）進行逆向工程失敗，嘗試對其早期版本進行逆向工程以提取核心引擎。不幸的是，逆向工程的過程并不像微博那么容易，因為 Facebook 早期版本的部分源代碼也被混淆了。為了克服這個限制，使用 App 重新打包技術來構建惡意 App。攻擊者經常使用重新打包技術將惡意負載注入普通App。編寫了一個名為“Logger”的日志記錄負載，并將其注入 Facebook（版本 1.9.2）。Logger在Face book（1.9.2版本）的原始方法中注冊了監聽器，通過它可以記錄感興趣的值，包括輸入、輸出和特定函數生成的臨時值。

Logger的執行過程如上圖所示。通過將“Logger”注入多個早期版本（已經測試了三個版本，包括“V1.91”、“V1.6”和“V2.2”） ，重構了一個算法。Facebook使用的算法以用戶名和密碼作為動態輸入，以“signatureKey” 為靜態字符串作為MD5哈希函數的salt，最終返回MD5哈希算法的哈希值。

Analysis Strategy

通過觀察上述攻擊實例，總結分析和攻擊步驟如下：

1) 早期版本發現：對于給定的升級后的 App，攻擊者需要找到它的早期版本。基于這些，攻擊者可以執行他的分析。

2) 可運行分析：當攻擊者探索一個不安全的接口時，攻擊者需要從他發現的所有早期版本中選擇可以正常運行的早期版本。正常運行的早期版本表明仍在使用弱接口。

3) 相似性分析：攻擊者需要確保他找到的早期版本與相應的升級版本相似。較早版本與升級版本相似度高，說明開發者并未過多改動本App的函數，攻擊者仍可借此從較早版本中提取有用信息（即安全相關函數或key）。

4) 漏洞分析：攻擊者需要進一步將選擇的早期版本縮小到易受攻擊的版本。

5）攻擊：攻擊者分析易受攻擊的早期版本和升級版本之間的共同函數。在這個過程中可以探索漏洞。

已經有很多相關工作探索保護不良的App的漏洞能力，因此最后一個階段超出了本文的范圍。專注于前四個階段，以確定可能成為候選的早期版本。給出了如算法 1 所示的基本算法。在開始描述算法之前，下表列出了一些使用的函數。將在以下部分詳細介紹每個階段。

A.早期版本發現

判斷一個App是否是早期的，應該知道這個App發布的合適時間。一般來說，App的創建時間就是用戶下載的時間，不包括App的開發者何時發布的信息。但是，有些下載頁面記錄了發布時間。另一方面，通過實驗發現使用解壓軟件可以解壓APK文件，解壓后的文件表示App的創建時間。

B.可運行分析

回想一下，攻擊者需要知道他發現的早期版本運行正常。基于一個簡單的觀察，這能夠知道App是否正常運行。App可以分為兩類：使用 Internet 連接的App和不使用 Internet 連接的App。對于不使用互聯網的App，只要用戶安裝它，它就會始終工作，因為 Android 系統向下兼容。對于使用互聯網的App，如果服務端停止向App提供服務，App就會停止工作。對于這些App，還需要考慮到服務器端。基于這一觀察，在算法 2 (isRunnable(a)) 中提出。

在算法 2 中，將閾值定義為 50%，它表示可用 URL 占應用源代碼中找到的總 URL 的比率。如果其可用網址占總網址的比例大于閾值，認為該App運行正常。如果App的源代碼包含敏感 URL，則函數 containsSAURLeaT 將返回值 TRUE。具體而言，如果 URL 包含以下信息，則該 URL 是敏感的：

用戶操作：在用戶向服務器請求服務的過程中，用戶動作表示用戶請求服務器執行的命令。這種動作分為兩類：操作請求和認證請求。操作請求是指用戶希望對服務器上的資源進行操作，例如刪除文件或查看文件。認證請求包括登錄請求和注冊請求。

操作sink：同樣，操作的sink被認為是敏感的，可以知道用戶想要操作哪些資源。

身份：用戶的身份信息存在于系統中，例如電話號碼、帳戶、電子郵件地址和密碼。

哈希值：如前所述，使用鹽進行密碼散列是保護密碼完整性的首選方法。可以在 URL 中附加密碼和用戶名的哈希值。

例如，假設有這樣一個格式的 URL：http://a.com?un=a&pwd=b&key=c&op=delete&fn=1.txt 。在此示例中，用戶名“a”和密碼“b”的用戶想要刪除（op=delete）其 cloudDrive 上名為“1.txt”的文件。參數鍵是生成的散列。在這種情況下，刪除文件是用戶操作，而文件名是操作sink。用戶名和密碼是他的身份信息。

C.相似性分析

為了了解早期版本和新版本之間的相似性，引入了 SimiDroid 來分析App。SimiDroid是一個用于比較 Android App的框架。它可以識別和解釋不同App之間的相似性和變化。它帶有三個插件，它可以識別和解釋不同應用程序之間的相似性和變化。這些插件是基于方法的比較、基于資源的比較和基于組件的比較。本文專注于基于方法的比較，因為它將提供有關開發人員是否更改其App功能的信息。基于方法的比較可以從兩個不同的App中提取所有方法簽名和語句的抽象表示，然后計算兩個App之間的相似度。這些簽名和描述不僅基于常量值（方法或參數的名稱），還基于其結構。因此，即使開發者使用布局混淆技術來保護其源代碼，結果也不會受到影響。

D.漏洞分析

應該確保攻擊者可以破壞替代的早期版本。什么使App易受攻擊？首先，源代碼沒有受到嚴格的保護。否則，攻擊者無法從中獲取足夠的信息。其次，它不使用密碼算法來保留其基本參數。

（1）源代碼保護分析

為了解決第一個問題，需要知道App對其源代碼的保護程度。首先將Android程序代碼保護技術分為兩類：邏輯保護（LP）和文件保護（FP）。LP 通過降低源代碼的可讀性來保護源代碼文件的邏輯功能。LP 最常用的方法是布局混淆。FP 防止源代碼文件在 App 文件中泄露。它是一種防止攻擊者提取所有源代碼文件的方法。FP 最常見的技術是 JNI。因此，在本研究中專注于 JNI 技術。

邏輯保護處理：App 的漏洞與其源代碼的可讀性密切相關。定義當應用布局混淆 (LP) 時，布局混淆率是決定 App 是否可以被攻陷的重要因素之一。布局混淆率 RLP 可以使用以下公式計算：

ClassNumLP 是開發人員在源代碼中混淆的類數，而 ClassNumNOLP 是未混淆的類數。

文件保護處理：暴露給上層的 JNI 函數通常是基本的，它涵蓋了其原生層的底層邏輯。當應用 JNI (LP) 時，攻擊者可以直接使用 JNI-libs，而無需了解其邏輯。對于一些攻擊者來說，他們并不關心是否使用了 FP。例如，在 Facebook 的情況下，使用原始 App 的源代碼，包括所有 JNI-libs，重新打包惡意 App。在整個過程中，使用 JNI 庫作為惡意App的構建塊，但并不了解它們。然而，對于其他一些攻擊者，他們可能也關心App的 JNI-libs 的實現。為了涵蓋這兩種情況，引入了 FP IFFP (IFFP小于1)的影響因子。IFFP 將成為結果的一部分，但其值可以自定義。換句話說，可以檢測是否有文件保護，但會讓攻擊者或開發人員決定它是否重要。

（2）密碼算法分析

如前所述，攻擊者可以從早期版本中提取不安全的接口。什么使接口不安全？不安全的接口通常接受純文本作為他們的輸入，并直接提交它而不需要任何加密過程。基于這一觀察，引入了污點分析技術來追蹤參數如何從一個函數傳遞到另一個函數。對于 Android App，污點分析能夠構建從特定入口點（稱為源）到特定出口點（稱為sink）的路徑。為了確定是否使用加密算法，將加密 API 的返回值作為源，將網絡 API 的輸入作為sink。污點技術可以識別在給定的 App 中是否有應用加密算法來保護接口，但它不能決定這個接口提交的參數有多少。因此，引入IFcrypto的影響因子來解決這個問題。開發人員或攻擊者可以自定義此值。

現在可以決定App是否易受攻擊。具體來說給出了 VunRate 的定義，它表明了攻擊 App a 的可能性。VunRate 可以描述如下：

DROIDSKYNET

基于算法 1實現了一個工具，可以識別App是否面臨潛在的安全風險。將該工具命名為 DroidSkynet。在 Droid Skynet 的幫助下，試圖向開發人員發出警報，即攻擊者可以借助早期版本發起攻擊。此外，DroidSkynet 還可以區分給定 App 上使用了哪種代碼保護技術，并了解 App 保護技術的趨勢。

A.概述設計

在本節中，將概述“DroidSkynet”并描述框架中采用的關鍵技術。上圖展示了“DroidSkynet”的整個工作流程。DroidSkynet 由五個主要部分組成：基礎信息分析、源代碼提取器、可運行分析、相似性分析、漏洞分析。DroidSkynet 接受一個 App 的多個版本，并返回攻擊該 App 的可能性。為了進行分析，DroidSkynet 需要將最新版本與每個早期版本一一比較。具體來說，基本信息分析組件解析最新版本和較早版本中的“AndroidMainfest.xml”文件，然后從中提取基本信息。該信息包括包名稱、版本代碼和版本名稱。最新的基本信息會緩存在內存中，留待以后使用。這部分可以知道正在測試的App和版本，以及每個App的發布時間。源代碼提取器從 APK 文件中提取源代碼。

可運行分析使用算法 2 確定給定的 App 是否是可運行的。這兩個組件僅適用于早期版本。之后，如果早期版本的App是可運行的，使用相似度分析工具來分析最新版本和較早版本的相似度。同時，漏洞能力分析組件分析較早版本是否受到保護。它返回一個值，指示攻擊以前版本的App的可能性。最后，在對所有版本進行分析后，該工具會結合上述分析結果，得出App是否受到早期版本威脅的結論。

B.核心引擎實現

在所有組件中，基本信息分析、源代碼提取器沒有包含太多具有挑戰性的問題，而相似性分析基于Simi Droid。因此，在本節中將詳細介紹如何實現可運行分析和漏洞分析。

（1）可運行分析

對于不聯網的App，只要用戶安裝它就會一直工作，而對于聯網的App，需要測試App中使用的URL是否可用。為了識別 App 是否使用互聯網，解析 Android App 的“AndroidMainfest.xml”文件。該文件記錄了 App 的運行時權限。如果App使用互聯網，它必須在此文件中的權限樹上注冊。換句話說，如果字符串“uses-permission android:name=”android.permission.INTERNET””可以在文件“AndroidMainfest.xml ”，App可能會使用網絡連接。另一方面，由于 App 往往需要過多的權限，因此具有 INTERNET 權限的 App 無疑意味著該 App 需要網絡連接 [23]。為了解決這個問題，引入了靜態分析框架 Soot 來搜索互聯網相關的 API。Soot 是一個 Java 優化框架，可以處理來自給定 App 的 Android 源代碼。它可以將 Android 源代碼轉換為 Java 實例。函數 getApplicationClasses（） 和 getMethods（）可以提取類和函數。搜索每個類以查找是否使用了與 Internet 相關的 API，例如 getInputStream（） 和 openConnection（）。

另一方面，DroidSkynet 遍歷源代碼文件并返回可用鏈接的數量。為了識別這些找到的 URL 是否可用，DroidSky 網絡遵循 HTTP 狀態代碼的語義，用于在 HTTP 中傳遞狀態信息。我們鏈接在源代碼中找到的每個 URL，它代表連接操作的結果。根據狀態碼，可以判斷連接是否可用。例如，狀態碼 200 是對成功請求的響應，而狀態碼 404 表示服務器沒有找到與 Request-URL 匹配的任何內容。實際上，雖然一些 URL 請求可能依賴于其他先前的請求，但狀態碼仍然是一個可以接受的解決方案。例如，只有在認證請求完全通過后才能發送數據下載請求。當認證失敗時，狀態碼為401。類似的狀態碼有403和407。也就是說，如果得到上面的狀態碼，就可以知道請求的URL處于保護狀態，但仍然可用。另一方面，根據之前的討論，無法通過分析可用鏈接的數量來輕松確定運行是否正常。還應考慮與隱私相關的 URL。每個 URL 代表一個潛在的敏感來源。

漏洞分析

（2）漏洞分析

保護方法分析：保護方法分析確定它使用的保護類型。組件保護方法分析的一個必不可少的模塊是APKTool，它也是設計源代碼提取器的關鍵因素。APKTool 是一個逆向工程 Android 應用程序的工具。它將資源解碼為幾乎原始的形式，例如 AndroidMainfest.xml 和布局文件。同時解析APK文件中的“classex.dex”，將DEX文件轉換為SMALI文件。

提取源代碼后，開始分析以識別 LP 和 FP。為了確定源代碼是否受 LP 保護，重點介紹了布局混淆的識別方法。基本思想是檢查提取的源代碼文件的名稱是否滿足預定義的原則。將文件名作為標識信息，因為文件名可以完全保留原始程序源代碼的字符。經過逆向工程后，源代碼文件位于“smali”文件夾中。原來的類名轉換成這個文件夾中的文件名，包名變成了目錄名。在實驗中，只考慮類名作為檢查布局混淆的標識指示，因為很少發生App在類中混淆其有價值的名稱而將類名保留為純文本的情況。

布局混淆通常使用無意義或不可理解的有價值的名稱而不是有意義的名稱。例如，經過工具混淆后，代碼的有價值的名稱由小寫字母組成，從一到三（以“abc”為例）。正則表達式將匹配特定格式的單詞，用于搜索和替換單詞的技術滿足預定義的規則。Java 庫提供了現成的算法來查找這些混淆的詞。此類單詞的正則表達式可以表示為“[a-z]{1,2,3}$”。

另一方面，也有一些混淆的代碼行，比如一些函數名，在 Apps 中不滿足這樣的正則表達式。這些混淆的函數名使用了一些特殊字符來代替原來的變量，導致第一個正則表達式匹配失敗。存在一種稱為駝峰命名法的通用命名規則來命名 Java 類。實際上，大多數使用駝峰命名規則的類名是由開發人員編寫的，而不是由機器編寫的。基于這樣的事實，構造了一個函數來識別滿足駝峰模式的類名。只在第一個正則表達式匹配失敗后才使用該函數，以提高運行時的性能。如果程序源代碼匹配第一種正則表達式，則代碼受到混淆方法的保護，這意味著沒有必要進行第二種正則表達式匹配。如果改變這兩個函數的順序，把第二種類型放在前面，需要遍歷每個類名并檢查它是否滿足駝峰命名規則，只有在所有循環完成后才能得到結果。

對于這些使用 FP 來保護其源代碼的 App，重點關注這些使用 JNI 技術的 App。如果使用 JNI 技術，可以在逆向源代碼中找到調用本機接口的 C/C++ 庫。并且這些庫經常出現在App的相同位置（在目錄根目錄的“lib”文件夾中）并使用“. so”以他們的文件名結尾。

值得注意的是，也有很多App使用第三方庫來服務（例如LBS服務）或盈利（例如展示廣告視圖）。在這種情況下，App本身不受保護方法的保護，但其庫使用了一些程序代碼保護。認為這樣的App不應被視為受保護的，因為這些庫不用于構建其核心邏輯或可公開訪問。當確定App是否受保護方法保護時，這些庫被排除在外。為了實現目標，在數據庫中收集了常用的第三方庫的名稱。如果找到的所有庫也在數據庫中，則將被放棄。

最后，將反饋組件引入分析中以降低錯誤率。根據漏洞分析的結果，存在一個規律，即升級后發布的App漏洞更小，而不是早期的App。例如，如果發現 2011 年發布的 App 是安全的，但其 2018 年發布的升級版本不安全，那么分析可能有問題。在這種情況下將對這些樣品進行標記，然后將手動執行以確認結果。

密碼算法分析：污點分析能夠確定是否使用了加密算法，將加密 API 的返回值作為源，將網絡 API 的污點輸入作為sink。本文工具擴展了 Amandroid 框架，它為污點分析提供了先決條件。現在介紹如何擴展 Amandroid。特別是，通過自定義配置文件“TaintSourcesAndSinks”，可以跟蹤感興趣的污點路徑。關心以下源和sink。對于來源，關心可以處理加密或解密的函數，例如 cipher：doFinal()。污點sink涉及具有將數據發布到服務器的功能的網絡 API 和函數。例如，污染了系統網絡函數 urlConnection：getOutputStream():write()。

Experiments and Evalution

A.樣本采集

需要選擇合適的App，時間跨度是過濾條件。但是，分支所在的時間分區并不能簡單地通過應用發布的年份來確定。例如，當一些App誕生時，另一個App已經發布了多個版本，即使它們屬于同一類別。同時，對于近期發布的App來說，實驗樣本可能不夠，導致缺乏深入的對比分析。因此，收集了每個App的三個版本。最新版本、能找到的最早版本、以及中間發布的版本。

基于這一原則，從三個分支（每個分支 50 個）中收集了前 10 個類別的 1500 個App，每個類別 150 個。這 10 個類別是：游戲、玩家、瀏覽器、下載管理器、金融、健身、消息、工具、個人、社交。從 Google Play 和一些第三方市場收集了樣本，例如 UptoDown。下圖顯示了每個分支的發布時間。可以看出，大部分早期版本是在2013年發布的，中間版本是在2015年發布的，而升級版本是在2018年發布的。

B.可運行分析評估

首先執行可運行分析。為此，Droid Skynet 需要檢查 App 的網絡使用情況以及仍有多少 URL 可用。下表顯示了不同類別中 URL 的分布數量。可以觀察到，對于大多數使用互聯網的App，一個App中存在的 URL 數量平均在 200 個左右。消息App包含的 URL 比任何其他類別都多。一個 App 中存在的 URL 數量平均在 330 個左右。一款名為“Email TypeApp”的App甚至包含 711 個 URL。URL 的數量隨著版本逐漸增加，這表明App變得越來越復雜。

下圖提供了App網絡使用情況的詳細圖片。從圖中可以了解到，大多數 App 都需要網絡連接。具體來說，在500個早期版本中，不需要聯網的App只有64個。根據前面的討論，這些App被認為是可運行的。

在下圖中，顯示了可用 URL 和敏感 URL 的平均比率。從圖中可以看到，每個類別都有超過 50% 的 URL 現在仍然可用。在個人、健身下載管理器和播放器的情況下，甚至超過 70%。這表明這些App的大部分功能都運行正常。在所有可用的 URL 中，將近 30% 被認為是敏感的。所有這些可能包含敏感操作的 URL，例如登錄服務器和刪除用戶的文件。

C.相似度分析評估

然后進行相似度分析。為此，Droid Skynet 結合了所有三個分支，并比較了不同版本之間的相似性。首先檢查三個不同版本共享的方法。在這里考慮了兩種情況：（i）這些方法在所有三個版本中都存在，沒有變化。(ii) 這些方法存在于彼此相似的所有三個版本中。后者用于描述共享相似方法簽名性質和執行邏輯的方法。這些比較方法由 SimiDroid 提供。下圖顯示了結果。平均而言，對于每個類別的每個App，三個版本中都有超過 23,000 種方法沒有改變。與它相比，類似的方法要少得多。這表明開發人員傾向于不加改變地使用這些方法，而不是重新實現它。在所有的 App 中，游戲的相同和相似的方法比任何其他類別都多，因為游戲通常比其他 App 更復雜。

然后檢查早期版本和升級版本之間的相似性，以及中間版本和升級版本之間的相似性。下圖顯示了結果。平均而言，對于每個類別的每個App，早期版本和升級版本之間的相似度約為 30%（29.7%），而中間版本和升級版本之間的相似度約為 50%（47.3%）。在所有應用中，游戲與其他應用相比，每個版本之間的相似度更大。這證實了在介紹部分的陳述。游戲可能會添加新角色或新場景，使其更有趣。如何玩的基本思想可能不會改變太多。另一方面，微信和Whatsapp等消息應用與其對應的升級版本不太相似。對于這些App，用戶對通信速度和用戶體驗，甚至安全性都有更高的要求。因此，這些App的開發者希望改進這些功能以滿足用戶的需求。

D.漏洞分析評估

為了證明 DroidSkynet 提供有關潛在攻擊檢測的高質量情報，使用手動方法對其進行評估。評估樣本涵蓋健身類別，共包含 150 個App。在手動方法中，關注保護方法分析的準確性。在實驗中，DroidSkynet 可以無錯誤率地檢測所有 LP 和 FP。因為只關心布局保護和JNI保護，這兩個比較容易識別。在未來的工作中，工具將支持更復雜的 LP 和 FP 功能。

首先展示了所有三個分支中使用的保護方法。從上圖中可以看出，沒有任何保護的App正在逐漸減少。隨著時間的推移，沒有任何保護的數字在某些類別中甚至下降到零，這表明今天的開發人員比以前更加重視代碼保護。因此，利用升級的App比利用早期的App要困難得多。下降最快的類別是金融，推斷這些App涉及支付功能，這使得開發人員必須加強代碼保護以防止攻擊者。但是對于游戲、消息等其他的來說，他們的坡度比較平緩，一開始的位置比較低。這表明他們的代碼在開發之初就受到了很好的保護。這些類別的App往往是由企業而不是個人開發者開發的原因。企業高度重視產品的安全性，擁有大量可用的軟件開發資產，這使得個體開發者的創造在這些方面沒有優勢。相比之下，與其他類別相比，個人App中的創造力和創新特征比安全性更有意義，這導致這些類別的斜率下降得更慢，而它們的起點更高。

從上圖可知，LP一般是前期首選的保護方式。這樣做的原因是，布局混淆作為一種常用的LP方法，已廣泛應用于其他程序代碼保護領域。因此，將 LP 應用于 Android 代碼保護是微不足道的。這三個數字都表明，雖然現在App得到很好的保護，但早期版本的保護很差是可能的。

上圖顯示了App使用的加密保護方法。可以觀察到，加密保護的App版本逐漸增加，這表明破解升級后的App比破解早期的App要困難得多。在所有App中，游戲的開發者希望使用加密方法來增強他們的App。手游中使用的作弊工具很多，流行的作弊工具有幾十種，打破了游戲的平衡。因此，涉及密碼學方法是一種處理平衡問題的方法。

最后，基于以上所有因素和算法 1，可以計算出以早期版本為攻擊向量的 App 攻擊成功率。在例子中，IFcrypto 和 IFP 的值都設置為 0.5。上表顯示了最終結果。DroidSkynet 發現使用“中間”版本和早期版本攻擊App的成功率分別為 21% 和 13%。使用較早版本攻擊App的成功率總計為 34%。所有這些受影響的App也可以被利用來被動地公開各種類型的App數據，例如哈希鹽，或者可能隨后導致安全問題的不良 API。雖然實驗中的某些類別沒有受到太大影響，例如消息類別，但這并不意味著這些 App 就足夠安全。原因之一是檢測結果與樣本集的大小有關。

Discussion

A.潛在威脅

已經知道早期版本的 App 可以用作攻擊媒介。當早期版本被成功逆向時，攻擊者還可以知道以下信息：

1) 核心引擎：明顯的例子是在上一部分提到的游戲和工具App。獲取早期版本的程序代碼將幫助攻擊者重建盜版App，從而威脅到原始開發者的知識產權。

2) 用戶界面設計：一些軟件的用戶界面從一開始就發生了一些變化。布局描述是顯示在位于文件夾 /res/layout/ 中的布局文件中的文本。通過使用逆向工程，攻擊者可以竊取App的 UI 設計。

3) 編程風格：編程風格也是公司的隱私，可以從App中提取出來。很少有公司經常改變編程風格，而好的編程風格優化了編碼效率。

4) 潛在的漏洞：正如之前討論的，訪問認證和一些弱接口可以用來發起攻擊。更重要的是，一些攻擊者可能會通過早期版本來破解App，繞過收費App的注冊。

B.問題的根本原因

現在企業之間的競爭越來越激烈。一個沒有良好可維護性和可擴展性的 App 是不會長久存在的。遺憾的是，版本升級是一個復雜的過程，會耗費大量的財務成本和資源。為了讓版本更新更順暢，開發者不僅要實現功能性，還要在設計過程中兼顧高內聚和低耦合。因此，當漏洞發生時，開發者通過調整模塊而不是重寫整個App來修補它，這使得大多數舊模塊作為升級模塊的一部分被重用。因此，早期版本存在的漏洞仍然保留在升級版本中。

在用戶方面，老用戶可能會拒絕升級App，因為他們無法承受升級版本提供更多服務帶來的高額計算和存儲成本。一些以前的用戶可能不想更新他們的App，因為升級版本通常需要更好的設備、更多的計算能力和更多的存儲空間。因此，舊版本中使用的早期 API 不能直接關閉，盡管它們可能不夠安全。

C.緩解

由于開發者不能放棄不想升級他們的App的用戶，因此很難防止App遭受此類攻擊。在現實生活中，一些App希望每隔幾周更新一次客戶端，而服務器仍會支持早期版本，直到幾個月后。這是安全性和便利性之間的正確平衡點。雖然有些App今天不能被攻破，但這并不意味著它在未來永遠不會被逆向。隨著逆向工程技術的進步，目前被認為是安全的App，可能有一天會被攻破。因此，持續保持程序代碼保護的開發過程并定期關閉早期的API，可以緩解此類問題。

Conclusion

在本文中定義并研究了一個問題，即早期版本的 App 會使升級后的 App 面臨被攻擊的風險。由于早期版本很容易受到逆向工程技術的影響，因此早期版本中存在的漏洞可以作為構建塊對升級版本發起更嚴重的攻擊。在示例中對Cloud-Driven發起了 MITM 攻擊，并破解了來自 Facebook 和Weibo的 HMAC 密鑰。此外，通過逆向工程技術設計了一個靜態分析器DroidSkynet，以檢測大量App中的此類潛在問題。DroidSkynet 使用從現實世界中收集的 1500 個App進行評估。實驗結果表明，這些 App 中大部分都存在此類問題。使用較早版本攻擊 App 的成功率為 34%。此外還提出了一些建議，以彌合 App 更新的實用性和安全性之間的差距。