关于Detours/Minhook挂钩引擎的UnHook

本文链接：https://blog.csdn.net/xiao_0429/article/details/48573059

本文探讨了Detours和MinHook钩子引擎在UnHook过程中可能遇到的问题，包括Hook链的形成和不正确UnHook顺序导致的潜在风险。分析了多个模块对同一目标函数多次Hook时的UnHook顺序影响，强调任意UnHook可能导致的不稳定性和程序错误。

摘要由CSDN通过智能技术生成

关于Detours/Minhook挂钩引擎的UnHook

文章本身可能用处不大，很少有人会用到所说的这些，权当积累。

一直在使用Detours 和 MinHook 两个Hook引擎进行一些系统API的挂钩，实现特殊的功能。就如标题所用词，UnHook，很少将一个已经Hook的函数再次进行UnHook，所以一直没有注意到问题所在。同事的提醒，让自己有了一点兴趣看一下这个UnHook 到底有什么问题呢?

首先简单说一下Detours / MinHook的基本原理，就是在要挂钩的函数地址处，置一个跳转指令，直接跳转到Detours函数上。然后再由Detours函数通过Trampoline函数（保存的是被Hook函数地址处被置换为JMP指令的原始指令加上一个JMP指令（用于跳转到原始函数））调用原始函数。在依次返回。这样就实现了Detours函数的调用。可以在Detours函数中实现一些特殊的逻辑，满足特殊需求。下面的图是从其他地方借鉴过来的，可以参考一下，非常清晰地说明了整个过程。