首先看一下DX对于这种自身的虚拟源码保护是怎么说明的？

结合免费版分析可以猜测是这样的加固流程：

1.      首先进行免费版转换把dex中对应的方法通过JNI反射转换为cpp文件（当然这里企业版比免费版转换的方法要多，免费版中的内部类MainActivity$1就没有进行转换）；

2.      然后就是独有工具链的编译，猜测很有可能是基于LLVM的自定义编译；

3.      进行虚拟化保护，生成相对的VMdata和对应的Handler解释器，最后每次通过dispatcher来读取VMdata完成解释。

一、分析篇：

1.So脱壳：

根据上一次的免费版分析知道顶象中so的保护采用的变形的UPX加壳。

在linker执行完第一个init函数，也就是upx的loader函数后开始dump.

在偏移值为274E处下断点：

根据base和Size dump出来

dump下来接着修复。

通过对Load和dynamic进行简单修复后基本上所有的函数，静态都可以看到了，如图所示：

2.直接分析：

静态分析：

这里面要抓住几个核心的问题，一是核心代码的虚拟指令，二是虚拟安全运行环境.

OK，开始吧！在IDA中打开

分析看到JNI_Onload、oncreate、wanwan01、wanwan02、wanwan0、Testloop等这些函数基本上是遵从一个规则那就是：

所以可以猜想的是这几个函数是构成那个虚拟运行环境的重点函数，也是我们分析的重点。

进入sub_43B0这个函数以后发现如下：

经过简单分析以后发现

在F5看伪代码以后发现：是一个控制流平展图，里面的case总共有250个左右，但是只有50多个，200个左右没有显示，大致猜测加固原理如下：

在加固处理的时候对dex native化形成的cpp文件进行语法分析，或者就是上面所说的形成了中间二进制文件，然后根据这些二进制文件的特征来形成了50个左右“Handler”。（总共是253个“Handler”，这里只用到50个），每次解释的时候读取这个虚拟指令集合。然后调用相应的Handler来进一步的进行解释完成。

动态调试分析：

如上图所示为取虚拟指令的一个过程。下图是每次调用执行完返回的一个过程。

下面感觉是维护一个地址表：

并且在调试过程中发现case94、case 249、case107、case222、case197这些Handler的内容是一样的,或许是一些无用的垃圾指令。

在调试中如下图所示会发现有大量的重复的虚拟指令，并且对应的Handler也没有具体的语义。如下图所示：

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课