vmp3.X脱壳-工具向

Rootkit123

vmp壳一直是作为加密壳中的一个难啃的骨头，这次从工具使用角度学习一下这个脱壳的过程，本次尝试vmp3.4。3.x的系列都差不多源码

[C++] 纯文本查看 复制代码

?

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

#include<stdio.h>  #include<stdlib.h>  #include<windows.h>  #include<string.h>   void get_promt()  {      if(MessageBox(NULL,TEXT("context"),TEXT("title"),MB_OK))      {          printf("1212121212\n");      }      else      {          printf("error");      }  }    int main()  {      printf("this is main func\n");      char str_ptr[] = "please input a string: ";      char str[128];      char flag[15] = "aabbccddeeff";      scanf("%s", str);      if(strlen(str)<=10)      {          printf("too late\n");      }             if(!strcmp(str, flag))      {          get_promt();      }      else      {          printf("too error\n");      }             return 0;  }

加壳使用52破解上找到的vmp软件按照默认的配置对程序进行加壳


都是默认配置，模仿的是大多数的情况，也是常见的一种加密模式。实际上VMP强大之处在于它的虚拟功能，但是默认是关闭的。得到加密后的程序。大小相比于源程序扩大20倍左右调试因为程序多次中断跑飞，所以这些截图可能不是来自同一次进程，所以辩证看待调试器配置断点断点要求：如图


这也是调试器的默认配置，断点不宜太多，会触发vmp的完整性检测。增强使用插件sharpOD，这个和xdbg是通用的]




添加这些功能是为了防止vmp的一个检测，然后主要选这几个就行，主要是防止被检查调试器。区段对比


看到相较于正常程序，他出现了vmp0和1两个段。这是正常的程序区段详情


注意一下地址的范围。进行调试找入口点特征利用gcc编译的，所以需要定位一下start函数的部分，同时需要看到函数入口点的位置特征


看到这个call和jmp的结构，类似于MSVC编译的结构。 call    ___security_init_cookie跟进这个函数，发现两个函数


脱壳直接在动态调试中找到这两个函数然后下断点，然后通过栈回溯的方式进行定位。 GetSystemTimeAsFileTime --> 在kernelbase中，直接在dll界面下断点就行另一个同理，下好断点，断点下的要靠后一点，避免VMP的头部断点检测。直接f9运行，程序断在如下图位置


通过内存布局定位，发现还在vmp区段里，那就继续运行，可能是其他的地方也调用了同样的api函数


直接f9就可以，然后观察啊堆栈窗口


看到返回地址更新了。这一次程序已经来到text区段算是成功进来程序本身了。


看到IDA里的伪代码（未加壳的程序）如图


第一个函数已经断进程序本身了，继续运行断第二个api。需要注意的是，断点下载了kernelbase中，重新调试的时候会出现0xc000007b错误，这时候需要顶着错误进断点界面把俩kernelbse的断点删除，或者删除xdbg的缓存或者改个文件名。还有需要注意的是，不要一载入程序就下断点，先运行一步到程序领空之后，再去下这个api断点。看到程序已经跳转到了正常的text段的一个程序里了。


我们开始通过ida可以看到，程序的start函数的形式是一个call+jmp的形式


所以我们继续调试下去，当进入正常text段凌空之后就不要f9了，会直接跑飞，所以慢慢调试。


