简介面向需要掌握DLL内存加载与手动映射技术的C/C开发者内容围绕从内存资源形式直接加载并调用DLL导出函数的完整示例展开。压缩包共22个文件约87KB包含h头文件、cpp源码、dsp/dsw工程配置、dll/lib二进制文件及txt说明等区分xDll测试DLL与testLoadDll调用端两个工程前者提供导出函数后者演示使用MemoryLoadLibrary加载、MemoryGetProcAddress取址、MemoryFreeLibrary释放的流程。已有1511人学习适合研究PE加载、免落盘调用DLL或排查模块加载问题的读者源码与工程文件可直接编译调试便于对照理解内存模块管理的接口设计、资源释放时机及测试DLL与调用端的组织方式。1. 内存加载 DLL 的真实门槛卡住人的从来不是那两百行代码内存加载 DLL 这件事我第一次写的时候真以为两百行搞定结果一个下午全耗在 DllMain 里那次访问冲突上。后来才想明白难点从来不在代码量而在于你得先搞清楚系统加载器背着你做了多少事重定位、导入表、TLS 回调、异常展开表登记漏掉哪一个都会当场崩而且崩的位置离真正原因十万八千里玄学得很。这篇把我自己趟过的完整流程摊开讲。前半段讲 PE 结构和每个阶段的判断依据为什么这一步必须做、不做会怎样后半段给你能直接编译跑通的代码、编译参数和排查清单。做安全研究的、写插件加载器的、单纯想搞懂为什么非得自己映射一遍的都能照着往下走。看完你至少能做到两件事代码能跑且出问题时知道去哪一层找。2. 手写映射和系统加载差在哪四个阶段拆开看2.1 先看清加载器替你做了哪些事一个最容易犯的错是把加载 DLL理解成把文件读进内存然后跳过去执行。中间被省略掉的每一步都是后面崩掉的伏笔。判断依据很简单打开一个 DLL 的可选头看 DataDirectory 里哪些项非零非零的项就是加载器必须处理的额外工作你自己写加载器时一个都不能跳。系统加载器实际做的事按顺序大致是把文件映射进地址空间、按 SectionAlignment 对齐铺开各节区、检查首选基址是否被占用并做重定位、遍历导入表把依赖模块拉进来并填充 IAT、注册异常处理表、执行 TLS 回调、最后才调 DllMain。而没走系统加载器的代价是这个模块不进 PEB 的模块链表系统不认识它所以后面任何一步都得你自己来。我一般会这么判断一个 DLL 好不好手工加载可选头里 ImageBase 是多少、有没有 .reloc 节、导入表里依赖了几个模块、有没有 TLS 目录。这四项决定了你要写多少代码也决定了第一次能不能跑通。2.2 四个阶段的输入输出对照表把整个流程拆成四个阶段每一阶段的输入、输出和失败表现列清楚比读十遍文档都管用。下面这张表是我自己调试时贴在屏幕边上的后面写代码基本是照着它填阶段输入输出失败时的典型表现头部解析磁盘或内存中的 DLL 字节流SizeOfImage、SizeOfHeaders、节区数量立刻返回空或映射后越界写内存申请与节区映射上一步的参数 节区表一块可读写的连续镜像调用导出函数读到的字符串是乱码重定位修复基址差 delta .reloc 内容所有绝对地址改成新基址32/64 位切换时访问冲突静态变量必崩导入表修复导入描述符 系统 API填满的 IAT走到某个 API 调用就跳进空地址前两个阶段是体力活参数抄对了基本不会错后两个阶段是理解活参数抄对了也可能错因为依赖你对 PE 结构的理解深度。真正的分界线在第三个阶段只要 delta 不为零重定位就必须做没有可能不需要这一说。2.3 为什么重定位和导入表必须自己修重定位的本质是编译期假设模块会落在 ImageBase 上所以所有绝对地址都按这个基址算死了。系统加载器拿到模块后如果发现基址被占会整体平移然后把所有需要修正的位置按 .reloc 表里记录的偏移改一遍。你自己 VirtualAlloc 拿到的地址几乎不可能是首选基址所以 delta 一定非零——除非你运气好到用 lpAddress 参数强行申请到了同一个地址。常见做法是先尝试按 ImageBase 申请失败再随便给个地址并走重定位。这个顺序值得保留能跳过重定位就跳过调试时少一层变量。导入表的逻辑更直白IAT 里每一项原本存的是函数名在内存中的相对偏移加载器要把它替换成函数真实地址。系统加载器通过模块链表找到依赖模块你没有这个链表就只能自己调 LoadLibrary 把依赖模块拉起来再 GetProcAddress 填进去。这就是为什么手写加载器最终还是要用到系统 API——你不是在替代整个加载体系只是在替代登记这一步。提示先把 delta 打印出来看一眼。很多重定位写错了的问题其实是 delta 算错而不是遍历逻辑错。3. 代码逐段落地把字节流变成能调用的模块3.1 头部校验与内存申请的关键参数第一段只做两件事确认这块字节流真的是个 PE拿到后面要用的三个尺寸。别小看校验调试阶段把一份被截断的文件喂进去没有校验的话崩在几万行之外的 memcpy 上找起来非常难受。// 传入完整 DLL 字节流返回映射后的镜像基址失败返回 NULL BYTE* MapImage(const BYTE* buf, SIZE_T size) { if (size sizeof(IMAGE_DOS_HEADER)) return NULL; PIMAGE_DOS_HEADER dos (PIMAGE_DOS_HEADER)buf; if (dos-e_magic ! IMAGE_DOS_SIGNATURE) return NULL; // MZ if (dos-e_lfanew 0 || (SIZE_T)dos-e_lfanew sizeof(IMAGE_NT_HEADERS) size) return NULL; // e_lfanew 越界是常见脏数据 PIMAGE_NT_HEADERS nt (PIMAGE_NT_HEADERS)(buf dos-e_lfanew); if (nt-Signature ! IMAGE_NT_SIGNATURE) return NULL; // PE\0\0 DWORD sizeOfImage nt-OptionalHeader.SizeOfImage; // 镜像铺开后的总大小 DWORD sizeOfHeaders nt-OptionalHeader.SizeOfHeaders; // 头部对齐后的大小 if (sizeOfImage 0 || sizeOfHeaders sizeOfImage) return NULL; // 先试首选基址能拿到就省掉重定位 BYTE* base (BYTE*)VirtualAlloc((LPVOID)nt-OptionalHeader.ImageBase, sizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); if (!base) { base (BYTE*)VirtualAlloc(NULL, sizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); if (!base) return NULL; } // 整块清零.bss 段VirtualSize SizeOfRawData 的部分靠这一步兜底 memset(base, 0, sizeOfImage); memcpy(base, buf, sizeOfHeaders); // 头部原样拷过去节区表后面还要用 return base; }三个尺寸里最容易用错的是 sizeOfHeaders 和 sizeOfImage。前者是头部本身占多少字节用来拷贝 DOS 头、NT 头和节区表后者是整个镜像铺开占多少字节用来申请内存。这两个值反着用表现是能跑但某天加载一个稍大的 DLL 就崩——典型的血泪经验。权限这里我用了 PAGE_READWRITE 而不是一步到位的可执行权限。原因在最后一章会讲简单说就是能不给执行权限的阶段就别给等重定位和导入都修完了再按节区改权限既不给自己埋坑也让行为看起来正常一点。3.2 节区映射别只盯着 SizeOfRawData节区映射看起来就是一次循环拷贝但有两个细节决定成败一是 SizeOfRawData 为 0 的节区要跳过比如只有未初始化数据的节二是 VirtualSize 大于 SizeOfRawData 时多出来的部分必须是零。上一段已经整块 memset 过了所以这里只需要拷贝有文件内容的那些节。PIMAGE_SECTION_HEADER sec IMAGE_FIRST_SECTION(nt); for (WORD i 0; i nt-FileHeader.NumberOfSections; i, sec) { if (sec-SizeOfRawData 0) continue; // 无文件内容的节跳过 if (sec-PointerToRawData sec-SizeOfRawData size) return NULL; // 数据越界保护 memcpy(base sec-VirtualAddress, buf sec-PointerToRawData, sec-SizeOfRawData); // 目标按 VirtualAddress 对齐 }这段代码里唯一需要解释的参数是 VirtualAddress 和 PointerToRawData 的区别前者是在内存镜像里的偏移后者是在磁盘文件里的偏移两者通常不同因为内存里按 SectionAlignment一般 0x1000对齐文件里按 FileAlignment一般 0x200对齐。很多新手直接把文件偏移当内存偏移用结果是数据整体错位导出的函数能调但读到的全局变量全是垃圾值。顺带说一句如果某个节区的 Characteristics 里带了 IMAGE_SCN_MEM_DISCARDABLE理论上可以不映射但实践中建议照常拷——少拷一节省不了多少内存出问题排查成本却翻倍。3.3 重定位表遍历与 delta 计算这段是整份代码里最容易写错的地方没有之一。重定位表是一串块每块描述一个 4KB 页面内需要修正的若干位置每个位置用一个 WORD 表示高 4 位是类型低 12 位是页内偏移。类型不匹配就直接跳过这是规范要求不是容错。typedef struct { WORD offset : 12; WORD type : 4; } RELOC_ENTRY; void DoRelocate(BYTE* base, PIMAGE_NT_HEADERS nt) { // delta 必须用有符号的指针宽度整型32 位下算成 32 位会翻转 LONGLONG delta (LONGLONG)(base - (BYTE*)nt-OptionalHeader.ImageBase); if (delta 0) return; // 正好落在首选基址什么都不用做 IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC]; if (dir.VirtualAddress 0 || dir.Size 0) return; DWORD consumed 0; while (consumed dir.Size) { PIMAGE_BASE_RELOCATION block (PIMAGE_BASE_RELOCATION)(base dir.VirtualAddress consumed); if (block-SizeOfBlock sizeof(IMAGE_BASE_RELOCATION)) break; DWORD count (block-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); RELOC_ENTRY* items (RELOC_ENTRY*)(block 1); for (DWORD i 0; i count; i) { if (items[i].type 0) continue; // IMAGE_REL_BASED_ABSOLUTE填充项 BYTE* target base block-VirtualAddress items[i].offset; if (items[i].type IMAGE_REL_BASED_HIGHLOW) // 32 位 *(DWORD*)target (DWORD)delta; else if (items[i].type IMAGE_REL_BASED_DIR64) // 64 位 *(ULONGLONG*)target (ULONGLONG)delta; } consumed block-SizeOfBlock; } }参数说明delta 是实际基址减首选基址可正可负所以必须用有符号类型block-VirtualAddress 是页起始的 RVA加上页内 offset 才是最终位置。判定条件里我特意保留了type 0就跳过因为编译器经常插入这种填充项把它当真实项处理会写坏相邻数据。这里还有一个隐藏判断点如果你在 32 位进程里加载 64 位 DLL类型是 DIR64 但你按 DWORD 写结果就是只改了低 32 位表面上不崩实际调到某个函数才炸。所以位宽必须匹配后面的差异清单会再提一次。3.4 导入表修复自己把 IAT 填满导入表的遍历逻辑比重定位简单但有两个坑OriginalFirstThunk 可能为 0以及按序号导入时高位掩码。这两点后面排查章还会遇到这里先把正确写法摆出来。void FixImports(BYTE* base, PIMAGE_NT_HEADERS nt) { IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]; if (dir.VirtualAddress 0) return; PIMAGE_IMPORT_DESCRIPTOR desc (PIMAGE_IMPORT_DESCRIPTOR)(base dir.VirtualAddress); for (; desc-Name; desc) { const char* modName (const char*)(base desc-Name); HMODULE hMod LoadLibraryA(modName); // 依赖模块交给系统加载 if (!hMod) continue; // OFT 为 0 时退回用 FirstThunk 当名字表此时两者指向同一块 PIMAGE_THUNK_DATA oft (PIMAGE_THUNK_DATA)(base (desc-OriginalFirstThunk ? desc-OriginalFirstThunk : desc-FirstThunk)); PIMAGE_THUNK_DATA iat (PIMAGE_THUNK_DATA)(base desc-FirstThunk); for (; oft-u1.AddressOfData; oft, iat) { FARPROC fn NULL; if (oft-u1.Ordinal IMAGE_ORDINAL_FLAG) { // 按序号导入 WORD ord (WORD)(oft-u1.Ordinal 0xFFFF); // 必须屏蔽高位标志 fn GetProcAddress(hMod, (LPCSTR)(ULONG_PTR)ord); } else { // 按名字导入 PIMAGE_IMPORT_BY_NAME nb (PIMAGE_IMPORT_BY_NAME)(base oft-u1.AddressOfData); fn GetProcAddress(hMod, nb-Name); } iat-u1.Function (ULONG_PTR)fn; // 写进 IAT } } }关键参数IMAGE_ORDINAL_FLAG 在 32 位下是 0x8000000064 位下是 0x8000000000000000所以判断时直接用它取序号时用 0xFFFF 掩码。这里没有做函数找不到就报错的处理是因为研究场景下我更需要它继续跑完、把缺失的函数名全部打印出来一次性看全而不是卡在第一个失败项上。还有一点值得留意LoadLibraryA 传的是模块名比如某个常见的运行时库系统会按它自己的搜索顺序去找。如果你的依赖模块根本不在搜索路径里这一段会静默失败表现是后面调到某个 API 直接跳空。所以调试版里把hMod NULL的分支加上日志能省很多时间。3.5 TLS 回调与入口点调用顺序顺序这件事没有商量余地TLS 回调必须在 DllMain 之前跑因为很多编译器把静态对象的构造放进 TLS 回调里。漏了这一步DllMain 里访问任何全局对象都可能是未初始化状态崩溃点看起来莫名其妙。typedef BOOL (WINAPI *PDLLMAIN)(HMODULE, DWORD, LPVOID); typedef void (NTAPI *PTLS_CALLBACK)(PVOID, DWORD, PVOID); // 先跑 TLS 回调DLL_PROCESS_ATTACH 阶段 IMAGE_DATA_DIRECTORY tlsDir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS]; if (tlsDir.VirtualAddress) { PIMAGE_TLS_DIRECTORY tls (PIMAGE_TLS_DIRECTORY)(base tlsDir.VirtualAddress); PTLS_CALLBACK* cb (PTLS_CALLBACK*)tls-AddressOfCallBacks; // 注意这是 VA不是 RVA if (cb) { for (; *cb; cb) (*cb)(base, DLL_PROCESS_ATTACH, NULL); } } // 再调入口点等价于 DllMain(hModule, DLL_PROCESS_ATTACH, NULL) if (nt-OptionalHeader.AddressOfEntryPoint) { PDLLMAIN entry (PDLLMAIN)(base nt-OptionalHeader.AddressOfEntryPoint); entry((HMODULE)base, DLL_PROCESS_ATTACH, NULL); }这里有个特别容易踩的点TLS 目录里的 AddressOfCallBacks 存的是绝对地址VA不是 RVA因为它是在链接期由重定位修好的。如果你像其他目录那样加上 base 偏移就会跳到野地址。判断依据是 PE 规范里 TLS 目录字段的类型定义其余目录基本都是 RVA唯独这里不是——这种例外最坑人。入口点调用完之后导出函数就能正常用了。如果目标 DLL 里还有 C 静态对象、需要注册异常处理表那还得补一步这个留到排查章里说。4. 一次完整复现从编译参数到调用成功4.1 调用方与目标 DLL 的编译约定复现环境我建议这样搭一个极简的目标 DLL只导出一个加法函数和一个返回字符串的函数一个控制台程序做加载器。目标 DLL 先别用 C、别加静态对象、别开异常把变量降到最低跑通之后再逐项加回来——这个顺序能让你明确定位是哪一项特性让加载器崩掉。// 目标 DLL只用 C导出两个函数不引入任何 C 特性 __declspec(dllexport) int Add(int a, int b) { return a b; } __declspec(dllexport) const char* Greet(void) { return loaded-from-memory; }加载器侧读取文件、调映射、调导出// 加载器读文件 - 映射 - 修表 - 调入口 - 取导出地址 FILE* fp fopen(demo_target.dll, rb); fseek(fp, 0, SEEK_END); long fsize ftell(fp); fseek(fp, 0, SEEK_SET); BYTE* raw (BYTE*)malloc(fsize); fread(raw, 1, fsize, fp); fclose(fp); BYTE* image MapImage(raw, (SIZE_T)fsize); // 头部校验 申请 拷贝头部 MapSections(image, raw, fsize); // 节区铺开 PIMAGE_NT_HEADERS nt GetNt(image); DoRelocate(image, nt); // 基址不一致时修正 FixImports(image, nt); // 填 IAT RunTlsAndEntry(image, nt); // TLS 回调 入口点编译参数上有两个约定值得写死目标 DLL 用/MT静态链接运行时避免依赖额外的运行时 DLL加载器和目标 DLL 的位宽必须一致32 位加载器只能加载 32 位 DLL。这两条不是最优解但能让第一次复现的成功率接近百分之百。4.2 三步验证加载是否真的成功很多人验证的方式是没崩就算成功这个标准太低因为大部分错误是延迟触发的。我一般会用三个检查点从弱到强第一检查镜像是否真的铺开。打印 base、delta、SizeOfImage再用调试器看 base 某个节区的 VirtualAddress 处的内容跟磁盘文件对应偏移的内容比对一致才算映射正确。第二用自己实现的取地址函数拿导出而不是靠计算偏移。这一步同时验证了导出表解析和节区映射两件事。// 自己实现 GetProcAddress遍历导出表 FARPROC MemoryGetProcAddress(BYTE* base, const char* name) { PIMAGE_NT_HEADERS nt GetNt(base); IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]; if (dir.VirtualAddress 0) return NULL; PIMAGE_EXPORT_DIRECTORY exp (PIMAGE_EXPORT_DIRECTORY)(base dir.VirtualAddress); DWORD* names (DWORD*)(base exp-AddressOfNames); // 函数名 RVA 数组 WORD* ords (WORD*)(base exp-AddressOfNameOrdinals); // 名字索引到函数索引的映射 DWORD* funcs (DWORD*)(base exp-AddressOfFunctions); // 函数 RVA 数组 for (DWORD i 0; i exp-NumberOfNames; i) { if (strcmp((const char*)(base names[i]), name) 0) { DWORD rva funcs[ords[i]]; // 注意二次索引 // 落在导出目录范围内的 RVA 是转发导出这里直接放弃 if (rva dir.VirtualAddress rva dir.VirtualAddress dir.Size) return NULL; return (FARPROC)(base rva); } } return NULL; }这段里最容易错的是funcs[ords[i]]names 数组和 funcs 数组的下标不是一一对应的中间隔了一层序号映射。直接用funcs[i]取到的是别的函数症状是能取到地址但调用结果不对比取不到还难查。第三真正调用一次并且调两次。第一次看返回值是否符合预期第二次看是否有状态被写坏——很多加载器的问题是第一次调用正常、第二次崩原因是全局变量或静态缓冲区地址没被正确重定位。4.3 32 位与 64 位的差异清单位宽切换是这套代码里最容易翻车的一环我把它单独列出来。核心差异集中在三处差异项32 位64 位重定位类型IMAGE_REL_BASED_HIGHLOW写 DWORDIMAGE_REL_BASED_DIR64写 ULONGLONG序号导入标志IMAGE_ORDINAL_FLAG 为 0x80000000同名为 0x8000000000000000指针宽度4 字节thunk 用 u1.Function8 字节同字段不同宽度除此之外还有一个不在表里的差异64 位下异常展开依赖 .pdata 段里登记的函数表模块没被系统加载器登记异常就没法正常展开。表现是一旦目标 DLL 里出现 try/catch 或任何需要栈展开的路径进程直接终止。解决办法是调系统的函数表注册接口把 .pdata 范围登记进去或者干脆在目标 DLL 编译期关掉异常——研究阶段我更倾向于后者先把主流程跑通。5. 常见问题排查五次真实的翻车记录5.1 加载阶段就崩掉的三种情况现象一入口点一进去就崩在全局对象构造里调用栈只有几层。原因没有执行 TLS 回调或者执行顺序放到了入口点之后。C 的静态对象构造、部分运行时的初始化都挂在 TLS 回调上跳过它等于让代码在未初始化环境里跑。 解决把 TLS 回调的遍历放到入口点调用之前并且严格使用 DLL_PROCESS_ATTACH。调试时把回调地址打印出来确认至少有一个非空项。现象二映射完成后读到的字符串是乱码函数能调但数据全错。原因节区映射只拷了 SizeOfRawData而 VirtualSize 更大的部分没有被清零或者漏拷了头部导致某些依赖头部数据的逻辑读到脏值。 解决申请内存后立刻整块 memset 清零再拷头部、再按节区拷。养成先清零再填充的习惯这类问题基本绝迹。现象三访问冲突发生在 VirtualAlloc 返回的地址附近偏移看着眼熟。原因节区拷贝时把文件偏移 PointerToRawData 当成内存偏移 VirtualAddress 用了数据整体错位越界写穿到相邻页。 解决把两个字段的含义写在注释里调试版里对每个节区打印VirtualAddress / PointerToRawData / SizeOfRawData三元组肉眼比对一次就能发现异常。5.2 加载成功但一调用就出问题的两种现象四GetProcAddress 返回空导入表里明明有这个函数名。原因OriginalFirstThunk 为 0 时错误地继续用它做名字表读到的是已经被填过的 IAT 内容或者按序号导入时没屏蔽 IMAGE_ORDINAL_FLAG把 0x80000005 当成序号 2147483653 去查。 解决OFT 为 0 时回退用 FirstThunk但要注意此时不能边读边写同一块内存稳妥做法是先完整解析出地址再统一回填。序号分支一定加 0xFFFF 掩码。现象五本地跑得好好的一放到有安全产品的环境就被拦或者行为直接消失。原因整个镜像是一块没有对应模块记录的私有内存权限还是可读写可执行这个组合在检测规则里非常显眼再加上申请内存、改权限、跳转执行这条调用序列本身就很有特征。 解决研究阶段在隔离环境里做别在生产机上试实现层面把权限收紧映射时只给读写等所有修正完成再按节区分别改成可执行或只读别一上来就给全权限。这不是为了绕过而是让实现本身更接近正常加载器的行为减少误报也减少自己踩坑。注意以上排查建议仅用于自有程序的功能调试与安全产品的能力验证任何针对他人系统的使用都不在讨论范围内。6. 收尾验证三个检查点确认加载器没有埋雷写到这里代码能跑已经不算难事难的是确认它跑对了。我自己收尾时会强制走三个检查点缺一个都不算完。第一个检查点看头部一致性。镜像铺开之后把 base 处的前 0x1000 字节和磁盘文件的前 0x1000 字节做一次逐字节比对理论上只有节区表之后的部分可能不同。这一步能一次性抓出头部没拷全和拷贝长度算错两类问题比在导出函数里调试快得多。对比的时候顺手把 SizeOfImage 和实际分配长度也打出来两个值不相等就说明申请阶段就有问题。第二个检查点看每个导入函数的落点。填完 IAT 之后遍历一遍所有非空项判断每个函数地址是否落在某个已加载模块的地址范围内——取模块基址和大小做区间比较就行不需要多精确。这一步的价值在于抓静默失败某个依赖模块没加载成功对应的 IAT 项是 0 或者是个野指针不检查的话要等到真正调用那一行才崩中间可能隔了几百行代码。第三个检查点看两次调用的差异。同一个导出函数连着调两次中间穿插一次读全局状态的调用两次结果必须一致。不一致说明有状态在第一次调用时被写坏通常是重定位漏改或者 .bss 段没清零。这一步是我被坑过之后才加上的之前一直以为调通一次就是通了。最后一个技巧关于重定位到底有没有跑对。加一行调试输出把实际分配基址和首选 ImageBase 的差值打出来差值为 0 说明你运气好跳过了重定位这时候能跑完全不能证明重定位代码正确差值为 0 的情况下我会人为在申请时加一个 0x10000 的偏移强制让 delta 非零再跑一遍全部检查点。这个动作多花不了五分钟但能提前发现绝大多数位宽和遍历边界的问题。回过头看这套东西真正的门槛不是代码而是你愿不愿意为看不见的步骤付出耐心。从那以后我每次写这类加载逻辑都会先把 delta 打印出来看它是不是非零再决定要不要相信后面的测试结果——玄学归玄学能验证的东西就别靠感觉。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 15:10:41 · 阅读 1.2k 内存加载DLL全流程：PE映射、重定位与导入表修复
简介面向需要掌握DLL内存加载与手动映射技术的C/C开发者内容围绕从内存资源形式直接加载并调用DLL导出函数的完整示例展开。压缩包共22个文件约87KB包含h头文件、cpp源码、dsp/dsw工程配置、dll/lib二进制文件及txt说明等区分xDll测试DLL与testLoadDll调用端两个工程前者提供导出函数后者演示使用MemoryLoadLibrary加载、MemoryGetProcAddress取址、MemoryFreeLibrary释放的流程。已有1511人学习适合研究PE加载、免落盘调用DLL或排查模块加载问题的读者源码与工程文件可直接编译调试便于对照理解内存模块管理的接口设计、资源释放时机及测试DLL与调用端的组织方式。1. 内存加载 DLL 的真实门槛卡住人的从来不是那两百行代码内存加载 DLL 这件事我第一次写的时候真以为两百行搞定结果一个下午全耗在 DllMain 里那次访问冲突上。后来才想明白难点从来不在代码量而在于你得先搞清楚系统加载器背着你做了多少事重定位、导入表、TLS 回调、异常展开表登记漏掉哪一个都会当场崩而且崩的位置离真正原因十万八千里玄学得很。这篇把我自己趟过的完整流程摊开讲。前半段讲 PE 结构和每个阶段的判断依据为什么这一步必须做、不做会怎样后半段给你能直接编译跑通的代码、编译参数和排查清单。做安全研究的、写插件加载器的、单纯想搞懂为什么非得自己映射一遍的都能照着往下走。看完你至少能做到两件事代码能跑且出问题时知道去哪一层找。2. 手写映射和系统加载差在哪四个阶段拆开看2.1 先看清加载器替你做了哪些事一个最容易犯的错是把加载 DLL理解成把文件读进内存然后跳过去执行。中间被省略掉的每一步都是后面崩掉的伏笔。判断依据很简单打开一个 DLL 的可选头看 DataDirectory 里哪些项非零非零的项就是加载器必须处理的额外工作你自己写加载器时一个都不能跳。系统加载器实际做的事按顺序大致是把文件映射进地址空间、按 SectionAlignment 对齐铺开各节区、检查首选基址是否被占用并做重定位、遍历导入表把依赖模块拉进来并填充 IAT、注册异常处理表、执行 TLS 回调、最后才调 DllMain。而没走系统加载器的代价是这个模块不进 PEB 的模块链表系统不认识它所以后面任何一步都得你自己来。我一般会这么判断一个 DLL 好不好手工加载可选头里 ImageBase 是多少、有没有 .reloc 节、导入表里依赖了几个模块、有没有 TLS 目录。这四项决定了你要写多少代码也决定了第一次能不能跑通。2.2 四个阶段的输入输出对照表把整个流程拆成四个阶段每一阶段的输入、输出和失败表现列清楚比读十遍文档都管用。下面这张表是我自己调试时贴在屏幕边上的后面写代码基本是照着它填阶段输入输出失败时的典型表现头部解析磁盘或内存中的 DLL 字节流SizeOfImage、SizeOfHeaders、节区数量立刻返回空或映射后越界写内存申请与节区映射上一步的参数 节区表一块可读写的连续镜像调用导出函数读到的字符串是乱码重定位修复基址差 delta .reloc 内容所有绝对地址改成新基址32/64 位切换时访问冲突静态变量必崩导入表修复导入描述符 系统 API填满的 IAT走到某个 API 调用就跳进空地址前两个阶段是体力活参数抄对了基本不会错后两个阶段是理解活参数抄对了也可能错因为依赖你对 PE 结构的理解深度。真正的分界线在第三个阶段只要 delta 不为零重定位就必须做没有可能不需要这一说。2.3 为什么重定位和导入表必须自己修重定位的本质是编译期假设模块会落在 ImageBase 上所以所有绝对地址都按这个基址算死了。系统加载器拿到模块后如果发现基址被占会整体平移然后把所有需要修正的位置按 .reloc 表里记录的偏移改一遍。你自己 VirtualAlloc 拿到的地址几乎不可能是首选基址所以 delta 一定非零——除非你运气好到用 lpAddress 参数强行申请到了同一个地址。常见做法是先尝试按 ImageBase 申请失败再随便给个地址并走重定位。这个顺序值得保留能跳过重定位就跳过调试时少一层变量。导入表的逻辑更直白IAT 里每一项原本存的是函数名在内存中的相对偏移加载器要把它替换成函数真实地址。系统加载器通过模块链表找到依赖模块你没有这个链表就只能自己调 LoadLibrary 把依赖模块拉起来再 GetProcAddress 填进去。这就是为什么手写加载器最终还是要用到系统 API——你不是在替代整个加载体系只是在替代登记这一步。提示先把 delta 打印出来看一眼。很多重定位写错了的问题其实是 delta 算错而不是遍历逻辑错。3. 代码逐段落地把字节流变成能调用的模块3.1 头部校验与内存申请的关键参数第一段只做两件事确认这块字节流真的是个 PE拿到后面要用的三个尺寸。别小看校验调试阶段把一份被截断的文件喂进去没有校验的话崩在几万行之外的 memcpy 上找起来非常难受。// 传入完整 DLL 字节流返回映射后的镜像基址失败返回 NULL BYTE* MapImage(const BYTE* buf, SIZE_T size) { if (size sizeof(IMAGE_DOS_HEADER)) return NULL; PIMAGE_DOS_HEADER dos (PIMAGE_DOS_HEADER)buf; if (dos-e_magic ! IMAGE_DOS_SIGNATURE) return NULL; // MZ if (dos-e_lfanew 0 || (SIZE_T)dos-e_lfanew sizeof(IMAGE_NT_HEADERS) size) return NULL; // e_lfanew 越界是常见脏数据 PIMAGE_NT_HEADERS nt (PIMAGE_NT_HEADERS)(buf dos-e_lfanew); if (nt-Signature ! IMAGE_NT_SIGNATURE) return NULL; // PE\0\0 DWORD sizeOfImage nt-OptionalHeader.SizeOfImage; // 镜像铺开后的总大小 DWORD sizeOfHeaders nt-OptionalHeader.SizeOfHeaders; // 头部对齐后的大小 if (sizeOfImage 0 || sizeOfHeaders sizeOfImage) return NULL; // 先试首选基址能拿到就省掉重定位 BYTE* base (BYTE*)VirtualAlloc((LPVOID)nt-OptionalHeader.ImageBase, sizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); if (!base) { base (BYTE*)VirtualAlloc(NULL, sizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); if (!base) return NULL; } // 整块清零.bss 段VirtualSize SizeOfRawData 的部分靠这一步兜底 memset(base, 0, sizeOfImage); memcpy(base, buf, sizeOfHeaders); // 头部原样拷过去节区表后面还要用 return base; }三个尺寸里最容易用错的是 sizeOfHeaders 和 sizeOfImage。前者是头部本身占多少字节用来拷贝 DOS 头、NT 头和节区表后者是整个镜像铺开占多少字节用来申请内存。这两个值反着用表现是能跑但某天加载一个稍大的 DLL 就崩——典型的血泪经验。权限这里我用了 PAGE_READWRITE 而不是一步到位的可执行权限。原因在最后一章会讲简单说就是能不给执行权限的阶段就别给等重定位和导入都修完了再按节区改权限既不给自己埋坑也让行为看起来正常一点。3.2 节区映射别只盯着 SizeOfRawData节区映射看起来就是一次循环拷贝但有两个细节决定成败一是 SizeOfRawData 为 0 的节区要跳过比如只有未初始化数据的节二是 VirtualSize 大于 SizeOfRawData 时多出来的部分必须是零。上一段已经整块 memset 过了所以这里只需要拷贝有文件内容的那些节。PIMAGE_SECTION_HEADER sec IMAGE_FIRST_SECTION(nt); for (WORD i 0; i nt-FileHeader.NumberOfSections; i, sec) { if (sec-SizeOfRawData 0) continue; // 无文件内容的节跳过 if (sec-PointerToRawData sec-SizeOfRawData size) return NULL; // 数据越界保护 memcpy(base sec-VirtualAddress, buf sec-PointerToRawData, sec-SizeOfRawData); // 目标按 VirtualAddress 对齐 }这段代码里唯一需要解释的参数是 VirtualAddress 和 PointerToRawData 的区别前者是在内存镜像里的偏移后者是在磁盘文件里的偏移两者通常不同因为内存里按 SectionAlignment一般 0x1000对齐文件里按 FileAlignment一般 0x200对齐。很多新手直接把文件偏移当内存偏移用结果是数据整体错位导出的函数能调但读到的全局变量全是垃圾值。顺带说一句如果某个节区的 Characteristics 里带了 IMAGE_SCN_MEM_DISCARDABLE理论上可以不映射但实践中建议照常拷——少拷一节省不了多少内存出问题排查成本却翻倍。3.3 重定位表遍历与 delta 计算这段是整份代码里最容易写错的地方没有之一。重定位表是一串块每块描述一个 4KB 页面内需要修正的若干位置每个位置用一个 WORD 表示高 4 位是类型低 12 位是页内偏移。类型不匹配就直接跳过这是规范要求不是容错。typedef struct { WORD offset : 12; WORD type : 4; } RELOC_ENTRY; void DoRelocate(BYTE* base, PIMAGE_NT_HEADERS nt) { // delta 必须用有符号的指针宽度整型32 位下算成 32 位会翻转 LONGLONG delta (LONGLONG)(base - (BYTE*)nt-OptionalHeader.ImageBase); if (delta 0) return; // 正好落在首选基址什么都不用做 IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC]; if (dir.VirtualAddress 0 || dir.Size 0) return; DWORD consumed 0; while (consumed dir.Size) { PIMAGE_BASE_RELOCATION block (PIMAGE_BASE_RELOCATION)(base dir.VirtualAddress consumed); if (block-SizeOfBlock sizeof(IMAGE_BASE_RELOCATION)) break; DWORD count (block-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); RELOC_ENTRY* items (RELOC_ENTRY*)(block 1); for (DWORD i 0; i count; i) { if (items[i].type 0) continue; // IMAGE_REL_BASED_ABSOLUTE填充项 BYTE* target base block-VirtualAddress items[i].offset; if (items[i].type IMAGE_REL_BASED_HIGHLOW) // 32 位 *(DWORD*)target (DWORD)delta; else if (items[i].type IMAGE_REL_BASED_DIR64) // 64 位 *(ULONGLONG*)target (ULONGLONG)delta; } consumed block-SizeOfBlock; } }参数说明delta 是实际基址减首选基址可正可负所以必须用有符号类型block-VirtualAddress 是页起始的 RVA加上页内 offset 才是最终位置。判定条件里我特意保留了type 0就跳过因为编译器经常插入这种填充项把它当真实项处理会写坏相邻数据。这里还有一个隐藏判断点如果你在 32 位进程里加载 64 位 DLL类型是 DIR64 但你按 DWORD 写结果就是只改了低 32 位表面上不崩实际调到某个函数才炸。所以位宽必须匹配后面的差异清单会再提一次。3.4 导入表修复自己把 IAT 填满导入表的遍历逻辑比重定位简单但有两个坑OriginalFirstThunk 可能为 0以及按序号导入时高位掩码。这两点后面排查章还会遇到这里先把正确写法摆出来。void FixImports(BYTE* base, PIMAGE_NT_HEADERS nt) { IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]; if (dir.VirtualAddress 0) return; PIMAGE_IMPORT_DESCRIPTOR desc (PIMAGE_IMPORT_DESCRIPTOR)(base dir.VirtualAddress); for (; desc-Name; desc) { const char* modName (const char*)(base desc-Name); HMODULE hMod LoadLibraryA(modName); // 依赖模块交给系统加载 if (!hMod) continue; // OFT 为 0 时退回用 FirstThunk 当名字表此时两者指向同一块 PIMAGE_THUNK_DATA oft (PIMAGE_THUNK_DATA)(base (desc-OriginalFirstThunk ? desc-OriginalFirstThunk : desc-FirstThunk)); PIMAGE_THUNK_DATA iat (PIMAGE_THUNK_DATA)(base desc-FirstThunk); for (; oft-u1.AddressOfData; oft, iat) { FARPROC fn NULL; if (oft-u1.Ordinal IMAGE_ORDINAL_FLAG) { // 按序号导入 WORD ord (WORD)(oft-u1.Ordinal 0xFFFF); // 必须屏蔽高位标志 fn GetProcAddress(hMod, (LPCSTR)(ULONG_PTR)ord); } else { // 按名字导入 PIMAGE_IMPORT_BY_NAME nb (PIMAGE_IMPORT_BY_NAME)(base oft-u1.AddressOfData); fn GetProcAddress(hMod, nb-Name); } iat-u1.Function (ULONG_PTR)fn; // 写进 IAT } } }关键参数IMAGE_ORDINAL_FLAG 在 32 位下是 0x8000000064 位下是 0x8000000000000000所以判断时直接用它取序号时用 0xFFFF 掩码。这里没有做函数找不到就报错的处理是因为研究场景下我更需要它继续跑完、把缺失的函数名全部打印出来一次性看全而不是卡在第一个失败项上。还有一点值得留意LoadLibraryA 传的是模块名比如某个常见的运行时库系统会按它自己的搜索顺序去找。如果你的依赖模块根本不在搜索路径里这一段会静默失败表现是后面调到某个 API 直接跳空。所以调试版里把hMod NULL的分支加上日志能省很多时间。3.5 TLS 回调与入口点调用顺序顺序这件事没有商量余地TLS 回调必须在 DllMain 之前跑因为很多编译器把静态对象的构造放进 TLS 回调里。漏了这一步DllMain 里访问任何全局对象都可能是未初始化状态崩溃点看起来莫名其妙。typedef BOOL (WINAPI *PDLLMAIN)(HMODULE, DWORD, LPVOID); typedef void (NTAPI *PTLS_CALLBACK)(PVOID, DWORD, PVOID); // 先跑 TLS 回调DLL_PROCESS_ATTACH 阶段 IMAGE_DATA_DIRECTORY tlsDir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS]; if (tlsDir.VirtualAddress) { PIMAGE_TLS_DIRECTORY tls (PIMAGE_TLS_DIRECTORY)(base tlsDir.VirtualAddress); PTLS_CALLBACK* cb (PTLS_CALLBACK*)tls-AddressOfCallBacks; // 注意这是 VA不是 RVA if (cb) { for (; *cb; cb) (*cb)(base, DLL_PROCESS_ATTACH, NULL); } } // 再调入口点等价于 DllMain(hModule, DLL_PROCESS_ATTACH, NULL) if (nt-OptionalHeader.AddressOfEntryPoint) { PDLLMAIN entry (PDLLMAIN)(base nt-OptionalHeader.AddressOfEntryPoint); entry((HMODULE)base, DLL_PROCESS_ATTACH, NULL); }这里有个特别容易踩的点TLS 目录里的 AddressOfCallBacks 存的是绝对地址VA不是 RVA因为它是在链接期由重定位修好的。如果你像其他目录那样加上 base 偏移就会跳到野地址。判断依据是 PE 规范里 TLS 目录字段的类型定义其余目录基本都是 RVA唯独这里不是——这种例外最坑人。入口点调用完之后导出函数就能正常用了。如果目标 DLL 里还有 C 静态对象、需要注册异常处理表那还得补一步这个留到排查章里说。4. 一次完整复现从编译参数到调用成功4.1 调用方与目标 DLL 的编译约定复现环境我建议这样搭一个极简的目标 DLL只导出一个加法函数和一个返回字符串的函数一个控制台程序做加载器。目标 DLL 先别用 C、别加静态对象、别开异常把变量降到最低跑通之后再逐项加回来——这个顺序能让你明确定位是哪一项特性让加载器崩掉。// 目标 DLL只用 C导出两个函数不引入任何 C 特性 __declspec(dllexport) int Add(int a, int b) { return a b; } __declspec(dllexport) const char* Greet(void) { return loaded-from-memory; }加载器侧读取文件、调映射、调导出// 加载器读文件 - 映射 - 修表 - 调入口 - 取导出地址 FILE* fp fopen(demo_target.dll, rb); fseek(fp, 0, SEEK_END); long fsize ftell(fp); fseek(fp, 0, SEEK_SET); BYTE* raw (BYTE*)malloc(fsize); fread(raw, 1, fsize, fp); fclose(fp); BYTE* image MapImage(raw, (SIZE_T)fsize); // 头部校验 申请 拷贝头部 MapSections(image, raw, fsize); // 节区铺开 PIMAGE_NT_HEADERS nt GetNt(image); DoRelocate(image, nt); // 基址不一致时修正 FixImports(image, nt); // 填 IAT RunTlsAndEntry(image, nt); // TLS 回调 入口点编译参数上有两个约定值得写死目标 DLL 用/MT静态链接运行时避免依赖额外的运行时 DLL加载器和目标 DLL 的位宽必须一致32 位加载器只能加载 32 位 DLL。这两条不是最优解但能让第一次复现的成功率接近百分之百。4.2 三步验证加载是否真的成功很多人验证的方式是没崩就算成功这个标准太低因为大部分错误是延迟触发的。我一般会用三个检查点从弱到强第一检查镜像是否真的铺开。打印 base、delta、SizeOfImage再用调试器看 base 某个节区的 VirtualAddress 处的内容跟磁盘文件对应偏移的内容比对一致才算映射正确。第二用自己实现的取地址函数拿导出而不是靠计算偏移。这一步同时验证了导出表解析和节区映射两件事。// 自己实现 GetProcAddress遍历导出表 FARPROC MemoryGetProcAddress(BYTE* base, const char* name) { PIMAGE_NT_HEADERS nt GetNt(base); IMAGE_DATA_DIRECTORY dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]; if (dir.VirtualAddress 0) return NULL; PIMAGE_EXPORT_DIRECTORY exp (PIMAGE_EXPORT_DIRECTORY)(base dir.VirtualAddress); DWORD* names (DWORD*)(base exp-AddressOfNames); // 函数名 RVA 数组 WORD* ords (WORD*)(base exp-AddressOfNameOrdinals); // 名字索引到函数索引的映射 DWORD* funcs (DWORD*)(base exp-AddressOfFunctions); // 函数 RVA 数组 for (DWORD i 0; i exp-NumberOfNames; i) { if (strcmp((const char*)(base names[i]), name) 0) { DWORD rva funcs[ords[i]]; // 注意二次索引 // 落在导出目录范围内的 RVA 是转发导出这里直接放弃 if (rva dir.VirtualAddress rva dir.VirtualAddress dir.Size) return NULL; return (FARPROC)(base rva); } } return NULL; }这段里最容易错的是funcs[ords[i]]names 数组和 funcs 数组的下标不是一一对应的中间隔了一层序号映射。直接用funcs[i]取到的是别的函数症状是能取到地址但调用结果不对比取不到还难查。第三真正调用一次并且调两次。第一次看返回值是否符合预期第二次看是否有状态被写坏——很多加载器的问题是第一次调用正常、第二次崩原因是全局变量或静态缓冲区地址没被正确重定位。4.3 32 位与 64 位的差异清单位宽切换是这套代码里最容易翻车的一环我把它单独列出来。核心差异集中在三处差异项32 位64 位重定位类型IMAGE_REL_BASED_HIGHLOW写 DWORDIMAGE_REL_BASED_DIR64写 ULONGLONG序号导入标志IMAGE_ORDINAL_FLAG 为 0x80000000同名为 0x8000000000000000指针宽度4 字节thunk 用 u1.Function8 字节同字段不同宽度除此之外还有一个不在表里的差异64 位下异常展开依赖 .pdata 段里登记的函数表模块没被系统加载器登记异常就没法正常展开。表现是一旦目标 DLL 里出现 try/catch 或任何需要栈展开的路径进程直接终止。解决办法是调系统的函数表注册接口把 .pdata 范围登记进去或者干脆在目标 DLL 编译期关掉异常——研究阶段我更倾向于后者先把主流程跑通。5. 常见问题排查五次真实的翻车记录5.1 加载阶段就崩掉的三种情况现象一入口点一进去就崩在全局对象构造里调用栈只有几层。原因没有执行 TLS 回调或者执行顺序放到了入口点之后。C 的静态对象构造、部分运行时的初始化都挂在 TLS 回调上跳过它等于让代码在未初始化环境里跑。 解决把 TLS 回调的遍历放到入口点调用之前并且严格使用 DLL_PROCESS_ATTACH。调试时把回调地址打印出来确认至少有一个非空项。现象二映射完成后读到的字符串是乱码函数能调但数据全错。原因节区映射只拷了 SizeOfRawData而 VirtualSize 更大的部分没有被清零或者漏拷了头部导致某些依赖头部数据的逻辑读到脏值。 解决申请内存后立刻整块 memset 清零再拷头部、再按节区拷。养成先清零再填充的习惯这类问题基本绝迹。现象三访问冲突发生在 VirtualAlloc 返回的地址附近偏移看着眼熟。原因节区拷贝时把文件偏移 PointerToRawData 当成内存偏移 VirtualAddress 用了数据整体错位越界写穿到相邻页。 解决把两个字段的含义写在注释里调试版里对每个节区打印VirtualAddress / PointerToRawData / SizeOfRawData三元组肉眼比对一次就能发现异常。5.2 加载成功但一调用就出问题的两种现象四GetProcAddress 返回空导入表里明明有这个函数名。原因OriginalFirstThunk 为 0 时错误地继续用它做名字表读到的是已经被填过的 IAT 内容或者按序号导入时没屏蔽 IMAGE_ORDINAL_FLAG把 0x80000005 当成序号 2147483653 去查。 解决OFT 为 0 时回退用 FirstThunk但要注意此时不能边读边写同一块内存稳妥做法是先完整解析出地址再统一回填。序号分支一定加 0xFFFF 掩码。现象五本地跑得好好的一放到有安全产品的环境就被拦或者行为直接消失。原因整个镜像是一块没有对应模块记录的私有内存权限还是可读写可执行这个组合在检测规则里非常显眼再加上申请内存、改权限、跳转执行这条调用序列本身就很有特征。 解决研究阶段在隔离环境里做别在生产机上试实现层面把权限收紧映射时只给读写等所有修正完成再按节区分别改成可执行或只读别一上来就给全权限。这不是为了绕过而是让实现本身更接近正常加载器的行为减少误报也减少自己踩坑。注意以上排查建议仅用于自有程序的功能调试与安全产品的能力验证任何针对他人系统的使用都不在讨论范围内。6. 收尾验证三个检查点确认加载器没有埋雷写到这里代码能跑已经不算难事难的是确认它跑对了。我自己收尾时会强制走三个检查点缺一个都不算完。第一个检查点看头部一致性。镜像铺开之后把 base 处的前 0x1000 字节和磁盘文件的前 0x1000 字节做一次逐字节比对理论上只有节区表之后的部分可能不同。这一步能一次性抓出头部没拷全和拷贝长度算错两类问题比在导出函数里调试快得多。对比的时候顺手把 SizeOfImage 和实际分配长度也打出来两个值不相等就说明申请阶段就有问题。第二个检查点看每个导入函数的落点。填完 IAT 之后遍历一遍所有非空项判断每个函数地址是否落在某个已加载模块的地址范围内——取模块基址和大小做区间比较就行不需要多精确。这一步的价值在于抓静默失败某个依赖模块没加载成功对应的 IAT 项是 0 或者是个野指针不检查的话要等到真正调用那一行才崩中间可能隔了几百行代码。第三个检查点看两次调用的差异。同一个导出函数连着调两次中间穿插一次读全局状态的调用两次结果必须一致。不一致说明有状态在第一次调用时被写坏通常是重定位漏改或者 .bss 段没清零。这一步是我被坑过之后才加上的之前一直以为调通一次就是通了。最后一个技巧关于重定位到底有没有跑对。加一行调试输出把实际分配基址和首选 ImageBase 的差值打出来差值为 0 说明你运气好跳过了重定位这时候能跑完全不能证明重定位代码正确差值为 0 的情况下我会人为在申请时加一个 0x10000 的偏移强制让 delta 非零再跑一遍全部检查点。这个动作多花不了五分钟但能提前发现绝大多数位宽和遍历边界的问题。回过头看这套东西真正的门槛不是代码而是你愿不愿意为看不见的步骤付出耐心。从那以后我每次写这类加载逻辑都会先把 delta 打印出来看它是不是非零再决定要不要相信后面的测试结果——玄学归玄学能验证的东西就别靠感觉。希望帮到你。本文还有配套的精品资源点击获取