首先这篇文章是具体参考【原创】**应用加固的脱壳分析和修复，上文作者在今年2月12号发了一篇文章详细分析了整个过程，由于腾讯加固的技术也不断演进，所以我在上文的基础，分析现在7月份腾讯加固采用的新方法。与上文重复的部分就不再过多说明，所以阅读本文之前，要首先看懂上文的大致思路。
查看加固的DEX
首先，用010 Editor来分析一下该加固后的DEX文件，在文件的尾部明显看到injected_data，injected_data的偏移地址为0x415C，大小为0x1310BF，选中这一部分数据，可以看到明显的qihoo文件头，黑色下划线的部分：0x71, 0x68, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00。在libprotectClass.so加固的版本中，最初的版本文件头的后四位均为0，后面的升级版本后四位可能为数据大小。
关键部分数据分析
在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的部分。
代码的思路
具体的代码可以参考Recover origin DEX from protected one
- 首先定位到
injected_data，用KEY来对加密的数据进行RC4解密 - 解密后数据进行标准的
lzma解压缩，就可以得到DEX文件 - 对DEX文件的header进行恢复，用8bit的数，对DEX Header，即头部大小
0x70的数据进行异或处理，这样就得到原始的DEX Header，而这个8bit的数，就是偏移0x108那个8bit的数：0x9a。