LoadLibraryExA无法直接加载内存中DLL数据，必须手动实现PE加载器：申请RWX内存、复制字节、修复重定位与导入表、调用DllMain；需绕过DEP、ASLR及签名限制，或改用CreateFileMapping+LoadLibraryExA等系统支持的伪文件方案。
Windows下用LoadLibraryExA加载内存中DLL数据需绕过签名和ASLR限制
直接传入内存地址给LoadLibraryExA会失败，它只接受磁盘路径。真正可行的是先申请可读写执行（RWX）内存，把DLL原始字节拷进去，再手动修复重定位、解析导入表、调用入口点——这本质上是实现一个极简版PE加载器。
关键障碍在于：Windows默认禁止从非映像页执行代码（DEP），且现代系统要求DLL有有效签名或启用LOAD_LIBRARY_SEARCH_*标志才能跳过路径校验。但这些对纯内存加载无效，必须自己处理PE结构。
-
VirtualAlloc分配PAGE_READWRITE内存后，必须用VirtualProtect改为PAGE_EXECUTE_READWRITE，否则调用DllMain时触发访问违例 - 不能直接memcpy整个文件到内存——PE头中
OptionalHeader.ImageBase通常不为0，若加载地址与期望不符，必须执行重定位修正（.reloc节存在时） - 导入表（
.idata）中的函数地址全为空，需遍历IMAGE_IMPORT_DESCRIPTOR，对每个DLL调用GetModuleHandleA+GetProcAddress填入函数指针
Linux下用mmap + mprotect加载ELF内存镜像要处理段权限和符号解析
Linux没有现成API加载内存中ELF，必须手动解析ELF头、程序头（PT_LOAD段），将各段按p_vaddr、p_memsz、p_flags映射到对应虚拟地址，并设置正确内存权限。
常见错误是忽略PT_INTERP段（动态链接器路径）和PT_DYNAMIC段（动态链接信息），导致_init或__libc_start_main调用失败；更隐蔽的问题是，即使所有段映射成功，DT_INIT指向的初始化函数也可能因GOT/PLT未修正而跳转到错误地址。
立即学习“C++免费学习笔记（深入）”；
- 必须检查ELF文件是否为ET_DYN（PIE），否则
p_vaddr可能与当前进程地址空间冲突，需用mmap指定MAP_FIXED_NOREPLACE或重新基址重写 -
DT_STRTAB和DT_SYMTAB用于解析符号，但DT_JMPREL（PLT重定位）和DT_REL/DT_RELA（全局偏移表重定位）必须逐条执行，否则函数调用会崩溃 - 调用
dlclose等标准函数前，需确保_fini或DT_FINI_ARRAY已注册，否则资源泄漏且无法卸载
跨平台通用陷阱：DllMain或_init里调用LoadLibrary/dlopen会死锁
手动加载过程中，若目标DLL的初始化函数内部又调用LoadLibraryA（Windows）或dlopen（Linux），极易触发加载器锁死——因为主加载流程尚未完成，而嵌套调用试图获取同一把全局加载锁。
这个问题在调试时表现为进程卡住无响应，且堆栈停留在ntdll!LdrpLoadDll或libdl!_dl_open内，没有任何错误码返回。根本原因不是代码写错，而是加载器自身设计限制。
- 规避方式：初始化阶段禁用所有外部库加载逻辑，把依赖DLL提前全部手动加载完毕再调用目标DLL的
DllMain - Windows下可临时用
DisableThreadLibraryCalls减少线程附加开销，但不影响死锁本身 - Linux下若用
LD_PRELOAD注入，需确认目标进程未设AT_SECURE（如SUID程序），否则getauxval(AT_SECURE)为1时dlopen直接失败
实际工程中建议用memfd_create（Linux）或CreateFileMapping（Windows）替代裸内存加载
真正在生产环境做“不写盘”的DLL加载，硬解析PE/ELF并手动修复是高危操作：Windows 10 RS5后引入CFG（控制流防护），Linux 5.12+强化了vm.mmap_min_addr和kernel.unprivileged_userns_clone限制，导致多数手动加载逻辑在新系统上直接拒绝执行。
更稳妥的做法是利用系统提供的“伪文件”机制：Linux用memfd_create创建匿名内存文件，fd传给dlopen；Windows用CreateFileMapping + MapViewOfFile生成可执行映射，再用LoadLibraryExA加载该映射路径（路径形如\.GlobalXXXX）。两者都不落盘，但复用系统加载器，规避了重定位、导入解析、安全策略绕过等全部复杂性。
真正难的从来不是“怎么把字节放进内存”，而是“怎么让操作系统相信这段内存合法且值得信任”。这点常被忽略，直到在客户机器上遇到STATUS_INVALID_IMAGE_HASH或SEGV_MAPERR才意识到——你对抗的不是API文档，是整个加载生态的设计约束。
