相信大家对于Vmprotect虚拟机的逆向一定非常头痛吧，尤其是最新版本，我去官网看了一下已经到了3.96了，如果我们直接去分析他，那无疑是螳臂当车，杯水车薪，根本是不可能的事情了，经过多年的发展，已经发生了翻天覆地的变化了，在准备材料的过程中，我也浏览了早期大神们发的很多文章，而我介绍的这个版本大概是在2010年前的，具体时间没有去查，属于是初代版本的，而我之所以发这篇文章，其实我也是菜鸟，发出来和大家一起交流共同成长，可能会出现错误，老鸟勿喷。Ok，废话不多说。步入正题。

我要讲的内容大概有是Vmp1.2从到1.6的改动，为什么选择1.6呢，那是因为1.64版本开始加入了反调试，所以选择这个版本比较具有代表性，还有一个原因就是，他们中间的版本网上不好找，而且相邻的版本之间改动的并不多，没必要每个版本都去分析。相比于1.2版本1.6版本，虚拟寄存器已经放在了堆栈里面了，1.2版本是放在vmp区段，这是一个比较有意思的变动。有意思的是我找的1.64版本是个demo版本，很多功能被阉割了，连代码混淆都没有，这恰巧给我分析带来了参照，所以，我将结合1.63和1.64版本进行分析讲解，我第一次拿到1.63版本给程序加密后，用OD调试的时候发现，看起来感觉这还是vmp吗？怎么跟我分析的1.2版本不大一样，一眼看上去像天书。没关系，接下来我会慢慢的给大家分析出来。这篇帖子如果对于初学者来说还是有一定难度的，不过没关系我出过一部关于vmprotect逆向入门的课程，讲的非常详细主要就是围绕vmp1.2版本的深度讲解，https://www.kanxue.com/book-section_list-200.htm 大家可以去看看，如果手头不宽裕的也可以自己去研究，其实并不难，想开飞机的可以花点小钱。

我们找到vmp1.64目录下HelloASM.vmp1.exe,这个程序经过vm过的，设置选项选择最快速度，然后把检测调试器勾去掉，vm的代码我们在程序入口点选择5个nop，如下所示

这5个nop会被忽略，根据我以前分析1.2的经验，他还是会生成把当前寄存器入虚拟堆栈和出虚拟堆栈的伪代码并执行，之所以采用最简单的加密也是为了排除不必要的额外分析，然后生成的这个程序，把他拖到OD我们跟踪看下，之前的5个nop，被替换成了jmp 如下代码

接着单步我们来看下，如何将当前寄存器值压入虚拟堆栈的

跟踪发现，上面这条指令一共执行了12次，对应的伪代码如下

因为我vm的代码是nop，编译的时候其实是会被忽略的，如果是其他代码，执行到这边，就是真正开始执行被vm的代码了，既然这边没有东西需要执行，那就进入收尾阶段就是，取出返回地址完了之后把堆栈上的所有虚拟寄存器，全部赋值到堆栈，我们可以继续看下代码是怎么样的

接着我们看下jmp HelloASM.004056C8的代码

上面这段代码比较长，我使用的这个demo，执行到ja HelloASM.00405105，就跳转了，我猜测应该是执行某些特殊的handler才需要执行后面那些代码吧，他们最终都是会跳回00405105继续读取执行伪代码，在这里我稍微卡了一下，没必要把这里也弄的那么清楚，这里只是一个小小的细节而已，OK，我们继续，执行到这边我们发现esp的值一直都没变，从开始执行handler之后esp这个寄存器就没有用到了，倒是epb反复的被用到，想想还蛮复杂的，有很多细节我们不必太在意。我们刚刚执行到这边，结果其实就是这两句

ebp在这里可以比作esp，这时候edx的值是0，其实上面两句是不是相当于push edx，接着我们再往下执行，又来到了004056C8 这里，在这边这一部分代码可以忽略，我们
单步到 0040510D ，去看看下一条handler，

由于是使用demo版本的vmp编译的所以，数据都没有加密啥的，所以我们可以在伪代码看到401005这个地址，如果是push xxxxxxxx，我们甚至可以看到xxxxxxx，当然正式版不可能看到的，不过这方便了我们分析，我们再看下一条handler

上面是一个加法的handler，用于重定位，算出返回地址的时候同时已经把结果存放到堆栈里面了。接着我们看下一条handler

上面这条handler是把标志寄存器，存放到对应的虚拟标志寄存器，我们接着看下一条handler，

上面是把虚拟寄存器的值全部弹出到堆栈，总共执行10次，下面是对应的伪代码

