简介一份基于 EasyHook 的函数钩子完整演示程序面向 C 开发者、Windows 系统编程与逆向安全学习者目标是解决如何对系统函数稳定挂钩并快速复用到自己工程中的实际问题。示例由 Hook 动态库与注入程序两部分构成动态库封装了一套完整的挂钩机制使用者在钩子数组中填写函数名和对应的新函数指针即可扩展任意 Win32 函数的钩子无需再修改底层重复代码注入程序是基于 MFC 的对话框界面只要输入目标进程号就能完成注入操作直观整个工程代码风格清晰可在 VS2010 环境下稳定编译。资源共 36 个文件以头文件与 C 源码、DLL 运行库、LIB 导入库及工程配置文件为主包体仅 278KB便于下载与学习。目前已有 2091 人学习下载适合需要为程序增加监控、调试或扩展功能的开发者和希望快速用 EasyHook 做二次封装的技术人员。1. 函数钩子不是黑匣子EasyHook 的完整 Demo 到底能替你省多少事做 Windows 客户端开发的人早晚会撞上一个需求在不改被调试程序源码的前提下去看它内部某个 API 到底被调了几次、传了什么参数。初学者第一反应是往上堆调试断点但等目标程序没有 PDB、或者是个不归你管的老模块时才知道什么叫绝望。EasyHook 这种函数钩子库就是为了这一类场景存在的它能在运行期直接拦截 Win32 乃至任意 native 函数把调用日志、参数快照、返回值全部抓出来。这次拆的是一份基于 VS2010 C 的完整稳定 Demo不是那种只有几个头文件的空壳而是拿来改改就能跑的完整程序。适合正在做逆向分析、插件开发、或者被某位老 C 模块折磨的从业者新手按步骤走也能在半小时内把第一个 Hook 挂上去。2. 选型与原理为什么 EasyHook 比老式 DLL 注入更稳VS2010 版好在哪2.1 钩子机制的三层拆解从 SetWindowsHookEx 到 EasyHook 的绕行Windows 上做钩子最老套的路子是SetWindowsHookEx但它只能钩消息层面的东西比如键盘鼠标、消息队列钩不到CreateFile这种被进程直接调用的导出函数。想要拦住这类函数传统做法是写一个 DLL然后让它注入到目标进程里再自己手工改函数入口处的字节码也就是俗称的 inline hook。这个方案有两个让所有做过的人都皱眉的点一是注入过程本事就很容易被杀软盯上二是你改完别人函数头五个字节得保证自己写的跳转代码足够健壮否则目标函数一被递归调用栈直接给你干碎。EasyHook 的做法是用所谓的 trampoline蹦床机制它在被钩函数开头放一条绝对跳转跳到 EasyHook 自定义的桩函数上同时把原始函数头几条指令原样搬到一片新分配的内存里在那里再补一条跳转回到原函数剩余代码。这样目标进程里别的模块调这个函数时会先踩进钩子里你的回调执行完如果想放行就继续执行搬移后的原始代码整个调用链不丢上下文。中招的概率比手工改字节码小很多因为 trampoline 的生成、参数栈处理、甚至 x64 下的寄存器传参EasyHook 都帮你打点好了。这份 VS2010 C 版 Demo 之所以我觉得值得下是因为它把 EasyHook 的三个典型层都给你铺好了第一层是RemoteHook负责在远程目标进程里安装钩子处理跨进程的注入与通信第二层是HookManager或者版本里对应的管理模块维护钩子句柄、回调地址、被钩函数与 trampoline 的映射关系第三层是具体的 Hook 方法就是你自己写的回调函数签名为int HookProc(...)或类似形式EasyHook 在触发时把原函数参数按约定传进来。这个分层非常重要因为 DebugDemo 里看起来无非是一堆代码但你在自己项目里复用时必须搞清楚哪些是你不能碰的哪些是你必须改的。比如 RemoteHook 的安装方式需要注入 DLL如果你只改了回调内容却忘了适配目标进程位数那照样跑不起来。2.2 这东西到底稳在哪线程级拦截与托管/非托管边界的处理很多人听到 EasyHook 以为它是专门给 .NET 用的其实它是同时支持托管和非托管的库。VS2010 这个老版本里有几个核心机制比后来某些简化版靠谱得多一是线程劫持的命脉——ACL。EasyHook 在安装钩子时不是简单地CreateRemoteThread塞一个 LoadLibrary 进去它用了一种带恢复机制的注入流程。注入线程跑完后目标进程会恢复到正常线程调度不会因为多线程竞争而随机崩。Demo 里Inject的调用参数里有一个RunTime或者是超时配置这就是管这个的。我一般会把它设成 5 秒以上尤其是目标进程在启动早期线程太多、调度太乱时超时太短会直接注入失败。二是它对手动修改机器码的大小做了严格校验。EasyHook 的HookManager在安装钩子时会判断被钩函数头部可替换的指令长度是不是满足最小 5 个字节x86或 12 个字节左右的约束如果函数太短、或者开头是一个跳转表它就会报NtHookManager初始化错误。这个错误早些年特别常见因为新手喜欢钩一些像GetTickCount这种只占几字节的小函数EasyHook 分分钟教你做人。三是托管与非托管的边带处理。EasyHook 在回调触发时会自动帮你把调用方线程的上下文切到可调试状态避免你一边在回调里访问托管堆、一边原始函数还在用非托管栈导致内存碰撞。Demo 里有一个明显的分隔线REMOTE_ENTRY相关代码处理注入和通信HookRoutes或HookProc部分只负责把从钩子处拿到的参数转发出来。这个设计值得学习——它把易错部分锁在库里你能改的部分保持纯 C 接口可读性和稳定性同时保证了。2.3 为什么还要用 VS2010 的老版本既然 EasyHook 有新版为什么还要回头找这份 VS2010 C 版本最现实的一个原因很多遗留项目的主工程还锁在 VS2010编译环境、SDK、第三方库全是老版本的你贸然引入新版 EasyHook 的动态库编译出来的东西动不动就报_MSC_VER冲突或者ntdll.lib链接阶段报一堆unresolved external symbol。这份 Demo 是跟着 VS2010 工程配置走的Platform Toolset 是v100引入库和 DLL 的位数也明确是 32 位还是 64 位省掉你自己来回试错的时间。第二个原因是稳定性边界清楚。新版 EasyHook 加入了更多现代编译器适配和反注入保护但对于只想在本地调试工具上做 API 拦截的人这些新特性反而可能引入兼容性黑匣子。老版本代码路径简单调起来顺出了问题你能按着源码一行行跟进去。我见过某开发者把新版 EasyHook 动态库扔进生产工具结果因为在回调里调了OutputDebugString被目标进程主动拉黑换回老版本反而没事——倒不是说老版本多神而是它的行为模式是多年验证过的。所以我的建议是如果你是接手了一个老工程目标程序也是 x86 或 x64 的老模块直接用这份 VS2010 Demo 做底子最合适如果你是从零起步做新项目也可以先拿它搞明白机制再决定要不要换新版。3. 把 Demo 跑起来VS2010 下的编译、注册、注入三步走3.1 工程结构与关键文件解压后你会看到几个工程文件和文件夹布局大同小异。典型结构有EasyHook.sln主解决方案文件双击就能在 VS2010 里打开。DemoClient被注入的目标进程示例。它往往是一个简单对话框或控制台程序里面会调用MessageBox、CreateFile或某个自定义导出函数用来证明钩子确实生效。DemoInjector负责把钩子 DLL 注入目标进程的模块。它本身也是个可执行程序接受目标进程名或进程 ID 作为参数。DemoHookDll包含实际钩子回调的 DLL。这里面的HookProc就是你在钩子触发时要执行的业务逻辑。其他像EasyHook32.dll、EasyHook64.dll以及EasyHook.lib是库本身。先打开解决方案确认每个工程左边的项目图标有没有被 VS 正确识别。如果显示为“不可用”右键选 Reload Project。最容易出的坑是路径里有中文或空格尤其是路径中的“测试”这类目录导致#include查找失败。我一般会先把整个包复制到D:\EasyHookDemo\这种纯英文路径下再解压。3.2 编译顺序和配置选项编译顺序很关键。先编译 EasyHook 基础库通常会被标记为EasyHook32或EasyHook64再编译DemoHookDll最后编译DemoInjector和DemoClient。如果直接按解决方案里从上到下的顺序按 F7有时候会因为DemoHookDll依赖的 lib 文件还没生成而报找不到EasyHook.lib。遇到这种情况不用慌单独右键基础库工程重新生成一次。VS2010 的编译环境要记得设置这几个选项我按自己在两台机器上跑过的经验说在项目属性的C/C - Code Generation里Runtime Library建议保持/MTdDebug或/MTRelease而不要用/MDd或/MD。因为被注入目标进程可能本身是静态链接 CRT 的你用动态 CRT回调里调用fopen时会因为 CRT 句柄表不一致踩到多重初始化问题。这个坑非常隐蔽表现出来就是回调第一次执行正常第二次就崩溃。在C/C - Preprocessor里确保定义了WIN32和_DEBUG之类的基本宏如果找不到用默认配置即可但注意不要把 EasyHook 自带的宏覆盖掉。在Linker - General里Additional Library Directories要指向包含EasyHook.lib的目录Linker - Input里要明确写上EasyHook.lib否则你会遇到LNK2019无法解析的外部符号。编译成功后把生成的EasyHook32.dll或EasyHook64.dll放到最终的输出目录里最好和DemoHookDll.dll放一起因为注入时会加载同一目录下的 DLL。3.3 第一个能跑的注入实验启动DemoClient假设它的进程名是DemoClient.exe。这时候先别急着注入打开任务管理器确认目标进程的位数如果它是 32 位则必须使用 32 位版本的DemoInjector如果是 64 位则要编译并运行 x64 配置下的DemoInjector。位数不匹配是最容易忽略的第一大坑报错通常是Access is denied或莫名其妙的File not found。然后在命令行里执行注入命令DemoInjector.exe -p DemoClient.exe -h DemoHookDll.dll这里-p指定目标进程名-h指定钩子 DLL 的路径。如果你想用进程 ID也可以用-pid 1234之类的参数具体格式看DemoInjector的源码里ParseCommandLine函数。执行后观察DemoClient里是否弹出了日志输出窗口或者在DemoHookDll里用OutputDebugString写出的调试信息是否在 Debug View 里可见。如果钩子没触发先回到DemoClient源码里找到它真正调用的那个函数。// 在 DemoClient 中比如有一处调用是被钩目标 ::MessageBoxW(NULL, LHello EasyHook, LDemo, MB_OK);而DemoHookDll里的回调应该是这样// 钩子回调拦截 MessageBoxW int __stdcall HookedMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType) { // 这里已经把参数抓到了 OutputDebugStringW(lpText); // 放行原始调用 return RealMessageBoxW(hWnd, L hooked! , lpCaption, uType); }这个回调对应的 trampoline 指针RealMessageBoxW是 EasyHook 在你安装钩子时自动填充的。你只修改lpText其他参数原样放行这就证明钩子已经跑在目标进程内。值得注意的参数说明__stdcall不能省略因为你钩的是 Win32 API调用约定必须是__stdcall或对应类型否则栈平衡不对必崩。我第一次跑这个 Demo 时卡在-h参数给了相对路径导致 DLL 没被加载。后来改成绝对路径就通了。如果你的钩子总是不生效先看注入器输出有没有Successfully injected字样有的话再检查目标进程是不是真的把这个 call 走到了你钩的函数上。有的函数在版本更新后系统里实际调用的是MessageBoxW的底层实现钩在导出层就无效这时候需要换一个更底层的NtUserMessageBox之类的但这不是本 Demo 的问题看你的目标而定。4. 核心参数与接口说明怎么把钩子改造成自己业务要的样子4.1 入口函数与安装参数Demo 里最核心的安装代码是InstallHook不同的版本叫法可能不一样它的典型签名和参数如下bool InstallHook( const wchar_t* targetProcessName, const wchar_t* hookDllPath, const wchar_t* hookFunctionName, void* originalFunctionPtr, void* callbackPtr, void** trampolinePtr);这段代码是承接上层指令和底层注入的关键。关键参数逐一说targetProcessName目标进程名必须带扩展名例如LDemoClient.exe。不要传全路径EasyHook 内部会通过快照查找进程传全路径反而可能因为权限不足找不到。hookDllPath指向你的钩子 DLL 所在路径刚才强调过要用绝对路径。hookFunctionName你打算钩哪个导出函数名比如MessageBoxW。originalFunctionPtr目标进程里那个函数的真实地址。Demo 里通常用GetProcAddress(GetModuleHandleW(Luser32.dll), MessageBoxW)来获取。callbackPtr你自己写的回调函数指针必须和原函数有相同的调用约定。trampolinePtr出参。EasyHook 会在这里返回一个可以调用的原始函数指针你的回调里如果要放行原始逻辑就调用它。安装钩子后别忘了对应使用UninstallHook或Unhook来复原。Demo 里通常会写一个挂钩的 CPluginDlg 或线程来管理钩子生命周期。如果你不恢复进程退出时 EasyHook 会帮你清理但如果你在一个会频繁创建销毁的进程里反复安装卸除建议主动调Unhook避免 trampoline 内存泄漏。4.2 文件、网络、注册表等常见拦截点的配置方法把 Demo 改成实际业务用的钩子难点不在 EasyHook 本身而是选好钩的地址和回调要处理的参数。这里分享我拆过几个项目的经验文件操作钩CreateFileW或ReadFile重点是拿到lpFileName和dwDesiredAccess。在回调里不要直接做重活因为目标进程可能正处于文件加锁状态。我曾看到一个做法是在回调里把文件名写到一个共享内存队列再由外部监控线程去分析这样可以避免因为你的fopen造成文件句柄冲突。网络请求钩send/recv或者WSAConnect。注意ws2_32.dll里的导出函数在 Windows 8 以后有些被KernelBase.dll转发GetProcAddress时要考虑转发函数的情况否则拿到的地址可能不是实际执行体钩子不生效。另一个常见问题是你钩send的回调会被频繁调用如果它在回调里分配内存、格式化字符串性能会急剧下降。要提前设置一个高频调用检测比如每秒最多处理多少条否则在高吞吐服务器上会拖垮目标进程。注册表钩RegOpenKeyExW或RegQueryValueExW这类回调相对低频但要注意HKEY句柄的访问。有一些程序会用RegOpenKeyEx探测是否存在某个键然后根据返回值决定行为。你可以在回调里模拟存在或不存在但别在回调里调用 Reg 系列函数会造成递归钩子。如果确实需要查询原始数据使用 trampoline 指针去调用原始函数。4.3 返回值、错误码与回调内的异常处理回调函数的返回值语义必须和原函数完全一致。打个比方如果你钩MessageBoxW原函数返回的是int表示点击了哪个按钮你回调里如果不小心把它写成了void编译器不会报错但运行时栈上返回值的位置会被后续逻辑误读轻则按钮行为错乱重则内存访问越界。所以我的习惯是先从函数头文件里复制原始声明再做两个改造把函数名改成Hooked...把末尾加一个Real...指针参数。EasyHook 在回调里如果抛出了 C 异常未捕获它会尝试捕获并包装成错误码返回但这不代表安全因为 C 异常跨过 trampoline 的边界后原始函数的栈帧可能已经被破坏。最好的办法是回调里用try/catch包住所有可能出错的代码尤其不要catch(...)完还不处理直接把异常吞掉——那样你可能永远不知道钩子已经失效了。// 一个安全的回调骨架 int __stdcall HookedSend(SOCKET s, const char* buf, int len, int flags) { int ret SOCKET_ERROR; try { SendLog(s, buf, len); // 你的业务逻辑 ret RealSend(s, buf, len, flags); // 放行原逻辑 } catch (...) { // 记录错误但不要再次触发钩子 OutputDebugStringA(send hook exception); } return ret; }参数说明RealSend是 EasyHook 填充的 trampoline 函数指针。在 try 块里先做业务再放行原调用这个顺序不能反因为如果原调用先执行了你的回调再抛异常目标进程可能已经开始处理网络事件了。另外buf指针指向的数据块在回调返回后可能会被释放所以如果你需要异步记录数据要拷贝一份而不是保存指针。5. 避坑与常见问题钩子不生效、崩溃、权限不足的 5 条血泪记录5.1 注入总是失败返回 Access is denied现象DemoInjector 执行后输出提示OpenProcess失败或注入超时查看 Windows 事件日志没有明显错误。原因目标进程权限比你的注入器高常见的要么是管理员进程要么是正在被调试器附着的进程。EasyHook 的注入需要以相同的完整性级别打开目标进程否则OpenProcess(PROCESS_ALL_ACCESS)直接失败。解决用管理员身份运行你的注入器。最好是 VS2010 也启动管理员权限这样调试时能直接命中。如果目标进程是系统服务你要先获得 SeDebugPrivilege 权限。Demo 源码里通常没加你需要自己加一段提升权限的辅助代码// 启用 SeDebugPrivilege HANDLE hToken; if (OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, hToken)) { TOKEN_PRIVILEGES tp; LookupPrivilegeValue(NULL, SE_DEBUG_NAME, tp.Privileges[0].Luid); tp.PrivilegeCount 1; tp.Privileges[0].Attributes SE_PRIVILEGE_ENABLED; AdjustTokenPrivileges(hToken, FALSE, tp, 0, NULL, 0); CloseHandle(hToken); }这段代码之后再用 DemoInjector 去注入高权限进程成功率会高很多。5.2 钩子看着装上了但回调一次都不触发现象InstallHook返回成功注入也显示成功但目标进程行为完全没有变化。原因之一钩错了函数地址。有些 Win32 API 在不同进程中是被动态转发或延迟加载的GetProcAddress拿到的可能是一个条形桩函数shim而不是实际的函数体。原因之二目标进程的对应 DLL 还没加载GetModuleHandle返回 NULL导致GetProcAddress失败或拿到错误地址。解决在安装钩子前先强制加载目标 DLL。以CreateFileW为例你可以先在你的注入器进程里加载一次kernelbase.dll获取地址然后通过 EasyHook 的GetHookFunctionAddress之类的辅助函数读取目标进程的同名函数地址。或者干脆把GetProcAddress的调用放在注入 DLL 的 DllMain 里这样能确认 DLL 确实加载了。更实用的做法是把预期函数地址打印出来与目标进程里用调试器读取的地址对比看看是否一致。5.3 回调执行几次后进程崩溃栈显示离奇的地址现象第一次 Hook 生效第二次调用时目标进程直接异常退出用调试器看是内存访问违例。原因极可能是 trampoline 内存保护页设置有问题或者是回调函数里用了与原始函数不一致的调用约定导致栈不平衡。我就遇到过某开发者把被钩函数声明成__cdecl而实际 API 是__stdcall前几个参数刚好碰巧能传对到第四个参数时栈顶偏了直接崩。解决严格核对函数原型。用def文件或 MSDN 上的声明复制粘贴不要凭记忆手写。如果检查了签名没问题就要考虑是否回调中调用了目标进程尚未加载、或被重定向的 CRT 函数。回调中尽量只做参数记录不做动态字符串操作确实需要时用StringCbPrintfA并用固定缓冲区。5.4 注入后目标进程出现白色窗口或者 UI 失去响应现象目标进程没有崩但界面卡住任务管理器显示 CPU 占用为 0看起来像死锁。原因EasyHook 在安装钩子时会挂起目标进程的所有线程等 trampoline 生成完毕后恢复。如果有一个线程恰好停在某个同步对象上而该同步对象的释放逻辑就在你要钩的函数内部那么注入线程与业务线程会互相等待形成死锁。这个坑在高频调用同步区域的函数时特别明显。解决不要在目标进程临启动时立刻注入等它完全启动后再试。还有一种方案是安装钩子时设置额外的超时参数让 EasyHook 在挂起线程前先尝试获取线程上下文。如果程序里存在进程内通信锁最好在注入前通过共享内存发出一个“请暂停业务处理”的信号然后再安装钩子完成后恢复业务。5.5 同一函数在 32 位和 64 位下表现不一致现象同一个HookProc用 32 位 DemoInjector 注入 32 位进程没问题换到 64 位进程后回调能触发但参数错位字符串打印出来是乱码。原因x64 下函数的传参约定与 x86 完全不同x64 使用rcx,rdx,r8,r9和栈混合传参。如果工程里默认编译的是 x86 的钩子 DLL而目标进程是 x64那么回调被调用时EasyHook 把栈上的参数按 x86 格式拿到再按 x64 格式解释数据错位是必然。解决一定要为 x64 目标单独编译一份 x64 版本的钩子 DLL 和注入器。Demo 源码里通常在解决方案配置管理器上有Win32和x64两个配置记得右键配置管理器新建一个 x64 平台而不是直接在工具栏上切平台。因为工程文件里的库依赖和输出路径都可能不一样直接切平台会导致链接到旧库。另一个易错点是#pragma comment(lib, EasyHook.lib)在不同配置下要指向对应的 32 或 64 位 lib如果有条件可以把库统一复制为EasyHook32.lib和EasyHook64.lib避免混淆。6. 进阶技巧用日志把钩子行为变成可回放的调试证据钩子装上、回调能跑这只是第一步。真正让人头疼的是目标进程出问题时你怎么把当时的调用现场还原出来。我的建议是把 Demo 里的日志模块改造成三个级别普通日志、详细参数日志、内存快照日志。普通日志记录函数名、线程 ID、时间戳详细参数日志把各参数展开比如字符串内容、缓冲区大小内存快照日志在关键数据块被释放前复制一份到独立文件。实现时不要直接在回调里写磁盘因为目标进程的 I/O 路径可能被重定向或占满。常见做法是开一块共享内存环形缓冲区回调只负责往缓冲区里写数据外部监控进程用ReadFile或 Memory Mapped File 读取并落盘。这样可以避免钩子对目标进程造成 I/O 影响也能保证高频调用下不遗漏记录。另外一个很实用的技巧是用OutputDebugString配合调试器过滤但不建议长期开。因为我踩过一个坑目标进程如果有反调试策略它会禁用调试输出通道导致你的记录全部丢失还不敢报错。从那以后我每次做钩子项目都会强制走一遍完整流程先跑通 Demo 的原始安装再钩一个低频测试函数验证回调确认稳定后再换到真正要跟踪的高频函数并且所有业务日志都通过共享内存输出。希望这个流程帮到你少走那些黑匣子一样的弯路。本文还有配套的精品资源点击获取
简介一份基于 EasyHook 的函数钩子完整演示程序面向 C 开发者、Windows 系统编程与逆向安全学习者目标是解决如何对系统函数稳定挂钩并快速复用到自己工程中的实际问题。示例由 Hook 动态库与注入程序两部分构成动态库封装了一套完整的挂钩机制使用者在钩子数组中填写函数名和对应的新函数指针即可扩展任意 Win32 函数的钩子无需再修改底层重复代码注入程序是基于 MFC 的对话框界面只要输入目标进程号就能完成注入操作直观整个工程代码风格清晰可在 VS2010 环境下稳定编译。资源共 36 个文件以头文件与 C 源码、DLL 运行库、LIB 导入库及工程配置文件为主包体仅 278KB便于下载与学习。目前已有 2091 人学习下载适合需要为程序增加监控、调试或扩展功能的开发者和希望快速用 EasyHook 做二次封装的技术人员。1. 函数钩子不是黑匣子EasyHook 的完整 Demo 到底能替你省多少事做 Windows 客户端开发的人早晚会撞上一个需求在不改被调试程序源码的前提下去看它内部某个 API 到底被调了几次、传了什么参数。初学者第一反应是往上堆调试断点但等目标程序没有 PDB、或者是个不归你管的老模块时才知道什么叫绝望。EasyHook 这种函数钩子库就是为了这一类场景存在的它能在运行期直接拦截 Win32 乃至任意 native 函数把调用日志、参数快照、返回值全部抓出来。这次拆的是一份基于 VS2010 C 的完整稳定 Demo不是那种只有几个头文件的空壳而是拿来改改就能跑的完整程序。适合正在做逆向分析、插件开发、或者被某位老 C 模块折磨的从业者新手按步骤走也能在半小时内把第一个 Hook 挂上去。2. 选型与原理为什么 EasyHook 比老式 DLL 注入更稳VS2010 版好在哪2.1 钩子机制的三层拆解从 SetWindowsHookEx 到 EasyHook 的绕行Windows 上做钩子最老套的路子是SetWindowsHookEx但它只能钩消息层面的东西比如键盘鼠标、消息队列钩不到CreateFile这种被进程直接调用的导出函数。想要拦住这类函数传统做法是写一个 DLL然后让它注入到目标进程里再自己手工改函数入口处的字节码也就是俗称的 inline hook。这个方案有两个让所有做过的人都皱眉的点一是注入过程本事就很容易被杀软盯上二是你改完别人函数头五个字节得保证自己写的跳转代码足够健壮否则目标函数一被递归调用栈直接给你干碎。EasyHook 的做法是用所谓的 trampoline蹦床机制它在被钩函数开头放一条绝对跳转跳到 EasyHook 自定义的桩函数上同时把原始函数头几条指令原样搬到一片新分配的内存里在那里再补一条跳转回到原函数剩余代码。这样目标进程里别的模块调这个函数时会先踩进钩子里你的回调执行完如果想放行就继续执行搬移后的原始代码整个调用链不丢上下文。中招的概率比手工改字节码小很多因为 trampoline 的生成、参数栈处理、甚至 x64 下的寄存器传参EasyHook 都帮你打点好了。这份 VS2010 C 版 Demo 之所以我觉得值得下是因为它把 EasyHook 的三个典型层都给你铺好了第一层是RemoteHook负责在远程目标进程里安装钩子处理跨进程的注入与通信第二层是HookManager或者版本里对应的管理模块维护钩子句柄、回调地址、被钩函数与 trampoline 的映射关系第三层是具体的 Hook 方法就是你自己写的回调函数签名为int HookProc(...)或类似形式EasyHook 在触发时把原函数参数按约定传进来。这个分层非常重要因为 DebugDemo 里看起来无非是一堆代码但你在自己项目里复用时必须搞清楚哪些是你不能碰的哪些是你必须改的。比如 RemoteHook 的安装方式需要注入 DLL如果你只改了回调内容却忘了适配目标进程位数那照样跑不起来。2.2 这东西到底稳在哪线程级拦截与托管/非托管边界的处理很多人听到 EasyHook 以为它是专门给 .NET 用的其实它是同时支持托管和非托管的库。VS2010 这个老版本里有几个核心机制比后来某些简化版靠谱得多一是线程劫持的命脉——ACL。EasyHook 在安装钩子时不是简单地CreateRemoteThread塞一个 LoadLibrary 进去它用了一种带恢复机制的注入流程。注入线程跑完后目标进程会恢复到正常线程调度不会因为多线程竞争而随机崩。Demo 里Inject的调用参数里有一个RunTime或者是超时配置这就是管这个的。我一般会把它设成 5 秒以上尤其是目标进程在启动早期线程太多、调度太乱时超时太短会直接注入失败。二是它对手动修改机器码的大小做了严格校验。EasyHook 的HookManager在安装钩子时会判断被钩函数头部可替换的指令长度是不是满足最小 5 个字节x86或 12 个字节左右的约束如果函数太短、或者开头是一个跳转表它就会报NtHookManager初始化错误。这个错误早些年特别常见因为新手喜欢钩一些像GetTickCount这种只占几字节的小函数EasyHook 分分钟教你做人。三是托管与非托管的边带处理。EasyHook 在回调触发时会自动帮你把调用方线程的上下文切到可调试状态避免你一边在回调里访问托管堆、一边原始函数还在用非托管栈导致内存碰撞。Demo 里有一个明显的分隔线REMOTE_ENTRY相关代码处理注入和通信HookRoutes或HookProc部分只负责把从钩子处拿到的参数转发出来。这个设计值得学习——它把易错部分锁在库里你能改的部分保持纯 C 接口可读性和稳定性同时保证了。2.3 为什么还要用 VS2010 的老版本既然 EasyHook 有新版为什么还要回头找这份 VS2010 C 版本最现实的一个原因很多遗留项目的主工程还锁在 VS2010编译环境、SDK、第三方库全是老版本的你贸然引入新版 EasyHook 的动态库编译出来的东西动不动就报_MSC_VER冲突或者ntdll.lib链接阶段报一堆unresolved external symbol。这份 Demo 是跟着 VS2010 工程配置走的Platform Toolset 是v100引入库和 DLL 的位数也明确是 32 位还是 64 位省掉你自己来回试错的时间。第二个原因是稳定性边界清楚。新版 EasyHook 加入了更多现代编译器适配和反注入保护但对于只想在本地调试工具上做 API 拦截的人这些新特性反而可能引入兼容性黑匣子。老版本代码路径简单调起来顺出了问题你能按着源码一行行跟进去。我见过某开发者把新版 EasyHook 动态库扔进生产工具结果因为在回调里调了OutputDebugString被目标进程主动拉黑换回老版本反而没事——倒不是说老版本多神而是它的行为模式是多年验证过的。所以我的建议是如果你是接手了一个老工程目标程序也是 x86 或 x64 的老模块直接用这份 VS2010 Demo 做底子最合适如果你是从零起步做新项目也可以先拿它搞明白机制再决定要不要换新版。3. 把 Demo 跑起来VS2010 下的编译、注册、注入三步走3.1 工程结构与关键文件解压后你会看到几个工程文件和文件夹布局大同小异。典型结构有EasyHook.sln主解决方案文件双击就能在 VS2010 里打开。DemoClient被注入的目标进程示例。它往往是一个简单对话框或控制台程序里面会调用MessageBox、CreateFile或某个自定义导出函数用来证明钩子确实生效。DemoInjector负责把钩子 DLL 注入目标进程的模块。它本身也是个可执行程序接受目标进程名或进程 ID 作为参数。DemoHookDll包含实际钩子回调的 DLL。这里面的HookProc就是你在钩子触发时要执行的业务逻辑。其他像EasyHook32.dll、EasyHook64.dll以及EasyHook.lib是库本身。先打开解决方案确认每个工程左边的项目图标有没有被 VS 正确识别。如果显示为“不可用”右键选 Reload Project。最容易出的坑是路径里有中文或空格尤其是路径中的“测试”这类目录导致#include查找失败。我一般会先把整个包复制到D:\EasyHookDemo\这种纯英文路径下再解压。3.2 编译顺序和配置选项编译顺序很关键。先编译 EasyHook 基础库通常会被标记为EasyHook32或EasyHook64再编译DemoHookDll最后编译DemoInjector和DemoClient。如果直接按解决方案里从上到下的顺序按 F7有时候会因为DemoHookDll依赖的 lib 文件还没生成而报找不到EasyHook.lib。遇到这种情况不用慌单独右键基础库工程重新生成一次。VS2010 的编译环境要记得设置这几个选项我按自己在两台机器上跑过的经验说在项目属性的C/C - Code Generation里Runtime Library建议保持/MTdDebug或/MTRelease而不要用/MDd或/MD。因为被注入目标进程可能本身是静态链接 CRT 的你用动态 CRT回调里调用fopen时会因为 CRT 句柄表不一致踩到多重初始化问题。这个坑非常隐蔽表现出来就是回调第一次执行正常第二次就崩溃。在C/C - Preprocessor里确保定义了WIN32和_DEBUG之类的基本宏如果找不到用默认配置即可但注意不要把 EasyHook 自带的宏覆盖掉。在Linker - General里Additional Library Directories要指向包含EasyHook.lib的目录Linker - Input里要明确写上EasyHook.lib否则你会遇到LNK2019无法解析的外部符号。编译成功后把生成的EasyHook32.dll或EasyHook64.dll放到最终的输出目录里最好和DemoHookDll.dll放一起因为注入时会加载同一目录下的 DLL。3.3 第一个能跑的注入实验启动DemoClient假设它的进程名是DemoClient.exe。这时候先别急着注入打开任务管理器确认目标进程的位数如果它是 32 位则必须使用 32 位版本的DemoInjector如果是 64 位则要编译并运行 x64 配置下的DemoInjector。位数不匹配是最容易忽略的第一大坑报错通常是Access is denied或莫名其妙的File not found。然后在命令行里执行注入命令DemoInjector.exe -p DemoClient.exe -h DemoHookDll.dll这里-p指定目标进程名-h指定钩子 DLL 的路径。如果你想用进程 ID也可以用-pid 1234之类的参数具体格式看DemoInjector的源码里ParseCommandLine函数。执行后观察DemoClient里是否弹出了日志输出窗口或者在DemoHookDll里用OutputDebugString写出的调试信息是否在 Debug View 里可见。如果钩子没触发先回到DemoClient源码里找到它真正调用的那个函数。// 在 DemoClient 中比如有一处调用是被钩目标 ::MessageBoxW(NULL, LHello EasyHook, LDemo, MB_OK);而DemoHookDll里的回调应该是这样// 钩子回调拦截 MessageBoxW int __stdcall HookedMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType) { // 这里已经把参数抓到了 OutputDebugStringW(lpText); // 放行原始调用 return RealMessageBoxW(hWnd, L hooked! , lpCaption, uType); }这个回调对应的 trampoline 指针RealMessageBoxW是 EasyHook 在你安装钩子时自动填充的。你只修改lpText其他参数原样放行这就证明钩子已经跑在目标进程内。值得注意的参数说明__stdcall不能省略因为你钩的是 Win32 API调用约定必须是__stdcall或对应类型否则栈平衡不对必崩。我第一次跑这个 Demo 时卡在-h参数给了相对路径导致 DLL 没被加载。后来改成绝对路径就通了。如果你的钩子总是不生效先看注入器输出有没有Successfully injected字样有的话再检查目标进程是不是真的把这个 call 走到了你钩的函数上。有的函数在版本更新后系统里实际调用的是MessageBoxW的底层实现钩在导出层就无效这时候需要换一个更底层的NtUserMessageBox之类的但这不是本 Demo 的问题看你的目标而定。4. 核心参数与接口说明怎么把钩子改造成自己业务要的样子4.1 入口函数与安装参数Demo 里最核心的安装代码是InstallHook不同的版本叫法可能不一样它的典型签名和参数如下bool InstallHook( const wchar_t* targetProcessName, const wchar_t* hookDllPath, const wchar_t* hookFunctionName, void* originalFunctionPtr, void* callbackPtr, void** trampolinePtr);这段代码是承接上层指令和底层注入的关键。关键参数逐一说targetProcessName目标进程名必须带扩展名例如LDemoClient.exe。不要传全路径EasyHook 内部会通过快照查找进程传全路径反而可能因为权限不足找不到。hookDllPath指向你的钩子 DLL 所在路径刚才强调过要用绝对路径。hookFunctionName你打算钩哪个导出函数名比如MessageBoxW。originalFunctionPtr目标进程里那个函数的真实地址。Demo 里通常用GetProcAddress(GetModuleHandleW(Luser32.dll), MessageBoxW)来获取。callbackPtr你自己写的回调函数指针必须和原函数有相同的调用约定。trampolinePtr出参。EasyHook 会在这里返回一个可以调用的原始函数指针你的回调里如果要放行原始逻辑就调用它。安装钩子后别忘了对应使用UninstallHook或Unhook来复原。Demo 里通常会写一个挂钩的 CPluginDlg 或线程来管理钩子生命周期。如果你不恢复进程退出时 EasyHook 会帮你清理但如果你在一个会频繁创建销毁的进程里反复安装卸除建议主动调Unhook避免 trampoline 内存泄漏。4.2 文件、网络、注册表等常见拦截点的配置方法把 Demo 改成实际业务用的钩子难点不在 EasyHook 本身而是选好钩的地址和回调要处理的参数。这里分享我拆过几个项目的经验文件操作钩CreateFileW或ReadFile重点是拿到lpFileName和dwDesiredAccess。在回调里不要直接做重活因为目标进程可能正处于文件加锁状态。我曾看到一个做法是在回调里把文件名写到一个共享内存队列再由外部监控线程去分析这样可以避免因为你的fopen造成文件句柄冲突。网络请求钩send/recv或者WSAConnect。注意ws2_32.dll里的导出函数在 Windows 8 以后有些被KernelBase.dll转发GetProcAddress时要考虑转发函数的情况否则拿到的地址可能不是实际执行体钩子不生效。另一个常见问题是你钩send的回调会被频繁调用如果它在回调里分配内存、格式化字符串性能会急剧下降。要提前设置一个高频调用检测比如每秒最多处理多少条否则在高吞吐服务器上会拖垮目标进程。注册表钩RegOpenKeyExW或RegQueryValueExW这类回调相对低频但要注意HKEY句柄的访问。有一些程序会用RegOpenKeyEx探测是否存在某个键然后根据返回值决定行为。你可以在回调里模拟存在或不存在但别在回调里调用 Reg 系列函数会造成递归钩子。如果确实需要查询原始数据使用 trampoline 指针去调用原始函数。4.3 返回值、错误码与回调内的异常处理回调函数的返回值语义必须和原函数完全一致。打个比方如果你钩MessageBoxW原函数返回的是int表示点击了哪个按钮你回调里如果不小心把它写成了void编译器不会报错但运行时栈上返回值的位置会被后续逻辑误读轻则按钮行为错乱重则内存访问越界。所以我的习惯是先从函数头文件里复制原始声明再做两个改造把函数名改成Hooked...把末尾加一个Real...指针参数。EasyHook 在回调里如果抛出了 C 异常未捕获它会尝试捕获并包装成错误码返回但这不代表安全因为 C 异常跨过 trampoline 的边界后原始函数的栈帧可能已经被破坏。最好的办法是回调里用try/catch包住所有可能出错的代码尤其不要catch(...)完还不处理直接把异常吞掉——那样你可能永远不知道钩子已经失效了。// 一个安全的回调骨架 int __stdcall HookedSend(SOCKET s, const char* buf, int len, int flags) { int ret SOCKET_ERROR; try { SendLog(s, buf, len); // 你的业务逻辑 ret RealSend(s, buf, len, flags); // 放行原逻辑 } catch (...) { // 记录错误但不要再次触发钩子 OutputDebugStringA(send hook exception); } return ret; }参数说明RealSend是 EasyHook 填充的 trampoline 函数指针。在 try 块里先做业务再放行原调用这个顺序不能反因为如果原调用先执行了你的回调再抛异常目标进程可能已经开始处理网络事件了。另外buf指针指向的数据块在回调返回后可能会被释放所以如果你需要异步记录数据要拷贝一份而不是保存指针。5. 避坑与常见问题钩子不生效、崩溃、权限不足的 5 条血泪记录5.1 注入总是失败返回 Access is denied现象DemoInjector 执行后输出提示OpenProcess失败或注入超时查看 Windows 事件日志没有明显错误。原因目标进程权限比你的注入器高常见的要么是管理员进程要么是正在被调试器附着的进程。EasyHook 的注入需要以相同的完整性级别打开目标进程否则OpenProcess(PROCESS_ALL_ACCESS)直接失败。解决用管理员身份运行你的注入器。最好是 VS2010 也启动管理员权限这样调试时能直接命中。如果目标进程是系统服务你要先获得 SeDebugPrivilege 权限。Demo 源码里通常没加你需要自己加一段提升权限的辅助代码// 启用 SeDebugPrivilege HANDLE hToken; if (OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, hToken)) { TOKEN_PRIVILEGES tp; LookupPrivilegeValue(NULL, SE_DEBUG_NAME, tp.Privileges[0].Luid); tp.PrivilegeCount 1; tp.Privileges[0].Attributes SE_PRIVILEGE_ENABLED; AdjustTokenPrivileges(hToken, FALSE, tp, 0, NULL, 0); CloseHandle(hToken); }这段代码之后再用 DemoInjector 去注入高权限进程成功率会高很多。5.2 钩子看着装上了但回调一次都不触发现象InstallHook返回成功注入也显示成功但目标进程行为完全没有变化。原因之一钩错了函数地址。有些 Win32 API 在不同进程中是被动态转发或延迟加载的GetProcAddress拿到的可能是一个条形桩函数shim而不是实际的函数体。原因之二目标进程的对应 DLL 还没加载GetModuleHandle返回 NULL导致GetProcAddress失败或拿到错误地址。解决在安装钩子前先强制加载目标 DLL。以CreateFileW为例你可以先在你的注入器进程里加载一次kernelbase.dll获取地址然后通过 EasyHook 的GetHookFunctionAddress之类的辅助函数读取目标进程的同名函数地址。或者干脆把GetProcAddress的调用放在注入 DLL 的 DllMain 里这样能确认 DLL 确实加载了。更实用的做法是把预期函数地址打印出来与目标进程里用调试器读取的地址对比看看是否一致。5.3 回调执行几次后进程崩溃栈显示离奇的地址现象第一次 Hook 生效第二次调用时目标进程直接异常退出用调试器看是内存访问违例。原因极可能是 trampoline 内存保护页设置有问题或者是回调函数里用了与原始函数不一致的调用约定导致栈不平衡。我就遇到过某开发者把被钩函数声明成__cdecl而实际 API 是__stdcall前几个参数刚好碰巧能传对到第四个参数时栈顶偏了直接崩。解决严格核对函数原型。用def文件或 MSDN 上的声明复制粘贴不要凭记忆手写。如果检查了签名没问题就要考虑是否回调中调用了目标进程尚未加载、或被重定向的 CRT 函数。回调中尽量只做参数记录不做动态字符串操作确实需要时用StringCbPrintfA并用固定缓冲区。5.4 注入后目标进程出现白色窗口或者 UI 失去响应现象目标进程没有崩但界面卡住任务管理器显示 CPU 占用为 0看起来像死锁。原因EasyHook 在安装钩子时会挂起目标进程的所有线程等 trampoline 生成完毕后恢复。如果有一个线程恰好停在某个同步对象上而该同步对象的释放逻辑就在你要钩的函数内部那么注入线程与业务线程会互相等待形成死锁。这个坑在高频调用同步区域的函数时特别明显。解决不要在目标进程临启动时立刻注入等它完全启动后再试。还有一种方案是安装钩子时设置额外的超时参数让 EasyHook 在挂起线程前先尝试获取线程上下文。如果程序里存在进程内通信锁最好在注入前通过共享内存发出一个“请暂停业务处理”的信号然后再安装钩子完成后恢复业务。5.5 同一函数在 32 位和 64 位下表现不一致现象同一个HookProc用 32 位 DemoInjector 注入 32 位进程没问题换到 64 位进程后回调能触发但参数错位字符串打印出来是乱码。原因x64 下函数的传参约定与 x86 完全不同x64 使用rcx,rdx,r8,r9和栈混合传参。如果工程里默认编译的是 x86 的钩子 DLL而目标进程是 x64那么回调被调用时EasyHook 把栈上的参数按 x86 格式拿到再按 x64 格式解释数据错位是必然。解决一定要为 x64 目标单独编译一份 x64 版本的钩子 DLL 和注入器。Demo 源码里通常在解决方案配置管理器上有Win32和x64两个配置记得右键配置管理器新建一个 x64 平台而不是直接在工具栏上切平台。因为工程文件里的库依赖和输出路径都可能不一样直接切平台会导致链接到旧库。另一个易错点是#pragma comment(lib, EasyHook.lib)在不同配置下要指向对应的 32 或 64 位 lib如果有条件可以把库统一复制为EasyHook32.lib和EasyHook64.lib避免混淆。6. 进阶技巧用日志把钩子行为变成可回放的调试证据钩子装上、回调能跑这只是第一步。真正让人头疼的是目标进程出问题时你怎么把当时的调用现场还原出来。我的建议是把 Demo 里的日志模块改造成三个级别普通日志、详细参数日志、内存快照日志。普通日志记录函数名、线程 ID、时间戳详细参数日志把各参数展开比如字符串内容、缓冲区大小内存快照日志在关键数据块被释放前复制一份到独立文件。实现时不要直接在回调里写磁盘因为目标进程的 I/O 路径可能被重定向或占满。常见做法是开一块共享内存环形缓冲区回调只负责往缓冲区里写数据外部监控进程用ReadFile或 Memory Mapped File 读取并落盘。这样可以避免钩子对目标进程造成 I/O 影响也能保证高频调用下不遗漏记录。另外一个很实用的技巧是用OutputDebugString配合调试器过滤但不建议长期开。因为我踩过一个坑目标进程如果有反调试策略它会禁用调试输出通道导致你的记录全部丢失还不敢报错。从那以后我每次做钩子项目都会强制走一遍完整流程先跑通 Demo 的原始安装再钩一个低频测试函数验证回调确认稳定后再换到真正要跟踪的高频函数并且所有业务日志都通过共享内存输出。希望这个流程帮到你少走那些黑匣子一样的弯路。本文还有配套的精品资源点击获取
