未进行加固  

                                        进行加固之后反编译效果

可以看到加固之后部分函数已经成了native 了，抱着侥幸的心理，心想免费版本会不会是个假的vmp加固。重新重构还原DEX之后，发现效果还是如上图所示。看来vmp已经成了加固厂商的最低标准了。下面就开始分析了,lib目录下面有个名称为libx3g.so的文件。拖入IDA，效果如下图所示，发现并不能正常反编译，看来是做处理了。那就试着dump+修复这个so了。

0x02 so的dump及修复

 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)

 

2. 赋值指令

对应smali指令： 

const                    v2, 0x7F080001
invoke-virtual MainActivity->findViewById(I)View, p0, v2
move-result-object      v2
check-cast              v2, TextView
iput-object             v2, p0, MainActivity->factor:TextView

对应java代码是：  

this.factor=this.findViewById(2131230721);

大致对应虚拟机执行代码：

sub_2146(v4, &v44, &v22, (int)"com/example/vmptest/MainActivity") )
v6 = sub_10E8(v4, v5, v22, 2131230721); 
sub_223C(v4, &v44, &v32, (int)"com/example/vmptest/MainActivity")
(*v4)->SetObjectField)(v4, v5, v32, v6);

其中   sub_2146是获取findViewById 方法。 sub_10E8 调用findViewById方法。sub_223c获取类成员变量factor,也就是通过jni提供的GetFieldID方法获取。最后调用SetObjectField方法对类成员factor赋值。

3. 循环语句

java代码：

对应虚拟机执行的指令：

0x04  总结

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法