android几个漏洞

1、apk伪加密

读取APK的字节，找到连续4位字节标记为”P K 01 02”的后第5位字节，如果是偶数表示不加密，如果是奇数就表示加密。



mod之后的压缩包：



解压缩要求输入密码：



文件解密不出来

防解压防反编译

应用限制：
4.2之前。

2、apk压缩文件被破坏

APK在PC上面可以看作一个压缩文件，在Android系统里面它就是一个手机系统软件文件。

Android系统对APK的识别是从标志头到标志尾，其他多余数据都会无视。

所以说在标志尾添加其他数据对把APK看做压缩文件的PC端来说这个文件被破坏了，

所以你要对其进行解压或者查看都会提示文件已损坏，用反编译工具也会提示文件已损坏，

但是它却不会影响在Android系统里面的正常运行和安装而且也能兼容到所有系统。

但是这种APK压缩包破坏存在APK伪加密一样的问题，个别市场会不能识别导致不能上传市场。





应用：阻止反编译

-------------------------------------------------------------------------------------------------------------------
> 正在清理旧工作目录 ... - 成功！旧工作目录被清理到系统回收站内。

> 正在反编译Apk... - 失败：Exception in thread "main" brut.androlib.AndrolibException: brut.directory.DirectoryException: java.util.zip.ZipException: invalid CEN header (bad signature)

at brut.androlib.ApkDecoder.hasSources(ApkDecoder.java:199)

at brut.androlib.ApkDecoder.decode(ApkDecoder.java:83)

at brut.apktool.Main.cmdDecode(Main.java:146)

at brut.apktool.Main.main(Main.java:77)

Caused by: brut.directory.DirectoryException: java.util.zip.ZipException: invalid CEN header (bad signature)

at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:55)

at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:38)

at brut.androlib.res.util.ExtFile.getDirectory(ExtFile.java:55)

at brut.androlib.ApkDecoder.hasSources(ApkDecoder.java:197)

... 3 more

Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)

at java.util.zip.ZipFile.open(Native Method)

at java.util.zip.ZipFile.<init>(ZipFile.java:214)

at java.util.zip.ZipFile.<init>(ZipFile.java:144)

at java.util.zip.ZipFile.<init>(ZipFile.java:158)

at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:53)

... 6 more

> .smali输出目录：F:\360云盘\书籍\android\ApkIDE\Work\com.example.helloapplication

> .class输出目录：Not supported.

-------------------------------------------------------------------------------------------------------------------

可以安装运行。无系统限制，可能会影响apk上线。

3、master key
原理：apk压缩包里构造两个classes.dex，原dex在后，java层的签名校验代码读取到一个dex时会继续读，最后是用的远dex进行签名校验，ok通过。
但是在运行时却是C代码，读取第一个dex（伪造的）就运行了。



4、second master key
漏洞的原理是java代码在读取“Central directory file header”结构的“Extra field length”字段（java代码视为有符号short，C代码视为无符号short）时，如果大小超过0x7FFF则认为是负数，代码逻辑将负数一律按零处理。

思考：comment字段是否也一样？如果是，则需要检测。

5、another master key

Java使用的fileNameLength是从索引段的ZipEntry获得的，而C则是从数据段的ZipEntry获得的，所以就这里造成了不一致性，导致java和c定位到的data[]不一致。因此可以在数据段的ZipEntry中构造一个不一样的fileNameLength，进而让java校验签名时读取的是合法的文件，而c在安装是读取的是恶意的文件，绕过签名验证。



由于fileNameLength这个字段的类型是一个无符号short，最大值为64K，所以为了能让C代码成功能跳转到fake classes.dex，必须要求 real classes.dex加上"classes.dex"字符串的长度小于64k。也就是说，对这个漏洞的利用要求被绕过的原始正常文件的大小必须小于64k，这对这个漏洞的利用带来了很大的限制，所以实际的危害并不很大。

替换资源文件，例如修改apk图标。