EnumProcessModules 是 Windows 下获取模块基地址最可靠方式，需两步调用并确保权限；Linux 用 /proc/self/maps 解析内存映射段；macOS 必须用 _dyld_image_count 和 _dyld_get_image_header 获取 Mach-O 镜像基址。
Windows下用 EnumProcessModules 获取模块基地址最可靠
在 Windows 上，EnumProcessModules 是获取当前进程已加载模块（DLL/EXE）基地址映射表的标准方式。它返回的是每个模块的 HMODULE，本质就是模块在内存中的基地址（即 LoadLibrary 返回值或 PE 映像首地址）。注意：必须链接 psapi.lib，且推荐用 psapi.dll 的新版本（Win10+ 可用 EnumProcessModulesEx 过滤 32/64 位模块）。
常见错误是只调用一次就以为拿到全部——实际需两步：先用 NULL 参数调用一次获取所需缓冲区大小，再分配足够内存重试。否则 EnumProcessModules 返回 FALSE 且 GetLastError() 为 ERROR_INSUFFICIENT_BUFFER。
- 确保进程有
PROCESS_QUERY_INFORMATION和PROCESS_VM_READ权限（调试器或自身进程通常默认具备） - 模块列表顺序不保证稳定，不要依赖索引取
kernel32.dll或ntdll.dll -
GetModuleFileName配合HMODULE可查路径，但某些注入模块或内存加载 DLL 可能无路径（返回空字符串）
Linux 下靠 /proc/self/maps 解析更直接
Linux 没有“模块句柄”概念，而是通过 /proc/self/maps 文本文件获取所有内存映射段信息。其中标记为 r-xp 且含 .so 或可执行文件名的行，基本对应动态库或主程序的加载基址。
关键点在于解析字段：每行前两字段是地址范围（如 7f8b2c000000-7f8b2c002000），第一个地址即基地址；第6列是映射路径（可能为空或为 [vdso]、[heap] 等伪名称）。
立即学习“C++免费学习笔记（深入）”；
- 用
std::ifstream逐行读取，std::stringstream提取前两个十六进制数，转成uintptr_t - 跳过不含路径或路径以
[开头的行（除非你明确需要 vdso/vvar 等内核映射） -
mmap显式加载的库也会出现在 maps 中，但不会出现在dlopen的 handle 列表里——所以/proc/self/maps更全
macOS 必须用 _dyld_image_count + _dyld_get_image_header
macOS 不提供类似 Windows 的枚举 API，也不开放 /proc，唯一正统方式是使用 Darwin 的 dyld API。模块数量由 _dyld_image_count() 返回，每个模块的 Mach-O 头地址由 _dyld_get_image_header(i) 获得——这个地址就是该镜像的加载基址（即 __TEXT 段起始地址）。
注意：_dyld_get_image_header 返回的是 struct mach_header *，不是模块名。要获取路径需调用 _dyld_get_image_name(i)；而基地址 ≠ 路径加载地址，因为 ASLR 会导致每次偏移不同，但 _dyld_get_image_header 返回值已包含 ASLR 偏移后的实际地址。
- 这些函数声明在
mach-o/dyld.h，无需额外链接库 - 序号
i从 0 开始，i == 0总是主可执行文件，后续为依赖的 dylib - 不能在
main()之前调用（dyld 尚未完成初始化），也不能在dlclose后继续用对应序号——序号会随加载/卸载动态变化
跨平台封装时别硬套“模块”抽象
三个系统对“模块”的定义差异很大：Windows 侧重 HMODULE（可直接重定位调用）、Linux 侧重内存映射段（可能无符号表）、macOS 侧重 Mach-O 镜像（有丰富的 load command 但无统一句柄）。强行统一成 struct ModuleInfo { void* base; std::string path; } 容易漏信息或误判。
比如：Linux 的 libc.so.6 在 maps 中可能拆成多个段（.text、.data 分开映射），而 macOS 的 libsystem_c.dylib 是单个镜像；Windows 的某个 DLL 可能被多次 LoadLibrary，但 EnumProcessModules 只返回一个 HMODULE（引用计数管理，非多次加载）。
- 如果只是做内存扫描或 hook，优先用各平台原生方式获取基址，别试图“合并”逻辑
- 路径不可靠：注入模块、内存加载、ASLR + PIE 可使路径为空或指向临时位置
- 真正需要符号解析时，基地址只是起点，还得结合
dbghelp.dll（Windows）、libbfd（Linux）、dyld符号API（macOS）进一步处理
