MasterKey签名验证漏洞简单研究
本作者是七少月对于安卓 Masterkey漏洞相信很多人不会陌生，也是一个很老的漏洞了，是一个安卓4.4系统以下都会存在的系统漏洞。不过有哥们把它利用JAVA开发出了一个jar包工具，利用这个工具可以对APK进行处理，处理之后重新生成的APK，签名不会有任何改变，但是执行的classes.dex却是修改后的。看起来很不错，这个工具使用起来很简单，下面简单说说，首先看看这个工具的内容和使用：这个工具中1.apk就是原始APK，AndroidMasterkey.jar就是这个jar包工具，moddedClassesDex.zip存放的就是修改后的classes.dex，运行bat文件就可以重新生成一个利用此漏洞的签名完全一样但执行的dex不同的APK。打开bat文件看看配置：很简单，就是命令运行这个jar包，对原始APK，名字为1.apk进行处理，修改后的dex在moddedClassDex.zip中，最终输出out.apk就是新的APK。如果你愿意，可以把这些名字更改，相当于更改配置。我们把生成的APK打开看看：关键就是这里面出现了两个DEX，而修改后的DEX放在原始的DEX前面，签名文件夹META-INF没有发生任何变化。我们看看这个JAR包，分析下原理。其实也是相当清楚，这个JAR包把原始APK数据抽取出来，然后全部压缩进修改后的未签名的APK中。这个手法也可以用于一些加固和加密，这里我们就不展开了。当然，以上原理也是本身这个签名漏洞的原理所在，如下图：但是，有时我们在处理一些APK时，运行bat文件，会出现错误，然后一堆错误提示后，bat文件闪退。出现这种情况，我们可以使用原始的ANT方法来处理这个APK，详见看雪的帖子：这个利用签名漏洞来过签名验证的方法明显更为简单有效，比HOOK签名办法可以说更加具有操作性和容易理解，HOOK往往要HOOK很多处，且兼容性要重新去处理。再来往前看看，这个漏洞是怎么工作于系统的，其实也比较简单，当要安裝 APK时，Android会检查其凭证。主要的 function 是 ZipFile 的 mEntries struct。而当读取 ZIP 档时, 系统会寻找 Zip Central Directory Entry. 以 Name 当成 index, 依序放置LinkedHashMap 中。当 index 发生collision 时，LinkedHashMap 会回传旧的值，并以新的值取代。因此检测凭证时会使用原始的 classes.dex，但执行的却是修改后的classes.dex。在执行过程中，几个关键性的函数如下：执行APP的关键步骤：开启一个ZIP档： 依照ZIP入口点的顺序，找回ZIP档中的DEX，找到后直接回传，因此，执行的是新的DEX：当你看到以上过程，立刻会明白这个方法的一个弊病，就是由于要运行修改后的DEX，所以把修改后的DEX放到前面，然而，这种做法势必会使当APK采取DEX检测时，修改后的DEX会首先被检测到，导致无法通过DEX检测。这也是这种办法的一个弱点所在。不过上述函数给了我们启发，当我们面对APK完整性检测时，往往会写在so里，如果看到一些函数名为dexzipXXXX，那么我们就要注意了，可能它要对APK压缩包动手了。下载地址：http://pan.baidu.com/s/1mgF2ZTA
好厉害的样子！！前排支持，学习一下~ 链接已挂,楼主看见记得补下链接 谢谢 连接已失效 谢谢分享！！！！！！！！！11 请教一个问题，有一个电视直播软件，每次开机会下载服务器的直播源，能将这个地址改到我的直播源网址吗？
页:
[1]