C++ 加载自定义DLL而不是原始DLL

下面的问题仅用于教育目的，所讨论的内容不是为了更改已注册的DLL或开发恶意软件，而是为了学习和体验。

最近，我一直在探索一些方法来加载我自己的定制DLL，而不是应用程序的原始DLL。 出现的方法之一是

.local

方法

在体验了一下这种方法之后，在我从注册表中删除了

KnownDlls

条目之后，我成功地用我的补丁DLL替换了一些系统DLL

这些是DLL：

但是，DLL位于本地文件夹中：

但是，仍然有一些DLL坚持从

system32

目录加载，尽管它们存在于本地文件夹中

---

有没有办法强制从本地文件夹而不是system32文件夹加载DLL？

您应该看看Windows加载程序是如何工作的。这取决于操作系统的版本，但有些DLL在程序加载之前加载，加载程序总是在系统提供的路径上查找它们。通过使用WinDbg启动您的程序来查看序列。

这与其说是一个答案，不如说是一个杂乱无章、毫无来源的大脑转储

这确实可以解释为什么我对你的结果不感到惊讶。对我来说，这可以归结为CreateProcess和LoadLibrary之间的关键区别，以及Win32进程的工作方式

通常，在使用LoadLibrary时，您是从希望加载dll的进程中使用它的。因此，它可以利用一大堆关于激活上下文、dll搜索路径等的进程内上下文信息，包括app.local标志等知识。 所有这些值都是特定于当前进程的，任何其他进程（甚至内核）都无法跟踪这样的内容

但是，如果我们看看CreateProcess，就会发现一些问题。最初调用它时，它是在启动进程的上下文中调用的，而不是在目标进程的上下文中调用的，因此它对目标进程激活上下文一无所知。事实上，目标进程还不存在

CreateProcess实现需要创建一个NT流程，并尽快在其中执行一些代码以执行流程加载，因为在当前流程中实例化所有每个流程的上下文内容没有任何意义

但是，要做到这一点，目标进程中至少需要一些代码：负责解析EXE文件头、提取头并构建将用于加载其余DLL的激活上下文的内核代码

---

这意味着，对您来说很不幸，kernel32.dll和某些依赖项需要映射到进程中很久，然后该进程才能构建dll搜索上下文，注意app.local标志等。

任何试图通过definition@WeatherVane这样做有许多正当理由。1.使用代理DLL监视API调用。2.如我所愿替换功能。3.因为有些人热衷于学习和体验。@WeatherVane我同意OP-这有合法的用途。@Aviv你这么说。本地重定向在这里是可能的。你知道什么是我们不知道的。我们说这是不可能的，因为系统加载器加载了那些DLL。你为什么不用钩子？事实是，你不想这样做，因为你想把你的伪造DLL强加给别人的进程。@Aviv:David最后两条评论是对的。MSDN页面非常清楚，app.exe.local文件更改了

LoadLibrary

和

LoadLibraryEx

的行为

ntdll.dll

和

kernel32.dll

提供了

LoadLibrary

（Ex），因此通过鸡和蛋分析，您可以看到它们不是由

LoadLibrary

（Ex）加载的，因此不受dll重定向的影响。事实上，我想你会发现

ntdll

和

kernel32

根本没有加载到新进程中，它们在初始模块表中。这确实有点杂乱无章。也许最重要的是，

CreateProcess

实际上并没有做那么多工作。它启动内核代码，然后创建新进程，映射几个核心DLL，然后开始运行新进程。但所有这些都不是

CreateProcess

。浏览一下

NtCreateProcess