11、内核钩子技术：Inline Hook原理、Detour技术、函数前/后置处理、多核安全Hook、恢复与卸载
内核钩子，说白了就是“劫持”系统原本的执行流程。你想想看，Windows内核里那么多函数，我们怎么知道某个API被调用了？怎么拦截它？怎么修改它的行为？答案就是——Hook。
我个人习惯把内核钩子分成两大类：一类是修改函数入口的Inline Hook，另一类是利用系统机制的表钩子（比如SSDT Hook）。今天咱们重点聊Inline Hook，这是最底层、最灵活，也是最危险的技术。
11.1 Inline Hook原理：从一条jmp说起
Inline Hook的原理其实很简单。每个函数在内存里都是一段连续的字节码。我们只要把函数开头的几个字节改成jmp MyHandler，CPU执行到这里就会直接跳到我们的代码里。
但这里有个坑——x86和x64下的跳转指令长度不一样。x86下一条jmp是5字节（E9 + 4字节偏移），x64下则需要14字节（FF 25 + 8字节地址）。我刚开始做驱动开发时，在x64上用了5字节跳转，结果系统直接蓝屏。嗯，血的教训。
// x86 Inline Hook 示例（伪代码）
// 目标函数：NtCreateFile
// 我们的处理函数：MyNtCreateFile
// 1. 保存原始字节
UCHAR originalBytes[5];
RtlCopyMemory(originalBytes, NtCreateFile, 5);
// 2. 写入jmp指令
UCHAR jmpCode[5] = {0xE9};
*(ULONG*)(jmpCode + 1) = (ULONG)MyNtCreateFile - (ULONG)NtCreateFile - 5;
// 3. 禁用写保护（CR0 WP位）
// 4. 写入跳转代码
RtlCopyMemory(NtCreateFile, jmpCode, 5);
// 5. 恢复写保护你看，核心代码就这么几行。但实际项目中，远没这么简单。为什么？因为多核、因为同步、因为恢复。
11.2 Detour技术：优雅的跳转与回跳
Detour这个词，直译是“绕路”。在Hook领域，它特指一种更优雅的跳转方式——不是简单地在函数头写jmp，而是把原始指令搬走，留出空间做跳板。
我遇到过这样一个场景：某个函数开头只有3字节，但jmp需要5字节。怎么办？硬写5字节会覆盖后面的指令，导致函数逻辑被破坏。Detour技术就是用来解决这个问题的。
// Detour跳板示例
// 原始函数：NtCreateFile (开头5字节被覆盖)
// 跳板函数：TrampolineNtCreateFile
// 跳板内存布局：
// [被覆盖的5字节原始指令]
// [jmp NtCreateFile + 5] // 跳回原始函数剩余部分
// 我们的处理函数：
NTSTATUS MyNtCreateFile(...)
{
// 前置处理：检查参数、记录日志
KdPrint(("NtCreateFile called, FileName: %wZ\n", ObjectAttributes->ObjectName));
// 调用原始函数（通过跳板）
NTSTATUS status = TrampolineNtCreateFile(...);
// 后置处理：修改返回值、清理
if (NT_SUCCESS(status))
{
KdPrint(("NtCreateFile succeeded\n"));
}
return status;
}说白了，Detour就是造了一个“替身”，让原始函数还能正常工作。我们的处理函数可以自由地做前置/后置处理，然后通过替身调用原始逻辑。
11.3 函数前/后置处理：拦截与篡改的艺术
前置处理和后置处理，是Hook最常用的两种模式。前置处理在原始函数执行前拦截，后置处理在原始函数执行后拦截。
前置处理常用于：参数检查、权限验证、日志记录。比如你想阻止某个文件被创建，在前置处理里判断文件名，直接返回STATUS_ACCESS_DENIED，原始函数根本不会执行。
后置处理常用于：修改返回值、记录结果、清理资源。比如你想隐藏某个进程，在后置处理里把返回的进程列表中的特定条目删掉。
| 处理类型 | 典型用途 | 注意事项 |
|---|---|---|
| 前置处理 | 参数过滤、权限检查、日志 | 不要阻塞太久，会影响系统性能 |
| 后置处理 | 返回值修改、结果记录 | 注意返回值类型，不要越界修改 |
| 前后结合 | 统计耗时、上下文跟踪 | 注意多核下的数据竞争 |
11.4 多核安全Hook：别让蓝屏找上你
多核环境下的Hook，是真正的技术难点。你想想看，当你在CPU0上修改函数入口时，CPU1可能正在执行这个函数。如果CPU1读到了半修改的指令——嗯，蓝屏就在眼前。
我建议的做法是：使用原子操作或中断屏蔽来保证安全。
// 多核安全的Hook安装示例
// 使用InterlockedExchange系列函数
// 1. 先准备好跳转代码
UCHAR jmpCode[5] = {0xE9};
*(ULONG*)(jmpCode + 1) = (ULONG)MyHandler - (ULONG)TargetFunc - 5;
// 2. 逐字节写入（使用原子操作）
for (int i = 0; i < 5; i++)
{
InterlockedExchange8((CHAR*)TargetFunc + i, jmpCode[i]);
}
// 或者使用更激进的方式：中断所有CPU
// KeIpiGenericCall(MyHookCallback, Context);这里有个细节：InterlockedExchange8在x64上可能没有直接支持。我一般用_InterlockedExchange8内建函数，或者干脆用锁内存总线的方式。
还有一种更稳妥的做法：先暂停所有其他CPU的执行（通过IPI中断），然后修改代码，再恢复。但这种方式开销较大，不适合频繁Hook/Unhook的场景。
11.5 恢复与卸载：善始善终
Hook装上去容易，卸下来难。我见过太多驱动卸载时忘记恢复Hook，结果系统直接崩溃的例子。
恢复Hook的核心就是：把之前保存的原始字节写回去。但这里有个问题——如果在你卸载时，其他CPU正在执行你的处理函数怎么办？
// 安全卸载Hook的步骤
// 1. 设置卸载标志
g_Unloading = TRUE;
// 2. 等待所有CPU离开处理函数
KeMemoryBarrier();
KeStallExecutionProcessor(100); // 等待100微秒
// 3. 恢复原始字节
// 再次禁用写保护
RtlCopyMemory(TargetFunc, originalBytes, 5);
// 恢复写保护
// 4. 释放跳板内存
ExFreePool(TrampolineAddr);还有一个容易被忽略的点：如果你Hook的是分页函数（Paged函数），在卸载前必须确保该函数在内存中。否则你恢复时读到的可能是无效数据。
知识体系总览
下面这张图，是我对内核Inline Hook技术的整体理解。你可以把它当作一个思维导图来用。
这张图把Inline Hook的五个核心维度串在了一起。从原理出发，到Detour技术，再到前后置处理，最后落到多核安全和恢复卸载。每个环节都环环相扣，缺一不可。
最后说一句：内核Hook是把双刃剑。用好了，可以实现强大的监控、保护、调试功能；用不好，蓝屏、数据损坏、系统崩溃都是家常便饭。我建议你在测试环境里多练手，把每个细节都吃透，再考虑上生产环境。