简单方法使 kernel32.dll 发生重定位

简单方法使 kernel32.dll 发生重定位

系统启动后 kernel32.dll 在每个进程的加载地址都相同。。。。吗？

相信很多人都知道这个，因为这个是远程线程注入的基础，类似的还有user32.dll之类的系统dll。

不过这个概念是错误的，或者说它在绝大多数时候是正确的

因为通常来说这些系统dll默认在不同进程中保持相同的地址（通过观察它们在不同进程中加载的地址可以确定这一点），不过在有些情况下可能会使得它们发生重定位，比如在这些dll还没有加载之前，如果有一个方法把加载的目标地址给占住，那么就可以使得重定位发生（ntdll.dll除外）。

当然你在中文网站上搜索基本都是告诉你，啊重启后是相同的之类的，还要给你解释一堆，当年我刚刚接触远程线程注入的时候也是在网上找到相关的资料，不过后来我想到如果把ASLR关了，然后把基址写成和kernel32.dll相同的地址它可行吗？

操作环境如下

Windows 10 Enterprise LTSC 19044.3930
Microsoft Visual Studio Professional 2022 Version 17.8.6

在我的系统上当前某个进程中kernel32.dll的地址如下

Base=771D0000
Module=kernel32.dll
Party=System
Path=C:\Windows\SysWOW64\kernel32.dll

现在用vs来新建一个项目，全部都是默认配置，但关闭ASLR和把默认基址改成0x771D0000

接下来我们将会看到神奇的一幕，0x00480000的kernel32.dll你见过吗？

Base=00480000
Module=kernel32.dll
Party=System
Path=C:\Windows\SysWOW64\kernel32.dll

重新打开一个进程，可以发现，只是当前的test.exe的kernel32.dll发生了重定位而已

而且它是完全可以正常运行的，但会不会有其它副作用很难说。

现在大家应该知道了 所谓 系统启动后 kernel32.dll 在每个进程的加载地址都相同 其实是个错误的概念，或者说以前是对的，现在已经不适用了,而且这种方法基本上除了ntdll.dll以外的所有dll都可以。

最初学习远程线程注入的时候我就注意到了这点，但我并不是什么Windows系统大神，很难去解释这是为什么，而且也很难去搜索原因，而且我也不是挂哥，很少用到这种功能，就没有去深究了，
几年前录过一个dll注入方法简介的视频也谈到过这点，即 远程线程注入获取的那个地址只是个巧合罢了，https://www.bilibili.com/video/BV1pW4y1m7gh/，当然评论区也有人给我抬杠，显然他们没真正去做过实验。

写这篇文章主要是因为今天偶然又刷到了一篇文章，还在说这件事，但是评论区有一个人的回答可能才是这个问题的真正原因所在。https://bbs.kanxue.com/thread-279591.htm