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>