来到这里，看起来结构和没加科的入口点就很相似了，看了一下基本是一样的，然后直接把eip蹦到sub指令上，然后使用一个github脚本恢复一下iat。
C:\Users\Rootkit\Desktop>vmp3-import-fix -p 16200
start emualte pattern address:00401238
start emualte pattern address:00401433
start emualte pattern address:00401555
start emualte pattern address:00401730
start emualte pattern address:0040178F
start emualte pattern address:004017A0
start emualte pattern address:004017A8
start emualte pattern address:004017B1
start emualte pattern address:004017BF
start emualte pattern address:00401860
start emualte pattern address:0040186F
start emualte pattern address:00401878
start emualte pattern address:0040188A
start emualte pattern address:00401B17
start emualte pattern address:00401B6D
start emualte pattern address:00401D5E
start emualte pattern address:0040207F
start emualte pattern address:00402091
start emualte pattern address:004020CC
start emualte pattern address:00402122
start emualte pattern address:00402141
start emualte pattern address:00402187
start emualte pattern address:004021C7
start emualte pattern address:00402247
start emualte pattern address:004022AC
start emualte pattern address:004026AD
start emualte pattern address:004026B5
start emualte pattern address:004026BC
start emualte pattern address:004026C4
start emualte pattern address:004026CC
start emualte pattern address:004026D4
start emualte pattern address:004026DD
start emualte pattern address:004026E5
start emualte pattern address:004026ED
start emualte pattern address:004026F4
start emualte pattern address:004026FC
start emualte pattern address:00402705
start emualte pattern address:0040270C
start emualte pattern address:00402714
start emualte pattern address:0040271D
start emualte pattern address:00402724
start emualte pattern address:0040272D
start emualte pattern address:00402734
start emualte pattern address:0040273C
start emualte pattern address:00402745
start emualte pattern address:0040274C
start emualte pattern address:00402754
start emualte pattern address:0040275C
start emualte pattern address:00402765
start emualte pattern address:0040276D
VirtualAlloc IAT address:00EB0000

完事之后可以去对应的地址看一下是不是真的被复原了。经过验证那些call确实已经被还原名称了。利用xdbg自带的脚本进行dump，直接dump就可以，dump之后通过cff去观察一下文件的几个指标：
入口点（这里的入口点和源程序的出口点一样的，并没有发生改变）
是否重定位（关掉）


然后点击下面的东西，看一下重定位


之后使用UIF工具进行IAT重建（针对这个进程）。


重建结束之后，使用另一个工具进行fix dump而不是xdbg去修复，这里要注意


注意这些参数，防止出问题，然后点击那个get import，之后fixdump即可


将得到的最后的文件放进ida进行查看，可以看到效果已经非常好了




总结面对一个默认配置加壳的vmp程序的整体的脱壳思路：
定位两个关键api（kernelbase的GetSystemTimeAsFileTime、ntdll的QueryProformanceCounter）。
在api尾部下断点，不要都下载ret之前，最好有一定的辨识度。
观察堆栈，在执行完QueryProformanceCounter的断点之后注意返回text领空的情况。
在text段向上寻找程序入口点，利用dos脚本进行修复。
利用xdbg自带的脚本进行dump。
检查dump文件。
ufi修复进程，IF重建进程后修复dump文件。

Rootkit123

还是有几个问题：1md格式上传图片我没搞明白，导致这个帖子可能看起来有些地方比较混乱。2这次仅仅是在工具使用层面上进行的不完整的脱壳，期待大佬们的深层解读。3使用到的软件应该是有超链接的，但是贴子里可能消失了，基本都可以在看雪和本站找到，问题不大。4我没有加好友的权限。5可以在如下地址看到比较清晰的文章（我的blog：aHR0cHM6Ly9kcm9vdGtpdC5naXRodWIuaW8vTXlBcnRpY2xlcy9SZS92bXAzLjV1bnBhY2tlLmh0bWw=）【自建blog，没有引流的必要，勿喷】

Hmily

Rootkit123 发表于 2023-3-24 15:56
还是有几个问题：1md格式上传图片我没搞明白，导致这个帖子可能看起来有些地方比较混乱。2这次仅仅是在工具 ...

1、你就直接用MD的格式好了，唯一注意的是，图片插入可以用discuz自己的插入方式，如果是网络图床图片用MD的方式。
3、你的用户组不支持超级链接，我给你编辑上了，可以直接贴链接也行。

pjy612

学习了...不明觉厉... 可惜自从入了win10的笔记本，就不敢折腾这些东西了...之前没弄就被搞得重装好几次。。。

enzospace

学习收藏了

linczh

感谢分享

wzp1995

pjy612 发表于 2023-3-24 13:03
学习了...不明觉厉... 可惜自从入了win10的笔记本，就不敢折腾这些东西了...之前没弄就被搞得 ...

虚拟机不行吗？

kerwincsc

我知道我学不会, 但我知道大佬很厉害

fast123

可以，很有用。

pipiji233

这个脱壳思路非常好，精简而清晰

guagua2023

谢谢老师分享