[转帖]一款有意思的VB样本分析

文件名:uzi.exe样本大小: 600KMD5: D99D7FE10CC64F40C6168BFF11379292SHA-256: E14A7CDB3043FC278A1E34839A968D6E99B7D4755B8297C198E17A8DFE2D5CBE样本其他信息:

这之前我看了一些VB相关的东西，但是感觉还是自己调试时，才能真正了解。首先将样本拖入VB Decompiler，观察整体结构，但是静态看并不能分析出什么有价值的东西，于是动态调试起来

在调试过程中发现一些端倪

这里存在一个DllFuntionCall，该函数为VB的API接口该接口首先会通过LoadLibrary和GetProcAddress动态获取其API地址

这里我们看到一个关键函数EnumThreadWindows,该API会通过会调用程序定义的回调函数

查看代码，回调函数为0x0046e99d

查看回调，其实本能的就会发现这些代码肯定是有问题的

找到这个回调直接下断点，运行，代码是结果膨胀的，而且还很多，至少中间几百行都是。看的眼花。

1. 找到模块首地址
2. 调用关键API，申请空间大小为0xB02C
3. 拷贝代码
4. 异或0x9A88393C 解码
5. 解码后代码通过jmp eax调用

进入代码一路F7，不管乱跳的jmp，找到关键函数0x003B1423,该函数通过查找DllFuntionCall的API接口函数，动态调用API

当看到这些API时,发现这些为调试器的API

直接来到创建进程，可以清楚的看到进程是以调试状态运行的

这里说一下调试器中比较重要的一个函数 WaitForDebugEvent
该函数包含两个参数 BOOL WaitForDebugEvent(   LPDEBUG_EVENT lpDebugEvent,DWORD         dwMilliseconds );
第一个参数为指针，表明事件类型第二个为等待调试事件的事件，一般为INFINITE
其中第一个参数指向一个结构体DEBUG_EVENT typedef struct _DEBUG_EVENT {   DWORDdwDebugEventCode;   DWORD dwProcessId;   DWORD dwThreadId;   union {EXCEPTION_DEBUG_INFO      Exception;CREATE_THREAD_DEBUG_INFO  CreateThread;CREATE_PROCESS_DEBUG_INFO CreateProcessInfo;EXIT_THREAD_DEBUG_INFO    ExitThread;EXIT_PROCESS_DEBUG_INFO   ExitProcess;LOAD_DLL_DEBUG_INFO       LoadDll;UNLOAD_DLL_DEBUG_INFO     UnloadDll;OUTPUT_DEBUG_STRING_INFO  DebugString;RIP_INFO                  RipInfo;   } u; } DEBUG_EVENT, *LPDEBUG_EVENT;
第一个参数为事件码 第二三个参数为进程、线程ID最后一个为共用体，由第一参数决定，基本每种事件来，都会有与之对应的一个结构体，可以获取相应的信息，这里就不展开了。

接下来我们看样本的具体操作查看调试器主体部分，已经采用注释

可以看到该基本所有来的事件都是通过ContinueDebugEvent 放过去了。主要关注内存访问异常首先获取ntdll模块的地址，与获取异常的模块地址进行比较，如果大于等于的话，就直接修改内存地址为可读可执行

我们猜测该调试程序如果直接调试可能通过引起内存访问异常，进而调试失败。

首先，找到调试开关，还是比较明显的

我们首先把ntdll 模块的属性修改为0x40，防止那个内存访问异常(内存访问异常可能不会到，我调试过程中，存在访问异常，之后再复现的时候，死活不出现访问异常了)找到自身模块地址，并找到加密代码

代码复制解码

密钥解码

二者最后xor运算

解码之后得到一个PE文件

再次创建进程，以挂起的形式进行创建

之后就是常规操作了模块卸载

申请空间，大小为A200

代码写入

获取进程上下文

设置进程上下文

最后恢复进程并退出