首先这篇文章是具体参考【原创】**应用加固的脱壳分析和修复,上文作者在今年2月12号发了一篇文章详细分析了整个过程,由于腾讯加固的技术也不断演进,所以我在上文的基础,分析现在7月份腾讯加固采用的新方法。与上文重复的部分就不再过多说明,所以阅读本文之前,要首先看懂上文的大致思路。

1.查看加固的DEX

首先,用010 Editor来分析一下该加固后的DEX文件,在文件的尾部明显看到injected_data,injected_data的偏移地址为0x415C,大小为0x1310BF,选中这一部分数据,可以看到明显的qihoo文件头,黑色下划线的部分:0x71, 0x68, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00。在libprotectClass.so加固的版本中,最初的版本文件头的后四位均为0,后面的升级版本后四位可能为数据大小。
DEX文件

2.关键部分数据分析

在injected_data数据部分,偏移0x10c开始的数据,长度为0x10,图中的红色下划线部分,为标准RC4加密的KEY,16字节,128bit的KEY。
然后紧随其后偏移量为0x11c的5个比特,白色下划线的部分为lzma的压缩级别:0x5D, 0x00, 0x00, 0x00, 0x01。
接着偏移量为0x121的4个比特,灰色下划线的部分为解压缩后的DEX文件大小:0xBC, 0x4B, 0x4D, 0x00。
最后偏移量为0x125的4个比特,绿色下划线部分为加密的DEX文件大小:0x96, 0x0F, 0x13, 0x00。
加密的数据部分就是从偏移量0x129开始,长度为0x130F96的部分。

3.代码的思路

具体的代码可以参考Recover origin DEX from protected one
1.首先定位到injected_data,用KEY来对加密的数据进行RC4解密
2.解密后数据进行标准的lzma解压缩,就可以得到DEX文件
3.对DEX文件的header进行恢复,用8bit的数,对DEX Header,即头部大小0x70的数据进行异或处理,这样就得到原始的DEX Header,而这个8bit的数,就是偏移0x108那个8bit的数:0x9a。

更多