背景

随着移动应用的广泛普及，恶意软件也日趋复杂和隐蔽。本报告着眼于一个由 ReBensk 提交至 incinerator.cloud 的恶意 Android 软件样本。

• 样本哈希值：

• MD5: 2f371969faf2dc239206e81d00c579ff

• SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

在 ReBensk 提交至 incinerator.cloud 的多个恶意样本中，我们特别关注了一款经过自定义修改的 APK 文件，以下简称为“样本 b356”。这个样本采用了独特的混淆和隐蔽技术，导致标准的解压缩工具无法成功解压其内容。通过特定的修正操作，我们成功突破这一限制，并进一步分析了该样本。

分析过程

1. 解压失败分析

在尝试使用 7z 工具解压这个 APK 文件时（Apk 本质上是一个 ZIP 文件），遇到错误显示 AndroidManifest.xml header 错误，这说明标准的解压过程无法正确地解压样本 b356。

在使用 010 Editor 打开 APK 文件并应用 ZipAdv 模板进行解析后，并未发现任何明显的错误或异常。

为了更深入地了解问题，我们打开了一个正常运行的 APK 文件进行对比分析。这样做是为了确定是否存在某种特殊或不规则的结构或数据，可能是导致解压失败的原因。

通过对比发现，我们发现样本 b356 采用了一个不非法的压缩算法 0x23C2。在标准的 ZIP 格式规范中，压缩方法由一个短整数（short）表示，取值通常如下文所示（以下代码取自 010 Editor 的 ZIPAdv.bt 模板）。由于 0x23C2 不是任何已知的标准压缩方法，因此 7z 等解压工具无法识别和处理。

因此，样本 b356 采用了未知的压缩算法，导致通用压缩工具解压缩失败。但为什么它能在 Android 系统上仍然可以成功安装和运行呢？

2. Android 系统的成功解析与运行原因

正如下图所示， 根据 Android 系统源代码，当系统遇到非 COMP_DEFLATE 的压缩算法时，它会采用“未压缩”（COMP_STORED）的方法处理输入文件。具体来说，系统直接读取未压缩数据的长度，并据此进行解析。

请注意看黄框和红框中的代码对比，在黄框中，如果使用的是 COMP_DEFLATE 压缩算法，系统将按照相应的方法解压缩，如果不是，系统将直接读取压缩前的长度，然后进行处理。

这就解释了为什么修改了 AndroidManifest 的压缩方法后，系统仍然可以正确运行。样本 b356 在正常打包流程完成后，将包中的 AndroidManifest.xml 文件内容替换为未压缩前的内容，并将压缩算法替换为非 COMP_DEFLATE 。因此，常规解压工具会失败，但 Android 系统会按照未压缩的方式处理，因此可以正常运行。

3. 解压程序的修改建议

3.1 修复 Apk

按照 Android 系统的处理方式，Apk 的 AndroidManifest.xml 只能采用两种压缩方式。COMP_DEFLATE 或未压缩。

如果压缩算法不是默认的 COMP_DEFLATE ，那么一定是未压缩。因此修复 apk 的方法是，如果发现压缩算法不是 COMP_DEFLATE ，将压缩算法设置为 0，即未压缩，并将压缩后的长度设置为压缩前的长度。这样，常规解压工具就可以解压了。

修复后，我们尝试使用 7-Zip（通常简称为 7z）工具进行解压，结果如下图所示。尽管仍然存在错误，特别是关于 CRC（循环冗余检查）值尚未修复的问题，但我们已成功解压了 APK 文件，并可以访问其中的 AndroidManifest.xml 内容。

3.2 静态分析工具的修复

静态分析工具可以按照系统的解压方式处理，如果发现 AndroidManifest.xml 的压缩方法不是 COMP_DEFLATE ，那么就读取压缩前的长度作为 AndroidManifest.xml 的内容。

总结

由于 Android 系统在解析时对非 COMP_DEFLATE 的压缩方式采取的是未压缩处理，从逻辑上看，这种做法并不符合规范，因此，导致 b356 成功地利用了这一逻辑漏洞。彻底的解决方案应该是 Android 系统按照规范的 zip 包解压格式进行处理。

来源：https://www.liansecurity.com/#/main/news/GzKmQIoBUQjGUXE22_tO/detail