为了提升APP的安全性，加固技术应运而生。目前，App加固技术经历了以下四代技术发展

第一代加固技术——混淆技术；

第二代加固技术——加壳技术；

第三代加固技术——指令抽离；

第四代加固技术——指令转换，即现在经常被应用的VMP加固技术。

但是由于VMP加壳技术目前无标准化，所以各厂商加固的效果也不尽相同，我们抽选了一款经过VMP加壳过加固的APP来验证加固的安全强度，对比第三代加固安全性，看一下安全效果的对比。

1、首先我们来验证三代加固的安全：

三代加固：即抽取dex文件中DexCode的部分结构，即虚拟机操作码。在虚拟机加载到此类的时候对DexCode结构进行还原。从而保证app能正常的运行。

如图1-2，可知accountLogin()方法被抽取了，经过分析得知其hook 系统函数dvmResolveClass(以andorid4.4.4为例)，在系统执行此函数之前会先对ClassObject进行修复，修复之后即可正常运行。

修复演示：修复代码可以参考开源工具DexHunter,在dvm情况下，DexHunter脱壳工具主要的实现思路是修改Android源码文件/dalvik/vm/native/dalvik_system_DexFile.cpp里的Dalvik_dalvik_system_DexFile_defineClassNative函数的实现，具体操作是在Android系统代码调用函数dvmDefineClass进行类加载之前，主动地一次性加载并初始化Dex文件所有的类。

此时拿到类就是已经修复过的。以上为修复思路，仅仅作为参考。

修复工具部分代码见图1-1

图1-1

修复后的效果：如图1-2。

图1-2

反编译为java源码文件，代码逻辑更加清晰，如图 1-3

图 1-3

总结：抽取加固一般可以防住一些基础手段的攻击，但网上有很大一部分工具可以破解此类技术的加固，核心代码保护强度不够，对网上的工具稍作修改即可破解。

2、再次验证VMP加壳的安全性：

VMP加壳：VMP加壳在三代基础上，抽取代码后，并没有对代码进行还原，而是通过厂商自研的“虚拟机”来进行解析opcode，然后通过JNI 接口反射执行各个方法。VMP加壳对于对代码保护的效果、加壳后的运用价值相对于历代加壳技术就高出不止一个台阶了，那么下一步让我们拿出各加固厂商的自称的“VMP加壳”版本进行验证：

我们获取到*（匿名）厂商自称VMP加壳样本，通过初步分析确认该厂商VMP加壳版本有自己一套虚拟机操作码表，这个表和正常虚拟机操作码表是一一对应的关系。也就是说拿到了这个表就可以还原操作码。

首先通过HOOK JNI部分接口查看其是否是通过JNI接口来实现VMP函数执行。效果图2-0如下

图 2-0

可以确定此VMP是通过JNI接口来执行VMP函数。

通过一些手段可以拿到此加固的操作码表，需要一个一个操作码比较，其置换表（测试样本）如下图2-1所示,

图2-1

加固前被加固的方法如下图2-2，通过简单查看这些被”vmp”方法基本都是是一些事件方法，核心代码基本上采用的都是三代加固技术（测试样本）。

图2-2

可以知道，此加固是将原有的方法内容抽取掉并替换掉成自己的方法，然后在这个方法里通过反射调用原先的代码。还原工具部分代码如下图

通过hook dlopen函数等待libdexjni.so库加载，一旦加载成功开始获取相关函数，其中两个导出函数，可以获取DexCode的内存、处理加密后的DexCode。如图2-3

图 2-3

接着根据特征信息获取被加固方法的ID，如图2-4

图 2-4

调用通过调用libdexjni.so 中的方法进行还原。如图2-5

图 2-5

其中说测试样本的结构体.如下图也就是我们通过调用libdexJni.so中方法的返回值。如图2-6

图 2-6

通过如上方法可以还原此加固样本的“vmp”的方法。

还原效果如下图2-7可以和图2-2做对比

图2-7

总结：用VMP加固后的APP的还原过程是比较复杂和困难的，需要用大量的时间做相关分析，分析过程中的困难主要来自于函数名的混淆，由于现在的VMP都是基于JNI接口的，在某些情况下有可能泄露逻辑，比如HOOK 虚拟机的JNI接口函数，加上日志输出，还是可以看到调用的函数。但是，由于目前VMP加壳版本没有统一标准与要求，就导致了不同厂商给出不同VMP加壳版本的方案在对安全、性能上会呈现不一样的效果。