Winapi ASLR是否会导致地址与DLL注入发生摩擦？

我在读关于DLL注入技术的书，我想到了这个问题

假设我们想在Windows7中向目标进程注入一个DLL，该进程已为kernel32.DLL启用ASLR

因此，任何注入代码都不能使用任何winapi或任何系统调用，因为注入代码中loadLibrary函数的地址与目标进程中loadLibrary函数的地址不同，不是吗

因此，对

CreateRemoteThread

的此类调用将不起作用：

CreateRemoteThread(hProcess,
                   NULL,
                   0,
                   (LPTHREAD_START_ROUTINE) ::GetProcAddress(hKernel32,
                                                             "LoadLibraryA" ),
                   pLibRemote,
                   0,
                   NULL );

::WaitForSingleObject( hThread, INFINITE );

---

如果我的推理错误，请纠正我。

不，我认为这是错误的。机器启动时，诸如

kernel32.dll等模块的地址是随机的，但对于所有进程都是相同的。
他可以从注入器的导入表中直接使用GetModuleHandle（和GetProcAddress），该表将重定向到对kernel32上GetModuleHandle的调用，以获取kernel32上LoadLibraryA的地址，可用于任何流程

如果他直接传递硬编码的LoadLibraryA地址，他将在注入器的导入表上找到LoadLibraryA的地址，这在目标进程上是不同的

有人可能会问：“为什么它不转换导入表，而调用GetModuleHandle和GetProcAddress？”。导入表只是可执行加载程序使用相同的GetModuleHandle和GetProcAddress（实际上不相同，但类似）获得的指针表。
这意味着像kernel32.dll这样的模块只加载一次？当一个可执行文件被加载并且它在导入表中时，它只是得到一个指向已经加载的dll的指针？那么，您能否解释一下这个链接中的“ASLR和LoadLibrary”部分，为什么GetModuleHandle在同一个地址，而LoadLibraryA不是？？？@CnativeFreak，它这样说“因为每次重新启动（或两次）时，kernel32.dll的地址（包含LoadLibrary过程）可能会更改我们使用GetModuleHandle检索LoadLibraryA的地址，该地址在远程线程地址空间中相同。”在该文档中。它没有说
GetModuleHandle（）
在同一地址。“我们使用GetModuleHandle检索LoadLibraryA的地址，该地址在远程线程地址空间中相同”为什么GetModuleHandle在远程线程地址空间中相同，而LoadLibraryA不相同？@CnativeFreak，它们都是相同的。这只是说明它是如何完成的，并且kernel32.dll导出的任何函数的地址都不能硬编码。模块的地址可能不会更改，但这并不能保证操作的安全！考虑一下你的应用程序使用SHIMS（你不控制的东西）运行的情况，或者甚至在你的进程中运行的一些其他软件也在运行过程中（再一次，而不是你控制的东西）。在这种情况下，GetProcAddress可以返回一个指向另一个模块中函数的指针，指向您期望/请求的内容，包括一个未加载到您将调用CreateRemoteThread的进程中的内容，在这种情况下，目标将崩溃。