这就是前面把堆栈上的值入虚拟寄存器相反的操作了，最后执行一个返回handler

执行完retn后就回到了401005，以上就是1.64最简单的虚拟机的执行过程了。我们发现和1.2比把虚拟寄存器放在堆栈上，确实让handler变得更加复杂化，为什么刚开始把虚拟寄存器放在vmp区段，应该是刚开始开发没那么多精力吧，什么东西都是摸石头过河，没办一下子，做到完美的原因吧。要是这么简单，确实vmp也不难，于是作者肯定要在每个指令上下功夫，垃圾指令加膨胀。1.63版本的我刚拿到分析的时候确实有点懵，感觉就是一堆看不懂的指令外加各种跳转，确实这么一搞很有效果，反正我第一眼看了，在想，完了这还怎么分析，都看不懂，不过猪鼻子插葱，再怎么也不可能变成大象，你们说对不对，比如说，伪代码地址，和计算handler有关的代码比如 eax*4+地址，等等都是能够找到的，在这个版本是这样的，后面版本作者想要做的更加隐蔽，也是有可能的

前面我们分析了1.64demo版的vm代码，接下来我们看看，使用同样的设置，在1.63编译后的在OD调试时候的样子，将vmp1.63目录下的HelloASM.vmpa.exe拖入OD，

上面这几个代码使用一些垃圾无意义的指令让代码变复杂，干扰我们分析，可能还有一些别的操作，我们在看下一个代码块

以上就是未执行handler前的所有代码了，可以看到，通过解密各个数据然后加入了很多垃圾指令，让整个代码变得很没有可读性。接着往下执行到第一个handler，

上面这几个代码块就是执行第一个handler整个过程，这前面分析的1.64相比就是加了很多花指令，但是流程还不变的，所以我们可以推测出来，编译器在编译的时候先生成没有混淆的代码，也就是1.64分析的那样，然后进行变异膨胀加花指令等等。

接下来我们分析一下1.64的反调试，在帮助说明那边说了，v1.64 新增 调试器检测 和 VMWare 虚拟运行环境检测。果然这个版本强度直接上了一个档次，这边我就单独分析一下他的反调试，其他的分析思路都是一样的，我这边编译的时候设置跟前面一样，只不过检测调试器勾选择上，然后下拉框选择user-mode，把编译好的HelloASM.vmp2拖到OD里面，

上面的代码前两句没有用jmp xxxxxxxx，而是直接push和call，因为这边原来的代码已经被加密了，不需要考虑空间的问题了，当执行权交给宿主程序的时候，这边会被还原，然后这边可以看到已经被handler给替换了，这个和1.2版本的一模一样，我们继续跟进看看，

到这边就是和前面分析的一样进入vm了，我们可以在00408934下个断点，然后F9运行多次，他首先会先填充虚拟寄存器，也就是多次在00408687断下，然后就真正执行我们想要的代码了，接着解密返回地址，最后把虚拟寄存器的值给堆栈，再弹出到各自的寄存器中返回。按照这个思路我们其实只要分析，中间的那部分我们想要的代码就可以了，
我们按F9运行多次在00408687断下后，接着在00408899断下，这个是从虚拟寄存器取出值放到ebp指向的堆栈里面，这个值显然是标志寄存器的值，应该没什么用，我们接着看下一条handler，很显然是取值handler，从伪代码取出2个字节的数据也是存放到ebp指向的堆栈，他的值是0，再看下一条，和前面一样也是0，占用空间却是4个字节，再下一条是，从虚拟寄存器中取出值放到bp指向的堆栈里面，和前面一样也是0，占用空间4个字节，我们再看下一条，是个加法运算的handler，是0和0相加，显然这个是耍流氓，干扰我们分析的，类似花指令，我们在看下一条，因为在虚拟机模拟算术运行过程中，第一条handler是计算，第二条handler就是把标志寄存器更新到对应的虚拟寄存器中，所以这一条忽略，分析到这边的时候大家是不是觉得很迷茫了，一个一个伪代码去分析已经不切实际，既然是分析检测调试器那部分伪代码，我们可以在00408934下断点，一直F9直到他弹出一个发现调试器的消息框，这时候再看下他的伪代码指针也就是esi的值，我是边按住F9边录屏，期间可以看到很多东西比如检测调试器的函数和提示内容等等，这些内容的解密都是在虚拟机里面进行的，我按住F9的时间也挺长的，编译生成的伪代码的量也挺多的，虽然加密只是5个nop指令，不像前面分析的伪代码量不多，但是反调试也在里面，这就相当于编译器私自加入一段反调试指令然后又vm了， 经过我多次的调试观察发现，他总共对三个地方进行了处理第一个就是int3异常改变EIP，我们调试的时候就会被调试器捕捉，导致无法继续，

