Bluebox Security在7月3號的時候，在官網上發布了一個據稱99%
Android機器都有的一個漏洞。國內最早在4號開始有媒體報道，并持續升溫。該漏洞可使攻擊者在不更改Android應用程序的開發者簽名的情況下，對APK代碼進行修改。并且，這個漏洞涉及到從1.6版本至今全部的Android版本，換句話說，這4年中生產的9億設備，即當今市場上99%的Android產品都面臨這一問題。
如果是APK安裝校驗簽名的漏洞，而這個Bug又從1.6開始就有，那也太傷我自尊了。出于某種嗜好，俺怎么著也是從1.5起就對包管理充滿了濃厚興趣，2011年還寫了一篇
《Android
APK 簽名比對》的文章，里面對Android簽名機制做了稍詳細的解析。不過回過頭來一想，Google Android負責包管理的工程師估計更傷自尊了，當然這是后話。
在將信將疑的感情中，迎來了一個休息兩天的周末。于是我開始翻翻包管理的代碼，跟著APK安裝流程往下看。以前一直有個地方讓我覺得google工程師真的這么重視效率嗎？結果今天一看，發現好像存在問題。大家來評評：
安裝應用的時候包管理檢查簽名不知檢查了多少次，在這里針對系統應用卻只檢查manifest.xml一個文件的簽名。Google Android工程師真的是為了效率么？不管怎樣，他一定是深思熟慮之后的結果，因為這里有段注釋：“If this package comes from the system image, then we can trust it... we'll just use the AndroidManifest.xml to retrieve its signatures, not validating all of the files.”（所以如果真是這段代碼導致的漏洞，他真傷自尊了...）
事實上，大多數時候安裝一個APK對于Android來說是一個復雜的過程，這個過程中Google為了安全做了很多冗余的事情。但是結合Bluebox Security的漏洞描述，我聯想到一種情況。那就是開機過程中掃描安裝/system/app中的應用時！基于這個想法，我自己鼓搗了一會兒，發現按這個邏輯往下還真能繞過簽名認證！當然，還有一些令人掃興的附加操作，例如需要root權限以對/system/app下的文件進行讀寫操作。
這里我貼一下我的操作步驟吧。
（先聲明：我所描述的不一定是Bluebox Security最近宣稱的漏洞，只是一種系統應用修改代碼而繞過Android簽名校驗的方法。Bluebox Security所描述的漏洞據官網消息稱，將由Bluebox的CTO Jeff Forristal，在本月27號到8月1號的拉斯維加斯美國黑帽安全大會上講話時，公布具體的技術細節并放出相應的工具和資料）
1、好吧，我以MIUI ROM中的系統應用FileExplorer為例（切記這是99%
Android手機都有的漏洞，MIUI是無辜的）。
2、找一臺刷了MIUI的手機，先將它從/system/app摳出來。（這個apk我們暫且稱作APK_ORG）
3、使用apktool工具（或者其他類似工具）將FileExplorer.apk反編譯。apktool需要安裝MIUI的Framework資源包，詳查百度。
4、修改smali代碼，想怎么改怎么改，這里我只是在onCreate的時候打印了一個Log。
5、將smali及其他文件再打包成apk文件。（這個apk我們成為APK_DIST）
(前面的步驟和一般破解的步驟都差不多, 后面就不一樣了。)
6、將APK_ORG做zip包解壓，取出其中META-INF文件夾和AndroidManifest.xml文件。
7、將尚未簽名的APK_DIST用WinRAR打開，將APK_ORG中取出的META-INF文件夾和AndroidManifest.xml文件拖入APK_DIST中。
（OK，apk包做好了！）
8、將APK_DIST命名為FileExplorer.apk（與手機中文件管理器名字相同）。
9、adb push APK_DIST 到 /system/app/ 下，覆蓋原來的APK_ORG。
到此為止，大功告成了！如果系統沒有更新應用，可以重啟一下手機。結果發現文件管理器安裝成功，自己添加的Log正常打印，之前在APK_ORG時登錄的網盤（快盤），數據都在且能正常使用。
總結：這段代碼應該是從1.6之后就一直是這樣，因此符合Bluebox Security所說的99%
Android手機都存在此漏洞。但是我現在發現的漏洞需要手動root之后才能操作出來，且只針對system app，與Bluebox
Security所描述的情況有所出入。也許是同一個漏洞，不同的操作方式，也許不是同一個漏洞，或者這個壓根不算漏洞。希望這篇文章起到拋磚引玉的作用，呼吁國內Android安全人員和手機廠商一起加入探討～
（哦，對了，我直接把這個apk放到官方ROM中會怎么樣？文章發布后，再試試～ ^-^）
關于ANDROID-8219321漏洞的后續補充說明。沒有后續補充說明，這篇文章是不完美的。因為實際漏洞并不是上文分析的這個。
具體后續跟蹤，之前只在看雪論壇上發布，沒有更新過來。為了本文的完整性。先將看雪上我發的后續跟蹤分析的帖子一起貼在這里。★ 2013.07.08 （
http://bbs.pediy.com/showthread.php?t=174928）
更新補充說明：
目前已確認本文所述問題與bluebox所說的漏洞不是同一個問題。大家可以繼續研究，但是與bluebox所稱的漏洞無關。
bluebox所述漏洞編號：ANDROID-8219321。Insertion of arbitrary code without changing package signature due to incorrect parsing of APKs (update to previous bulletin)First published: March 4th, 2013Last Updated: May 31st, 2013ID: ANDROID-8219321Severity: HighAffected Android Versions: all由于可能涉及保密問題，更多信息在我確認允許公布后才能公布。現在可以說的是，確實是對apk包進行處理，無需操作權限。可能不是Google本身的問題，上傳應用商店后下載即可直接安裝。我沒研究過這部分代碼，因為以為它是不會出問題的。。。最后想說，出問題的代碼就一句話。。。
★ 2013.07.10 （
http://bbs.pediy.com/showthread.php?t=175175）
這兩天這個問題基本已經公之于眾了。所以不用再保密了。相關信息及自己研究的一些結果放上來，匯總一下。首先是3月和5月google官方發出的補丁說明：3月：Improper installation of unsigned codeID: ANDROID-8219321Severity: HighAffected versions: Android 2.0 and greaterAn inconsistency in the handling of zip files during application installation may lead to the installation and execution of unsigned code in a privileged context.This issue will be publicly disclosed in 90 days. A CTS test will be included in the next CTS release.5月：Insertion of arbitrary code without changing package signature due to incorrect parsing of APKs (update to previous bulletin)First published: March 4th, 2013Last Updated: May 31st, 2013ID: ANDROID-8219321Severity: HighAffected Android Versions: allArbitrary code can be inserted into an APK and pass signature verification due to incorrect parsing of APKs. A maliciously crafted classes.dex can be inserted before a legitimately signed classes.dex in an APK. Signature verification will be performed on the second, legitimate classes.dex, but the first, malicious classes.dex is installed for application use. Update: This issue will be publicly presented at Blackhat 2013. Please see http://www.blackhat.com/us-13/briefings.html#Forristal for more details. At that time, we expect active public exploitation of this issue outside of Google Play.官方補丁：patch.rar.---------------------------------------------------------------------------------當然大家關注這個問題是在7月3號bluebox在官網發文以后。發文地址：http://bluebox.com/corporate-blog/bl...id-master-key/由于問題的嚴重性，一時間大家開始研究起來。漏洞基本公之于眾是在7號cyanogenmod打上補丁之后。詳見：http://review.cyanogenmod.org/#/c/45251/根據打補丁的代碼，大家推測到是apk中存在兩個相同的classes.dex文件。于是大家又開始研究POC的問題。我也自己做了嘗試，由于打包順序問題沒弄出來（失之毫厘，謬以千里啊~）。今天上班沒法弄，之后大家關注到了這個網址：https://gist.github.com/poliva/36b0795ab79ad6f14fd8---------------------------------------------------------------------------------到這本來應該已經完了。結果下午我網上下載了一個網易新聞Android客戶端按照上面網址的操作方法，卻怎么也安裝不上。我曾懷疑是我方法的問題，后來寫了一個簡單的demo，發現通過這個方法又能成功安裝。這個方法是將原始apk數據全部壓縮進修改后的未簽名的apk中，體積直接增大了一倍！網站上自己對這個方法的描述也是“Quick & dirty PoC for Android bug 8219321 discovered by BlueboxSec”。所以確實存在問題。經過上述方法的啟發，我明白之前的方法問題出在壓縮順序上。應該是先壓縮修改后的dex文件，再壓縮原本的dex。于是，比較完善的方法是：1、將原本的apk中的文件解壓出來。分成兩個文件夾，orgin_dex和orgin_nodex。其中orgin_dex僅放解壓出來的classes.dex文件，orgin_nodex放剩余的所有文件。2、創建第三個文件夾dirty_dex，放修改之后編譯出的classes.dex文件。3、利用ant打包。build.xml如下：代碼:
<?xml version="1.0" encoding="UTF-8"?> <project name="MyProject" default="dist" basedir="."> <zip destfile="evil.apk" duplicate="add"> <fileset dir="D:\\ant\\orgin_nodex\\"/> <fileset dir="D:\\ant\\dirty_dex\\"/> <fileset dir="D:\\ant\\orgin_dex\\"/> </zip> </project>