某版本360加固保动态调试&DEX静态脱壳

Intro

360加固保是360针对Android app推出的加固服务。本文针对其DEX加密技术进行分析。

动态调试

动态调试过程略过。

文件结构&静态脱壳

这个版本的加固保中,加密后的DEX文件被附在了壳DEX的文件尾部,如图所示:

qihoo_dex_unpack
感谢QQ6.4提供的马赛克功能。

这块数据有个明显的文件头标志:

const BYTE qihoo_payload_header [] = {
    0x71, 0x68, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00
};

之后的关键数据从偏移0x10C开始到文件尾部的数据,由长度为0x10的key和压缩、加密的DEX组成。在加壳的时候,加固保没有对原始的DEX做结构上的变形和处理,处理的流程如下:

  1. 首先会生成8字节8 bit的随机数,对原始的DEX Header,即头部大小0x70的数据进行异或处理。
  2. 接下来使用标准lzma压缩DEX文件。
  3. 最后随机生成长度为0x10的key,使用标准RC4对压缩后的数据进行加密。

由于没有对DEX进行结构上的变形处理(上一个版本的加固保有处理,估计兼容性有问题就移除了),静态脱壳十分简单。

某版本360加固保动态调试&DEX静态脱壳》有13个想法

    1. TheCjw 文章作者

      笔误,生成的是8bitd随机数,即一个字节。然后用该字节对DexHeader进行逐个字节异或。
      所以猜就好了,因为DexHeader中有些域始终为0。

      回复
  1. ZT

    而且我这里的文件头标志是0x71,0x68,0x00,0x01, 0x67,0x00,0x1A,0x00, 后面四个好像是长度

    回复
      1. ZT

        还有一个问题:你的例子里的偏移0x10C是如何得到的?
        如何确实是不是新版呢?
        谢谢

        回复
          1. ZT

            我在脱壳方面是新手,好多都不是很明白,就是看你的文章刚开始试验。很希望以后能得到你的指点。我如何能学习你的其他文章呢?

  2. 米健

    看了你的帖子,感觉很有帮助。有个问题,我在脱壳的时候,用16byte的key进行RC4解密,然后lzma解压是报错,不知道哪里有问题,请您指教,谢谢!

    回复

TheCjw进行回复取消回复