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压缩包动手了。

游客，如果您要查看本帖隐藏内容请回复

下次写文章的时候 带下你参考的链接吧
也是对其他原创的尊重

牛逼支持，又学到一条

支持一下，，，，，进来学习了呀。

少月威武。。。受教。。。。

谢谢分享经验！

，又学到一条，又学到一条

牛逼支持又学到了

支持一下。。。

4.4以下