# Android uncovers master-key 漏洞分析 Author: 乌云历史资料库 (@wooyun_archive) Published: 2013-07-11T04:38:00Z Canonical: https://wepostx.com/topics/633 > 乌云历史资料归档 > > **原始作者：** livers > **原始编号：** superkieran-wooyundrops:40 > **原始发布时间：** 2013-07-11 12:38 > **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。** --- ### 0x00 背景 Bluebox的CTO Jeff Forristal在其官⽅方blog爆出一个漏洞叫做UNCOVERING ANDROID MASTER KEY,大致是不篡改签名修改android代码。 Link:[http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/](http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/) ##### blog:关于细节并没有讲太多,只有discrepancies in how Android applications are cryptographically verified & installed(安卓应⽤用签名验证和安装的不⼀一致)essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been(让andriod系统本⾝身认为应⽤用没有修改)这两条重要的信息。 剩下就是放出来一张更改基带字串的图: ![原文图片](/media/2016/06/4ed20f0793621aabd5e83dedcad2726f) 具体细节7月底的blackhat放出。 没多少天7月8号国外已经有人放出poc来。微博上看到rayh4c说已经搞定。就分析了一下。 ### 0x01 分析 POC还没出来之前,先是看了下android的签名机制和安装机制。 签名机制: 用简单的话来讲就是android把app应用的所有文件都做了sha1(不可逆)签名,并对这签名用RSA(非对称加密算法)的私钥进行了加密,客户端安装验证时用公钥进行解密。 从逻辑上看,这签名机制对完整性和唯一性的校验是完全没问题的。主流的很多加密都类似这样。 安装机制: 安装机制则较为复杂。 ```text 1.系统应用安装――开机时完成,没有安装界面 2.网络下载应用安装――通过market应用完成,没有安装界面 3.ADB⼯工具安装――没有安装界面。 4.第三⽅方应用安装――通过SD卡⾥里的APK⽂文件安装,有安装界面,由packageinstaller.apk应⽤用处理安装及卸载过程的界面。 ``` 安装过程:复制APK安装包到data/app目录下,解压并扫描安装包,把dex⽂文件(Dalvik字节码) 保存到dalvik-cache目录,并data/data目录下创建对应的应⽤用数据目录。 到这里看出在安装机制上的问题可能性比较大。 回头看⽼老外的POC:[https://gist.github.com/poliva/36b0795ab79ad6f14fd8](https://gist.github.com/poliva/36b0795ab79ad6f14fd8) ![原文图片](/media/2016/06/d2e84dd5fc116bdcd8a996ad300c3eb7) 在linux执⾏行了一遍,出现错误。可能是apk的原因。 索性把这poc移植到windows下,先是⽤用apktool 把要更改的apk给反编译出来到一个目录apk_test 然后⼜又把apk_test打包成⼀一个新的apk 把原先的apk解压出来apk_old 把apk_old所有⽂文件以zip压缩的⽅方式加⼊入新的apk中。我本机以weibo.apk为例: ![原文图片](/media/2016/06/9314e882c4e5345800201e3bb190b38f) 可见两者大小发生了变化,apktool在反编译过程不可避免的出现差异。并且重编译的apk不含有签名文件。 按照poc的做法我用批处理导出目录的文件名到1.txt修改了poc.py ```text import zipfile import sys f=open('1.txt','r') line=f.readline() test=[] while line: test1=line.replace("\n","") test.append(test1) if not line: break line=f.readline() f.close() z = zipfile.ZipFile("livers.apk", "a") for i in range(0,len(test)): print test[i] z.write(str(test[i])) z.close() ``` ![原文图片](/media/2016/06/cd0ec7dc8b853c2e6d275256915e4d53) 差不多增大了一倍,放在手机上安装了一下,成功安装。查看了下: ![原文图片](/media/2016/06/d3cb6dbf9e969e1253d4f677028be437) 出现了多对同名文件。CRC校验不同,查看了一下,基本上是两个字节便产生不同。 ![原文图片](/media/2016/06/956579475ceb23a53328e904eab48b19) 这里我又测试了只添加签名文件,或者dex文件等,均不能通过验证。 可证明其在scan list扫描目录或者复制文件时候对同名文件处理不当。 ### 0x02 验证 证明是否可以进行更改源码,并能使用原生签名。我把apk图标进行了更改。 顺便讲下一般的反编译修改: ```text 1. apktool或者其他工具进行反编译包含smalijava字节码汇编和xml图片文件。 2. apkzip解压。 3. 反编译dex成java文件。 4. 查找对应修改的smali文件或者xml(一般广告链接) 5. Apktool打包成apk文件 6. 用autosign进行签名。 这里没有进行签名直接借用原来的签名。 ``` ![原文图片](/media/2016/06/4d95d09ee440eb21447d92007d865bd6) ![原文图片](/media/2016/06/5de8cb7f7df8691c2ffceea52884b931) ### 0x03 查找根源 我这里下载的android 2.2的源码，查找到获取签名信息安装位于frameworks\base\core\java\android\content\pm\PackageParser.java这个文件，public boolean collectCertificates(Package pkg, int flags)和private Certificate[] loadCertificates(JarFile jarFile, JarEntry je, byte[] readBuffer)这个方法是用来获取签名信息的。 ```text Enumeration entries = jarFile.entries(); while (entries.hasMoreElements()) { JarEntry je = (JarEntry)entries.nextElement(); if (je.isDirectory()) continue; if (je.getName().startsWith("META-INF/")) continue; Certificate[] localCerts = loadCertificates(jarFile, je, readBuffer); 。。。。。。 } else { // Ensure all certificates match. for (int i=0; i