ASLR 会导致 DLL 注入的地址冲突吗？
我正在阅读有关 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 );
如果我的推理错误，请纠正我。
I was reading about the DLL injection technique, and I had this question in mind.
Let us assume we want to inject a DLL into a destination process in Windows 7 which has ASLR enabled for kernel32.dll
So any piece of the injected code can't use any winapi or any system call since the address of let's say loadLibrary function in the injector code will differ from the address loadLibrary in the destination process, Won't it ?
So such a call to CreateRemoteThread won't work:
CreateRemoteThread(hProcess,
NULL,
0,
(LPTHREAD_START_ROUTINE) ::GetProcAddress(hKernel32,
"LoadLibraryA" ),
pLibRemote,
0,
NULL );
::WaitForSingleObject( hThread, INFINITE );
Correct me if I am wrong in this reasoning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，我认为这是不正确的。像
kernel32.dll这样的模块的地址在机器启动时是随机的，但对于所有进程都是相同的。No, I believe that is incorrect. The addresses of modules like
kernel32.dllare randomized when the machine boots but are the same for all processes.他可以直接从注射器的导入表中使用 GetModuleHandle（和 GetProcAddress），这将重定向到对 KERNEL32 上的 GetModuleHandle 的调用，以获取 KERNEL32 上的 LoadLibraryA 的地址，
如果他传递了硬编码的 LoadLibraryA 的地址 ，则可以在任何进程上使用该地址直接，他将传递 LoadLibraryA 的地址INJECTOR'S IMPORT TABLE，与目标进程上的不一样，
人们可能会问：“为什么它不转换导入表而不是调用 GetModuleHandle 和 GetProcAddress？”。导入表只是可执行加载器使用相同的 GetModuleHandle 和 GetProcAddress 获得的指针表（实际上不一样，但相似）
he can use GetModuleHandle (and GetProcAddress) directly, FROM THE INJECTOR'S IMPORT TABLE, which will redirect to a call to GetModuleHandle ON KERNEL32, to get the Address of LoadLibraryA ON KERNEL32, that can be used on any process
if he passed the hardcoded LoadLibraryA's address directly, he would be passind the address of LoadLibraryA ON THE INJECTOR'S IMPORT TABLE, which is not the same on the target process
one may ask: "why it doesn't translate the import table instead of calling GetModuleHandle and GetProcAddress?". The import table is just a table of pointers obtained by the executable loader using THE SAME GetModuleHandle and GetProcAddress (actually not the same, but similar)