看到 CheckPoint 对恶意软件GachiLoader 的分析文章，提到了一种新的 PE 注入技术“Vectored Overloading（向量化重载）”，即通过 VEH 和对内存中的载荷进行直接映射，借助合法的 DLL 内存实现注入，从而规避检测。CheckPoint 提供了这项技术的测试代码，以下是对这项技术的学习记录。

• 编译环境：Windows 11， VS2019， debug x64
• 运行环境：Windows 11

1. 将 PE 文件读取到内存

读取 C:\Windows\System32\calc.exe 的文件内容到内存，这是之后要注入的 Payload。

GetProcessHeap 函数获取调用进程的默认堆的句柄。 进程可以使用此句柄从进程堆分配内存，而无需先使用 HeapCreate 函数创建专用堆

ReadFile 函数从指定的文件或输入/输出（I/O）设备读取数据

然后 exe 文件变成 dll 文件。calc.exe原本是 exe 文件，FileHeader.Characteristics 的字段IMAGE_FILE_DLL 为 0。

现在需要将 IMAGE_FILE_DLL 改为 1，并清除入口点地址（设置为 0，防止冲突，之后再设置具体地址）。这样能让calc.exe像 DLL 一样可以在内存任意位置运行，不挑剔地址；而且让它看起来和被替换的 wmp.dll 更像，起到一定免杀效果。

2. 创建 "傀儡" 节（Section）

首先需要调用函数NtCreateSection。 函数 NtCreateSection 属于是ntdll.dll 中未公开的函数。ntdll.lib 不是 Visual Studio 标准 C++ 桌面开发环境默认包含的库。它是 Windows Driver Kit (WDK) 的一部分，所以需要先声明，并且说明函数的名称、参数类型、返回值、调用约定

（这种隐式链接的方式很容易在逆向分析时被发现，这里应该是为了方便没有用 LoadLibrary + GetProcAddress 这种显式链接的方式获取NtCreateSection 地址了）

函数 NtCreateSection 负责创建节对象。

其中需要注意的参数是AllocationAttributes，用于确定节的分配属性，可以设置为 SEC_COMMIT（0x8000000）、SEC_IMAGE(0x1000000)、SEC_IMAGE_NO_EXECUTE(0x11000000)>、SEC_LARGE_PAGES0x80000000)等 7 个属性值。

这里程序将节对象的分配属性设置为SEC_IMAGE，也就是说告诉操作系统把这个文件当成 “可执行程序(Image)” 来解析和映射，别当成普通文本文件。SEC_IMAGE 属性必须与页面保护值（如 PAGE_READONLY）结合使用。

为什么不用VirtualAlloc，而是要用NtCreateSection ？

• VirtualAlloc 分配的是 MEM_PRIVATE，绝大多数合法的 EXE/DLL 代码不会运行在 MEM_PRIVATE 里，如果一块 MEM_PRIVATE 内存拥有 EXECUTE 权限，这在安全软件眼里是非常明显的恶意特征；NtCreateSection (SEC_IMAGE) 分配的是 MEM_IMAGE，这是所有正规 DLL 加载的方式
• 如果用 VirtualAlloc 分配内存然后加载 PE 文件，必须手动写代码去处理 PE 文件的映射，需要算地址、对齐节、处理导入表，这相当于你要手写一个加载器；NtCreateSection分配的内存因为有 SEC_IMAGE 标志，操作系统内核完成了所有的解析、对齐、加载工作

调用NtCreateSection函数时，Windows 内核会在内核空间创建一个 Section Object (节对象)。这个对象本身是存放在内核空间的，用户态程序无法直接操作。NtCreateSection 不能独自完成内存分配工作，还需要结合函数NtMapViewOfSection。

现在拿到的 gSectionHandle 只是一个句柄，程序后面紧接着调用的 NtMapViewOfSection，才能把节对象映射到当前进程的用户空间虚拟内存里。

3. 预先映射并篡改

使用 NtMapViewOfSection 将这个基于 wmp.dll 的节映射到当前进程内存

简单说，NtMapViewOfSection这个函数是把 SectionHandle 指定的文件，映射到 ProcessHandle 指定的进程里，大小由 ViewSize 决定，地址由 BaseAddress 接收。

映射内存后，紧接着使用 VirtualProtect 修改内存权限，清空原有 wmp.dll 的内容，并将 calc.exe 的 PE 头和各节（Section）手动复制进去，修复 calc.exe 的重定位，设置各节的属性。

虽然把内存里的内容全部清空并替换了，但这块内存的属性依然是 MEM_IMAGE，并且在操作系统眼中，这块内存区域依然关联着 wmp.dll 这个文件。

这里修改了内存，硬盘上的 wmp.dll 文件会不会也被改掉？并不会

Windows 有一种机制叫写时复制 (Copy-on-Write)。“写时复制”是一种内存优化技术，让多个进程共享同一份物理内存页面，直到其中一个进程尝试写入（修改）数据时，系统才真正创建一份独立的副本，从而节省内存和时间。

程序在调用memset、memcpy 等函数把数据写进 wmp.dll 的映射内存时，操作系统会申请一块新的物理页，把旧页面的内容拷贝到新页面，并将新页面的权限设置为可写入，CPU 重新执行写入指令，完成对新页面的数据修改。

4. 设置 hook

主要流程如下：注册VEH 异常处理函数，然后在函数NtOpenSection设置硬件断点，调用 loadlibrary 加载一个系统的 dll 触发断点，让程序进入VEH 异常处理函数，修改部分代码劫持程序执行流程，让程序跳转到之前设置好的 Payload，也就是映射 calc.exe 的内存，最后执行 Payload 弹出计算器窗口。

4.1 注册 VEH 异常处理函数

