关于LoadLibraryA地址差异及与kernel32.dll相对位置的技术问询

你观察到的现象完全符合Windows PE文件的动态链接机制，咱们一步步拆解清楚：

1. 直接打印LoadLibraryA得到低地址的原因 #

你输出里的0x420144并不是LoadLibraryA的真实函数地址，而是**EXE自身内存中的导入跳转桩（Import Thunk）**的地址。这个跳转桩是编译器编译EXE时自动生成的一段极小代码，存放在EXE的代码节里（所以地址靠近EXE的基址0x400000）。

2. 动态链接的底层运行逻辑 #

当Windows加载你的EXE时，会按流程处理导入表：

• 系统先找到kernel32.dll并加载到内存（基址0x75c80000），然后定位到LoadLibraryA在kernel32中的真实地址0x75c95980。
• 系统会把这个真实地址写入到EXE数据节里的一个指针变量——也就是__imp_LoadLibraryA中。
• 你代码里写的LoadLibraryA调用，汇编层面实际上是先跳到那个跳转桩，跳转桩的核心代码类似：

  jmp dword ptr [__imp_LoadLibraryA]
  

  它通过间接引用__imp_LoadLibraryA的指针，最终跳转到kernel32里的真实函数执行。

3. 为什么GetProcAddress能拿到真实地址 #

GetProcAddress是直接从加载后的kernel32.dll的导出表中查询函数地址，返回的就是kernel32内存空间里的真实函数入口（0x75c95980），自然靠近kernel32的基址0x75c80000。

4. 关于__imp_LoadLibraryA的作用 #

你的猜测完全正确！__imp_LoadLibraryA就是系统在加载时会替换为真实地址的标记。它本质是一个全局指针变量，存放在EXE的.idata（导入数据）节中。当EXE启动时，Windows加载器会遍历导入表，把所有__imp_开头的指针变量都填充为对应DLL函数的真实地址。

额外澄清：不是静态链接 #

你之前怀疑的静态链接并不成立——如果是静态链接，LoadLibraryA的代码会被直接编译进EXE，打印的地址会在EXE基址附近，但调用行为会完全绕开kernel32.dll，这显然不符合Windows系统API的调用逻辑。你看到的跳转桩机制，正是动态链接的典型特征。

内容的提问来源于stack exchange，提问作者sergiu reznicencu