勒索病毒分析-2024wdb-re2

检查相关信息

可以看到病毒存在VMProtect虚拟壳

简单脱壳

首先我在x64debug中运行一次，发现没有中断退出，证明大概率没有反调试，但是有crc检测，所以尽量不下int3断点（脱壳时）。

一：找OEP

法1：直接在.text段下内存执行断点

别问，问就是这个我调试了很多次。

然后直接运行到断点处，到oep

法2：在ida中猜出oep

在上面我们看到，这个程序是用vs写的，vs默认开了堆栈安全检查，我们可以利用这点找oep,通过交叉引用，我们可以找到入口OEP，我看到的大多数wp都这样，但是一笔带过。（让我一脸懵逼,写了跟没写一样）

具体过程

安全检查函数

SEH函数

添加seh函数的函数

调用添加seh函数的函数

到达OEP

所以你又明白了vs中安全检查的调用过程和原理

sub_4020a9(__security_init_cookie)中用___security_cookie初始化相关值(如果溢出会改变相关值)，然后通过跳到__tmainCRTStartup函数，正常执行程序，如果堆栈溢出，就抛出seh异常，这就是为什么数组等越界vs会提示异常

咳咳，跑题了。这样你就找到OEP了，动态运行到这就脱壳了。

法3：堆栈平衡

刚进入时可以看到pushad，先F8走到下面。

在栈顶下一个硬件访问断点

然后不断F9运行,然后会看到提示

之后再F9运行6次，在栈中发现有一个神奇的地址（为什么是6次，因为我调试时运行7次后从vmp0到text段过了）

其中跟随00B81D32后神奇的事情发生了，直接到oep（其实壳运行完后本来就要跳oep的，这个后面也要跳）

最后，我看网上说的在VirtualProtect下断点，我尝试过只断了两次（修改环境，回复环境），这两次的修改对象是rdata区段的，应该是动态解密，但是后面不知道怎么搞。

有人会的在评论区教教我

二：修复iat

如果想分析的时候能够显示系统api，逆向分析更爽。

如果简单修复不考虑运行

由于动态加载地址，这个是后面截图的，所以地址有点出入

这样修复后能够让ida的api显示出来，下面分析足够了，但是不能运行。因为刚刚删的两个api地址是有效的

手动寻找api

刚刚两个api是被壳虚拟化了，想要还原就要知道他的功能，你也不想硬刚虚拟化吧。

这张图是下面的，有两个函数（B83048，B83048+1）被虚拟化了，我们可以通过上下文推出api是什么。

推理过程

上面图可以看到，这两个函数的返回值被SizeofResource和LockResource调用，并且传入参数也确定了，接下来找文档。

SizeofResource： https://learn.microsoft.com/zh-cn/windows/win32/api/libloaderapi/nf-libloaderapi-sizeofresource

LockResource： https://learn.microsoft.com/zh-cn/windows/win32/api/libloaderapi/nf-libloaderapi-lockresource

根据文档可以推出：

B83048其实是FindResourceA

B83048+1其实是 LoadResource

动态调试

我们发现壳程序动态还原回iat表

继续运行发现，这两个地址发生了变化

这两个hook后的地址要后面动态填进去或者将程序的动态基址关闭pass

重新修复

将这两个地址替换后重新修复，经过比对发现第一个函数传入的参数对不上

很遗憾，运行不了，想让他运行，我大体是病了，有人会的分享在评论区

这就是典型的无效VMProtect保护，这两个函数对分析没有影响

三：静态分析

IDA打开后我们看到有调用了2个主要函数

我们逐个分析

main函数中的sub_B81620

分析过程

点进去可以看到一堆动态解密的字符串，简单分析可以知道，这是动态获取WindowsAPI函数到存放到buffer中

接下来是获取C:\WINDOWS\SysWOW64\目录并拼接成C:\WINDOWS\SysWOW64\svchost.exe

之后是简单的进程伪装+远程线程注入执行代码

主要功能

sub_B81620先xor解密字符串，将动态申请api存方到buf中，挂起svchost进程远程执行sub_B814e0中的代码

那么远程执行的代码有什么呢->分析sub_B814e0函数

分析思路

主要功能

对文件中的字符串异或加密后写回文件中

main函数中的startaddr函数

分析思路

其中有两个函数（B83048，B83048+1）被虚拟化了，下面是我猜的功能但不影响结果

我们需要知道lpbuffer是什么东西，还有sub_B81100干了什么

先分析lpbuffer

我们通过x64debug动态分析

在lockresource中下断点方便获取返回的lpbuffer地址（eax）

转到返回后的lpbuffer地址（eax）中，运行前记录下刚刚的大小（esi中）是B800，然后运行到解密完，可以看到PE文件的标志，说明资源解密后是一个新的pe文件

将内存中的pe文件dump出来，保存到为a.exe文件

接下来先分析刚刚没看完的sub_B81100函数

这个函数主要是进程镂空的技术思路，可以学习下

分析思路

这里有个分支它会先检查CPU标志考虑是否重定位

（为什么判断cpu架构决定重定位，我也不知道，我觉得直接修复也行）

下面是遍历重定位表重定位

修改跳转地址

总结思路

这里是一个免杀的进程镂空，它先挂起svchost进程，再对svchost进程中的代码进行替换，达到隐藏进程的目的。

分析dump下来的a.exe

PE信息

ida分析

main函数只有一个重要函数，

分析sub_401000

分析sub_401230

一般勒索软件不会留着源文件

进入加密函数sub_401360分析

用AES加密能够很快的加密，但是我感觉这个有跟没有一样，典型的无效加密

整理程序运行流程

程序运行->远程线程注入代码->对flag.txt进行xor加密->创建进程镂空(免杀)->运行病毒可执行文件->对flag.txt进行AES加密

解密

import Cryptodome.Cipher.AES as AES

key = [0x3B,0x7E,0x15![](https://img2024.cnblogs.com/blog/2450496/202505/2450496-20250501144002299-1902041684.png)

,0x16,0x38,0xAE,0xD2,0xA6,0xBB,0xF7,0x15,0x88,0x19,0xCF,0x4F,0x3C]

txt = open("./flag.txt.cry", "rb").read()

flag = AES.new(bytes(key), AES.MODE_ECB).decrypt(txt)

print(''.join(chr(i ^ 0x9) for i in flag))

总结

加密过程很简单，这道题在于理解进程镂空，动态加载shellcode, vmprotect脱壳等