对抗静态分析——运行时修复dex
对抗静态分析——运行时修复dex
本文来源:i春秋社区-分享你的技术,为安全加点温度
零、写在前面
这个系列本来题目想写对抗反编译,可是想想对抗反编译的这个范围有点大,总结如下
灵魂作图
<ignore_js_op>![]()

自己比较熟悉的是静态分析,所以就从这里入手吧,省的吹大了,挖了坑填不上那就不好了。当然也会写些动态分析的东西。
废话少说,开始吧,最近又把脱壳拿出来看了,就从这里开始吧
一、理论(总要解释一下)
壳是一个比较大的概念,发展的比较迅速。未来(或者现在?)加壳的主流会逐渐变为第四代壳,也就是VMP,各个厂商自己搞一套解释器,但是这种方式对运行效率影响比较大(有多大我没有详细的数据,也可能现在已经拿出来的VMP加壳方案已经解决了很大程度上的效率问题?这个不清楚)。
这篇讲的是一种采用比较多的办法,在运行时对dex进行修改。针对源APK(也就是真正运行的APK),将dex文件中的某部分指令提取出来,保存为一个文件。然后将dex文件中的这部分指令修改为错误的字节码,比如0x00 0x00 0x00 0x00 0x00 。。。运行时,壳程序将这部分指令修复。修复的方法简单点可以直接替换回去,如果复杂点可以在dex文件的范围外new一块区域,然后将原本指向这部分指令的指针指向new出来的区域(也就是在dex外部),这样即便你通过动态分析对dvmDexFileOpenPartial这样的API下断能dump出dex文件,还是没有办法正确反编译,因为正确的指令还是没有加入进来。
整个过程分为两个阶段
第一阶段:提取、替换正确的dex中的指令
第二阶段:运行时修复替换之后错误的dex文件
1、定位——提取——替换
首先,在dex中定位code的位置,我们看看android源码是怎么写的
源码位置dalvik\libdex\dexFile.h
[AppleScript] 纯文本查看 复制代码
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
|
/* * Direct-mapped "code_item". * * The "catches" table is used when throwing an exception, * "debugInfo" is used when displaying an exception stack trace or * debugging. An offset of zero indicates that there are no entries. */struct DexCode { u2 registersSize; u2 insSize; u2 outsSize; u2 triesSize; u4 debugInfoOff; /* file offset to debug info stream */ u4 insnsSize; /* size of the insns array, in u2 units */ u2 insns[1]; /* followed by optional u2 padding */ /* followed by try_item[triesSize] */ /* followed by uleb128 handlersSize */ /* followed by catch_handler_item[handlersSize] */}; |
这个结构,从上到下分别表示
~~~~~~~~~~~~~~
该函数寄存器的数目
传入的参数个数
调用其他函数时需要的参数个数
try结构的数目
debug信息的偏移
指令列表大小
该函数的指令
~~~~~~~~~~~~~~
看注释,这个结构我们一般不叫它DexCode,而是code_item(关于各种item,在深入Androguard源码中有解释)
而指向它的指针,位于encoded_method结构中的codeoff(源码位置dalvik\libdex\DexClass.h)
[AppleScript] 纯文本查看 复制代码
|
1
2
3
4
5
6
|
/* expanded form of encoded_method */struct DexMethod { u4 methodIdx; /* index to a method_id_item */ u4 accessFlags; u4 codeOff; /* file offset to a code_item */}; |
那么这个DexMethod来自于哪里呢?在这里(同一文件下)
..............................................略

浙公网安备 33010602011771号