1. 为什么要研究“PE 手动映射与反射式加载”在 Windows 平台做 C/C 开发的同学一定用过LoadLibrary/LoadLibraryEx。它把一个 DLL 从磁盘加载到进程地址空间并完成模块初始化。但在某些系统级功能开发、安全研究、漏洞分析场景中我们需要在不使用公开加载 API的情况下把一份已经存在于内存中的 DLL 数据“手动”装载成可执行模块。这种行为通常被称为手动映射Manual MapPE Loader 自定义实现反射式 DLL 加载Reflective DLL Loading严格来说反射式 DLL 加载是手动映射的一个进阶变种。常见做法是把加载逻辑编译进 DLL 自身DLL 在被注入内存后先通过 PEB、TEB 等系统结构定位自身基址再基于 PE 格式完成模块展开。手动映射则偏向“加载器在外部负责把 PE 映射进进程”。本文围绕“从零理解并手写一个教学版 PE 手动映射器”展开会完整讲解PE 文件的基础结构Windows 模块加载器大致做了什么如何用 C 手工解析 PE 头如何分配内存、拷贝节区、定位导出函数导入表IAT与重定位表的处理思路手动映射 Demo 的运行验证与常见排查点防御视角与工程建议。这里必须强调合规边界本文内容仅用于学习 Windows PE 结构、C 系统编程以及安全防御研究。相关技术一旦被用于恶意软件、免杀绕过、非法注入系统进程会产生严重法律风险。请在独立测试机、合法授权环境中进行实验。如果你正在做游戏模组加载器、插件系统、热更新组件或研究型 PE Loader这篇文章能提供一个相对完整的入门路径。如果你是零基础建议先掌握 C 基础语法、指针、内存管理概念再阅读效果更佳。2. PE 文件结构基础PEPortable Executable是 Windows 平台的可执行文件格式后缀可以是.exe、.dll、.sys等。在写手动加载器之前必须先用内存视角看懂 PE 结构。2.1 DOS 头与 NT 头PE 文件的最开始是一个IMAGE_DOS_HEADER它保留了 DOS 兼容信息。// WinNT.h 中定义 typedef struct _IMAGE_DOS_HEADER { WORD e_magic; // MZ WORD e_cblp; WORD e_cp; WORD e_crlc; ... LONG e_lfanew; // 指向 NT 头的偏移 } IMAGE_DOS_HEADER;判断一个文件是不是合法 PE前两个字节是M、Z根据e_lfanew偏移读取数据该位置前 4 字节是PE\0\0此时得到IMAGE_NT_HEADERS。typedef struct _IMAGE_NT_HEADERS { DWORD Signature; // PE\0\0 IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER32 OptionalHeader; // 64 位是 IMAGE_OPTIONAL_HEADER64 } IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;FileHeader中比较重要的字段NumberOfSections节区数量SizeOfOptionalHeader可选头大小Machine目标 CPU 架构。OptionalHeader不是“可选”它对加载 DLL 非常重要ImageBasePE 文件的建议加载基址SizeOfImage内存中完整映像大小SizeOfHeaders头 节表占用的字节数DataDirectory导入表、导出表、重定位表、异常表等目录数组。// 典型用法拿到加载基址后先映射到可选头 IMAGE_OPTIONAL_HEADER64* opt ntHeaders-OptionalHeader;2.2 节表与节区数据NT 头之后是节表Section Table每个条目对应一个节区typedef struct _IMAGE_SECTION_HEADER { BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 8字节节名 union { DWORD PhysicalAddress; DWORD VirtualSize; } Misc; DWORD VirtualAddress; // 内存中相对基址的偏移 DWORD SizeOfRawData; // 磁盘上数据大小 DWORD PointerToRawData; // 磁盘上文件偏移 DWORD Characteristics; // 读写执行属性 } IMAGE_SECTION_HEADER;磁盘上的 PE 文件中各节区按一定的文件对齐方式存储在内存中则按“内存页对齐”展开。加载器需要做一次“从文件布局到内存布局”的转换。一个.dll内常见的节区名节区名通常用途常见属性.text可执行代码可读、可执行.rdata只读数据、导入导出表可读.data可读写全局数据可读可写.pdata64 位异常处理信息可读.reloc重定位表可读、可丢弃在手动映射时并不是简单把整个文件复制到内存而是按节区的VirtualAddress和VirtualSize拷贝。2.3 导入表与导出表导入表描述“这个 DLL 需要依赖哪些外部 DLL、哪些函数”。它由IMAGE_IMPORT_DESCRIPTOR数组组成每个描述符对应一个被依赖的 DLL数组以全 0 结构结束。typedef struct _IMAGE_IMPORT_DESCRIPTOR { union { DWORD Characteristics; DWORD OriginalFirstThunk; // INT 地址 } DUMMYUNIONNAME; DWORD TimeDateStamp; DWORD ForwarderChain; DWORD Name; // DLL 名字符串 RVA DWORD FirstThunk; // IAT 地址 } IMAGE_IMPORT_DESCRIPTOR;导入函数名称通过IMAGE_THUNK_DATA结构引用。在 64 位程序中Thunk 也是 8 字节。最高位表示该函数是否按序号导入否则低 31 位指向IMAGE_IMPORT_BY_NAME。导出表则描述“这个 DLL 导出了哪些函数”由以下结构定位typedef struct _IMAGE_EXPORT_DIRECTORY { DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Name; // DLL 名称 RVA DWORD Base; // 起始序号 DWORD NumberOfFunctions; // 导出函数数量 DWORD NumberOfNames; // 导出名称数量 DWORD AddressOfFunctions; // 函数地址表 RVA DWORD AddressOfNames; // 函数名称表 RVA DWORD AddressOfNameOrdinals;// 序号映射表 RVA } IMAGE_EXPORT_DIRECTORY;手动加载一个 DLL 后要调用它的某个导出函数需要手动解析导出表找到函数地址。2.4 重定位表程序在编译链接时会有默认ImageBase。开启 ASLR 的模块允许系统把它加载到任意地址。如果最终实际加载地址与ImageBase不一致代码中很多绝对地址就必须进行修正这个修正过程叫“重定位”。重定位表由多个IMAGE_BASE_RELOCATION结构组成typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; // 这一页的起始 RVA DWORD SizeOfBlock; // 本块大小 } IMAGE_BASE_RELOCATION;紧跟在结构后面的是WORD数组每个低 12 位表示类型高 4 位表示相对当前页的偏移量。在 PE 手动映射时如果没有严格处理重定位被加载 DLL 中凡是引用全局变量、函数指针的指令都会指向错误位置轻则返回错误结果重则访问违例。3. 手动映射加载器的运行原理3.1 LoadLibrary 到底做了什么我们平时调用LoadLibrary(test.dll)Windows 模块加载器大致有以下动作把磁盘 DLL 映射到进程地址空间解析导入表加载依赖 DLL并修复 IAT处理重定位修正绝对地址调用 DLL 入口函数DllMain执行DLL_PROCESS_ATTACH初始化把模块信息登记到进程模块链表中。操作系统加载器非常复杂涉及加载顺序、路径搜索、DLL 重名策略、绑定导入、延迟加载、异常数据初始化等。3.2 手动映射与反射式加载的简化流程手动映射器要解决的问题是自己在用户态实现上述“映射”部分。它通常不调用LoadLibrary也不经过系统加载器。常用流程如下取得 DLL 的原始字节。可能是磁盘文件读取也可能是网络/内存传递校验 DOS 头、NT 头根据SizeOfImage使用VirtualAlloc分配一块连续内存拷贝 PE 头到分配区遍历节表将每个节的SizeOfRawData从文件偏移复制到虚拟地址对应的位置根据实际基址与ImageBase的差值修复重定位表解析导入表加载依赖模块并填写 IAT调用DllMain或入口点返回模块基址供调用方通过导出表解析函数地址。反射式 DLL 加载更进一步加载器代码常常被做成 DLL 的一个导出函数比如ReflectiveLoader。这段代码在目标进程内运行后通过 PEB 等结构找到“当前 DLL 在内存中的位置”然后由加载器自己完成后续展开。反射式加载的目的是让 DLL 不必先落地到磁盘也不依赖系统加载 API。本文演示 Demo 以“外部手动映射器”为主线。理解了手动映射再去研究反射式加载会更容易。3.3 技术适用边界与实际用途从工程角度看手动映射并非日常开发首选。正常加载 DLL 永远应该优先使用系统 API。手动映射可用于内存态插件系统研究学习 Windows PE 加载细节部分游戏模组加载器原理分析安全产品做内存模块审计时的反向研究。在学习过程中要注意系统加载器不属于公共 API手动映射会绕过很多安全机制也会导致模块不稳定、无法被常规卸载、调试困难等问题。4. 环境准备与测试 DLL 编写4.1 实验环境说明本文使用 Windows 10/11编译器使用 Visual Studio 2022 或 MSVC 命令行工具。为了方便验证在控制台工程中完成加载器 Demo。测试 DLL 的设计需要做减法为了让教学版手动映射器简单可控测试 DLL 不依赖外部系统 DLL也不使用 C/C 运行库避免复杂 IAT 修复。我本地构建方式使用 Visual Studio Developer Command Promptcl /LD /O1 testlib.cpp /Fe:testlib.dll /link /DLL /DYNAMICBASE:NO /FIXED:NO注意DYNAMICBASE:NO表示关闭 ASLR生成固定基址版本FIXED:NO表示是否强制固定基址需根据链接器参数调整。在实际编译时也可以通过 CMake 的LINK_FLAGS控制。4.2 测试 DLL 源码// 文件路径testlib.cpp // 编译方式cl /LD /O1 testlib.cpp /Fe:testlib.dll extern C __declspec(dllexport) int add_two(int a, int b) { return a b; } extern C __declspec(dllexport) int mul_two(int a, int b) { return a * b; } extern C __declspec(dllexport) const char* get_message() { return PE Manual Map Demo OK; }这里使用extern C防止 C 名字改编否则在导出表中函数名会变成?add_twoYAHHHZ不方便演示字符串查找。使用命令行编译cl /LD /O1 testlib.cpp /Fe:testlib.dll /link /DYNAMICBASE:NO编译完成后会生成testlib.dll。可以用dumpbin /headers testlib.dll查看它没有导入表依赖dumpbin /dependents testlib.dll dumpbin /exports testlib.dll从输出中能看到它导出add_two、mul_two、get_message。4.3 加载器工程结构我建议把加载器代码组织成以下结构manual_loader/ ├── testlib.cpp ├── miniloader.cpp └── README.txtminiloader.cpp是教学版手动映射器主要步骤读取testlib.dll二进制内容校验 PE 签名按 PE 格式分配内存并拷贝头与节区解析导出表得到add_two的地址通过函数指针调用验证加载成功。cl /EHsc miniloader.cpp /Fe:miniloader.exe这里编译加载器时不需要testlib.lib因为加载后我们利用导出表手动查找函数地址不是静态链接调用。5. C 实现教学版 PE 手动映射器下面我会按模块展示核心代码。完整工程代码可以复制到同一个.cpp中运行。5.1 读取 DLL 文件到内存// 文件路径miniloader.cpp #include windows.h #include iostream #include vector #include string bool ReadFileToBytes(const std::string path, std::vectorBYTE outBytes) { HANDLE hFile CreateFileA( path.c_str(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile INVALID_HANDLE_VALUE) { std::cerr 打开文件失败错误码: GetLastError() std::endl; return false; } LARGE_INTEGER fileSize{}; if (!GetFileSizeEx(hFile, fileSize)) { CloseHandle(hFile); return false; } outBytes.resize(fileSize.QuadPart); DWORD bytesRead 0; BOOL ok ReadFile(hFile, outBytes.data(), (DWORD)outBytes.size(), bytesRead, NULL); CloseHandle(hFile); if (!ok || bytesRead ! fileSize.QuadPart) { std::cerr 读取文件失败 std::endl; return false; } return true; }这里直接使用 Windows APICreateFileA/ReadFile读取文件比用ifstream更贴近 Windows 系统编程场景。5.2 校验 DOS 头与 NT 头bool ValidatePe(const std::vectorBYTE fileData) { if (fileData.size() sizeof(IMAGE_DOS_HEADER)) { std::cerr 文件太小不足以包含 DOS 头 std::endl; return false; } IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)fileData.data(); if (dos-e_magic ! IMAGE_DOS_SIGNATURE) { std::cerr 不是有效的 MZ 文件 std::endl; return false; } LONG peOffset dos-e_lfanew; if (peOffset 0 || peOffset sizeof(IMAGE_NT_HEADERS) fileData.size()) { std::cerr 无效的 e_lfanew 偏移 std::endl; return false; } IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(fileData.data() peOffset); if (nt-Signature ! IMAGE_NT_SIGNATURE) { std::cerr 不是有效的 PE 文件 std::endl; return false; } if (nt-FileHeader.Machine ! IMAGE_FILE_MACHINE_AMD64) { std::cerr 当前示例仅支持 64 位 DLL std::endl; return false; } return true; }IMAGE_DOS_SIGNATURE就是0x5A4D对应 ASCII 字符MZ。IMAGE_NT_SIGNATURE是0x00004550对应PE\0\0。5.3 分配内存并映射节区在拿到合法 PE 后需要根据OptionalHeader.SizeOfImage分配一整块内存。教学版使用固定基址避免重定位问题BYTE* MapDllImage(const std::vectorBYTE fileData) { IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)fileData.data(); IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(fileData.data() dos-e_lfanew); IMAGE_OPTIONAL_HEADER64* opt nt-OptionalHeader; // 优先请求 ImageBase。如果地址被占用VirtualAlloc 会返回 NULL BYTE* baseAddress (BYTE*)VirtualAlloc( (LPVOID)opt-ImageBase, opt-SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE); if (baseAddress NULL) { std::cerr VirtualAlloc 失败无法使用固定基址: 0x std::hex opt-ImageBase std::dec 错误码: GetLastError() std::endl; return nullptr; } // 拷贝 PE 头 memcpy(baseAddress, fileData.data(), opt-SizeOfHeaders); // 遍历节表逐个拷贝节区 IMAGE_SECTION_HEADER* sec IMAGE_FIRST_SECTION(nt); for (int i 0; i nt-FileHeader.NumberOfSections; i, sec) { if (sec-SizeOfRawData 0) { BYTE* src fileData.data() sec-PointerToRawData; BYTE* dst baseAddress sec-VirtualAddress; memcpy(dst, src, sec-SizeOfRawData); } } return baseAddress; }重点说明PAGE_EXECUTE_READWRITE同时赋予读、写、执行权限是为了让实验代码简单。真实项目中应尽量按节区属性分配最小化权限。这里直接请求ImageBase作为目标地址。如果该地址没被占用就能避免处理重定位表。如果分配失败最简单的办法是换一个 64 位测试 DLL 的ImageBase或者在程序早期退出其他占用模块。5.4 解析导出表并获取函数地址手动加载完成后模块虽然已经在内存中但进程并不知道它是“可用的 DLL”。调用导出函数的正确方法是解析IMAGE_EXPORT_DIRECTORY。FARPROC GetExportAddress(BYTE* moduleBase, const char* exportName) { IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)moduleBase; IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(moduleBase dos-e_lfanew); DWORD exportRva nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress; if (exportRva 0) { std::cerr 该模块没有导出表 std::endl; return nullptr; } IMAGE_EXPORT_DIRECTORY* exportDir (IMAGE_EXPORT_DIRECTORY*)(moduleBase exportRva); DWORD* functions (DWORD*)(moduleBase exportDir-AddressOfFunctions); DWORD* names (DWORD*)(moduleBase exportDir-AddressOfNames); WORD* ordinals (WORD*)(moduleBase exportDir-AddressOfNameOrdinals); for (DWORD i 0; i exportDir-NumberOfNames; i) { char* name (char*)(moduleBase names[i]); if (strcmp(name, exportName) 0) { DWORD funcRva functions[ordinals[i]]; return (FARPROC)(moduleBase funcRva); } } return nullptr; }值得注意导出表里的地址都是 RVA相对虚拟地址要加上moduleBase才能得到真实指针NumberOfNames是“有名字导出项的数量”可能少于NumberOfFunctions导出函数地址可能指向转发字符串例如转发到其他 DLL完整系统加载器会处理转发教学版忽略。在主函数中我们可以这样验证int main() { std::vectorBYTE dllBytes; if (!ReadFileToBytes(testlib.dll, dllBytes)) { return 1; } if (!ValidatePe(dllBytes)) { return 1; } BYTE* moduleBase MapDllImage(dllBytes); if (moduleBase nullptr) { return 1; } std::cout DLL 手动映射成功基址: 0x moduleBase std::endl; typedef int (*AddFunc)(int, int); typedef const char* (*MsgFunc)(); AddFunc addFunc (AddFunc)GetExportAddress(moduleBase, add_two); MsgFunc msgFunc (MsgFunc)GetExportAddress(moduleBase, get_message); if (addFunc nullptr || msgFunc nullptr) { std::cerr 导出函数查找失败 std::endl; return 1; } int result addFunc(30, 12); std::cout add_two(30, 12) result std::endl; const char* msg msgFunc(); std::cout get_message() msg std::endl; return 0; }预期输出DLL 手动映射成功基址: 0x00007FF700001000 add_two(30, 12) 42 get_message() PE Manual Map Demo OK如果你的测试 DLL 编译为 32 位请把代码中的IMAGE_NT_HEADERS换成IMAGE_NT_HEADERS32函数加载目标也换成 32 位工程。5.5 为什么这里不需要调用 DllMain正常的系统LoadLibrary会调用DllMain触发静态 C 运行时初始化、全局对象构造等。教学版手动映射器只适用于“无状态、无依赖”的导出函数集合没有调用入口点因此没有执行 TLS 回调和 CRT 初始化。这也解释了为什么实验 DLL 要刻意写成不依赖运行库的形式。6. 进阶导入表修复与重定位处理思路上面的教学 Demo 能跑通是因为实验 DLL 被设计成“纯净状态”。但真实 DLL 通常至少依赖系统提供的kernel32.dll或ntdll.dll。你写一个最简单的printf输出它底层就会调用 C 运行库导出函数。6.1 导入表处理思路如果需要加载真实 DLL必须处理导入表。处理流程大致如下定位IMAGE_DIRECTORY_ENTRY_IMPORT遍历IMAGE_IMPORT_DESCRIPTOR对每一项拿到 DLL 名调用LoadLibraryA加载依赖 DLL遍历其OriginalFirstThunkINT和FirstThunkIAT根据函数名或序号调用GetProcAddress拿到真实函数地址将函数地址写入当前模块 IAT。核心伪代码PIMAGE_IMPORT_DESCRIPTOR imp (PIMAGE_IMPORT_DESCRIPTOR)(base importRva); for (; imp-Name ! 0; imp) { const char* dllName (const char*)(base imp-Name); HMODULE hDep LoadLibraryA(dllName); PIMAGE_THUNK_DATA intThunk (PIMAGE_THUNK_DATA)(base imp-OriginalFirstThunk); PIMAGE_THUNK_DATA iatThunk (PIMAGE_THUNK_DATA)(base imp-FirstThunk); for (; intThunk-u1.AddressOfData ! 0; intThunk, iatThunk) { if (intThunk-u1.Ordinal IMAGE_ORDINAL_FLAG64) { // 按序号导入 iatThunk-u1.Function (ULONGLONG)GetProcAddress(hDep, (LPCSTR)IMAGE_ORDINAL(intThunk-u1.Ordinal)); } else { PIMAGE_IMPORT_BY_NAME byName (PIMAGE_IMPORT_BY_NAME)(base intThunk-u1.AddressOfData); iatThunk-u1.Function (ULONGLONG)GetProcAddress(hDep, byName-Name); } } }这里伪代码只用于理解。真实项目需要区分 32/64 位、处理按序号导入、校验OriginalFirstThunk是否为空还需要考虑加载失败后的回退策略。6.2 重定位表修复只要没有使用VirtualAlloc按ImageBase固定分配或者 DLL 开启了 ASLR就必须要处理重定位。重定位修复的基本公式是新值 旧值 (实际基址 - ImageBase)遍历IMAGE_BASE_RELOCATION块逐个读取 16 位条目IMAGE_BASE_RELOCATION* reloc (IMAGE_BASE_RELOCATION*)(base relocRva); INT64 delta (BYTE*)base - (BYTE*)ntHeaders-OptionalHeader.ImageBase; while (reloc-VirtualAddress ! 0 reloc-SizeOfBlock ! 0) { DWORD count (reloc-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); WORD* items (WORD*)((BYTE*)reloc sizeof(IMAGE_BASE_RELOCATION)); for (DWORD i 0; i count; i) { DWORD type items[i] 12; DWORD offset items[i] 0xFFF; if (type IMAGE_REL_BASED_DIR64) { ULONGLONG* patchAddr (ULONGLONG*)(base reloc-VirtualAddress offset); *patchAddr delta; } else if (type IMAGE_REL_BASED_HIGHLOW) { DWORD* patchAddr (DWORD*)(base reloc-VirtualAddress offset); *patchAddr (DWORD)delta; } // 其他类型按实际架构处理 } reloc (IMAGE_BASE_RELOCATION*)((BYTE*)reloc reloc-SizeOfBlock); }重定位修复是所有自实现 PE 加载器中最容易出错的部分因为代码中的绝对地址是链接器在编译期写死的一旦加载地址不同任何“漏修正”都会导致运行时崩溃。6.3 反射式加载的自定位差异如果你继续研究反射式 DLL 加载会发现它和外部手动映射有一个关键差异加载器函数运行在目标 DLL 的内存空间它必须先找到“自己所在模块的基址”再调用MapDllImage等逻辑加载自己。寻找自身基址常用思路通过NtCurrentTeb()访问 PEB遍历PEB-Ldr-InMemoryOrderModuleList但反射加载的模块不会出现在模块链表中所以这个方法不可靠更常见做法是借助call/pop或lea指令通过当前 EIP/RIP 附近的标志特征回溯到 DOS 头MZ在 DLL 编译时预留特定字节特征让加载器可以扫描定位。反射式加载器的实现难度远高于外部手动映射器因为它要考虑 shellcode 场景下的 API 地址解析、字符串哈希、自定位等问题。我不建议新手一上来直接做反射式加载先彻底搞懂 PE 节区映射、IAT、重定位、导出表四个部分再继续深入会顺利很多。7. 常见问题与排查思路手动映射过程中一旦崩溃调试难度比普通 DLL 大很多因为调试器可能不认为目标地址是一个模块。下面列出高频问题。问题现象常见原因解决思路VirtualAlloc返回空ImageBase 固定地址已被占用换用不同基址编译 DLL或改用偏移加载并实现重定位调用导出函数崩溃未处理重定位表实际基址与 ImageBase 不一致比较模块基址与可选头 ImageBase修复重定位函数返回乱码IAT 未修复或节区未完整拷贝检查导入表解析结果确认节区虚拟地址和文件偏移GetProcAddress找不到函数函数没有导出或名字改编使用extern C改导出名用dumpbin /exports查看内存访问违例 0xC0000005节区大小与实际 PE 不符确认 DLL 不是 32/64 位混用检查SizeOfImage与节区 RVA程序退出崩溃DllMain/CRT 初始化没有调用教学版只适合无依赖 DLL真实 DLL 需补全初始化逻辑排查时建议先分离问题先用dumpbin /headers确认 DLL 位数、ImageBase、是否包含重定位表、导入表把读取文件和 PE 头校验放在最前面打印e_lfanew、NumberOfSections、SizeOfImage每拷贝完一个节区就打印最终目标地址在调用导出函数前通过调试器确认函数地址是否属于可执行内存页。8. 工程建议与安全边界8.1 工程实践建议如果你未来需要在合法业务中实现类似模块加载机制我建议你注意以下几点。第一不要重复造轮子。能使用LoadLibrary就优先使用系统 API。手动加载带来的收益通常低于维护成本它不参与系统模块链无法被常规工具卸载也不兼容延迟加载和调试。第二权限最小化。不要把整块内存都设为PAGE_EXECUTE_READWRITE。更好的做法是解析每个节区的Characteristics分别设置PAGE_EXECUTE_READ、PAGE_READWRITE、PAGE_READONLY。代码节应该可读可执行但不可写数据节应该可读可写但不可执行这能降低被攻击面。第三生命周期管理。如果自己实现了DllMain调用在卸载时也要正确调用DLL_PROCESS_DETACH并处理 TLS 回调和全局对象析构。手动映射的模块不能简单用FreeLibrary卸载需要自己实现逆向卸载逻辑并释放VirtualAlloc分配的内存。第四错误处理必须完善。所有指针转换都要判断空指针所有VirtualAlloc、LoadLibraryA、GetProcAddress调用都要检查返回值并记录日志。8.2 防御视角与合规建议反射式 DLL 加载技术常被滥用作为开发者或安全研究人员应该从防御视角看待这个问题。如果负责安全产品开发可以关注以下检测点进程内存中是否存在不属于已知模块的 MZ/PE 头内存页同时具备可执行和可写权限且不在正常模块列表中通过 VADVirtual Address Descriptor或 ETW 监控异常内存分配审计VirtualAlloc与WriteProcessMemory的组合调用。对读者个人的建议是只在自己开发环境中做实验只能在本地测试虚拟机、自有进程中测试不用于攻击他人系统或绕过权限控制不把相关代码集成到未授权产品中。学习 PE 结构本身是安全、有价值的系统编程知识但“能写”和“该不该在真实项目中用”是两码事。请务必保持清晰的合规边界。9. 总结与下一步方向在这篇文章中我们从 PE 文件结构讲起手写了一个教学版 C PE 手动映射器实际完成了“读取 DLL 文件 - 校验 PE 头 - 分配内存 - 拷贝节区 - 解析导出表 - 调用导出函数”的完整流程。同时对导入表修复、重定位处理、反射式加载自定位等进阶点做了原理剖析。如果你能独立完成这个 Demo并解释清楚以下问题说明你已经基本掌握 PE 手动加载原理为什么SizeOfImage通常大于文件实际大小导入表与 IAT 的关系重定位表中delta如何计算为什么反射式 DLL 需要“自定位”手动加载的 DLL 为什么不会被GetModuleHandle找到。下一步可以尝试给加载器加上导入表修复加载一个使用kernel32.dll的常规 DLL给加载器加上重定位处理让VirtualAlloc不再依赖固定基址实现 DLL 入口点的调用和卸载逻辑研究 PEB 结构理解系统如何枚举模块阅读开源项目学习工业级手动映射器的错误处理和兼容性设计。C 与 Windows 底层交互的内容比较枯燥但 PE 结构是绕不开的核心知识。希望这篇文章能帮你打通“编译产物到底如何被加载进内存”这个关键点。如果在编译或运行过程中遇到问题可以按照第七节的排查表逐步定位也可以把关键输出信息打出来对比。动手改代码比只看文章理解更深。
1. 为什么要研究“PE 手动映射与反射式加载”在 Windows 平台做 C/C 开发的同学一定用过LoadLibrary/LoadLibraryEx。它把一个 DLL 从磁盘加载到进程地址空间并完成模块初始化。但在某些系统级功能开发、安全研究、漏洞分析场景中我们需要在不使用公开加载 API的情况下把一份已经存在于内存中的 DLL 数据“手动”装载成可执行模块。这种行为通常被称为手动映射Manual MapPE Loader 自定义实现反射式 DLL 加载Reflective DLL Loading严格来说反射式 DLL 加载是手动映射的一个进阶变种。常见做法是把加载逻辑编译进 DLL 自身DLL 在被注入内存后先通过 PEB、TEB 等系统结构定位自身基址再基于 PE 格式完成模块展开。手动映射则偏向“加载器在外部负责把 PE 映射进进程”。本文围绕“从零理解并手写一个教学版 PE 手动映射器”展开会完整讲解PE 文件的基础结构Windows 模块加载器大致做了什么如何用 C 手工解析 PE 头如何分配内存、拷贝节区、定位导出函数导入表IAT与重定位表的处理思路手动映射 Demo 的运行验证与常见排查点防御视角与工程建议。这里必须强调合规边界本文内容仅用于学习 Windows PE 结构、C 系统编程以及安全防御研究。相关技术一旦被用于恶意软件、免杀绕过、非法注入系统进程会产生严重法律风险。请在独立测试机、合法授权环境中进行实验。如果你正在做游戏模组加载器、插件系统、热更新组件或研究型 PE Loader这篇文章能提供一个相对完整的入门路径。如果你是零基础建议先掌握 C 基础语法、指针、内存管理概念再阅读效果更佳。2. PE 文件结构基础PEPortable Executable是 Windows 平台的可执行文件格式后缀可以是.exe、.dll、.sys等。在写手动加载器之前必须先用内存视角看懂 PE 结构。2.1 DOS 头与 NT 头PE 文件的最开始是一个IMAGE_DOS_HEADER它保留了 DOS 兼容信息。// WinNT.h 中定义 typedef struct _IMAGE_DOS_HEADER { WORD e_magic; // MZ WORD e_cblp; WORD e_cp; WORD e_crlc; ... LONG e_lfanew; // 指向 NT 头的偏移 } IMAGE_DOS_HEADER;判断一个文件是不是合法 PE前两个字节是M、Z根据e_lfanew偏移读取数据该位置前 4 字节是PE\0\0此时得到IMAGE_NT_HEADERS。typedef struct _IMAGE_NT_HEADERS { DWORD Signature; // PE\0\0 IMAGE_FILE_HEADER FileHeader; IMAGE_OPTIONAL_HEADER32 OptionalHeader; // 64 位是 IMAGE_OPTIONAL_HEADER64 } IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;FileHeader中比较重要的字段NumberOfSections节区数量SizeOfOptionalHeader可选头大小Machine目标 CPU 架构。OptionalHeader不是“可选”它对加载 DLL 非常重要ImageBasePE 文件的建议加载基址SizeOfImage内存中完整映像大小SizeOfHeaders头 节表占用的字节数DataDirectory导入表、导出表、重定位表、异常表等目录数组。// 典型用法拿到加载基址后先映射到可选头 IMAGE_OPTIONAL_HEADER64* opt ntHeaders-OptionalHeader;2.2 节表与节区数据NT 头之后是节表Section Table每个条目对应一个节区typedef struct _IMAGE_SECTION_HEADER { BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; // 8字节节名 union { DWORD PhysicalAddress; DWORD VirtualSize; } Misc; DWORD VirtualAddress; // 内存中相对基址的偏移 DWORD SizeOfRawData; // 磁盘上数据大小 DWORD PointerToRawData; // 磁盘上文件偏移 DWORD Characteristics; // 读写执行属性 } IMAGE_SECTION_HEADER;磁盘上的 PE 文件中各节区按一定的文件对齐方式存储在内存中则按“内存页对齐”展开。加载器需要做一次“从文件布局到内存布局”的转换。一个.dll内常见的节区名节区名通常用途常见属性.text可执行代码可读、可执行.rdata只读数据、导入导出表可读.data可读写全局数据可读可写.pdata64 位异常处理信息可读.reloc重定位表可读、可丢弃在手动映射时并不是简单把整个文件复制到内存而是按节区的VirtualAddress和VirtualSize拷贝。2.3 导入表与导出表导入表描述“这个 DLL 需要依赖哪些外部 DLL、哪些函数”。它由IMAGE_IMPORT_DESCRIPTOR数组组成每个描述符对应一个被依赖的 DLL数组以全 0 结构结束。typedef struct _IMAGE_IMPORT_DESCRIPTOR { union { DWORD Characteristics; DWORD OriginalFirstThunk; // INT 地址 } DUMMYUNIONNAME; DWORD TimeDateStamp; DWORD ForwarderChain; DWORD Name; // DLL 名字符串 RVA DWORD FirstThunk; // IAT 地址 } IMAGE_IMPORT_DESCRIPTOR;导入函数名称通过IMAGE_THUNK_DATA结构引用。在 64 位程序中Thunk 也是 8 字节。最高位表示该函数是否按序号导入否则低 31 位指向IMAGE_IMPORT_BY_NAME。导出表则描述“这个 DLL 导出了哪些函数”由以下结构定位typedef struct _IMAGE_EXPORT_DIRECTORY { DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Name; // DLL 名称 RVA DWORD Base; // 起始序号 DWORD NumberOfFunctions; // 导出函数数量 DWORD NumberOfNames; // 导出名称数量 DWORD AddressOfFunctions; // 函数地址表 RVA DWORD AddressOfNames; // 函数名称表 RVA DWORD AddressOfNameOrdinals;// 序号映射表 RVA } IMAGE_EXPORT_DIRECTORY;手动加载一个 DLL 后要调用它的某个导出函数需要手动解析导出表找到函数地址。2.4 重定位表程序在编译链接时会有默认ImageBase。开启 ASLR 的模块允许系统把它加载到任意地址。如果最终实际加载地址与ImageBase不一致代码中很多绝对地址就必须进行修正这个修正过程叫“重定位”。重定位表由多个IMAGE_BASE_RELOCATION结构组成typedef struct _IMAGE_BASE_RELOCATION { DWORD VirtualAddress; // 这一页的起始 RVA DWORD SizeOfBlock; // 本块大小 } IMAGE_BASE_RELOCATION;紧跟在结构后面的是WORD数组每个低 12 位表示类型高 4 位表示相对当前页的偏移量。在 PE 手动映射时如果没有严格处理重定位被加载 DLL 中凡是引用全局变量、函数指针的指令都会指向错误位置轻则返回错误结果重则访问违例。3. 手动映射加载器的运行原理3.1 LoadLibrary 到底做了什么我们平时调用LoadLibrary(test.dll)Windows 模块加载器大致有以下动作把磁盘 DLL 映射到进程地址空间解析导入表加载依赖 DLL并修复 IAT处理重定位修正绝对地址调用 DLL 入口函数DllMain执行DLL_PROCESS_ATTACH初始化把模块信息登记到进程模块链表中。操作系统加载器非常复杂涉及加载顺序、路径搜索、DLL 重名策略、绑定导入、延迟加载、异常数据初始化等。3.2 手动映射与反射式加载的简化流程手动映射器要解决的问题是自己在用户态实现上述“映射”部分。它通常不调用LoadLibrary也不经过系统加载器。常用流程如下取得 DLL 的原始字节。可能是磁盘文件读取也可能是网络/内存传递校验 DOS 头、NT 头根据SizeOfImage使用VirtualAlloc分配一块连续内存拷贝 PE 头到分配区遍历节表将每个节的SizeOfRawData从文件偏移复制到虚拟地址对应的位置根据实际基址与ImageBase的差值修复重定位表解析导入表加载依赖模块并填写 IAT调用DllMain或入口点返回模块基址供调用方通过导出表解析函数地址。反射式 DLL 加载更进一步加载器代码常常被做成 DLL 的一个导出函数比如ReflectiveLoader。这段代码在目标进程内运行后通过 PEB 等结构找到“当前 DLL 在内存中的位置”然后由加载器自己完成后续展开。反射式加载的目的是让 DLL 不必先落地到磁盘也不依赖系统加载 API。本文演示 Demo 以“外部手动映射器”为主线。理解了手动映射再去研究反射式加载会更容易。3.3 技术适用边界与实际用途从工程角度看手动映射并非日常开发首选。正常加载 DLL 永远应该优先使用系统 API。手动映射可用于内存态插件系统研究学习 Windows PE 加载细节部分游戏模组加载器原理分析安全产品做内存模块审计时的反向研究。在学习过程中要注意系统加载器不属于公共 API手动映射会绕过很多安全机制也会导致模块不稳定、无法被常规卸载、调试困难等问题。4. 环境准备与测试 DLL 编写4.1 实验环境说明本文使用 Windows 10/11编译器使用 Visual Studio 2022 或 MSVC 命令行工具。为了方便验证在控制台工程中完成加载器 Demo。测试 DLL 的设计需要做减法为了让教学版手动映射器简单可控测试 DLL 不依赖外部系统 DLL也不使用 C/C 运行库避免复杂 IAT 修复。我本地构建方式使用 Visual Studio Developer Command Promptcl /LD /O1 testlib.cpp /Fe:testlib.dll /link /DLL /DYNAMICBASE:NO /FIXED:NO注意DYNAMICBASE:NO表示关闭 ASLR生成固定基址版本FIXED:NO表示是否强制固定基址需根据链接器参数调整。在实际编译时也可以通过 CMake 的LINK_FLAGS控制。4.2 测试 DLL 源码// 文件路径testlib.cpp // 编译方式cl /LD /O1 testlib.cpp /Fe:testlib.dll extern C __declspec(dllexport) int add_two(int a, int b) { return a b; } extern C __declspec(dllexport) int mul_two(int a, int b) { return a * b; } extern C __declspec(dllexport) const char* get_message() { return PE Manual Map Demo OK; }这里使用extern C防止 C 名字改编否则在导出表中函数名会变成?add_twoYAHHHZ不方便演示字符串查找。使用命令行编译cl /LD /O1 testlib.cpp /Fe:testlib.dll /link /DYNAMICBASE:NO编译完成后会生成testlib.dll。可以用dumpbin /headers testlib.dll查看它没有导入表依赖dumpbin /dependents testlib.dll dumpbin /exports testlib.dll从输出中能看到它导出add_two、mul_two、get_message。4.3 加载器工程结构我建议把加载器代码组织成以下结构manual_loader/ ├── testlib.cpp ├── miniloader.cpp └── README.txtminiloader.cpp是教学版手动映射器主要步骤读取testlib.dll二进制内容校验 PE 签名按 PE 格式分配内存并拷贝头与节区解析导出表得到add_two的地址通过函数指针调用验证加载成功。cl /EHsc miniloader.cpp /Fe:miniloader.exe这里编译加载器时不需要testlib.lib因为加载后我们利用导出表手动查找函数地址不是静态链接调用。5. C 实现教学版 PE 手动映射器下面我会按模块展示核心代码。完整工程代码可以复制到同一个.cpp中运行。5.1 读取 DLL 文件到内存// 文件路径miniloader.cpp #include windows.h #include iostream #include vector #include string bool ReadFileToBytes(const std::string path, std::vectorBYTE outBytes) { HANDLE hFile CreateFileA( path.c_str(), GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile INVALID_HANDLE_VALUE) { std::cerr 打开文件失败错误码: GetLastError() std::endl; return false; } LARGE_INTEGER fileSize{}; if (!GetFileSizeEx(hFile, fileSize)) { CloseHandle(hFile); return false; } outBytes.resize(fileSize.QuadPart); DWORD bytesRead 0; BOOL ok ReadFile(hFile, outBytes.data(), (DWORD)outBytes.size(), bytesRead, NULL); CloseHandle(hFile); if (!ok || bytesRead ! fileSize.QuadPart) { std::cerr 读取文件失败 std::endl; return false; } return true; }这里直接使用 Windows APICreateFileA/ReadFile读取文件比用ifstream更贴近 Windows 系统编程场景。5.2 校验 DOS 头与 NT 头bool ValidatePe(const std::vectorBYTE fileData) { if (fileData.size() sizeof(IMAGE_DOS_HEADER)) { std::cerr 文件太小不足以包含 DOS 头 std::endl; return false; } IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)fileData.data(); if (dos-e_magic ! IMAGE_DOS_SIGNATURE) { std::cerr 不是有效的 MZ 文件 std::endl; return false; } LONG peOffset dos-e_lfanew; if (peOffset 0 || peOffset sizeof(IMAGE_NT_HEADERS) fileData.size()) { std::cerr 无效的 e_lfanew 偏移 std::endl; return false; } IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(fileData.data() peOffset); if (nt-Signature ! IMAGE_NT_SIGNATURE) { std::cerr 不是有效的 PE 文件 std::endl; return false; } if (nt-FileHeader.Machine ! IMAGE_FILE_MACHINE_AMD64) { std::cerr 当前示例仅支持 64 位 DLL std::endl; return false; } return true; }IMAGE_DOS_SIGNATURE就是0x5A4D对应 ASCII 字符MZ。IMAGE_NT_SIGNATURE是0x00004550对应PE\0\0。5.3 分配内存并映射节区在拿到合法 PE 后需要根据OptionalHeader.SizeOfImage分配一整块内存。教学版使用固定基址避免重定位问题BYTE* MapDllImage(const std::vectorBYTE fileData) { IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)fileData.data(); IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(fileData.data() dos-e_lfanew); IMAGE_OPTIONAL_HEADER64* opt nt-OptionalHeader; // 优先请求 ImageBase。如果地址被占用VirtualAlloc 会返回 NULL BYTE* baseAddress (BYTE*)VirtualAlloc( (LPVOID)opt-ImageBase, opt-SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE); if (baseAddress NULL) { std::cerr VirtualAlloc 失败无法使用固定基址: 0x std::hex opt-ImageBase std::dec 错误码: GetLastError() std::endl; return nullptr; } // 拷贝 PE 头 memcpy(baseAddress, fileData.data(), opt-SizeOfHeaders); // 遍历节表逐个拷贝节区 IMAGE_SECTION_HEADER* sec IMAGE_FIRST_SECTION(nt); for (int i 0; i nt-FileHeader.NumberOfSections; i, sec) { if (sec-SizeOfRawData 0) { BYTE* src fileData.data() sec-PointerToRawData; BYTE* dst baseAddress sec-VirtualAddress; memcpy(dst, src, sec-SizeOfRawData); } } return baseAddress; }重点说明PAGE_EXECUTE_READWRITE同时赋予读、写、执行权限是为了让实验代码简单。真实项目中应尽量按节区属性分配最小化权限。这里直接请求ImageBase作为目标地址。如果该地址没被占用就能避免处理重定位表。如果分配失败最简单的办法是换一个 64 位测试 DLL 的ImageBase或者在程序早期退出其他占用模块。5.4 解析导出表并获取函数地址手动加载完成后模块虽然已经在内存中但进程并不知道它是“可用的 DLL”。调用导出函数的正确方法是解析IMAGE_EXPORT_DIRECTORY。FARPROC GetExportAddress(BYTE* moduleBase, const char* exportName) { IMAGE_DOS_HEADER* dos (IMAGE_DOS_HEADER*)moduleBase; IMAGE_NT_HEADERS* nt (IMAGE_NT_HEADERS*)(moduleBase dos-e_lfanew); DWORD exportRva nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress; if (exportRva 0) { std::cerr 该模块没有导出表 std::endl; return nullptr; } IMAGE_EXPORT_DIRECTORY* exportDir (IMAGE_EXPORT_DIRECTORY*)(moduleBase exportRva); DWORD* functions (DWORD*)(moduleBase exportDir-AddressOfFunctions); DWORD* names (DWORD*)(moduleBase exportDir-AddressOfNames); WORD* ordinals (WORD*)(moduleBase exportDir-AddressOfNameOrdinals); for (DWORD i 0; i exportDir-NumberOfNames; i) { char* name (char*)(moduleBase names[i]); if (strcmp(name, exportName) 0) { DWORD funcRva functions[ordinals[i]]; return (FARPROC)(moduleBase funcRva); } } return nullptr; }值得注意导出表里的地址都是 RVA相对虚拟地址要加上moduleBase才能得到真实指针NumberOfNames是“有名字导出项的数量”可能少于NumberOfFunctions导出函数地址可能指向转发字符串例如转发到其他 DLL完整系统加载器会处理转发教学版忽略。在主函数中我们可以这样验证int main() { std::vectorBYTE dllBytes; if (!ReadFileToBytes(testlib.dll, dllBytes)) { return 1; } if (!ValidatePe(dllBytes)) { return 1; } BYTE* moduleBase MapDllImage(dllBytes); if (moduleBase nullptr) { return 1; } std::cout DLL 手动映射成功基址: 0x moduleBase std::endl; typedef int (*AddFunc)(int, int); typedef const char* (*MsgFunc)(); AddFunc addFunc (AddFunc)GetExportAddress(moduleBase, add_two); MsgFunc msgFunc (MsgFunc)GetExportAddress(moduleBase, get_message); if (addFunc nullptr || msgFunc nullptr) { std::cerr 导出函数查找失败 std::endl; return 1; } int result addFunc(30, 12); std::cout add_two(30, 12) result std::endl; const char* msg msgFunc(); std::cout get_message() msg std::endl; return 0; }预期输出DLL 手动映射成功基址: 0x00007FF700001000 add_two(30, 12) 42 get_message() PE Manual Map Demo OK如果你的测试 DLL 编译为 32 位请把代码中的IMAGE_NT_HEADERS换成IMAGE_NT_HEADERS32函数加载目标也换成 32 位工程。5.5 为什么这里不需要调用 DllMain正常的系统LoadLibrary会调用DllMain触发静态 C 运行时初始化、全局对象构造等。教学版手动映射器只适用于“无状态、无依赖”的导出函数集合没有调用入口点因此没有执行 TLS 回调和 CRT 初始化。这也解释了为什么实验 DLL 要刻意写成不依赖运行库的形式。6. 进阶导入表修复与重定位处理思路上面的教学 Demo 能跑通是因为实验 DLL 被设计成“纯净状态”。但真实 DLL 通常至少依赖系统提供的kernel32.dll或ntdll.dll。你写一个最简单的printf输出它底层就会调用 C 运行库导出函数。6.1 导入表处理思路如果需要加载真实 DLL必须处理导入表。处理流程大致如下定位IMAGE_DIRECTORY_ENTRY_IMPORT遍历IMAGE_IMPORT_DESCRIPTOR对每一项拿到 DLL 名调用LoadLibraryA加载依赖 DLL遍历其OriginalFirstThunkINT和FirstThunkIAT根据函数名或序号调用GetProcAddress拿到真实函数地址将函数地址写入当前模块 IAT。核心伪代码PIMAGE_IMPORT_DESCRIPTOR imp (PIMAGE_IMPORT_DESCRIPTOR)(base importRva); for (; imp-Name ! 0; imp) { const char* dllName (const char*)(base imp-Name); HMODULE hDep LoadLibraryA(dllName); PIMAGE_THUNK_DATA intThunk (PIMAGE_THUNK_DATA)(base imp-OriginalFirstThunk); PIMAGE_THUNK_DATA iatThunk (PIMAGE_THUNK_DATA)(base imp-FirstThunk); for (; intThunk-u1.AddressOfData ! 0; intThunk, iatThunk) { if (intThunk-u1.Ordinal IMAGE_ORDINAL_FLAG64) { // 按序号导入 iatThunk-u1.Function (ULONGLONG)GetProcAddress(hDep, (LPCSTR)IMAGE_ORDINAL(intThunk-u1.Ordinal)); } else { PIMAGE_IMPORT_BY_NAME byName (PIMAGE_IMPORT_BY_NAME)(base intThunk-u1.AddressOfData); iatThunk-u1.Function (ULONGLONG)GetProcAddress(hDep, byName-Name); } } }这里伪代码只用于理解。真实项目需要区分 32/64 位、处理按序号导入、校验OriginalFirstThunk是否为空还需要考虑加载失败后的回退策略。6.2 重定位表修复只要没有使用VirtualAlloc按ImageBase固定分配或者 DLL 开启了 ASLR就必须要处理重定位。重定位修复的基本公式是新值 旧值 (实际基址 - ImageBase)遍历IMAGE_BASE_RELOCATION块逐个读取 16 位条目IMAGE_BASE_RELOCATION* reloc (IMAGE_BASE_RELOCATION*)(base relocRva); INT64 delta (BYTE*)base - (BYTE*)ntHeaders-OptionalHeader.ImageBase; while (reloc-VirtualAddress ! 0 reloc-SizeOfBlock ! 0) { DWORD count (reloc-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); WORD* items (WORD*)((BYTE*)reloc sizeof(IMAGE_BASE_RELOCATION)); for (DWORD i 0; i count; i) { DWORD type items[i] 12; DWORD offset items[i] 0xFFF; if (type IMAGE_REL_BASED_DIR64) { ULONGLONG* patchAddr (ULONGLONG*)(base reloc-VirtualAddress offset); *patchAddr delta; } else if (type IMAGE_REL_BASED_HIGHLOW) { DWORD* patchAddr (DWORD*)(base reloc-VirtualAddress offset); *patchAddr (DWORD)delta; } // 其他类型按实际架构处理 } reloc (IMAGE_BASE_RELOCATION*)((BYTE*)reloc reloc-SizeOfBlock); }重定位修复是所有自实现 PE 加载器中最容易出错的部分因为代码中的绝对地址是链接器在编译期写死的一旦加载地址不同任何“漏修正”都会导致运行时崩溃。6.3 反射式加载的自定位差异如果你继续研究反射式 DLL 加载会发现它和外部手动映射有一个关键差异加载器函数运行在目标 DLL 的内存空间它必须先找到“自己所在模块的基址”再调用MapDllImage等逻辑加载自己。寻找自身基址常用思路通过NtCurrentTeb()访问 PEB遍历PEB-Ldr-InMemoryOrderModuleList但反射加载的模块不会出现在模块链表中所以这个方法不可靠更常见做法是借助call/pop或lea指令通过当前 EIP/RIP 附近的标志特征回溯到 DOS 头MZ在 DLL 编译时预留特定字节特征让加载器可以扫描定位。反射式加载器的实现难度远高于外部手动映射器因为它要考虑 shellcode 场景下的 API 地址解析、字符串哈希、自定位等问题。我不建议新手一上来直接做反射式加载先彻底搞懂 PE 节区映射、IAT、重定位、导出表四个部分再继续深入会顺利很多。7. 常见问题与排查思路手动映射过程中一旦崩溃调试难度比普通 DLL 大很多因为调试器可能不认为目标地址是一个模块。下面列出高频问题。问题现象常见原因解决思路VirtualAlloc返回空ImageBase 固定地址已被占用换用不同基址编译 DLL或改用偏移加载并实现重定位调用导出函数崩溃未处理重定位表实际基址与 ImageBase 不一致比较模块基址与可选头 ImageBase修复重定位函数返回乱码IAT 未修复或节区未完整拷贝检查导入表解析结果确认节区虚拟地址和文件偏移GetProcAddress找不到函数函数没有导出或名字改编使用extern C改导出名用dumpbin /exports查看内存访问违例 0xC0000005节区大小与实际 PE 不符确认 DLL 不是 32/64 位混用检查SizeOfImage与节区 RVA程序退出崩溃DllMain/CRT 初始化没有调用教学版只适合无依赖 DLL真实 DLL 需补全初始化逻辑排查时建议先分离问题先用dumpbin /headers确认 DLL 位数、ImageBase、是否包含重定位表、导入表把读取文件和 PE 头校验放在最前面打印e_lfanew、NumberOfSections、SizeOfImage每拷贝完一个节区就打印最终目标地址在调用导出函数前通过调试器确认函数地址是否属于可执行内存页。8. 工程建议与安全边界8.1 工程实践建议如果你未来需要在合法业务中实现类似模块加载机制我建议你注意以下几点。第一不要重复造轮子。能使用LoadLibrary就优先使用系统 API。手动加载带来的收益通常低于维护成本它不参与系统模块链无法被常规工具卸载也不兼容延迟加载和调试。第二权限最小化。不要把整块内存都设为PAGE_EXECUTE_READWRITE。更好的做法是解析每个节区的Characteristics分别设置PAGE_EXECUTE_READ、PAGE_READWRITE、PAGE_READONLY。代码节应该可读可执行但不可写数据节应该可读可写但不可执行这能降低被攻击面。第三生命周期管理。如果自己实现了DllMain调用在卸载时也要正确调用DLL_PROCESS_DETACH并处理 TLS 回调和全局对象析构。手动映射的模块不能简单用FreeLibrary卸载需要自己实现逆向卸载逻辑并释放VirtualAlloc分配的内存。第四错误处理必须完善。所有指针转换都要判断空指针所有VirtualAlloc、LoadLibraryA、GetProcAddress调用都要检查返回值并记录日志。8.2 防御视角与合规建议反射式 DLL 加载技术常被滥用作为开发者或安全研究人员应该从防御视角看待这个问题。如果负责安全产品开发可以关注以下检测点进程内存中是否存在不属于已知模块的 MZ/PE 头内存页同时具备可执行和可写权限且不在正常模块列表中通过 VADVirtual Address Descriptor或 ETW 监控异常内存分配审计VirtualAlloc与WriteProcessMemory的组合调用。对读者个人的建议是只在自己开发环境中做实验只能在本地测试虚拟机、自有进程中测试不用于攻击他人系统或绕过权限控制不把相关代码集成到未授权产品中。学习 PE 结构本身是安全、有价值的系统编程知识但“能写”和“该不该在真实项目中用”是两码事。请务必保持清晰的合规边界。9. 总结与下一步方向在这篇文章中我们从 PE 文件结构讲起手写了一个教学版 C PE 手动映射器实际完成了“读取 DLL 文件 - 校验 PE 头 - 分配内存 - 拷贝节区 - 解析导出表 - 调用导出函数”的完整流程。同时对导入表修复、重定位处理、反射式加载自定位等进阶点做了原理剖析。如果你能独立完成这个 Demo并解释清楚以下问题说明你已经基本掌握 PE 手动加载原理为什么SizeOfImage通常大于文件实际大小导入表与 IAT 的关系重定位表中delta如何计算为什么反射式 DLL 需要“自定位”手动加载的 DLL 为什么不会被GetModuleHandle找到。下一步可以尝试给加载器加上导入表修复加载一个使用kernel32.dll的常规 DLL给加载器加上重定位处理让VirtualAlloc不再依赖固定基址实现 DLL 入口点的调用和卸载逻辑研究 PEB 结构理解系统如何枚举模块阅读开源项目学习工业级手动映射器的错误处理和兼容性设计。C 与 Windows 底层交互的内容比较枯燥但 PE 结构是绕不开的核心知识。希望这篇文章能帮你打通“编译产物到底如何被加载进内存”这个关键点。如果在编译或运行过程中遇到问题可以按照第七节的排查表逐步定位也可以把关键输出信息打出来对比。动手改代码比只看文章理解更深。
