某版本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做结构上的变形和处理，处理的流程如下：

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

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

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

Jerry 2015年4月25日 11:55
key也藏在壳的dex文件中么？否则怎么解密？
回复 ↓
1. TheCjw 文章作者2015年4月25日 22:08
  图中绿框所示即RC4的key。
  回复 ↓
Asuka 2015年9月24日 17:03
首先会生成8字节的随机数
这8字节的随机数怎么生成的？
回复 ↓
1. TheCjw 文章作者2015年9月24日 17:57
  笔误，生成的是8bitd随机数，即一个字节。然后用该字节对DexHeader进行逐个字节异或。
  所以猜就好了，因为DexHeader中有些域始终为0。
  回复 ↓
  1. Asuka 2015年9月29日 18:45
    看来新版的加密方式不一样了，用这个方法已经不能解密
    回复 ↓
    1. TheCjw 文章作者2015年9月29日 22:18
      libjiagu？
      回复 ↓
      1. ZT 2015年10月8日 15:49
        请问偏移10C是如何得到的呢？
ZT 2015年10月8日 15:53
而且我这里的文件头标志是0x71,0x68,0x00,0x01, 0x67,0x00,0x1A,0x00, 后面四个好像是长度
回复 ↓
1. TheCjw 文章作者2015年10月8日 20:36
  你的样本也许是新版，确认一下。
  回复 ↓
  1. ZT 2015年10月8日 23:51
    还有一个问题：你的例子里的偏移0x10C是如何得到的？
    如何确实是不是新版呢？
    谢谢
    回复 ↓
    1. TheCjw 文章作者2015年10月9日 11:56
      外层DEX的Loader有版本号。
      0x10C是脱掉壳的so之后分析得到的。
      回复 ↓
      1. ZT 2015年10月9日 16:37
        我在脱壳方面是新手，好多都不是很明白，就是看你的文章刚开始试验。很希望以后能得到你的指点。我如何能学习你的其他文章呢？
米健 2015年12月11日 15:55
看了你的帖子，感觉很有帮助。有个问题，我在脱壳的时候，用16byte的key进行RC4解密，然后lzma解压是报错，不知道哪里有问题，请您指教，谢谢！
回复 ↓

发表评论取消回复