Dex文件是Android平台上可执行文件的类型。为了提升移动APP的安全性，通常会对Dex文件进行加固保护，本文简单介绍了Dex加固原理和方法。
1.整体Dex加固
DEX加固是对DEX文件进行加壳防护，防止被静态反编译工具破解而泄露源码，最刚开始出现的是整体加固技术方案。
整体加固技术的原理如上所示，包括替换application/classes.dex、解密/动态加载原classes.dex、调用原application相关方法、将原application对象/名称设置到系统内部相关变量四大环节。其中最为关键的一步就是解密/动态加载原classes.dex，通过加密编译好的最终dex源码文件，然后在一个新项目中用新项目的application启动来解密原项目代码并加载到内存中，再把当前进程替换为解密后的代码，能够很好地隐藏源码并防止直接性的反编译。
整体Dex加固逆向分析
整体Dex加固逆向分析有两种常用的方法。其一是在内存中暴力搜索 dex\n035，再 dump。以下是在32位系统中的效果示例：
另一种方法就是通过Hook dvmDexFileOpenPartial(void* addr, int len, DvmDex**)。
2.拆分Dex加固
但是如上所示，dex文件在加固时，针对中间缺失的一部分数据会以解密后的数据来替换，有的时候这种拆分替换也会导致数据不准确。那么到底应该拆分什么样的数据呢？就需要了解一下dex文件的数据结构。
Dex文件结构极为复杂，以下图示选取了其中较为重要的内容。事实上，dex文件是一个以class为核心组装起来的文件，其中最重要的是classdata和classcode两部分，有其特定的接口和指令数据，选取这两部分来拆分的话，即使拆分出来也不会泄露class数据和字节码数据，反编译出来也不完整，安全性较高。
但是如上所示，dex文件在加固时，针对中间缺失的一部分数据会以解密后的数据来替换，有的时候这种拆分替换也会导致数据不准确。那么到底应该拆分什么样的数据呢？就需要了解一下dex文件的数据结构。
Dex文件结构极为复杂，以下图示选取了其中较为重要的内容。事实上，dex文件是一个以class为核心组装起来的文件，其中最重要的是classdata和classcode两部分，有其特定的接口和指令数据，选取这两部分来拆分的话，即使拆分出来也不会泄露class数据和字节码数据，反编译出来也不完整，安全性较高。
拆分Dex加固逆向分析
对于dex拆分加固的逆向分析，如下所示，可以用classdata替换从而组装成新的dex文件，虽然和原来的dex文件不会完全一致，但也在一定程度上复原了被拆分数据的样子。
但要注意的是，这种方法仅适用于被拆分出去的数据变形一次性完成，也就是说，在有其他保护思路的情况下尽量避免使用，而且即使有需要也尽量选在用到这个类的时候才去恢复。
此外还有一个更底层一些的工具dexhunter，这个工具较为前卫，但同时也有一些局限性，譬如部分指令数据会被优化，形成的代码界面不是很美观等。
3.拆分Dex加固-虚拟机加固
虚拟机加固也属于dex拆分加固的一种，它是对字节做了一些变化处理。如下所示，这是一个正常安卓系统中的代码，在其中进行了虚拟机加固操作：
以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2这三条指令进行替换，然后进行加固编译，这样子操作后，即使把替换后的数据恢复了，也不会以add-int v0, v1, v2、sub-int v0, v1, v2、mul-int v0, v1, v2这三条指令进行替换，然后进行加固编译，这样子操作后，即使把替换后的数据恢复了，也不会变形成为之前的字节码，安全系数较高。
虚拟机加固逆向分析—HOOK JNI 接口
这种方式下的逆向分析，一方面可以通过HOOK JNI 接口来实现，它有两种实现方式。
通过HOOK JNI 接口实现虚拟机加固逆向分析
通过HOOK JNI 接口不用逆向底层，就可以了解APP大致的调用流程。但是对于复杂的调用过程，或者虚拟化方法数量较多的情况，这种逆向分析手段看起来会比较混乱；对于不需要返射到Java层执行的指令，如算术、逻辑运算等，则无法监控到。
虚拟机加固逆向分析—分析指令操作码映射
另一方面，也可以通过分析指令操作码映射来逆向分析。在同一加固版本，或者映射关系相同的情况下，可以采取以下所示的方法：
但在实际情况中，每次加固时的映射关系都是随机变化的，如下所示，这种情况下就无法直接建立映射关系。
不依赖于操作码的映射关系只与虚拟机结构有关，所以需要根据偏移关系建立映射关系，从而进行逆向分析。
4.Dex加固总结：
伴随着移动互联网的发展，应用安全越来越重要，Dex加固加固保护的技术在对抗中，不断进化和提升。
相关阅读：