上面的处理方法，我们可以使用StrongOD，把Skip Some Exceptions勾上，就可以过了，然而另外两个其实就是检测调试器的函数了，一个是CheckRemoteDebuggerPresent，另外一个是IsDebuggerPresent。这边我只拿一个出来分析，由于StrongOD第一个就是针对IsDebuggerPresent反调试的，为了方便分析我们把第一个勾勾上，这样我们就分析CheckRemoteDebuggerPresent，这个反调试流程。我们在CheckRemoteDebuggerPresent下个断点，运行之后断下，在esp+8位置就是存放结果的变量，如果检测到调试器，那就为真，这是个布尔类型的变量，我们要观察他这个变量是如果影响程序的流程的，我们记住这个变量的地址是0019FF50，ctl+f9执行到返回，再单步

来到了上面的代码，我们可以看到来到了下一个流程块，每个流程块的虚拟寄存器的位置是不一样的，我们接着一直单步走，接下来又是和刚开始一样，填充虚拟寄存器，执行关键代码，计算返回地址，虚拟寄存器全部恢复到堆栈，再填充真实寄存器，返回执行下一个代码块，这里我们直接在004086F3下个断点，这个handler是取出esi一个字节，这边是0，然后存放到ebp指向的堆栈，然后下一条handler就是把存放反调试结果的地址0019FF50取出来，存放到ebp指向的堆栈，我们再看下一条handler，这边是取出0019FF50的值再放到ebp指向的堆栈也就是0019F74C，我们再看下一条handler，这里是把0019F74C这个地址存放到0019F748，再下一条是，把反调试结果的值存放到0019F74A，注意这边存放的大小是2个字节，我们再看下一条，

上面的代码执行之后，后面还有很多类似的运算，就一句话，简单的问题复杂化，我先是按住F9录屏分两次一次是修改CheckRemoteDebuggerPresent函数执行完后，他的第二个参数，也就存放检测结果的那个参数，一次不修改，一次修改为0，0就表示没有检测到调试器，录完屏观察esi的变化，找到两次运行比较esi出现变化的地方下内存访问断点，这样一直往前分析，这边有几个关键点说下，上面那个代码是第一次变形，这个第一次指的是，输入的是原始数据也就是反调试结果这个布尔类型的值，变形就是通过某种运算比如说上面的运算，得到两个数据一个是ax的值，还有一个是运算后标志寄存器的状态，这两个数据接着作为下一次运算的输入值，一环扣一环，全部分析整个过程没有意义，当然我就这样描述感觉还不过，细节好像少了，这边我就在说下几个关键的地方，当我们在00407980下个内存访问断点，我们看这条handler

上面这条handler就是从伪代码中取出esi后面被替换的值，执行后ebp指向的堆栈值0040813B，然后执行下一条handler，其实下一条handller，和刚刚执行的是同一个handler，这次是把00407664存放在ebp指向的堆栈值，这两个相邻的堆栈地址，就是反调试结果的两个esi被替换的值，既然两个值都给他取出来了，那么下面就要通过判断决定使用哪个值了，我们在00407996下个内存访问断点，这时候的handler我们看下，

上面的第一条指令执行完，当检测结果布尔值为0时，eax = 40 ， 为1时，eax = 0 ，这个eax的值就是前面经过很多次变形后的结果，这条handler执行完，得到的eax就是个偏移，我们接着去看下一条指令，这条handler前面说了，更新状态寄存器的，很多时候可以忽略，我们再看下下条handler，

这条handler就是把存放第一个esi的值与eax相加，eax为0，那就结果指向0040813B，为1，就指向00407664，到现在就已经存放好将要拿来替换esi的值了，下面再看看是哪里替换了esi的值，我们再在4079ad下个内存访问断点，我们看下handler

这是一条修改esi值的handler，在这边两个结果就此分道扬镳，这其实就是在模拟条件跳转，在真实指令上只需要几行，然而在虚拟机上却要这么大费周章，以上就是1.64反调试分析的整个过程，多亏了有demo版本的帮助，分析起来还是相对比较轻松的，不能说轻松吧，都花了一个上下午，本来想睡个午觉的结果，没睡成，这个也终于弄完了，可以去干别的事情了，前面那些分析方法完全就是拿着一把钝了的刀去砍柴，真正去分析还得拿着好用的工具去。
大家有什么问题可以加我qq,2746074413

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！