getmodulehandle+getprocaddress得到的是运行时绝对地址，减去当前实际加载基址才得rva；静态rva需手动解析pe导出表获取，且x64下须用uintptr_t避免截断。
GetModuleHandle + GetProcAddress 能拿到的是绝对地址，不是偏移
很多人以为 GetProcAddress 返回的地址减去模块基址就是“符号在 DLL 中的 RVA（Relative Virtual Address）”，这在多数情况下成立，但有陷阱：DLL 可能被 ASLR 重定位，而你拿到的模块基址必须是它**当前实际加载地址**，不是 PE 文件头里写的 ImageBase。如果用 GetModuleHandle(NULL) 或硬编码地址去算，结果会错。
正确做法是先用 GetModuleHandle 获取目标 DLL 的真实加载基址，再用 GetProcAddress 拿函数地址，最后相减：
HMODULE hMod = GetModuleHandle(L"example.dll"); if (!hMod) return; FARPROC pFunc = GetProcAddress(hMod, "MyExportedFunc"); if (!pFunc) return; DWORD_PTR base = (DWORD_PTR)hMod; DWORD_PTR rva = (DWORD_PTR)pFunc - base;
注意：rva 是一个无符号整数，不是指针；它只在该次加载上下文中有效。
手动解析 PE 头获取导出表中的原始 RVA 更可靠
上面方法依赖运行时加载状态，一旦 DLL 卸载或重载，RVA 就失效。若需跨会话复用（比如做 patch 记录、离线分析），得直接读 DLL 文件，从导出目录（IMAGE_EXPORT_DIRECTORY）里提取函数名与 RVA 的映射。
关键步骤包括：
- 用
CreateFile+CreateFileMapping+MapViewOfFile映射 DLL 文件到内存（不能直接用LoadLibrary，否则可能触发重定位） - 校验 DOS/NT 头，定位导出目录 RVA（通常在
OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress） - 遍历
AddressOfFunctions数组，每个元素就是函数的原始 RVA（未加基址） - 用
AddressOfNames和AddressOfNameOrdinals关联函数名与序号
示例片段（跳过错误检查）：
PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)mapView; PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)((BYTE*)mapView + dos->e_lfanew); DWORD exportRva = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress; PIMAGE_EXPORT_DIRECTORY exp = (PIMAGE_EXPORT_DIRECTORY)((BYTE*)mapView + exportRva); DWORD* funcRvas = (DWORD*)((BYTE*)mapView + exp->AddressOfFunctions); // 这些就是原始 RVA
注意 Ordinal、Forwarder、ForwarderChain 等特殊情形
不是所有导出项都指向本 DLL 的代码。常见干扰项：
-
funcRvas[i]对应的值若落在导出目录地址范围内（即>= exportRva && ），大概率是 forwarder 字符串（如 <code>"KERNEL32.EnterCriticalSection"），此时该 RVA 实际是字符串 RVA，不是函数地址 - 某些函数只按序号导出（no name），需查
AddressOfNameOrdinals数组判断是否存在对应名字 - Windows 10+ 的某些系统 DLL 启用导出节压缩（如
ntdll.dll的 “export table compression”），此时AddressOfFunctions可能被重定向，需额外解析压缩块（极少见，一般可忽略）
简单判断 forwarder 的方式：
DWORD rva = funcRvas[i]; if (rva >= exportRva && rva <h3>64 位下指针宽度和 RVA 计算要统一用 DWORD64</h3><p>在 x64 环境中，模块基址和函数地址都是 64 位指针，但 PE 文件中导出表的 <code>AddressOfFunctions</code> 仍是 32 位数组（每个元素是 <code>DWORD</code>）。这意味着所有原始 RVA 都是 32 位值，最大支持 4GB 地址空间——对现代 DLL 来说完全够用，但计算时不能用 <code>DWORD</code> 截断 <code>DWORD_PTR</code>。</p><p>错误写法：<code>DWORD rva = (DWORD)((BYTE*)pFunc - (BYTE*)hMod);</code> —— 在 x64 下若地址高位非零，会丢数据。</p><p>正确写法（保持类型一致）：<code>DWORD rva = (DWORD)((uintptr_t)pFunc - (uintptr_t)hMod);</code> 或直接用 <code>DWORD32</code> 强制截断（因为 RVA 本身定义就是 32 位）。</p><p>读文件时也一样：映射后所有指针运算建议用 <code>uintptr_t</code>，避免隐式截断。</p><p>真正容易被忽略的点是：同一个 DLL 在不同进程里加载的基址不同，ASLR 下每次都不一样，所以“运行时 RVA”这个概念只有在当前进程上下文里才有意义；而“文件中静态 RVA”才是稳定可复用的——但你要自己解析 PE，不能靠 Windows 加载器帮你填。</p>
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
