合法DLL需满足：1. DOS头e_magic为0x5A4D且e_lfanew有效；2. NT头签名"PE\0\0"存在，Characteristics含IMAGE_FILE_DLL；3. 导出表RVA有效且NumberOfFunctions>0。
怎么用 ReadFile + IMAGE_DOS_HEADER 快速初筛 DLL 文件
Windows 下的合法 DLL 必须以 MS-DOS MZ 签名开头，且后续 PE 头结构完整。直接读文件前 64 字节判断 e_magic 是否为 0x5A4D（即 "MZ"）是最轻量的前置过滤。
- 只读前 64 字节即可，避免大文件 IO 开销
- 必须校验
e_lfanew字段：它指向IMAGE_NT_HEADERS起始位置，若为 0 或超出文件大小，直接不是合法 PE - 常见错误：没检查
e_lfanew是否对齐、或未验证该偏移处是否存在完整的"PE\0\0"签名（0x00004550） - 注意：仅靠 DOS 头不能区分 EXE/DLL，但能快速排除纯数据、文本、加密壳等非 PE 文件
如何通过 IMAGE_FILE_HEADER 和 IMAGE_OPTIONAL_HEADER 判断 DLL 属性
DLL 的核心标识在 PE 头的属性标志位，不是文件扩展名。关键看 Characteristics 字段是否含 IMAGE_FILE_DLL（值为 0x2000），同时 DllCharacteristics（可选头中）提供加载行为线索。
-
Characteristics & IMAGE_FILE_DLL为真 → 系统级认定为 DLL（否则 LoadLibrary 会拒绝） -
OptionalHeader.Subsystem应为IMAGE_SUBSYSTEM_WINDOWS_CUI或_GUI，若为_EFI_APPLICATION等则不是 Win32 DLL - 容易踩坑：有些加壳工具会清空
IMAGE_FILE_DLL位但保留导出表，此时LoadLibrary仍可能失败；需结合导出表进一步验证 - 64 位 DLL 的
OptionalHeader.Magic必须是0x20B（IMAGE_NT_OPTIONAL_HDR64_MAGIC），32 位是0x10B；错读会导致字段偏移全乱
为什么必须检查导出表（IMAGE_EXPORT_DIRECTORY）才能确认“可被加载为 DLL”
操作系统加载 DLL 时，至少需要一个有效导出函数（哪怕只是 DllMain）。没有导出表的 PE 文件，LoadLibrary 会返回 NULL 并设错误码 ERROR_BAD_EXE_FORMAT。
- 定位导出表：从
DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]获取 RVA 和大小，再换算为文件偏移 - 常见错误现象：
LoadLibrary返回 NULL 但GetLastError()是193 (ERROR_BAD_EXE_FORMAT)，往往就是导出表 RVA 无效、大小为 0、或地址落在节外 - 不必遍历所有导出函数，只要
NumberOfFunctions > 0且AddressOfFunctions指向的有效内存块不为空，就满足基本 DLL 加载前提 - 注意：某些 .NET DLL（如纯 IL 程序集）可能无原生导出表，但它们依赖 CLR 加载，不属于本机 DLL 判定范畴
实际调用 LoadLibrary 前还有哪些隐蔽限制
即使文件结构全合规，Windows 加载器还会做运行时校验。绕过静态解析、直接尝试加载并观察行为，是最终验证手段，但代价高、有副作用。
立即学习“C++免费学习笔记（深入）”；
-
LoadLibrary会检查导入表中 DLL 名称是否合法（如含..、控制字符、长度超MAX_PATH），非法名称导致ERROR_INVALID_NAME - 如果 DLL 依赖其他不存在的模块（如
MSVCR120.dll缺失），加载失败但错误码是ERROR_MOD_NOT_FOUND，易误判为文件本身不合法 - 安全软件或系统策略（如 WDAC）可能拦截加载，表现为
Access is denied（ERROR_ACCESS_DENIED），和文件格式无关 - 强烈建议：仅在必要时调用
LoadLibrary验证；优先用静态解析（前三个步骤）覆盖 95% 场景；真要加载，请用LOAD_LIBRARY_AS_DATAFILE标志避免执行初始化代码
真正麻烦的是那些结构上勉强合格、但故意把导出表 RVA 指向节间隙或填充区的文件——它们能骗过简单签名检查，却在加载瞬间崩掉。这时候得比对节头的 VirtualAddress/SizeOfRawData 和导出表 RVA 是否落在任一节的有效范围内。
