0

我有一个应用程序，它执行一堆 API 挂钩到 Win32 目标应用程序（使用 ASIO）来观察目标处理的命名管道流量。它使用 ReadFile 或 WriteFile 调用设置事务的开始，如果调用是同步进行的，则获取该调用的结果。如果调用是异步的，它还会通过到 GetQueuedCompletionStatus 的挂钩来捕获该调用的结束。检索到的数据被发送到我自己的 ASIO 线程池，该线程池为与 Wireshark 的命名管道连接提供服务。它实际上很甜。

一切都很好，除非我必须让程序恢复到原来的状态。取消挂钩功能可以正常工作，除非我强制目标应用程序通过命名管道处理大量请求，否则可以在 GetQueuedCompletionStatus 中无限期阻止现有调用。如果我不等待这些线程解除阻塞，当 GetQueuedCompletionStatus 最终解除阻塞并返回到不再存在的代码洞穴时，我将导致 AV。

我尝试的另一件事是跟踪对 GetQueuedCompletionStatus 的每次调用，并让挂钩函数在 GetQueuedCompletionStatus 的 LpOverlapped 参数与对 PostQueuedCompletionStatus 的相应调用匹配时通知信号。当然，这会解除对所有内容的阻塞，但会严重破坏调用 GetQueuedCompletionStatus 的代码，从而导致 AV。

有谁知道处理这个问题的好方法？如果我可以执行以下操作之一，这将起作用：

  • 使用 ASIO 将忽略的 PostQueuedCompletionStatus 进行调用
  • 捕获 PostQueuedCompletionStatus 进行的虚拟调用并覆盖堆栈中的返回值
  • 创建一个半永久性代码洞，其中包含一个用于挂钩阻塞调用的蹦床，它将函数指针访问器传递给挂钩调用。trampoline 函数将看到，如果该值不为 null，它将改为调用该函数指针，而不是将执行返回给调用者。在解除阻塞调度后，挂钩代码可以将该函数指针设置为 GetQueuedCompletionStatus 的地址，然后我们就能够将正确的调用结果返回给调用者。

第一个选项很简单，但如果能够将此应用程序概括为与其他目标一起使用会很好。第二个很容易，除了我想尽可能安全地编写代码。最后一个可能是可行的，我只是不想用代码洞穴污染外部内存空间。

4

1 回答 1

1

我怀疑是否存在通用且安全的解决方案——除了简单地保持 DLL 加载之外。或者首先避免所有这些钩子......（跳到答案的末尾以获取主要破坏者！）

该论点与我在对问题的评论中所写的内容一致。

要释放 DLL，您必须确保当前没有人在执行 DLL 中的代码，并且没有人会执行 DLL 中的代码（除了执行我们正在讨论的拆卸线程）。

代码可能会在 DLL 中执行，原因有两个，要么我们将要调用它，要么我们将返回它（或返回要返回 DLL 的代码等）。假设我们通过脱钩解决了第一个问题。我们还剩下第二个原因。也许我们已经陷入困境。

你可能会想到做这样的事情：

  1. 分配一个“代码洞穴”来做类似的事情

    PreHookWriteFile:
LOCK INC [ref_count]
POP R15
CALL HookWriteFile
PostHookWriteFile:
LOCK DEC [ref_count]
JMP R15

  2. 将 WriteFile 与JMP [PreHookWriteFile]

  3. 在解除 WriteFile 挂钩的专用线程中执行释放，并等待重新计数归零。然后它释放代码洞穴。

但这样做有两个问题。首先，我们真的没有地方存储原始的退货地址。我们不能把它放在堆栈上，因为HookWriteFile不希望在那里看到它，而且我们不能将它存储在任何非易失性寄存器中，因为我们需要在PostHookWriteFile跳回之前将其恢复，但问题是是我们没有地方存放东西。

其次，释放线程可能会在跳转发生之前注意到减少，并过早释放代码洞穴。

我认为我们尝试变得多么聪明（使用__declspec(naked)函数或通过修改原型）让钩子函数期望堆栈上的原始返回地址并不重要。第二个问题仍然存在 - 您在返回之前减少了引用计数。在您返回之前删除代码是不安全的，但您无法通知您的返回，因为在您返回后您不再可以控制。这正是FreeLibraryAndExitThread创建的原因。

有人可能会想到一些疯狂的事情，比如暂停 DLL 中的所有线程并遍历它们的堆栈以确保 DLL 中没有代码在其中任何一个中，但这只是打开了另一个蠕虫罐。

但也有好消息。

如果您真正想要的是监控命名管道通信，并且您愿意将自己限制在 Windows 8 和更新版本中，那么有一个解决方案更加健壮、文档化和受支持，所需的代码行数要少得多，而且不会造成干扰。Koby Kahane编写了一个文件系统微型过滤器，它正是这样做的。

它的输出是 ETW 事件，您可以在Microsoft 消息分析器或使用来自基于清单的提供程序的 ETW 事件的其他工具之一中查看这些事件。如果您真的需要在 Wireshark 中查看它，您可以编写一个小型 ETW 消费者来消费事件并通过管道将它们发送回 Wireshark。它仍然会比所有这些钩子更容易，而且肯定更安全且不那么混乱。

于 2016-09-29T01:38:03.020 回答