[原创]某Android DEX vmp加固逆向分析
最近无意中看到某家厂商的免费Android DEX 虚拟机壳，一时兴起，就上传了一个简单样本加固之后进行分析。本文只是对该DEX虚拟机的执行过程进行了简单分析，并没有提供对其进行修复的方案，原因当然是本人也不会咯。
测试原样本和加固样本经过jeb反编译，对比如下图所示0x00 背景
0x01前期分析
未进行加固
进行加固之后反编译效果
可以看到加固之后部分函数已经成了native 了，抱着侥幸的心理，心想免费版本会不会是个假的vmp加固。重新重构还原DEX之后，发现效果还是如上图所示。看来vmp已经成了加固厂商的最低标准了。下面就开始分析了,lib目录下面有个名称为libx3g.so的文件。拖入IDA，效果如下图所示，发现并不能正常反编译，看来是做处理了。那就试着dump+修复这个so了。
0x02 so的dump及修复
1. 运行应用，IDA直接attach上去，找到libx3g.so在内存的起始地址和结束地址， idc脚本dump下libx3g.so。
2. 修复so。用010解析dump下来的so文件。
首先将原apk的libx3g.so 文件的Dynamic Segment中的data部分拷贝到dump下来的so对应位置。 然后将第二个Loadable Segement 的p_offset 值等于p_vaddr，并且计算第二个Loadable Segement 的p_vaddr+p_memsz，最后将其结果赋给第一个Loadable Segement的p_filesz和p_memsz.最终的修复的so文件如下：
此时IDA就可以正常打开so文件了。如下图所示，看来免费版本连动态注册都省了，很容易一眼看出被虚拟执行的onCreate函数。该函数只是简单混淆了下，导致一些函数的参数伪 C不是很清楚。但是总体来说，还是比较好分析的。下面根据未加固的原包与加固之后的指令进行对比，看下该虚拟机是如何执行的。
0x03 DEX虚拟机执行过程
下面以onCreate函数为例。第一张图为未进行加固之后的反编译效果。第二张图为加固之后native层该函数的伪C代码。
本来以为该vmp加固应该也会在so中一条一条的读加密替换之后的smali指令，然后逐句解释执行。 But 不是啊，它直接就翻译了。直接通过嵌套的if 把指令给翻执行
了。。。。。。。。。。。。 不知道还有没有其它哪家加固厂商也是这样做的。
还是对比下几条指令，看下它的执行过程。
1. 方法调用指令：
invoke-super Activity->onCreate(Bundle)V, p0, p1
虚拟执行：
sub_2146(v4, &a2, &a3, (int)"android/app/Activity")
sub_1064(v4, v5, a2)
注意：上传附件及图片大小不得大于30M。
⚠️ 版权声明：
本博客所有内容（含教程、源码、工具）仅供个人技术学习与研究交流使用，严禁商用、倒卖、二次分发及非法用途。
未经作者书面授权，任何组织或个人不得转载、复制或用于其他平台，违者将追究相关责任。
参与讨论
登录后可查看全部回复并参与讨论。
