ASLR 会导致 DLL 注入地址的摩擦吗？答案

【问题标题】：Would ASLR cause friction for the address with DLL injection?ASLR 会导致 DLL 注入地址的摩擦吗？
【发布时间】：2023-03-06 06:06:01
【问题描述】：

我正在阅读有关 DLL 注入技术的信息，并且想到了这个问题。

假设我们想将一个 DLL 注入到 Windows 7 中为 kernel32.dll 启用 ASLR 的目标进程中

所以任何一段注入代码都不能使用任何 winapi 或任何系统调用，因为假设注入器代码中的 loadLibrary 函数的地址将与目标进程中的地址 loadLibrary 不同，不是吗？

所以对CreateRemoteThread 的这种调用是行不通的：

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

::WaitForSingleObject( hThread, INFINITE );

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

【问题讨论】：

标签： winapi dll inject aslr createremotethread

【解决方案1】：

不，我认为这是不正确的。 kernel32.dll 等模块的地址在机器启动时是随机的，但对于所有进程都是相同的。

【讨论】：

所以这意味着像 kernel32.dll 这样的模块只加载一次？当一个可执行文件被加载并且它在导入表中它只是得到一个指向已经加载的 dll 的指针？那么您能否解释一下此链接insecure.in/papers/vista_dll_injection.pdf 中的“ASLR 和 LoadLibrary”部分，为什么 GetModuleHandle 位于同一地址而 LoadLibraryA 不在？？
@CnativeFreak，它说“因为在每次重新启动（或两次）时，kernel32.dll（包含 LoadLibrary 过程）的地址可能会改变，我们使用 GetModuleHandle 来检索 LoadLibraryA 的地址，这将是在远程线程地址空间中也是如此。”在那个文件中。并不是说GetModuleHandle()在同一个地址。
"我们使用 GetModuleHandle 来获取 LoadLibraryA 的地址，这在远程线程地址空间中是相同的" 为什么 GetModuleHandle 在远程线程地址空间中是相同的，而 LoadLibraryA 不是？
@CnativeFreak，它们都是一样的。它只是说明它是如何完成的，并且 kernel32.dll 导出的任何函数的地址都不能被硬编码。
模块的地址可能不会改变，但这并不能保证 OP 正在做的事情是安全的！考虑您的应用程序在启用 shims 的情况下运行（您无法控制的事情！），或者甚至在您的进程中运行一些其他也执行 EAT 挂钩的软件的情况（同样，不是您控制的事情）。在这种情况下，GetProcAddress 可以将指向另一个模块中的函数的指针返回到您期望/要求的函数，包括在您要调用 CreateRemoteThread 的进程中未加载的函数，在这种情况下，目标将崩溃.

【解决方案2】：

他可以直接使用 GetModuleHandle（和 GetProcAddress），从 INJECTOR 的 IMPORT TABLE 中，这将重定向到对 KERNEL32 上的 GetModuleHandle 的调用，以获取可用于任何进程的 LoadLibraryA 在 KERNEL32 上的地址

如果他直接传递硬编码的 LoadLibraryA 的地址，他将在 INJECTOR 的 IMPORT TABLE 上传递 LoadLibraryA 的地址，这在目标进程上是不一样的

有人可能会问：“为什么它不翻译导入表而不是调用 GetModuleHandle 和 GetProcAddress？”。导入表只是可执行加载器使用 THE SAME GetModuleHandle 和 GetProcAddress 获得的指针表（实际上不一样，但相似）

【讨论】：