windows - 关于 SetWindowsHookEx() 和 Hook 的问题

Question

这里是一些背景信息。我正在通过 AppInit_DLLs 注册表项替换已在 dll 注入(inject)技术中使用的 dll。它的目的是出现在每个进程中，并在 GDI32.dll 中设置 Hook 以收集有关打印的信息。这是一种获得我们想要的东西的时髦方式。 .dll 本身已有 10 多年的历史(用 Visual Studio 97 编写)，我们想用比注入(inject)的 dll 侵入性更小的东西替换它。

看起来 SetWindowsHookEx() 可能就是我们要找的东西。我一直遇到一些麻烦，但我也和同事讨论过这棵树是否值得吠叫。以下是一些我们无法确定的问题:

1. 当我们从 dll Hook 例程时，例如来自 GDI32.dll 的 StartDoc()，我们真的会在每次其他进程使用该例程时收到通知吗从那个 dll 中提取出来？这是我们通过注入(inject)的 .dll 获得的一种功能，我们今后需要相同的功能。

2. 当钩子(Hook)被触发时，钩子(Hook)处理程序是运行在发起实际调用的进程的进程空间，还是运行在设置钩子(Hook)的进程的进程空间？ 我的意见是它必须在调用例程的进程的进程空间中运行。例如，如果程序从 GDI32.dll 调用 StartDoc()，它会将 Hook 处理过程代码“注入(inject)”到它的空间并执行。否则，将必须在调用进程和设置 Hook 的进程之间自动建立一些进程间通信，但我认为情况并非如此。此外，这个 Hook 处理例程在调用进程的进程空间中运行是必要的，因为它需要知道的一件事是调用进程的名称，而且我不确定如何获取该信息，如果它实际上并没有在那个进程中运行。

3. 如果 Hook 处理例程是使用 .NET 托管环境编写的，当它挂接到一个不使用 .NET 托管环境的进程时会中断吗？我们真的很想在这里离开 C++ 并使用 C#，但是如果我们的钩子(Hook)从不受管理的进程中调用会发生什么？如前所述，我认为我们的钩子(Hook)处理程序将在最初调用被钩子(Hook)例程的进程中运行。但如果这是真的，那么我认为如果此进程未使用 .NET 运行时环境但传入的 Hook 处理代码是，我们会遇到麻烦。

Answer 1

1. 是。

2. 一般来说，它是前者:它在它 Hook 其事件的进程的上下文中执行。

   SetWindowsHookEx调用成功后，操作系统自动将钩子(Hook)DLL(包含回调函数的)注入(inject)所有满足指定钩子(Hook)要求的目标进程的地址空间类型。 (当然， Hook 代码不一定立即注入(inject)。)

   此一般规则的异常(exception)是低级键盘和鼠标 Hook (WH_LL_KEYBOARD 和 WH_LL_MOUSE)。由于这些 Hook 类型未注入(inject)客户端进程，因此在最初调用 SetWindowsHookEx 的同一线程中调用回调。

3. 最后一点对于回答您的第三个问题很重要。由于低级键盘和鼠标 Hook 是仅有的两种不需要 DLL 注入(inject)的全局 Hook ，因此它们也是仅有的两种可以在托管 .NET 代码中编写的 Hook 类型。

   对于其他钩子(Hook)类型，您在问题中表达的担忧是完全正确的。您需要用 C 或 C++ 编写这些 Hook DLL。当然，您的应用程序的其余部分仍然可以用托管语言编写。唯一重要的是 Hook DLL。

您可以考虑查看 Microsoft Detours或 EasyHook .