1.classes.dex重名
漏洞原理
漏洞的关键点在于，Android假设一个APK包中的文件是不会重名的。可实际上Zip格式是允许一个Zip文件包含具有相同文件命的文件。（注意，这里的文件名，包括这个文件在Zip包里的相对路径）。
Android在安装应用时，会抽取APK包中每个文件，进行签名验证。但如果碰到了相同文件名的文件，则只会校验第二个文件，而忽略第一个文件。
另外在应用运行前会释放classes.dex到/data/dalvik-cache/目录生成优化过的odex文件，然后再运行。这个阶段如果APK里有两个classes.dex，就只会抽取第一个classes.dex进行优化，而忽略第二。
好了，说到这，相信读者应该明白怎么利用这个漏洞了吧。
如果我们将一个APK包中放入两个classes.dex文件。第一个classes.dex是被我们篡改过的恶意dex文件；第二个classes.dex是原来这个APK中的classes.dex文件。那么在签名验证时，就会验证原来的classes.dex，因此通过验证；而执行时，却执行了被篡改过的第一个classes.dex。
攻击步骤
a)
b)
c)
d)
e)
f)
总结
a)
b)
c)
2.extra file length溢出
在讲这个漏洞之前，首先需要搞明白java里short类型转int类型的问题。要理解这个漏洞，必须明白这个技术点。
public class JavaTest {
}
在每个Zip文件中都有一个Central directory，Central directory中的每一项是一个File header。这个File header的结构对应到Android代码的类就是ZipEntry。File header结构中有一个偏移量指向local file header，local file header后面就紧跟着file data。接下来我们详细看一下local file header的结构。
local file header signature 4 bytes
version needed to extract
general purpose bit flag
compression method
last mod file time
last mod file date
crc-32
compressed size
uncompressed size
file name length
extra field length 2 bytes
可以看到，除最后2个域以外，local file header的其他域都是定长的。而这两个变长域的长度是由file name length和extra field length所确定。再次说明，紧跟在extra field后面的就是文件的数据file data了。
Android在进行apk文件校验时，会调到ZipFile的public InputStream getInputStream(ZipEntry entry)函数。这函数中，有这么一段：
int localExtraLenOrWhatever = Short.reverseBytes(is.readShort());
rafstrm.skip(entry.nameLength + localExtraLenOrWhatever);
注意：上述代码中红色部分。localExtraLenOrWhatever就是local file header结构中的extra field length。回想一下我们第一部分将的技术点，如果这里的extra filed length的大小是大于2^15，会怎么样？
没错，localExtraLenOrWhatever将会是负值。因此接下来，rafstrm.skip(entry.nameLength + localExtraLenOrWhatever); 这句将无法真正跳过变长域file name (variable size) 和extra field (variable size)。反而有可能呢会跳到file name (variable size)中，甚至file name (variable size)之前。当然为了攻击方便，我们还是期望它跳到file name (variable size)中。
如何实施攻击
要改变一个apk的行为，显然攻击的目标就是apk里的classes.dex文件。对于classes.dex文件在apk文件中的local file header结构，其file name (variable size)域的内容肯定就是“classes.dex”了。注意，这里的后缀名dex，正好和dex文件开头的三个字节完全相同（不理解的，参见dex文件格式）。
a)
b)
c)
d)
具体攻击模型，如下图。
总结
总的来说该攻击手段，首先利用了Android在签名验证过程中，对Zip文件相应16位域的读取时，没有考虑到大于2^15的情况。（因为java的int , short, long都是有符号数，而不像C/C++里有无符号数）。
其次利用了Zip文件中的local file header结构的extra field域来存放原classes.dex。但这个域的大小最多只能是2^16-1，因此被攻击的Apk里的classes.dex大小必须在64K以内。否则，就无法对其进行攻击。这算是这种攻击方式的一个限制。
最后还有一个问题补充说明：之所以这种攻击方式能成功，还在于在运行时，系统抽取的是hacked classes.dex，而在签名校验时，验证的是extra域里的classes.dex。前者是在libdex.so中实现，后者在Java层实现。是由Java层跟Native层不一致导致。
