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

读取 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 更像，起到一定免杀效果。

首先需要调用函数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_PAGES(0x80000000)等 7 个属性值。

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

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

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

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

使用 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 重新执行写入指令，完成对新页面的数据修改。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

运行成功

GachiLoader: Defeating Node.js Malware with API Tracing

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

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