首先我们需要理了解VEH（Vectored ExceptionHandler，向量化异常处理）。简单说一下，从Windows XP开始，在以前的SEH(Structured Exception Handling)结构化异常处理的基础上， 微软又增加了一种新的异常处理VEH。

• VEH和进程异常处理类似，都是基于进程的，而且需要使用API（AddVectoredExceptionHandler）注册回调函数
• 可以注册多个VEH，VEH结构体之间串成双向链表
• VEH处理优先级次于调试器处理，高于SEH处理；即KiUserExceptionDispatcher()首先检查是否被调试，然后检查VEH链表，最后检查SEH链表
• 注册VEH时，可以指定其在链中的位置，不一定像 SEH 那样必须按照注册的顺序压入栈中
• VEH保存在堆中

注册一个 VEH (Vectored Exception Handler)：InjectHandler

1u 表示 ULONG 类型的 1， 表示只要有异常发生，第一个通知这里注册的异常处理程序InjectHandler。一旦异常发生，操作系统就会暂停当前的程序，转而去调用这个函数InjectHandler。

4.2 异常处理函数

注册的 InjectHandler 异常处理函数实现逻辑如下：

1. 先判断是不是硬件断点触发的异常。 EXCEPTION_SINGLE_STEP是硬件断点触发时特有的异常代码，如果条件符合，就继续异常处理；否则InjectHandler 直接返回。

1. 当程序（LoadLibrary）试图调用 NtOpenSection 去打开一个 dll 文件时，断点触发，进入这个 Case

• ctx->Rcx：根据 x64 调用约定，Rcx 是第一个参数。在 NtOpenSection 中，第一个参数是 PHANDLE SectionHandle（用来接收结果的指针）。
• (PHANDLE)ctx->Rcx = gSectionHandle：之前准备好的 gSectionHandle (那个伪装成 wmp.dll 的 calc) 填到了NtOpenSection 的第一个参数中。
• 跳过执行 (ctx->Rip = ... RET)：指令指针被修改了，直接跳到了函数的结尾（RET，0xC3 是汇编指令RET 的指令码）。
• 再设置硬件断点：在函数NtMapViewOfSection 也设置了一个硬件断点

真正的 NtOpenSection 根本没有执行！操作系统压根不知道程序想打开 amsi.dll。调用者收到了 STATUS_SUCCESS (Rax=0)，并且多了一个 Handle，操作系统以为成功打开了 amsi.dll，但其实是之前构造的填充了 calc.exe 的 Section。

根据 x64 调用约定，最左边 4 个位置的整数值参数从左到右分别在 RCX、RDX、R8 和 R9 中传递

NtOpenSection 也是一个未公开的函数，和之前的NtCreateSection 需要提前声明

1. 调用者拿到了假的 Handle，去调用 NtMapViewOfSection 想把文件映射到内存。断点再次触发。

• ctx->Rcx：这是传入的 Handle。代码先检查一下，确保这个请求是针对之前那个假 Handle 的。
• ctx->R8：这是 BaseAddress 的指针。正常情况下，内核会分配一块新内存，把地址填进去。
• *baseAddrPtr = gBaseAddress：把之前就已经在内存里布置好的、填满了 calc.exe 代码的那个地址 (gBaseAddress) 塞给了调用者。

同样，真正的 NtMapViewOfSection 也没有执行，内核什么都不知道。然后清除断点，抹除痕迹。

4.3 设置硬件断点

怎么人为地让异常发生呢？前面已经提过，需要设置硬件断点。

CPU 内部有 8 个调试寄存器：

• Dr0, Dr1, Dr2, Dr3 为存放断点地址的寄存器，这意味着同时最多只能下 4 个硬件断点
• DR4和DR5 目前保留，没有实际使用
• DR6为调试异常产生后显示的一些信息
• DR7保存了断点是否启用、断点类型和长度等信息，例如断点的长度设置到DR7的LEN0-LEN3中，将断点的类型设置到DR7的RW0-RW3中，将是否启用断点设置到DR7的L0-L3中
  

使用调试寄存器在NtOpenSection函数的地址上设置硬件断点；因为 NtOpenSection 是系统函数，如果用软件断点（修改内存），杀毒软件和反作弊系统（如 BattlEye）会立刻检测到系统 DLL 被篡改了。利用硬件断点 + VEH（异常处理），可以在不修改任何一个字节代码的情况下，劫持系统函数的执行流程。

5. 劫持加载流程

调用 LoadLibraryW(L"amsi.dll")，触发 Windows 加载器（Ldr）内部的 NtOpenSection 和 NtMapViewOfSection 调用

5.1 阶段 1 (NtOpenSection）

当 LoadLibrary试图打开 amsi.dll时会调用NtOpenSection，触发硬件断点。异常处理程序拦截执行，将输出参数SectionHandle 替换为之前创建的 gSectionHandle（即那个伪装的wmp.dll）。然后修改 RIP指针跳过真正的系统调用。

操作系统以为它成功打开了 amsi.dll，但实际上拿到的是篡改过的 Handle。

5.2 阶段 2 (NtMapViewOfSection)

VEH 异常处理流程随后在 NtMapViewOfSection 下断点。当加载器试图映射这个 Handle 时，处理程序再次拦截，将映射的基址（BaseAddress）替换为已经准备好的地址。

LoadLibrary认为它加载了amsi.dll，但实际上通过劫持，它“复用”了那块已经写入 calc.exe 代码的内存。

6. 执行 Payload

运行成功

7. 参考链接

GachiLoader: Defeating Node.js Malware with API Tracing

VectoredOverloading/main.cpp at main · CheckPointSW/VectoredOverloading（完整代码在这个项目链接中，可供各位读者参考）

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！