简介：这是一套用VS2010编译通过的EasyHook函数钩子完整Demo，面向需要在Windows下拦截API调用的C++开发人员。包内包含Hook.dll动态库与Inject.exe注入程序两部分：前者封装了一套稳定的挂钩机制，只需维护一张函数旧新地址映射表即可批量下钩子；后者基于MFC编写，输入目标进程ID即可完成注入并触发挂钩操作。同时附带了CreateFileW/CreateFileA/ReadFile三个典型API的钩子实现示例，代码结构清晰，注释完整，适合作为学习EasyHook原理或直接在此基础上二次开发的起点。压缩包共36个文件，主要包括11个h头文件、6个cpp源文件、4个dll运行库、2个rc界面资源及vcxproj/sln工程配置等，涉及Hook动态库、InjectHelper注入器、EasyHook依赖库三部分，整体仅278KB，轻量易用。该资源已有2094人浏览学习，是一份实用价值较高的C++钩子参考资料。
1. EasyHook 函数钩子：一个能跑通且能改的 VS2010 C++ 钩子 Demo
有开发者在接手老 C++ 工程时被要求统计某个 API 被谁调用了，翻遍方案最后锁定 EasyHook 函数钩子——一套不需要写驱动的用户态 Hook 库。而这份 VS2010 C++ 版本的完整 Demo，属于那种少见的“打开就能编译、注入就能拦截、改参数就能换目标”的成熟示例，适合刚接触 Hook 方向但不想从零啃汇编跳板的人，也适合要在老工程里快速做 API 审计或调试辅助的开发者。
它的价值不只是演示了 EasyHook 怎么用，而是把注入器、钩子 DLL、日志回传和卸载流程完整串了起来：拿它当骨架，换几个函数名和签名，就是一个可用的调用拦截工具。
2. 工程结构与注入模型：宿主 EXE、钩子 DLL 与 IPC 日志的分工
2.1 Demo 的工程组成和文件职责
这个 Demo 拆成两个工程，而不是一个 exe 干所有事：一个是注入器（承接用户输入的目标进程号和 DLL 路径），一个是钩子 DLL（真正在目标进程里工作的部分）。这个拆分是 EasyHook 场景下的标准做法，因为 Hook 的安装位置和目标进程必须严格分离。
整个目录结构大致是这样的：
| 文件 / 目录 | 作用 |
|---|---|
| HookDemo.sln | VS2010 解决方案，包含 Injector 与 HookDll 两个工程 |
| Injector.cpp | 注入器，负责调用 EasyHook 的远程注入 API |
| HookDll.cpp | 钩子 DLL，在目标进程内部完成 Hook 安装、拦截、卸载 |
| EasyHook.h | EasyHook 非托管 C++ 接口头文件 |
| EasyHook32.lib / EasyHook32.dll | 32 位运行库，Debug / Release 各有一份 |
| TestApp.cpp | 一个极简测试程序，专门用来触发被拦截的 MessageBox 调用 |
为什么不让 Injector 直接去改目标进程内存？因为 EasyHook 的库引导机制要求被注入的模块必须是一个独立 DLL，DLL 加载后由系统执行其初始化，才能在目标进程内安全拿到目标 API 的入口地址。把“注入”和“拦截”放在两个模块里，意味着以后换目标函数只需要改 HookDll，注入器完全不用动。
2.2 EasyHook 的注入模型：进程内安装与远程注入的分工
EasyHook 的思路和传统 Windows 钩子不同。传统 SetWindowsHookEx 依赖消息机制，很多场景下钩子根本不触发；而 EasyHook 走的是“远程线程注入 + 用户态 Inline Hook”路线：注入器把 HookDll.dll 送进目标进程，HookDll 在目标进程内自己修改目标函数的入口代码，插入一条跳转指令指向我们写的替代函数。
整个链路里最关键的分工是：注入器只负责“把 DLL 送进去”，它不直接接触被钩函数；而 HookDll 在 DllMain 之后立刻创建独立线程去执行安装逻辑，避免在 DLL 加载期间做太重的操作。EasyHook 库里已经替你处理了跳板生成、指令修复和线程同步，你只需要关心“钩哪个函数”和“钩完怎么办”。
2.3 数据回传方案：文件日志与共享内存
被拦截的调用发生在目标进程内部，Demo 需要把“谁调用了、参数是什么”传回给外部查看。这里我用了一个最朴素也最不容易出错的方式——日志文件。钩子函数里直接以追加模式写文件，一行一条记录，带上线程号和时间戳。文件日志适合验证阶段，因为查看零成本、不依赖调试器。
如果要实时通知宿主进程，常见做法是用共享内存或者命名管道。EasyHook 本身有 IPC 机制，但在 C++ 场景下反而复杂，因为 IPC 服务端通常需要 CLR 环境配合，VS2010 时代的非托管 C++ 项目没必要为了这个引入托管依赖。共享内存的缺点是并发写需要自己做锁，文件日志加个互斥量就够用了。
3. 核心代码拆解：一个 MessageBox 调用被拦截的完整链路
3.1 入口：注入器如何把钩子 DLL 送进目标进程
注入器是整个 Demo 的起点。它接收两个参数：目标进程 PID 和 HookDll 的路径，然后调用 EasyHook 的 RhInjectLibrary 完成注入。这段代码虽然短，但每个参数都值得讲清楚。
// Injector.cpp：把 HookDll.dll 注入目标进程 #include <windows.h> #include <easyhook.h> int wmain(int argc, wchar_t* argv[]) { if (argc < 3) { wprintf(L"用法: Injector.exe <PID> <HookDll.dll路径>\n"); return 1; } DWORD pid = (DWORD)_wtoi(argv[1]); // 核心注入调用：参数依次是目标PID、唤醒线程ID、注入选项、x86库路径、x64库路径 NTSTATUS status = RhInjectLibrary( pid, // 目标进程 PID 0, // 0 表示让 EasyHook 自行挑选注入线程 EASYHOOK_INJECT_DEFAULT, // 使用默认注入选项 argv[2], // 32 位钩子 DLL 路径 NULL, // 本 Demo 只考虑 32 位目标，64 位路径传 NULL NULL, // 不携带透传数据给 DLL 0, // 透传数据长度 NULL); // 不需要输出注入状态句柄 if (status == 0) // NTSTATUS 中 0 表示 STATUS_SUCCESS { wprintf(L"注入成功，请触发目标进程中的 MessageBoxW 调用\n"); system("pause"); return 0; } wprintf(L"注入失败，错误码 0x%08X\n", (ULONG)status); return -1; }RhInjectLibrary 是 EasyHook C++ 接口里最常被用错的函数。第一次传参时容易把 PID 和线程 ID 搞混：第一个参数是目标进程 PID，第二个参数是“唤醒线程 ID”，传 0 表示让库自己决定。第四个和第五个参数分别对应 32 位和 64 位 DLL 路径，如果目标进程是 32 位，64 位路径传 NULL 即可，反过来也一样。最后两个参数是透传缓冲，钩子 DLL 的入口函数可以从这里收到自定义数据，Demo 里用不到所以传空。
注意 NTSTATUS 返回 0 才是成功，很多刚接触 Windows 内核风格返回值的人会习惯性认为 0 是失败，看反了就会在“注入成功”的情况下误判。这条我当年就栽过。
3.2 安装：钩子 DLL 内的 LhInstallHook 与 ACL
HookDll 被注入目标进程后，DllMain 会收到 DLL_PROCESS_ATTACH。这里不能直接在 DllMain 里调用 LhInstallHook，因为 DllMain 执行期间系统持有加载锁（Loader Lock），EasyHook 内部可能需要加载其他模块，一旦互相等待就死锁了。标准做法是开一条独立线程去做安装。
// HookDll.cpp：在目标进程内部安装 MessageBoxW 钩子 #include <windows.h> #include <easyhook.h> // 定义原函数的真实签名，用于保存函数指针 typedef int (WINAPI *Original_MessageBoxW)(HWND, LPCWSTR, LPCWSTR, UINT); // 保存原始函数地址，钩子里通过它调用不被拦截的版本 Original_MessageBoxW RealMessageBoxW = NULL; // EasyHook 的钩子句柄：安装、卸载、ACL 设置都靠它 TRACED_HOOK_HANDLE g_TraceInfo = { 0 }; // 钩子函数，签名必须与 MessageBoxW 完全一致（稍后详述） int WINAPI MessageBoxWHook(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType); DWORD WINAPI InstallThread(LPVOID) { // 从 user32.dll 导出表里解析 MessageBoxW 的真实入口 HMODULE user32 = GetModuleHandleW(L"user32.dll"); RealMessageBoxW = (Original_MessageBoxW)GetProcAddress(user32, "MessageBoxW"); // 安装钩子：把 MessageBoxW 的入口替换成我们的钩子函数 NTSTATUS status = LhInstallHook( RealMessageBoxW, // 被钩函数入口 MessageBoxWHook, // 替代函数入口 NULL, // 回调参数，不需要 &g_TraceInfo); // 输出钩子句柄 if (status != 0) return (DWORD)status; // 放行所有线程：第一参数 0 表示所有线程，第二参数 0 表示所有进程 status = LhSetInclusiveACL(0, 0, &g_TraceInfo); return (DWORD)status; } BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID) { if (reason == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hModule); // 减少无谓的线程通知 CreateThread(NULL, 0, InstallThread, NULL, 0, NULL); } return TRUE; }LhInstallHook 的四个参数里，最容易踩坑的是第一个：它接收的是被钩函数的内存地址，而不是函数名。所以要先通过 GetProcAddress 把 MessageBoxW 的入口解析出来。这里的 RealMessageBoxW 保存的是“原始入口”，后面钩子函数里调用它才能绕开自己，否则一调用 MessageBoxW 又触发钩子，形成无限递归。
LhSetInclusiveACL 这一步是初学者最容易漏的。如果只调了 LhInstallHook 而不设置 ACL，钩子默认只对安装线程生效，其他线程调用 MessageBoxW 会静默放行，日志文件里什么都看不到。两个参数都传 0 表示“所有进程的所有线程”，这个 Demo 场景下就是要全局拦截。
3.3 拦截与放行：钩子函数签名保持、调用原始函数
钩子函数的实现是整个 Demo 的核心。它接收与 MessageBoxW 完全相同的参数，在函数体里先记录日志，再决定是放行原始调用还是改写参数。这里有一个必须遵守的硬规则：钩子函数必须声明成 noinline，并且调用约定、参数个数、返回值类型要和原函数完全一致，否则栈平衡会被破坏，目标进程直接崩溃。
// 钩子函数：必须和原函数签名一致，且禁止被内联 __declspec(noinline) int WINAPI MessageBoxWHook( HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType) { // 记录调用参数和线程信息到日志文件 FILE* fp = _wfopen(L"C:\\hook_log.txt", L"a, ccs=UTF-8"); if (fp) { fwprintf(fp, L"[Hook] thread=%u caption=%s text=%s type=%u\n", GetCurrentThreadId(), lpCaption, lpText, uType); fclose(fp); } // 放行：调用真实 MessageBoxW，而不是 MessageBoxW 本身，避免递归 return RealMessageBoxW(hWnd, L"被拦截的文本", L"Hooked by Demo", uType); }__declspec(noinline) 为什么这么重要？因为如果编译器把这个函数内联到 InstallThread 里，LhInstallHook 拿到的函数指针可能指向一段被优化过的代码，跳板生成了但行为不稳定，表现出“有时候拦截有时候不拦截”的玄学问题。我一般在钩子工程里直接关闭整个模块的优化，宁可性能差一点也要行为可预测。
这里调用的是 RealMessageBoxW 而不是 MessageBoxW，这个细节决定了你会不会翻车。RealMessageBoxW 是从导出表解析出来的原始入口，它没有被 EasyHook 修改过，所以走它就绕过了钩子；如果你在钩子函数里写 return MessageBoxW(...)，那又一次触发钩子，无休止递归直到栈溢出。
3.4 卸载：LhUninstallHook 与 LhWaitForPendingRemovals 的顺序
卸载钩子比安装更容易出事。正确的顺序是：先 LhUninstallHook 移除跳板，再调用 LhWaitForPendingRemovals 等待所有正在执行钩子函数的线程离开，然后才能 FreeLibrary 卸载 DLL。顺序一旦颠倒，可能某个线程正执行到跳板一半，代码所在的内存已经没了，直接访问违例。
// 从目标进程卸载钩子，必须在进程退出前完成 void UninstallHook() { if (g_TraceInfo.Handle != NULL) { // 第一步：摘除 Hook，原函数的跳板被恢复 LhUninstallHook(&g_TraceInfo); // 第二步：等待还在钩子函数里的线程返回，确保没有 in-flight 调用 LhWaitForPendingRemovals(); // 第三步：清空句柄，防止重复卸载 ZeroMemory(&g_TraceInfo, sizeof(g_TraceInfo)); } }LhWaitForPendingRemovals 这个名字直译就是“等待待移除的钩子完成”。它内部会阻塞调用线程，直到所有正在执行钩子修改区域的线程退出。这一步没有替代品，sleep 不行，轮询也不行，因为线程可能正卡在钩子函数里等某个锁。
4. 编译运行与避坑：VS2010 里从源码到跑通的五个注意点
4.1 编译配置：工程与 EasyHook 库的位数、字符集、优化开关
VS2010 默认生成的是 ANSI 字符集工程，而 EasyHook 的路径相关接口基本都是宽字符，所以第一步就是把两个工程都切到 Unicode 字符集：项目属性 → 配置属性 → 常规 → 字符集 → 使用 Unicode 字符集。不切的话中文字符串传到 MessageBoxW 会因为编码错位显示乱码。
位数匹配是第二个关键点。EasyHook 的 32 位库和 64 位库完全不通用，Demo 工程默认是 Win32 平台，那就必须在 32 位环境下运行：目标进程必须是 32 位，注入器和 HookDll 也必须是 32 位编译出来的。用 64 位注入器去注入 32 位进程，RhInjectLibrary 会返回访问违规之类的错误码，而且错误码本身很有迷惑性，容易被误判成权限问题。
第三个配置项是优化。整个 HookDll 工程建议关掉优化，或者至少把钩子函数所在的文件优化级别调低。VS2010 在 /O2 下可能把钩子函数内联或者调整指令顺序，导致 LhInstallHook 生成跳板时读取到的入口字节不对。这一步属于血泪经验：Release 版本运行不稳定时，先别怀疑 EasyHook，看看是不是优化开了。
4.2 运行步骤：用 TestApp 和日志文件验证全链路
编译通过后，运行流程分三步。先用 Demo 自带的 TestApp.exe 打开一个进程（或者自己写两行 MessageBoxW 的 exe 也行），再从任务管理器记下它的 PID，最后以管理员身份运行注入器。
# 假设 TestApp 的 PID 是 4312，HookDll 在 Release 目录 Injector.exe 4312 "D:\hook_demo\Release\HookDll.dll"注入成功后会提示“注入成功，请触发目标进程中的 MessageBoxW 调用”。这时候去 TestApp 里点按钮触发弹窗，弹窗出来的文本应该是“被拦截的文本”，标题是 “Hooked by Demo”，而不是程序原本设置的文案。同时打开 C:\hook_log.txt，能看到对应的日志记录。如果这两件事都成立，说明从注入、安装、拦截到放行的完整链路全部跑通了。
最后在 TestApp 里正常退出进程，退出时不应该报访问违例。如果报了，把 3.4 节的卸载顺序再对一遍——绝大多数卸载崩溃都是这个原因。
4.3 五条踩坑记录：现象、原因与解决方法
坑一：链接报错 LNK2001，找不到 LhInstallHook 符号。现象是编译没问题，链接阶段报找不到外部符号。原因是工程没有链接 EasyHook 的 lib 文件，或者 lib 的位数与工程平台不一致。解决：项目属性 → 链接器 → 输入 → 附加依赖项，加上 EasyHook32.lib（Win32 平台），并且确认 lib 文件放在工程能找到的路径下。
坑二：注入器返回成功，但日志文件始终为空。现象是 HookDll 已经加载进目标进程，但触发调用后没有任何记录。原因是漏了 LhSetInclusiveACL 这一步，钩子默认只对安装线程生效，而 TestApp 里触发 MessageBox 的线程和安装线程不是同一个。解决：安装后立刻执行 LhSetInclusiveACL(0, 0, &g_TraceInfo) 放行所有线程。
坑三：注入返回 0xC0000022（访问拒绝）。现象是 RhInjectLibrary 返回一个看起来像内存错误的状态码。原因是注入器没有以管理员权限运行，而目标进程是管理员权限启动的。解决：以管理员身份运行命令提示符，再启动注入器。VS2010 的工程默认不带 UAC manifest，生成的 exe 不会自动申请管理员权限，这点和版本无关，是 Windows 权限模型决定的。
坑四：目标进程退出时崩溃。现象是 TestApp 关闭瞬间报 0xC0000005。原因是 DLL 卸载顺序错了：进程退出时系统先释放了 HookDll，但某个线程还停在跳板代码里。解决：在 DLL_PROCESS_DETACH 分支里按“先 LhUninstallHook、再 LhWaitForPendingRemovals、最后返回 TRUE”的顺序执行，确保钩子先摘除再放行 DLL 卸载。
坑五：Release 版本下钩子时灵时不灵。现象是同样的代码 Debug 版本一切正常，切到 Release 就间歇性失效。原因是优化器对钩子函数做了内联，导致安装时的函数入口与跳板预期的入口不一致。解决：给钩子函数加 __declspec(noinline)，并且在工程级别把 Optimization 设为 Disabled（/Od），同时留意 /GL 全程序优化也要关掉。
5. 二次开发实战：换目标函数与多钩子管理的改造套路
5.1 从 MessageBoxW 换到 CreateFileW：入口解析与签名对齐
Demo 跑通的下一步，通常是换成自己真正要监控的 API。替换过程的核心就两件事：从正确的模块里解析入口地址，以及让钩子函数签名与目标函数严格一致。以拦截 CreateFileW 为例，它从 kernel32.dll 导出，签名是七个参数加一个返回值，写起来比 MessageBoxW 长一些，但套路完全一样。
// 把目标函数从 MessageBoxW 替换为 CreateFileW typedef HANDLE (WINAPI *Original_CreateFileW)( LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile); Original_CreateFileW RealCreateFileW = NULL; __declspec(noinline) HANDLE WINAPI CreateFileWHook( LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile) { // 只对 .dat 文件记录日志，避免日志文件爆炸 if (wcsstr(lpFileName, L".dat") != NULL) { LogAccess(lpFileName, dwDesiredAccess); } // 放行到真实函数 return RealCreateFileW(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile); }解析入口时注意，CreateFileW 在 kernel32.dll，所以 GetModuleHandleW(L"kernel32.dll") 再 GetProcAddress。但有个隐藏陷阱：应用层调用 CreateFileW 时，实际路径可能经过 kernelbase.dll 的转发。如果你观察发现钩子偶尔漏记录，不要怀疑变量作用域，去看看调用链是不是经过了 ntdll 的 NtCreateFile。直接钩 NtCreateFile 可以覆盖更底层，但参数结构变成 UNICODE_STRING 和对象属性，复杂度上一个台阶。做 API 审计时我一般先钩上层 API，漏了再下探。
5.2 参数改写与调用计数：让拦截不只是日志
能拦住调用之后，就是 EasyHook 真正有意思的地方：不光是看，还能改。把 MessageBoxWHook 里的放行语句改一下，就能在弹窗内容上做手脚。给日志加上调用计数，还能精确知道某个 API 在程序运行期间被调用了多少次。
// 全局原子计数，多线程环境下保证计数准确 volatile LONG g_callCount = 0; __declspec(noinline) int WINAPI MessageBoxWHook( HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType) { // 每次拦截即累加，用 Interlocked 保证原子性 LONG current = InterlockedIncrement(&g_callCount); wchar_t newText[256]; swprintf_s(newText, L"[第 %d 次调用] 原文本: %s", current, lpText); // 改写参数后再放行，原程序完全感知不到内容被替换了 return RealMessageBoxW(hWnd, newText, L"Hooked", uType); }InterlockedIncrement 比简单的 ++ 安全得多，因为钩子可能被多个线程同时触发，普通自增会被并发打乱。这里改的只是文本内容，实际上你可以用同样的手法改写 dwDesiredAccess 之类的权限参数，比如把 CreateFileW 的写权限悄悄改成只读——这属于 Hook 的常规应用，做沙箱和调试工具的人都懂。
5.3 多钩子管理：用句柄数组统一安装与卸载
真实项目里很少只钩一个 API。如果同时钩 MessageBoxW 和 CreateFileW，就需要维护多个 TRACED_HOOK_HANDLE。把它们放到一个数组里统一管理，安装和卸载都走循环，能少写很多重复代码。
// 定义三个钩子句柄，对应三个目标 API TRACED_HOOK_HANDLE g_Hooks[3] = { 0 }; // 统一安装：循环调用 LhInstallHook for (int i = 0; i < 3; i++) { NTSTATUS status = LhInstallHook( g_entries[i].target, g_entries[i].hookProc, NULL, &g_Hooks[i]); if (status == 0) { LhSetInclusiveACL(0, 0, &g_Hooks[i]); } }用数组管理钩子的好处是卸载也快：一个循环全摘掉，再一个循环 LhWaitForPendingRemovals。注意每个钩子句柄在安装时必须是独立的 TRACED_HOOK_HANDLE，不能复用同一个句柄装两次，否则第二次安装会覆盖掉第一次的信息，卸载时只摘掉一个。
6. 改造后的验证与收尾：把 Demo 变成可复用的 Hook 骨架
6.1 用最小验证清单确认改造没改坏
换完目标函数后，我习惯强制走一遍三组验证，少一步都不放心。第一是确认 DLL 真的进去了，用 Process Explorer 看目标进程加载模块，应该在列表里看到 HookDll.dll 和 EasyHook32.dll。第二是确认日志内容符合预期，触发几次调用后打开日志文件，核对文件名、参数和计数。第三是确认退出不崩溃，连续触发一百次调用再退出进程。
| 验证维度 | 操作 | 预期结果 |
|---|---|---|
| 钩子是否生效 | 触发一次目标 API 调用 | 日志文件新增一行对应记录 |
| 原函数是否被破坏 | 对比回调返回值 | 返回值与未钩时一致 |
| 卸载是否干净 | 结束目标进程 | 无访问违例弹窗，进程正常退出 |
| 多线程是否安全 | 多线程同时触发 | 计数与触发次数一致，无重复记录 |
这套清单看着简单，真能一次全过的不多。最常见的问题恰恰不在钩子本身，而在注入时机——钩子装晚了，前面几次调用没被记录；或者钩子装太早，目标模块还没加载，GetProcAddress 拿到空指针。
6.2 把 Demo 改造成可复用的注入骨架
沿用 Demo 的工程结构，我把注入器和钩子 DLL 之间约定一个透传协议：Injector 通过 PassThruBuffer 把“要钩的函数名 + 模块名 + 日志路径”传给 HookDll，HookDll 根据这份配置动态解析入口，就不用为每个新目标改代码重新编译 DLL 了。这个骨架后来被我反复用了很多次，换目标函数只改配置字符串。
有两点提醒：透传缓冲的格式要自己定义好长度和边界，EasyHook 只负责搬运，不解析内容；另外 HookDll 里解析配置的代码要放在 InstallThread 里，不要放 DllMain 里，原因前面说过，加载锁。从那以后我每拿到一个新版 EasyHook，第一件事就是先把透传骨架的 Release 版本跑一遍，确认注入、拦截、卸载三步全绿，再动手加自己的逻辑。魔鬼都在这些只有跑起来才能暴露的细节里，希望这篇拆解能帮你在 EasyHook 上少走我当年走过的弯路。
本文还有配套的精品资源，点击获取
