反射式 DLL 加载器Reflective DLL Loader听起来很底层、很难懂但它真正做的事情并不复杂在 C 程序里不调用 Windows 自带的LoadLibrary而是把一个 DLL 从内存中自行加载起来。很多文章一提反射式加载就往攻防方向带我这里不做那套思路也建议你别抱着绕过检测的预期来读。这一技术背后最有价值的是 Windows PE 加载原理。搞清楚导入表、重定位、节区映射这些机制对你学 C 底层、理解系统加载器、以后写插件系统或处理内存模块都会非常有帮助。适合读这篇文章的读者应该已经能写 C 类、结构体、指针并且愿意花时间跟 Windows 的 PE 结构打交道。我先把结论放在前面如果你想直接抄一份“万能内存加载器”去替换LoadLibrary大概率会失望。自己写的加载器在很多场景下不如系统加载器稳定尤其是遇到 C 的运行时初始化、TLS、静态对象、资源目录等情况。但如果你是想理解 DLL 从文件变成可执行内存块这一路到底发生了什么那自己动手实现一遍比单纯看资料有效得多。下面我会按 PE 加载顺序拆解一个“当前进程内、教学用途”的加载器骨架并给出验证方式和排查思路。1. 反射式 DLL 加载器到底在做什么1.1 为什么直接调用 LoadLibrary 不算“反射式加载”正常情况下Windows 加载 DLL 走的链路是LoadLibrary-LdrLoadDll- 系统加载器读取磁盘文件、解析 PE 结构、映射节区、修复导入表、执行初始化。这是操作系统帮你办完的开发者通常只需要关心函数能不能调用。反射式 DLL 加载器的特点是绕开标准加载入口由开发者自己的代码按 PE 结构手工处理加载流程。也就是把 DLL 字节看作一张“图纸”加载器照着图纸在当前进程内存里重新搭出一个可以运行的模块。之所以叫“反射”可以理解成 DLL 加载逻辑从自身结构出发像镜子反射一样逐项处理自己的头信息、节区、导入表和入口点。需要特别说明的是本文只讨论“当前进程内加载自己的内存模块”。如果把别人的进程当作目标去放代码那已经不是加载问题而是进程干扰或滥用场景。后面提到的一切默认都在你自己程序里加载你已经拿到数据的 DLL。1.2 一个内存加载器要处理哪些步骤按顺序来核心逻辑大概是拿到一段完整 DLL 文件字节校验 DOS 头和 PE 头。从 PE 头中取出SizeOfImage用VirtualAlloc分配一块足够大的内存。先把文件头、扩展头、节表复制到分配好的内存头部。遍历节区表把.text、.rdata、.data等节区从文件偏移复制到内存偏移。处理重定位表因为实际分配的基址通常不等于 PE 头里的ImageBase。构建导入表把导入函数的真实地址写入 IAT。调用 DLL 的入口点传入DLL_PROCESS_ATTACH。如果需要还要支持从导出表查找函数地址否则外部拿不到这个 DLL 里的函数。只看步骤不觉得难真正容易出错的是每步里的细节。比如“复制节区”并不是把整个文件直接memcpy到内存因为文件对齐和内存对齐不一样修复导入表时也不能拿源文件中的文件偏移直接写成虚拟地址需要做 RVA 和虚拟地址的换算。这里多花一点功夫理解后面排查时就能少走弯路。1.3 为什么要自己写一遍我推荐写一遍的原因很简单系统加载器帮你把错误都屏蔽掉了。你写个普通测试 DLL 再LoadLibrary几乎不会关心导入表是两张表、重定位块按页分组、SizeOfHeaders有时比实际头部大很多。可一旦换成内存加载这些都会直接变成崩溃或入口不执行。自己实现加载器另一个好处是能加深对调试器的理解。以后你看到模块加载地址、IAT 被填充成什么值、ImageBase为什么不是实际地址时心里会更有底。对 C 开发来说这不是日常增删改查的 API 调用而是真正贴近系统底层的一次练习。2. 学习前先补几个前置概念2.1 PE 文件不是“连续的二进制文件”很多 C 初学者对结构体、指针已经熟悉但第一次接触 PE 时会觉得头文件很多。简单理解Windows 的可执行文件和 DLL 都遵循 PE 结构最开头是 DOS 头主要作用是校验和定位紧接着会通过e_lfanew字段跳到真正的 PE 头再往后面是节区表每个节区描述一段内容的用途和位置。所以加载 DLL 时不能只把文件读进内存就完事必须解析两层内容头区告诉加载器这个模块有多大、入口点在哪、依赖哪些外部 DLL。节区把代码、只读数据、可写数据分别放到对应的虚拟地址中。为什么不能整块复制因为磁盘上的 Windows 文件通常按 512 字节或更粗粒度对齐到了内存里节区又按页面粒度对齐。一个文件偏移可能是 0x200同一段内容对应的内存 RVA 可能是 0x1000两者之间不是简单相加的关系。我见过很多初学者写出这样的代码直接拿到源文件里的指针去访问 PE 字段结果加了一堆偏移之后访问到错误位置。2.2 导入表、重定位表、导出表之间是什么关系一个普通 DLL 要运行往往会调用kernel32.dll或其他系统 DLL 的函数。这些“外部依赖”记录在导入表里。加载器需要找到每个导入函数名调用 API 获取真实地址再写回去。问题是系统加载器已经处理过包含LoadLibrary的那个进程地址而你写的自定义加载器还没注册到系统模块列表所以不能简单依赖GetProcAddress去查找自己加载的模块名。重定位表则负责“基址修正”。链接 DLL 时代码里很多绝对地址都基于预设的ImageBase计算。如果 DLL 被分配到了别的地址就需要把重定位表里记录的地址统一加上差值。对于自己VirtualAlloc出来的内存基本每次都可能不同所以这一步不能跳过否则代码跳转指针全是错的。导出表相对好理解就是告诉外部这个 DLL 提供哪些函数。学习用途中加载完模块之后往往要从导出表拿到DllMain之外的函数用来确认加载已经生效。2.3 用 C 方式理解这些结构在 C 里这些头结构体早就定义好了包括IMAGE_DOS_HEADER、IMAGE_NT_HEADERS、IMAGE_SECTION_HEADER等。使用 Windows SDK 或 MinGW 开发环境都可以直接引用。实际写代码时你用指针做类型转换就能解析PIMAGE_DOS_HEADER dosHeader reinterpret_castPIMAGE_DOS_HEADER(rawBuffer); PIMAGE_NT_HEADERS ntHeader reinterpret_castPIMAGE_NT_HEADERS(rawBuffer dosHeader-e_lfanew);新手容易犯的错误是拿到PIMAGE_NT_HEADERS后直接按文件偏移访问后续节区没有把 RVA 换算成加载后的虚拟地址。写到这一步之前建议把“文件偏移”“RVA”“VA”三者的区别想明白后面所有流程都依赖这组换算。3. 搭建测试环境从普通 C DLL 项目开始3.1 开发环境和编译工具这门实验不需要第三方框架只用 Windows 原生 API。建议选择以下任一方式Visual Studio 2022创建 C 控制台工程再单独创建或导入一个 DLL 工程。Visual Studio Code MinGW-w64这需要你把 C/C 扩展和编译任务配好网上很多教程都提到过“VSCode 配置 C/C 环境”本质上就是配置c_cpp_properties.json和tasks.json编译器能用g或gcc即可。使用 VS 更省事因为创建 DLL 项目时模板会自动生成dllmain.cpp。用 VS Code 也可以但要注意生成 DLL 时链接参数要加-shared。CPU 位数必须一致。例如调试程序是 x64测试 DLL 也必须是 x64。加载器按 64 位 PE 解析如果拿一个 32 位 DLL 来加载读取字段的位置和重定位算法都可能对不上很容易出现莫名其妙的崩溃。不要用“x86 程序加载 x64 DLL”去测试这不是加载器的问题而是指令集和指针宽度不一致。3.2 生成一个最简单的测试 DLL为了减少干扰我建议测试 DLL 不要做太复杂的事情。核心目标是在DllMain里留下一个可观察的执行痕迹。用 VS 创建 DLL 工程后可以这样写#include windows.h BOOL APIENTRY DllMain(HMODULE module, DWORD reason, LPVOID reserved) { if (reason DLL_PROCESS_ATTACH) { // 可以用 OutputDebugString也可以用写文件目的是确认入口被调用 ::OutputDebugStringA([TestDll] DLL_PROCESS_ATTACH called\n); } return TRUE; } extern C __declspec(dllexport) int Add(int a, int b) { return a b; }你可能会疑惑这里只用到了OutputDebugStringA如果加载器还没有实现导入表修复这个调用无法解析。没错所以测试 DLL 可以先不调用任何外部函数只在DllMain里设置一个全局变量或单纯返回TRUE随后通过导出表确认加载结果。如果 DLL 依赖太多比如用/MD动态链接了运行库那么加载它需要额外处理很多运行时初始化需求入门阶段会把问题搞复杂。可以把运行库改成/MT让测试 DLL 尽量少依赖外部 DLL。但这也不绝对VS 使用/MT时仍可能链接部分系统 DLL。这里的原则是一开始用最简单的裸 DLL先把加载器逻辑跑通再逐步加复杂度。3.3 验证现有 DLL 是否被系统加载器正常加载写自研 Loader 前最好先用系统加载器验证一次测试 DLL 可用HMODULE h ::LoadLibraryA(TestDll.dll); if (h) { auto fn reinterpret_castint(*)(int, int)(::GetProcAddress(h, Add)); if (fn) { // 调一下看结果是否符合预期 } ::FreeLibrary(h); }如果这里的LoadLibraryA(TestDll.dll)直接失败说明测试 DLL 本身有问题比如缺少依赖 DLL、运行时库搭配不对、导出符号被改名。先把这一步排除掉再用自研加载器测才不会把环境问题误判成加载逻辑问题。4. 核心流程手写一个教学版加载器4.1 整体主流程和参数设计自定义加载器主函数可以接收一块完整且已读入内存的 DLL 字节。参数通常是两块信息缓冲区指针、缓冲区长度。为什么不直接给文件路径因为“反射”场景的核心就是数据已经在内存里不需要再去磁盘读第二遍。教学版先不追求一次处理完所有 PE 特性先做能跑通的最小流程。主函数骨架看起来像这样BYTE* RawBuffer; // 测试用指向读入的 DLL 文件字节 SIZE_T RawSize; // 文件大小 BYTE* imageBase MemoryLoadDll(RawBuffer, RawSize); if (imageBase) { // 从导出表找 Add 地址并调用验证 }这里所有函数都只在当前进程内工作。加载结束后新增的模块不会出现在系统模块链表中所以不能期待调试器立刻显示模块名也不能用GetModuleHandle去查。如果你的功能需要“加载即正常出现在系统模块列表”那说明你选择的场景并不适合反射式加载。4.2 校验头部和节区映射第一步永远是校验头部而不是急着分配内存。常见判断是检查e_magic是否等于IMAGE_DOS_SIGNATURE第 64 字节位置是否等于IMAGE_NT_SIGNATURE。签名不正确说明数据不是有效 PE 文件直接返回FALSE。BOOL MemoryLoadDll(BYTE* rawBuffer, SIZE_T rawSize) { if (rawSize sizeof(IMAGE_DOS_HEADER)) return FALSE; PIMAGE_DOS_HEADER dos reinterpret_castPIMAGE_DOS_HEADER(rawBuffer); if (dos-e_magic ! IMAGE_DOS_SIGNATURE) return FALSE; if (rawSize dos-e_lfanew sizeof(IMAGE_NT_HEADERS)) return FALSE; PIMAGE_NT_HEADERS nt reinterpret_castPIMAGE_NT_HEADERS( rawBuffer dos-e_lfanew); if (nt-Signature ! IMAGE_NT_SIGNATURE) return FALSE; return TRUE; }校验通过后再看SizeOfImage分配内存。这里有一个细节VirtualAlloc是按页面对齐的而SizeOfImage本身通常已经对齐到页面边界。所以可以直接用SizeOfImage作为分配大小。如果你想保险一点可以用VirtualAlloc返回的地址按页取整再手动检查容量是否足够。分配内存后先复制头区再逐节拷贝。只做一次memcpy(imageBase, rawBuffer, rawSize)是不准确的也必须避免。别把“文件大小”当成“内镜像大小”。正确逻辑是分别处理SizeOfHeaders和每个节区BYTE* base static_castBYTE*( ::VirtualAlloc(nullptr, nt-OptionalHeader.SizeOfImage, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)); if (!base) return FALSE; ::memcpy(base, rawBuffer, nt-OptionalHeader.SizeOfHeaders); PIMAGE_SECTION_HEADER section IMAGE_FIRST_SECTION(nt); for (WORD i 0; i nt-FileHeader.NumberOfSections; i) { BYTE* dest base section[i].VirtualAddress; BYTE* src rawBuffer section[i].PointerToRawData; SIZE_T len section[i].SizeOfRawData; ::memcpy(dest, src, len); }这段代码映射的是“镜像”而不是普通文件节区拷贝。若某个节区在内存中的尺寸比文件中的原始尺寸大比如.bss或未初始化数据可能SizeOfRawData小于VirtualSize需要额外对多出来部分清零。很多人加载后数据是乱的就是因为少了这一步。4.3 解析导入表并填充 IAT做完头部和节区映射之后模块代码已经位于内存但外部函数地址还是空的。DLL 一旦跳到某个需要调用的 APIIAT 地址还是 0 或者旧值必然访问违规。导入表做起来不复杂但细节不少。加载器需要遍历IMAGE_DATA_DIRECTORY中的导入目录项找到每个导入描述符逐个读取 DLL 名称和函数名称。对于每个函数可以通过GetProcAddress获取地址前提是你得先确保对应宿主 DLL 已经加载。因为我们在当前进程内可以调用系统 API。但注意一个矛盾如果加载器还没有完成导入表修复它自己也不能调用GetProcAddress除非已经提前取得或硬编码这些 API 地址。解决思路通常有两种加载器代码链接时直接链接kernel32.lib编译后的加载器本身已经通过正常 PE 导入表包含GetProcAddress。当前进程内运行没有额外问题。学习时还可以先GetModuleHandleA(kernel32.dll)再转调用GetProcAddress。真正的反射式加载往往把加载器做成一小段独立代码不依赖自身模块的导入表。这种复杂度远超入门范围我也建议不要在测试版本里一上来就写。函数名需要从 PE 的导出目录中读取。如果使用序号导入可以直接按序号取地址。日常 DLL 大多按函数名字符串导入写在节区里。修复导入表的关键点是找到OriginalFirstThunk或FirstThunk数组遇到 0 表示结束高位如果是 1 表示按序号导入否则低位是函数名结构体的 RVA。这一部分最容易出错的就是偏移换算。举个例子IMAGE_IMPORT_BY_NAME里的Name字段是 RVA不是文件偏移也不是简单的“镜像基址 文件偏移”就能得到的。如果没有把 RVA 转成虚拟地址查出来的函数名可能是一串乱码或恰好指向别的数据。4.4 处理重定位表如果分配到的内存地址恰好等于OptionalHeader.ImageBase理论不需要重定位。但VirtualAlloc不能保证你总能分配到首选基址尤其是系统里很多模块已经占用了这些地址。为了让 DLL 能加载到任意基址必须处理重定位。重定位表按“块”组织。每个块有一个VirtualAddress和SizeOfBlock后面跟着若干 16 位项。低 12 位存类型高 4 位是相对当前块的偏移。类型为 3 表示需要把该位置的 64 位指针加上 base delta类型为 0 表示用来对齐可以直接跳过。我的建议是实现前先把 base delta 算好。base delta 就是“实际基址 - 原 ImageBase”。如果分配在 64 位环境需要注意指针大小是 8 字节不要用处理 32 位重定位的思路直接改 4 字节。重定位漏处理的常见表现是入口函数确实被调用了但代码一跳转就崩溃或者某个全局函数指针不对。排错时可以在加载器里加日志把每个重定位块处理的地址范围和修改前的值打出来。4.5 调用入口点和导出表验证重定位和导入表都处理完就可以调用入口了。入口点地址由OptionalHeader.AddressOfEntryPoint给出这个值是 RVA应该转换成加载后的虚拟地址using DllMainProc BOOL(WINAPI*)(HMODULE, DWORD, LPVOID); DllMainProc entry reinterpret_castDllMainProc( base nt-OptionalHeader.AddressOfEntryPoint); entry(reinterpret_castHMODULE(base), DLL_PROCESS_ATTACH, nullptr);注意如果基础 PE 结构没有做保护属性设置直接用PAGE_READWRITE调用代码可能会触发数据执行保护DEP。教学阶段只跑简单 DLL 可能没事但更标准的做法是在映射节区后根据每个节区的Characteristics设置内存保护比如代码节改成PAGE_EXECUTE_READ数据节保持PAGE_READWRITE。调用完DLL_PROCESS_ATTACH后可以从 DLL 的导出表里找函数地址。这时候不能直接GetProcAddress(GetModuleHandle(TestDll), Add)因为这个模块没有经过系统 Ldr 注册。比较实用的方式是自写一个FindExport遍历导出目录定位导出目录结构。拿到NumberOfFunctions。根据AddressOfNames数组找到函数名字符串对比要查的名字。如果名字项索引有效再从AddressOfNameOrdinals拿序号最后用AddressOfFunctions拿函数 RVA。记得把 RVA 转换成base rva的实际地址。这个FindExport函数需要写在哪通常先写在一个普通宿主程序里宿主程序自身动态链接kernel32。加载器本身在宿主程序里运行调用关系完全合法。你最后做出来的是“一个模块加载 Demo”不是脱离进程运行的独立 shellcode。4.6 一个最小工程的函数划分建议按下面职责拆分便于排查函数职责输入返回ValidatePeBuffer校验签名和文件大小DLL 文件字节、大小是否有效 PEMapPeSections分配镜像内存并复制节区PE 头、文件字节加载后基址FixRelocations基址修正实际基址、原始 ImageBase是否成功PatchImports填充 IAT实际基址是否成功RunDllEntry调用入口实际基址、reason返回值FindExport导出表查找实际基址、函数名函数地址每个函数都不要写得过长。出现问题时先定位到具体函数再局部调试比在一个“加载全流程大函数”里找问题容易得多。5. 验证与排查加载成功不等于万事大吉5.1 怎样才算加载成功最简单的验证让测试 DLL 在入口返回、并让宿主读取一个导出函数。如果入口没有执行先不要怀疑整个流程崩了可以用简单的“软件断点”或OutputDebugString输出判断。调用一个不导出任何函数的 DLL你只能确认入口执行不能确认模块内容完全可用。一个可行方法是测试 DLL 暴露一个函数extern C __declspec(dllexport) int GetMagicValue() { return 2025; }加载器调用FindExport(GetMagicValue)后得到函数地址如果返回值是 2025说明导出解析正常代码段映射也基本正确。再看 DLL 是否调用了外部 API如果调用成功说明导入表修复也生效了。5.2 常见问题表和排查顺序以下是我实际操作中容易遇到的几类问题可以先对照现象看现象最常见原因优先排查点VirtualAlloc返回空内存不足或SizeOfImage异常检查 PE 头字段是否读到垃圾调用入口时立即崩溃重定位未处理或节区映射错误看崩溃地址是否在镜像节区内导入函数调用崩溃IAT 没有填充或函数名查错打印导入函数地址是否是有效代码入口执行但导出函数找不到导出目录解析或 RVA 换算错误打印AddressOfNames值是否在镜像内数据全是 0.bss或未初始化节区没有清零看VirtualSize与SizeOfRawData差异代码能跑但被 DEP 拦截内存保护是PAGE_READWRITE给代码节设置PAGE_EXECUTE_READ只有 Debug 能跑 Release 崩溃初始化变量或优化后指针变动检查是否依赖未初始化栈内存排查顺序我建议固定下来先查 PE 头字段是否解释正确再查节区复制是否完整然后查导入表再查重定位最后才怀疑内存保护或代码本身。不要一上来就怀疑“反射加载不支持某某功能”。很多失败是因为文件对齐和内存对齐没理清楚或者拿源文件的 RVA 当虚拟地址用。5.3 为什么必须打印日志和中间值自己写加载器时日志不是你偷懒的选择而是唯一能看见内部状态的手段。你不妨在加载流程里临时加入这些输出输入文件大小与SizeOfImage。VirtualAlloc分配到的实际地址以及 PE 头里的ImageBase。节区数量、每个节区的VirtualAddress和SizeOfRawData。重定位表块的数量、每个块的 RVA。导入表解析到的 DLL 名称和函数名。打印时要注意如果没有正确处理完导入表你的宿主程序本身可以调用printf/OutputDebugStringA这没问题因为这些 API 是宿主程序的正常导入不经过自定义加载器。但加载器内部不能用尚未修复的目标 DLL 的函数。调试这一类代码另一个很实用的小技巧是使用 WinDbg 或 Visual Studio 的“混合调试”。在调entry(base, DLL_PROCESS_ATTACH, nullptr)那一行打断点按 F11 单步进入 DLL 入口直接看崩溃点是在导入调用之前还是之后。通过堆栈窗口你能看到是哪一条指令访问了非法地址这比盲改参数高效得多。5.4 边界提醒不要把系统 DLL 或复杂 C DLL 当第一个测试对象新手第一次测试很容易直接去找一个复杂的现有 DLL比如user32.dll或自己项目里带大量类、静态对象的项目 DLL。结果往往是加载后立即崩溃然后怀疑加载器写错了。实际上系统 DLL 往往和系统加载器强绑定自己加载复杂 DLL 时还会遇到 TLS、C 异常、静态初始化、资源目录等一大堆后续问题。所以应该把测试目标分成“三个级别”入门裸 DLL不导入外部函数只处理重定位和入口验证导出表。进阶DLL 调用少量kernel32.dll的 API验证导入表修复。挑战加入 C 类、全局对象、异常处理逐步逼近真实生产 DLL 的场景。这样逐步增加复杂度遇到问题才知道是哪一层没满足而不是把所有特性一次性叠加。6. 实用建议这项技术真正的价值和使用边界6.1 合适合法场景里有哪些用途抛开攻防联想自定义模块加载在日常开发里能被用到的地方其实不少。比如沙箱或插件系统希望从内存块加载已签名的模块避免磁盘上留下临时文件又比如游戏或工具需要验证模块完整性和签名后再加载不希望加载前被无关进程干扰。还有不少虚拟机、模拟器、分析工具在教学和研究中需要解释 PE 结构自己写加载器能更清晰地展示加载流程。但这些场景都要满足三个前提加载行为发生在自己的进程里。加载的是自己生成或已获得授权的模块。用途不涉及未授权访问、安全对抗或增加系统风险。如果只是单纯为了学 C 底层自己写一个“当前进程 PE 加载 Demo”已经足够。不要把代码扩展成远程进程相关的东西也不要为了演示效果而去绕过别人的安全边界。技术探索的乐趣在于理解原理而不是把原理用在越界的地方。6.2 生产项目能不能直接替换 LoadLibrary我的结论是不建议。系统LoadLibrary背后不光有 PE 映射还包括模块引用计数、依赖加载、DLL 目录搜索、Rtl 回调、TLS 回调、静态初始化、异常处理链、模块列表维护等一整套功能。一个自研加载器即使能跑通简单测试也很难覆盖这些复杂情况。尤其是 C DLL编译器会生成很多 CRT 初始化代码它们依赖系统加载器的标准初始化和清理机制。你手工加载一个带全局对象的 DLL对象可能不构造或析构时机异常。如果只是做学习和实验可以毫不在意这些边界。如果是给正式产品用要评估得不偿失。更稳健的做法是设计模块插件系统时考虑让 DLL 先存为临时文件并调用普通加载或者使用系统支持的加载机制保证兼容性。自研内存加载器更适合隔离环境、沙箱测试、原型验证等场景。6.3 需要继续深挖哪几个方向要是读完觉得 PE 结构很有意思值得往下展开的路线大致是从 PE 解析器开始只做文件信息读取不加载先理解各种目录表。然后做完整版“镜像加载”支持重定位、IAT 修复、调用入口。再做 TLS 回调和异常处理理解 C 运行时初始化在加载过程中扮演的角色。如果还要深入可以在开发者自己的测试进程里研究导出表解析和模块卸载清理。你会发现最后学到的不是一段能随便扔进项目的“高级代码”而是能解释“为什么这个 DLL 不能直接内存加载”“为什么系统加载器做了这么多额外动作”的底层判断力。这种判断力恰恰是普通 C 调用式开发很难获得的经验。这篇的核心就一句话反射式 DLL 加载器是理解 Windows PE 加载机制的绝佳练习题目但它不等于一个值得直接搬到生产环境的模块加载方案。先把最小流程跑通再一点点补齐系统加载器已经替你完成的部分你会对 C 和 Windows 系统之间的关系建立起完全不同的一层理解。真要做产品化记得回到系统支持的正规加载路径把内存加载限制在研究、沙箱和授权实验里。