背景
无
VMP的介绍
相信看到这篇文章的人都听过或了解过vmp，基本遇到vmp加壳的程序基本就是右键回收站，但是如果只是简单的加了一层vmp壳的话，还是可以分析的。
vmp加壳方式
下面是程序代码
int main() {
printf("222222222\n");
system("pause");
return 0;
}然后把随机基地址关一下，方便之后查找main函数
这里说明一下，目前大部分人加壳都会虚拟化代码段，这样的话基本上就需要右键回收站了，主要是核心代码被vm了，还原的话基本上是不太现实的。
下面是主函数被vm之后的样子，左边是被vm的，已经看不出函数的原来样子，在多几个call基本分析不了，当然还有其他方式爆破，侧性道攻击等 一些手段。
剩下的少部分不太了解vmp的人会直接把程序放进去选择反调试拉满和虚拟姬拉满（这里真机所以不管它）
好了，来看看这样加壳之后的主函数什么样,和原来的基本是 一样的，主要是iat方面的加密，这里不涉及iat的修复。
开整
脱壳的同学们都知道，要脱壳不得先在调试器跑起来，这里选择x96加上ScyllaHide插件，程序就能正常的跑起来了，记得点上drx Protection，之后会用到硬件断点。
相关的vmp反调试方式可以查看这个看雪的blog
如何查找oep，这里给几个思路
1、让程序正常跑起来，然后根据编译器的特征码去定位
2、壳会在解密代码段完成之后跳转到程序正常的.text段执行
3、程序在到达oep的时候需要还原寄存器，可以在栈上面做点事情
好了，顺着这个思路继续往下看看，第一个，有特征的情况下可以试试，但是编译器种类还是比较多的，所以这里从第二个开始。
加载程序然后在程序,text下一个内存执行断点（程序最终是要走到原始的程序入口的，所以这里vm还原代码段结束之后，会触发这个断点）
但是会发现被检测到了
emme，看来直接下.text段还不行，于是观察了一下，发现在触发第一次异常之后对.text下执行断点之后就不会被检测了，确实也断下了，但是问题是这里不是oep啊，还是会来回跳，距离oep的执行还有很长的一段距离。
所以，这里想到了下断VirtualAlloc，在程序真正执行起来之前对.text进行下段，这里可以看到断点如下，在观察一下周围的指令，发现差不多快到真正的oep的样子了，但是实际上还很远，这里还在壳里跑。作者也知道直接解密.text段然后跳过去会有这样的问题，所以他把.text段的代码和VirtualAlloc申请的地址来回跳，导致.text段会被一直断下。
这里想到了最开始脱壳时的esp定律，程序最后会还原栈的环境，所以这里在VirtualAlloc下断之后，oep执行之前对原始栈下硬件写入，之后在对.text下内存执行，此时段下来的就是正常的oep了。
操作方式如下
1、首先记录原始的esp是多少 0019FF40
2、在程序正常运行的前一个VirtualAlloc对0019FF40下硬件写断点
3、等断下，在继续在.text代码段下内存执行断点，记得把硬断删除了
4、最后到正常的oep
5、这里其实可以带壳分析了，当然不满意还要处理iat cpuid 申请的地址方面的东西