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

Question

以下问题仅用于教育目的，所讨论的功能并非旨在更改已注册的DLL或开发恶意软件，而是用于学习和体验。

最近，我一直在探索几种方法来加载我自己的自定义DLL而不是应用程序的原始DLL。 提出的方法之一是<exe>.local方法。

经历了这个方法后，我从注册表中删除了KnownDlls条目后，我成功地用修补的DLL替换了一些系统DLL。

这些是DLL：

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

但是，仍有一些DLL坚持从system32目录加载，尽管它们存在于本地文件夹中。

有什么方法可以强制DLL从本地文件夹而不是system32文件夹加载？

Answer 1

这不是一个答案，而是一个漫无目的，无源的大脑转储。

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

通常，在使用LoadLibrary时，您正在要将dll加载到的进程中使用它。因此，它可以利用关于激活上下文，dll搜索路径等的一大堆进程内上下文信息，包括app.local标志之类的知识。 所有这些值都是特定于当前进程的，并不是任何其他进程（甚至是内核）的工作来跟踪这样的事情。

但是，如果我们看一下CreateProcess，我们可以看到一些问题。当它最初被调用时，它在启动而不是目标进程的上下文中被调用，因此它不知道目标进程激活上下文。实际上，目标进程尚不存在。

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

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

这意味着，不幸的是，对于您来说，kernel32.dll和一些依赖项需要在该进程能够构建dll搜索上下文之前很久就被映射到一个进程，注意到app.local标志等。

Answer 2

您应该了解Windows加载程序的工作原理。这是依赖于OS版本的，但是其中一些DLL在程序之前加载，并且加载程序总是在系统提供的路径上查找它们。通过使用WinDbg启动程序来查看序列。