PE内存加载EXE：手写加载器的关键表与边界条件-北京尧图网络

简介围绕进程镂空RunPE的代码示例面向安全研究、逆向工程与系统编程学习者演示如何借助已有进程在内存中加载并执行exe避免可执行文件落盘内容涉及Windows API、PE文件格式与进程管理等底层知识。压缩包为zip格式仅含1个cpp源文件体积约2KB代码紧凑适合作为理解RunPE核心流程的阅读与实验起点。已有1210人学习具备一定关注度。读者可从中梳理选择承载进程、读取目标映像、保存并清空代码段、写入节区、修改PE头设置入口点、恢复寄存器与线程等关键环节理解NtResumeThread调用与内存加载的配合并留意承载进程与目标exe的依赖关系处理也可将其作为分析进程注入行为、思考内存PE检测与防御策略的对照材料适合具备Win32与PE基础、希望深入系统底层机制的中高级读者。1. 从“加载完三秒就退出”说起进程空中加载到底解决什么问题内存加载 exe 最容易出现的现象不是加载失败而是加载成功后目标进程跑了几秒就悄悄没了——调试器里看入口点明明跳进去了线程也跑起来了结果一调用ExitProcess或宿主线程返回整块VirtualAlloc出来的镜像就跟着进了回收站。所谓进程空中技术说白了就是把一个完整的 PE 文件从磁盘读进内存自己补上系统加载器本该做的那几步分配镜像空间、按节拷贝、修重定位、填导入表、跑 TLS 回调、注册异常表最后跳到入口点执行。它解决的是“不想让 exe 以文件形态落在磁盘上”这类需求常见于授权环境下的样本行为分析、加载器原理教学、CTF 逆向题和终端检测能力的对抗验证。适合已经能看懂 PE 头、写过LoadLibrary调用、但一直没搞明白“系统到底替我们做了什么”的从业者新手照着步骤能跑通熟手更该关注后面几章的边界条件——那才是决定加载器能不能活过三秒的地方。2. 拆开 PE 的骨架内存加载器真正要读的是哪几张表在动手写代码之前得先把“系统加载器替你干了哪些活”这件事拆清楚。很多人第一次写内存加载 exe代码不到两百行就能跳进入口点然后就开始怀疑人生为什么有的程序正常、有的程序一进来就崩有的程序界面出来了点按钮就退。问题几乎都出在对 PE 结构里那几张表的理解深度上。这一章不铺开讲 PE 格式的全部字段只讲内存加载场景下必须精确处理的部分剩下的字段读不读都不影响跑起来。2.1 DOS 头、NT 头与节表先把地址口径统一PE 文件的结构是层层嵌套的。最前面是IMAGE_DOS_HEADER唯一有用的字段是e_lfanew它给出 NT 头在文件里的偏移跳过这段 DOS 存根有些样本会把 shellcode 藏在这里加载器一律忽略即可在e_lfanew处读到IMAGE_NT_HEADERS它由三部分组成4 字节签名PE\0\0、IMAGE_FILE_HEADER机器类型、节数量、可选头大小、IMAGE_OPTIONAL_HEADER镜像基址、入口点 RVA、镜像总大小、各数据目录。对内存加载来说可选头里有六个字段是必须记住的字段作用加载器里怎么用ImageBase首选装载基址与实际分配地址比较决定要不要重定位SizeOfImage镜像在内存中的总大小VirtualAlloc的长度参数SizeOfHeaders所有头部的总大小头部拷贝的长度AddressOfEntryPoint入口点 RVA加上基址就是函数指针SectionAlignment内存对齐粒度节的虚拟地址都按它对齐DataDirectory[16]导入、重定位、TLS、异常等目录每一项给出 RVA 与大小节表紧跟在可选头之后用IMAGE_FIRST_SECTION(nt)拿到首地址NumberOfSections决定循环次数。每个IMAGE_SECTION_HEADER里VirtualAddress是节在内存中的 RVASizeOfRawData是它在文件里占的字节数PointerToRawData是文件偏移Misc.VirtualSize是节的真实内存长度。血泪经验是拷贝时长度要取SizeOfRawData和Misc.VirtualSize的较小值直接拿SizeOfRawData拷会把相邻节的数据踩掉尤其是最后那个节。提示.bss这类未初始化数据节的SizeOfRawData往往是 0Misc.VirtualSize却不为 0。跳过它是对的VirtualAlloc出来的内存本来就是零不需要再拷。2.2 重定位表、导入表、TLS 表、异常表缺一张就跑不起来这四张表决定了加载器是“能跳进去”还是“能跑下去”。重定位表IMAGE_DIRECTORY_ENTRY_BASERELOC解决的问题是PE 文件里的绝对地址是按ImageBase写死的如果实际装载地址和它不一样所有硬编码的地址都得按差值修正。修正量Delta 实际基址 - 首选基址。表的组织方式是分块每块一个IMAGE_BASE_RELOCATION头记录本块起始 RVA 和块长度后面跟着一串WORD高 4 位是类型低 12 位是块内偏移。32 位常见类型 3IMAGE_REL_BASED_HIGHLOW改 4 字节64 位常见类型 10IMAGE_REL_BASED_DIR64改 8 字节。现代编译器默认开 ASLR重定位表通常在但如果遇到/FIXED编译或被工具 strip 过的样本这张表是空的那就只能想办法让实际基址等于ImageBase否则加载必然失败。导入表IMAGE_DIRECTORY_ENTRY_IMPORT是一串IMAGE_IMPORT_DESCRIPTOR以全零项结尾。每项里有三个关键字段OriginalFirstThunk指向输入名称表INTName指向 DLL 名字符串FirstThunk指向导入地址表IAT。加载器要做的是LoadLibraryA把 DLL 拉起来再按 INT 里的名字或序号逐个GetProcAddress把结果写进 IAT。这里有个容易忽略的点如果OriginalFirstThunk为 0老式绑定样本INT 和 IAT 是同一块内存边读边写会把自己改坏得先把原始值存下来。TLS 表IMAGE_DIRECTORY_ENTRY_TLS对应IMAGE_TLS_DIRECTORY结构AddressOfCallBacks指向一个以 NULL 结尾的函数指针数组。系统加载器会在入口点执行之前逐个调用这些回调参数是模块基址、DLL_PROCESS_ATTACH和 NULL。静态链接 CRT 的程序、用了thread_local的程序都依赖这一步跳过它程序可能在第一次访问全局对象时就崩。异常表IMAGE_DIRECTORY_ENTRY_EXCEPTION只在 x64 上存在内容是RUNTIME_FUNCTION数组描述每个函数的起止地址和展开信息位置。x64 的异常分发完全依赖这张表不注册它throw、__try/__except、甚至某些 CRT 内部的异常处理都会直接让进程挂掉而且崩的位置和真实原因毫无关系非常玄学。2.3 RVA 与文件偏移两套口径换算的通用写法写加载器最容易犯的低级错误是把 RVA 当文件偏移用。文件里的数据是按FileAlignment通常 0x200排的内存里按SectionAlignment通常 0x1000排两套口径只有在头部区域才碰巧一致。任何“从文件缓冲区里按 RVA 取数据”的操作都必须先换算。换算逻辑本身很短遍历节表找到满足RVA VirtualAddress RVA VirtualAddress max(SizeOfRawData, Misc.VirtualSize)的那个节返回PointerToRawData (RVA - VirtualAddress)。但要注意两点一是比较时上界要用两个尺寸的较大值否则落在节尾对齐空洞里的 RVA 会找不到二是头部区域的 RVA 直接等于文件偏移遍历节表之前要先判断RVA SizeOfHeaders。一旦镜像被拷进VirtualAlloc出来的内存这套换算就彻底不需要了——所有 RVA 加基址就是真实地址。所以正确的做法是先在文件缓冲区里完成校验和必要的信息提取然后把整个镜像按节铺进内存后续所有表的解析一律在内存镜像上做用image rva直接取。这样代码能少一半出错点也少一半。3. 手写加载器从 VirtualAlloc 到跳入口点的六步这一章给一份能直接编译跑通的最小实现语言用 C只依赖 Win32 API。整个加载器拆成六步读文件、校验、分配、拷贝、修表、跳转。每一步都会说明参数为什么这么设以及改哪里会影响什么。代码是分段的拼起来是一个完整的LoadPeFromMemory函数。3.1 第一步与第二步读文件、校验、按 SizeOfImage 提交内存#include windows.h #include stdio.h // 把整个文件读进堆缓冲区exe 通常不大一次读完比映射简单 static BYTE* ReadWholeFile(const char* path, DWORD* outSize) { HANDLE h CreateFileA(path, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (h INVALID_HANDLE_VALUE) return NULL; DWORD size GetFileSize(h, NULL); if (size INVALID_FILE_SIZE || size 0) { CloseHandle(h); return NULL; } BYTE* buf (BYTE*)malloc(size); DWORD read 0; // 大文件可能读不满这里按需循环演示场景单次 ReadFile 足够 if (!ReadFile(h, buf, size, read, NULL) || read ! size) { free(buf); CloseHandle(h); return NULL; } CloseHandle(h); *outSize size; return buf; } // 三道校验MZ、PE 签名、可选头魔数与当前编译位数匹配 static bool ValidatePe(const BYTE* buf, DWORD size, bool want64) { if (size sizeof(IMAGE_DOS_HEADER)) return false; auto dos (const IMAGE_DOS_HEADER*)buf; if (dos-e_magic ! IMAGE_DOS_SIGNATURE) return false; if (dos-e_lfanew 0 || (DWORD)dos-e_lfanew sizeof(IMAGE_NT_HEADERS) size) return false; auto nt (const IMAGE_NT_HEADERS*)(buf dos-e_lfanew); if (nt-Signature ! IMAGE_NT_SIGNATURE) return false; WORD magic nt-OptionalHeader.Magic; if (want64 magic ! IMAGE_NT_OPTIONAL_HDR64_MAGIC) return false; if (!want64 magic ! IMAGE_NT_OPTIONAL_HDR32_MAGIC) return false; // 子系统必须是 GUI 或 CUI驱动类镜像用这套流程加载没有意义 if (nt-OptionalHeader.Subsystem ! IMAGE_SUBSYSTEM_WINDOWS_GUI nt-OptionalHeader.Subsystem ! IMAGE_SUBSYSTEM_WINDOWS_CUI) return false; return true; } // 分配镜像空间长度用 SizeOfImage权限先给读写 BYTE* AllocImage(const IMAGE_NT_HEADERS* nt) { return (BYTE*)VirtualAlloc(NULL, nt-OptionalHeader.SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); }逻辑说明ReadWholeFile用CreateFileA加ReadFile不用内存映射是因为后面所有操作都是在文件缓冲区上做一次性的解析映射反而多一层句柄管理。ValidatePe里加了位数校验这一条能挡掉一半“为什么跳进去就崩”的问题——32 位加载器硬跳 64 位入口点结果是确定的崩溃。参数说明VirtualAlloc的第三个参数用MEM_RESERVE | MEM_COMMIT一次到位避免后面按节提交时反复计算边界。第四个参数给PAGE_READWRITE而不是PAGE_EXECUTE_READWRITE是因为拷贝阶段根本不需要执行权限等全部表修完再逐节改成PAGE_EXECUTE_READ或PAGE_READWRITE。这一步在安全审计视角下很重要一块从一开始就带执行权限的匿名内存是内存扫描的重点关注对象。3.2 第三步拷贝头与节别忘了 SectionAlignment// 头部整块拷各节按 VirtualAddress 落位 static bool MapSections(BYTE* image, const BYTE* buf, const IMAGE_NT_HEADERS* nt) { memcpy(image, buf, nt-OptionalHeader.SizeOfHeaders); auto sec IMAGE_FIRST_SECTION(nt); for (WORD i 0; i nt-FileHeader.NumberOfSections; i, sec) { if (sec-SizeOfRawData 0) continue; // .bss 之类无文件数据 // 关键取两者较小值防止拷越界踩坏下一个节 DWORD copySize sec-SizeOfRawData; if (sec-Misc.VirtualSize sec-Misc.VirtualSize copySize) copySize sec-Misc.VirtualSize; if (sec-VirtualAddress copySize nt-OptionalHeader.SizeOfImage) return false; // 恶意构造的越界节 memcpy(image sec-VirtualAddress, buf sec-PointerToRawData, copySize); } return true; }逻辑说明头部必须整块拷因为 NT 头、节表、以及部分数据目录比如导入表在头部区域的情况都在这段范围内后续解析要直接从image上读。节的落位用VirtualAddress源地址用PointerToRawData这两个字段的口径不同写反了就是全盘错位。参数说明越界检查那两行建议保留真实样本里节表被篡改、VirtualAddress SizeOfRawData超出SizeOfImage的情况并不少见不做检查就是一次堆破坏。还有一个细节值得单独提节的权限。节头里的Characteristics字段带IMAGE_SCN_MEM_EXECUTE、IMAGE_SCN_MEM_WRITE等标志最严谨的做法是拷贝完成后逐节VirtualProtect成对应权限最后再按DllCharacteristics决定要不要开PAGE_TARGETS_NO_UPDATE之类。省事的做法是统一给PAGE_EXECUTE_READWRITE能跑但内存特征非常显眼做检测验证时基本等于自报家门。3.3 第四步重定位修正的 Delta 与块遍历// Delta 为 0 时整段跳过不为 0 且没有重定位表直接失败 static bool ApplyReloc(BYTE* image, const IMAGE_NT_HEADERS* nt, ULONG_PTR delta) { if (delta 0) return true; auto dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC]; if (dir.Size 0 || dir.VirtualAddress 0) return false; auto blk (IMAGE_BASE_RELOCATION*)(image dir.VirtualAddress); BYTE* end (BYTE*)blk dir.Size; while ((BYTE*)blk end blk-SizeOfBlock sizeof(IMAGE_BASE_RELOCATION)) { DWORD count (blk-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD); auto item (WORD*)(blk 1); for (DWORD i 0; i count; i) { WORD type item[i] 12; WORD off item[i] 0x0FFF; BYTE* patch image blk-VirtualAddress off; if (type IMAGE_REL_BASED_HIGHLOW) { *(DWORD*)patch (DWORD)delta; } else if (type IMAGE_REL_BASED_DIR64) { *(ULONGLONG*)patch delta; } // 类型 0 是填充项直接跳过 } blk (IMAGE_BASE_RELOCATION*)((BYTE*)blk blk-SizeOfBlock); } return true; }逻辑说明Delta在分配完内存、拿到实际基址后立刻算出来往后所有需要修地址的地方都用它。块遍历的终止条件是两种指针走到dir.Size末尾或者遇到SizeOfBlock为 0 的块——后一种是防御性判断防止畸形表导致死循环。参数说明ApplyReloc返回 false 有两种情况一种是Delta不为 0 但表为空镜像被编译成固定基址另一种是表结构损坏。前者不是 bug 而是边界遇到就只能想办法让分配地址等于ImageBase比如用VirtualAlloc指定基址加MEM_RESERVE失败就换地址重试重试上限自己定。实操中我一般给三次机会再失败就放弃。3.4 第五步导入表填充IAT 写入的两种写法// 统一用 OriginalFirstThunk 读、FirstThunk 写OF 为 0 时退回 FT 并先在栈上备份 static bool ResolveImports(BYTE* image, const IMAGE_NT_HEADERS* nt) { auto dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]; if (dir.Size 0) return true; auto desc (IMAGE_IMPORT_DESCRIPTOR*)(image dir.VirtualAddress); for (; desc-Name; desc) { const char* dllName (const char*)(image desc-Name); HMODULE h LoadLibraryA(dllName); if (!h) return false; DWORD intRva desc-OriginalFirstThunk ? desc-OriginalFirstThunk : desc-FirstThunk; auto int_ (IMAGE_THUNK_DATA*)(image intRva); auto iat (IMAGE_THUNK_DATA*)(image desc-FirstThunk); for (; int_-u1.AddressOfData; int_, iat) { FARPROC fn NULL; if (IMAGE_SNAP_BY_ORDINAL(int_-u1.Ordinal)) { // 按序号导入低 16 位是序号 fn GetProcAddress(h, (LPCSTR)IMAGE_ORDINAL(int_-u1.Ordinal)); } else { auto byName (IMAGE_IMPORT_BY_NAME*)(image int_-u1.AddressOfData); fn GetProcAddress(h, (LPCSTR)byName-Name); } if (!fn) return false; iat-u1.Function (ULONG_PTR)fn; // 写进 IAT调用时走这里 } } return true; }逻辑说明导入表遍历的终止条件是desc-Name为 0这是 PE 规范约定的全零结束项不要用dir.Size反推条数。INT 和 IAT 是两条平行的 thunk 数组长度一致、下标对应用同一个循环变量推进最稳妥。参数说明IMAGE_SNAP_BY_ORDINAL判断最高位为 1 表示按序号导入此时AddressOfData的低 16 位才是序号。按名字导入时AddressOfData是 RVA指向IMAGE_IMPORT_BY_NAME前两个字节是 Hint后面才是字符串。这两个分支漏掉任何一个都会在运行时表现为“函数地址是垃圾值一调就崩”。LoadLibraryA用的是 ASCII 版本因为 PE 里的 DLL 名字就是 ANSI 字符串。若目标 DLL 只存在于非默认搜索路径需要提前SetDllDirectory或改用完整路径加载否则LoadLibrary会悄悄失败返回的NULL就是加载器第一处报错的地方。3.5 第六步TLS 回调、异常表注册与入口点跳转typedef void (NTAPI* PIMAGE_TLS_CALLBACK)(PVOID, DWORD, PVOID); // TLS 回调先于入口点执行顺序严格按照 AddressOfCallBacks 数组 static void RunTlsCallbacks(BYTE* image, const IMAGE_NT_HEADERS* nt) { auto dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS]; if (dir.Size 0 || dir.VirtualAddress 0) return; auto tls (IMAGE_TLS_DIRECTORY*)(image dir.VirtualAddress); auto cb (PIMAGE_TLS_CALLBACK*)tls-AddressOfCallBacks; for (; cb *cb; cb) (*cb)(image, DLL_PROCESS_ATTACH, NULL); } // x64 专属把 .pdata 注册进运行时函数表否则异常分发直接崩 static void RegisterX64ExceptionTable(BYTE* image, const IMAGE_NT_HEADERS* nt) { auto dir nt-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXCEPTION]; if (dir.Size 0 || dir.VirtualAddress 0) return; RtlAddFunctionTable((PRUNTIME_FUNCTION)(image dir.VirtualAddress), dir.Size / sizeof(RUNTIME_FUNCTION), (DWORD_PTR)image); } // 入口点exe 的入口是 RVA加基址即可调用约定在 x86 上是 __stdcall using EntryFn void (__stdcall*)(void); bool InvokeEntry(BYTE* image, const IMAGE_NT_HEADERS* nt) { RunTlsCallbacks(image, nt); RegisterX64ExceptionTable(image, nt); auto entry (EntryFn)(image nt-OptionalHeader.AddressOfEntryPoint); DWORD old 0; VirtualProtect(entry, 1, PAGE_EXECUTE_READ, old); // 至少让入口页可执行 entry(); return true; }逻辑说明顺序不能乱。TLS 回调必须在入口点之前异常表注册也必须在任何可能抛异常的代码执行之前。VirtualProtect只改入口点那一页是偷懒写法严谨做法是按节头把每个节的权限都设对这里为了代码短只保留最小可行版本。参数说明RtlAddFunctionTable是ntdll导出但微软文档化的 API链接时不需要额外库声明一下就能用。第二个参数是函数表项数用dir.Size / sizeof(RUNTIME_FUNCTION)算注意RUNTIME_FUNCTION在某些 SDK 版本里是 12 字节别自己按 8 字节硬算。调完entry()之后的事情才是真正的坑如果被加载的 exe 入口点最终返回了比如main返回控制流会回到加载器此时镜像还得活着如果它内部调了ExitProcess整个宿主进程就没了。下一章展开这些分支。4. 那些让加载器翻车的分支x64 异常、TLS 与托管 exe能跳进入口点只完成了一半剩下的一半全在边界条件里。这一章挑四个最容易翻车的分支讲清楚x64 的函数表、TLS 与 CRT 的初始化顺序、托管 exe 为什么走不通、以及入口点的调用约定问题。这四条每一条都能独立让加载器“加载成功但跑不起来”而且现象各不相同。4.1 x64 下的 pdata/xdata不注册函数表就等着崩32 位时代异常处理靠栈上的链表加载器基本不用管。x64 换成了表驱动编译器为每个函数在.pdata节生成一条RUNTIME_FUNCTION记录函数起止 RVA 和.xdata里展开信息的位置。系统抛异常时RtlLookupFunctionEntry拿当前RIP去查这张表查不到就认为当前帧不可展开直接__fastfail。这里的关键在于系统加载器在映射 DLL/EXE 时会把.pdata自动注册进全局函数表而我们的加载器绕过了系统加载器这张表就是空的。于是任何一次throw、结构化异常、甚至 CRT 内部的栈探测都可能触发崩溃且崩溃点在ntdll里栈回溯一片空白非常像“玄学”。解决办法就是 3.5 节里的RtlAddFunctionTable。有一个坑要提前说注册进去的RUNTIME_FUNCTION数组里的地址是按镜像基址写的 RVARtlAddFunctionTable的第三个参数就是基址函数内部自己加。如果镜像被重定位过.pdata里的UnwindInfoAddress也需要跟着修正——好消息是这个字段在重定位表里通常有对应项只要你老老实实跑了 3.3 节的重定位它就是对的。还有一个细节IMAGE_DIRECTORY_ENTRY_EXCEPTION在 32 位镜像上大小通常为 0但极少数用 SEH 的 32 位程序也有内容。所以RegisterX64ExceptionTable必须加位数判断不能只看目录大小。我一般写成if (!Is64Bit(nt)) return;放在函数最前面省得后面每次都要想。4.2 TLS 回调与静态 CRT初始化顺序错了就是玄学静态链接 CRT 的程序会在 TLS 回调里做一堆事初始化_tls_index、准备每个线程的 TLS 数组、初始化 CRT 内部的一些全局状态。入口点mainCRTStartup会读这些状态如果回调没跑读到的就是零程序可能表现成“全局变量全是 0”“errno一用就崩”“std::locale初始化直接挂”。顺序上还有一个容易忽略的点TLS 回调数组是AddressOfCallBacks指向的里面每个元素都是绝对地址VA不是 RVA。系统加载器在映射时会对这个数组本身做重定位所以你的重定位流程必须覆盖到.rdata里存这个数组的位置。检查方法很简单跑完ApplyReloc之后把AddressOfCallBacks指的那几个值打印出来和image基址比一比如果还落在几百兆的范围内基本就是没重定位对。回调的执行顺序也有讲究。按 PE 规范同一模块的多个 TLS 回调按数组顺序执行不同模块之间系统加载器是倒序后加载的先跑。手工加载场景下一般只有一个模块按数组正序跑就行。回调的第二个参数在进程加载阶段是DLL_PROCESS_ATTACH值等于 1第三个参数保留为 NULL。有些 CRT 实现在回调里会检查这个参数传错了会走不同分支。注意TLS 回调里如果抛异常而你的异常表还没注册就是必崩。所以正确顺序是先注册异常表再跑 TLS 回调。3.5 节的代码里把RegisterX64ExceptionTable放在RunTlsCallbacks之后是早期版本留下的错误顺序实际使用时要把这两行对调这一点务必留意。4.3 托管 exe 与资源节这条路的边界在哪.NET 编译出来的 exe 是个混合体它有标准 PE 头但入口点 RVA 指向的是一小段启动桩真正逻辑在 CLR 头IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR指向的元数据里。如果你拿这套加载器去加载托管 exe跳进入口点后启动桩会尝试通过 CLR 接口找到mscoree.dll、加载运行时、再根据元数据启动程序集。理论上这个过程能走通实际上经常失败原因是启动桩依赖 PE 的某些文件系统特征模块句柄、程序集路径解析而手工映射的镜像不在PEB的模块链表里运行时找不到它。结论很直接这套流程适合原生 exe托管 exe 不要指望。如果确实需要思路是先手工映射mscoree.dll之外的东西或者干脆放弃内存加载改用 CLR 的宿主 API 在进程内创建域——那是完全不同的技术栈。资源节.rsrc是另一个边界。资源节的数据在内存里是可用的但FindResource、LoadString这些 API 会走LdrFindResource内部依赖模块句柄手工映射的镜像没有对应的模块记录调用基本会失败。绕过办法是自己解析资源目录树按IMAGE_RESOURCE_DIRECTORY结构手动定位数据。工作量大但对资源依赖重的程序绕不开。4.4 入口点调用约定mainCRTStartup 不是你想的那样AddressOfEntryPoint指向的不是main是 CRT 的启动函数mainCRTStartup控制台或WinMainCRTStartupGUI。这两个函数的签名是void __stdcall(void)不接受参数、不返回值内部通过GetCommandLineA、GetStartupInfoA这些 API 自己拿启动信息最后要么调ExitProcess要么在main返回后自己调ExitProcess。这意味着两件事。第一你根本没法给它传命令行参数除非提前改PEB里的ProcessParameters或者 hookGetCommandLineA。第二绝大多数情况下entry()这个调用不会返回——main返回后 CRT 会直接ExitProcess整个宿主进程一起没了。这就解释了第 1 章那个“三秒退出”的现象。如果希望宿主进程活下来办法是在独立线程里调入口点并且提前 hook 掉ExitProcess、TerminateProcess这类 API把它们改成只结束当前线程ExitThread。这个 hook 本身又需要改 IAT 或者做 inline patch代码量和风险都不小。实操里更常见的做法是本来就不需要宿主活着那就接受进程退出需要长驻的改用 DLL 形式加载DLL 的入口点DllMain返回后线程还能继续跑。另外调用约定这一条在 x86 上尤其要注意。上面的EntryFn用的是__stdcall和 CRT 启动函数一致如果你按__cdecl声明函数返回时栈不平后果是宿主线程栈指针偏移之后任何一次调用都可能崩而且崩的地方和加载器毫无关系。5. 排查清单加载失败与加载成功后崩溃的五种典型下面这些是我在不同镜像上反复踩过的坑按“现象 → 原因 → 解决”写顺序大致对应加载流程的先后。每条都值得在写代码之前先看一眼能省掉大量对着调试器发呆的时间。5.1 加载阶段就返回失败第一种ValidatePe过了AllocImage也成功了导入表解析到一半返回 NULL。现象是加载器打印出“import failed”但没说是哪个 DLL、哪个函数。原因是LoadLibraryA或GetProcAddress失败而代码里没记录上下文。解决办法很简单在LoadLibraryA失败时打印dllName和GetLastError()在GetProcAddress失败时打印byName-Name。绝大多数情况是 DLL 只存在于程序自己的目录而当前工作目录不对少数情况是按序号导入但那个序号在新版 DLL 里被移除了。第二种加载器在ApplyReloc里返回 false但目标程序明明能正常运行。现象是dir.Size 0且delta ! 0。原因是镜像被编译成固定基址/FIXED或者被人为 strip 掉了重定位表。解决思路不是硬修而是让实际分配地址等于ImageBase用VirtualAlloc((LPVOID)nt-OptionalHeader.ImageBase, SizeOfImage, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE)失败就隔一段地址重试。成功率取决于目标基址是否被占用一般重试三五次内能成。5.2 跳进入口点之后崩溃第三种Debug 版镜像跑得好好的Release 版一进入口点就崩。现象是入口点前几条指令就触发访问违例。原因通常是/GS的栈 cookie 检查Release 版在函数返回时比对 cookie而 cookie 的初始值放在.data的一个特定位置这个位置在加载时应该由 CRT 初始化填上。如果 TLS 回调没跑、或者.data节拷贝长度算错cookie 就是 0比对必然失败。解决办法是先确认 TLS 回调执行了再确认.data节的Misc.VirtualSize不小于SizeOfRawData拷贝长度取的是较小值而不是 0。第四种程序能跑但一抛异常就静默退出事件查看器里只有一条 0xc0000409。这就是 4.1 节说的 x64 函数表没注册。0xc0000409 是STATUS_STACK_BUFFER_OVERRUN但被__fastfail复用来表示“不可展开的异常”。解决办法是补上RtlAddFunctionTable并且确认dir.Size是sizeof(RUNTIME_FUNCTION)的整数倍——不是整数倍说明镜像被人动过这时候要么放弃要么自己按 12 字节步长强行遍历。第五种入口点跑了几秒界面都出来了然后进程消失。现象是没有崩溃对话框进程直接没了。原因就是 4.4 节说的main返回后 CRT 调ExitProcess。解决办法分两种场景不需要宿主长驻的接受它需要长驻的在入口点执行前把ExitProcess的 IAT 项替换成一个只调ExitThread的桩函数或者干脆整个加载流程放到独立进程里跑进程退出了也无所谓。5.3 跑起来但状态不对第六种程序内部调GetModuleHandle(NULL)拿到的是宿主 exe 的句柄不是被加载镜像的。原因是手工映射的镜像没有登记到PEB的Ldr模块链表里系统根本不知道它的存在。影响面比想象中大GetModuleFileName、FindResource、部分 CRT 初始化都会走这条路。解决办法是要么手工往PEB-Ldr-InLoadOrderModuleList里插一个LDR_DATA_TABLE_ENTRY结构在各版本 Windows 上有差异属于硬编码活要么接受这个限制把依赖模块句柄的 API 全部绕开。第七种加载后内存扫描工具一抓一个准。现象是镜像在内存里的MZ头和PE\0\0签名完好无损随便一个特征扫描都能命中。这不是 bug是设计使然。如果目标只是验证加载逻辑不用管如果目的是评估检测能力就得在跳入口点之前把头部擦掉或加密节权限也改对别整块PAGE_EXECUTE_READWRITE。但擦头之前想清楚擦掉之后自己也没法再从内存里还原结构调试会变得非常痛苦建议留一份未擦的副本在调试构建里。6. 验证与进阶怎么证明它真的在内存里跑起来了加载器写完最难的不是让它跑起来是证明它“确实是以内存加载的方式跑起来的”而不是碰巧调用了某个系统 API。我一般按三层验证从粗到细每一层都能独立证伪。第一层是文件痕迹。用进程监视工具过滤目标进程的CreateFile操作确认整个过程里没有任何一次对源 exe 的读取——注意加载器自己读文件那一次要排除掉看的是被加载镜像运行期间有没有再去碰磁盘。有些程序会在启动时读自己的配置文件、图标资源这些操作会暴露原始路径属于预期行为不算失败。第二层是内存布局。用内存查看工具看目标进程的地址空间重点看三件事有没有一块大小等于SizeOfImage的私有提交区域、这块区域的初始权限是不是读写、跳进入口点之后权限有没有变成可执行。更细一点可以在这块内存里搜MZ头能搜到说明头部没擦搜不到但程序正常运行说明擦头逻辑生效了。下面这段代码可以直接嵌在加载器里把关键状态打印出来做交叉验证// 在 InvokeEntry 之前调用打印镜像的关键布局便于和外部工具对照 static void DumpImageLayout(BYTE* image, const IMAGE_NT_HEADERS* nt) { printf(image base : %p\n, image); printf(preferred base : %p\n, (void*)nt-OptionalHeader.ImageBase); printf(size of image : 0x%X\n, nt-OptionalHeader.SizeOfImage); printf(entry rva : 0x%X - %p\n, nt-OptionalHeader.AddressOfEntryPoint, image nt-OptionalHeader.AddressOfEntryPoint); auto sec IMAGE_FIRST_SECTION(nt); for (WORD i 0; i nt-FileHeader.NumberOfSections; i, sec) { char name[9] {0}; memcpy(name, sec-Name, 8); printf( %-8s rva0x%-6X vsize0x%-6X raw0x%-6X flags0x%X\n, name, sec-VirtualAddress, sec-Misc.VirtualSize, sec-SizeOfRawData, sec-Characteristics); } }这段输出要和外部工具看到的结果对得上image base必须等于工具里那块私有内存的起始地址各节的rva必须落在[base, base SizeOfImage)区间内入口点地址必须可执行。对不上就说明镜像布局有问题别急着往下走。第三层是行为验证。最直接的办法是在入口点下断点看调用栈是不是从加载器的InvokeEntry进来的而不是从LdrpInitializeProcess进来的——后者说明走的是系统加载器你的代码根本没生效。再进一步可以在 TLS 回调里埋一个标记比如改一个全局变量的值入口点里检查这个标记能读到就说明 TLS 顺序对了。这一招在排查“Release 版崩溃”那类问题时特别好用比对着汇编猜快得多。进阶方向有两个。一个是把加载流程从“同步调用入口点”改成“独立线程挂起恢复”这样宿主进程和被加载镜像的生命周期解耦退出行为可控。另一个是把节权限、头部擦除、导入表混淆这些处理做成可配置的编译选项调试构建全开保留信息发布构建全关减少特征。这两个方向都不难难的是想清楚每个选项对调试能力的影响——我吃过一次亏把头部擦除和节权限收紧一起打开结果程序崩在一个完全无关的地方查了整整一天才发现是.reloc节被设成了不可读重定位流程自己读不了自己。从那以后我每次改内存布局相关的参数都强制先用DumpImageLayout打一遍完整快照再跑多花三十秒省下的是整天。希望这套流程帮到你少走一点我走过的弯路。本文还有配套的精品资源点击获取

PE内存加载EXE：手写加载器的关键表与边界条件

相关推荐

Cocos安卓ANT打包全链路：版本对齐、签名与排错

Agent技能库越用越笨？SkillBrew多目标精炼实现技能库“做减法”

雷达信号处理链路拆解：DBF、相干积累与目标角度测量

更多资讯

Codex：从代码补全到软件工程智能体的范式跃迁

销售易CRM系统实战指南：配置、迁移与性能优化

社交媒体主页工具开发：技术架构与盈利模式解析

C语言职工管理系统：链表与文件读写打通增删改查实战

工业AI操作系统如何落地？西门子新技术的实战拆解

Token市场海外对标：从API报错到大模型定价的生态密码

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？