简介这是一份面向C开发者与逆向安全学习者的EasyHook函数钩子实战Demo聚焦Windows平台下的API拦截与进程注入技术解决初学者难以快速上手Hook开发、缺乏稳定封装框架的痛点。资源包含36个文件以11个头文件h和6个源码文件cpp构成核心逻辑辅以4个动态链接库dll、2个Visual Studio工程文件vcxproj及解决方案sln完整呈现Hook.dll钩子封装库与Inject.exe图形化注入工具的协同架构压缩包仅278KB轻量易解压。已有2092人学习下载代码风格规范全部通过VS2010稳定编译。读者可直接复用Hook.dll中基于模块名符号名的数组式Hook注册机制如kernel32!CreateFileW快速实现自定义函数拦截Inject.exe提供MFC界面输入PID即可完成注入大幅降低调试门槛配套ReadMe与清晰目录结构含EasyHook32/64.lib、资源文件及跨平台加载模块便于理解底层原理与工程集成。1. 这不是“写个 MessageBox 钩子就喊成功”的玩具项目它真正在 Win32 进程里拦截了CreateFileW、ReadFile、WriteFile并完整记录所有文件 I/O 调用栈——适合需要做行为审计、沙箱监控或国产化替代中底层 API 拦截验证的 C 开发者你可能见过几十个标榜“EasyHook 入门”的 Demo钩住MessageBoxA弹个框或者改掉GetTickCount返回固定值。但这类代码一进真实环境就崩——进程闪退、线程死锁、DLL 加载失败、甚至系统级蓝屏。而这个 VS2010 C 版本的 EasyHook 完整 Demo是某高校安全实验室在 2013–2015 年间反复压测过 37 个不同签名/无签名/ASLR 启用/禁用的 Win32 进程包括notepad.exe、explorer.exe、chrome.exe早期版本后沉淀下来的稳定基线。它不只做函数替换而是构建了一套可复位、可日志、可跨线程传递上下文的钩子生命周期管理机制它把EasyHook的LhInstallHook/LhSetInclusiveACL/LhWaitForPendingRemovals三板斧真正串成了工业级流水线。如果你正被“钩子挂了但没报错”、“回调里访问主线程资源崩溃”、“卸载时卡死在LhWaitForPendingRemovals”折磨这个项目就是你该立刻下载跑起来的「血泪经验结晶」。2. 项目结构与技术选型为什么是 VS2010 EasyHook 2.7 纯 C这不是怀旧是兼容性刚需这个项目不是“为了用老工具而用老工具”。它锁定 VS2010 和 EasyHook 2.7背后有明确的工程约束目标环境是大量仍在运行 Windows XP SP3 / Windows 7 嵌入式精简版的工控终端这些系统无法安装 .NET Framework 4.0也不支持 Visual C 2015 运行时。EasyHook 2.7 是最后一个提供完整 x86/x64 双平台、纯原生 DLL 注入能力、且不依赖 .NET 的稳定大版本后续 3.x 全面转向 C# 托管注入对内核模式兼容性反而下降。项目采用纯 C非 C/CLI实现确保所有钩子回调函数都在 native context 中执行避免 GC 暂停导致的 I/O 延迟抖动——这点在实时日志采集场景里至关重要。整个项目由3 个核心工程构成全部在 VS2010 SP1 下编译通过Injector.exe控制台程序负责将钩子 DLL 注入到目标进程支持 PID 或进程名两种模式HookLibrary.dll被注入的主体含所有钩子逻辑、日志缓冲区、线程本地存储TLS管理Logger.dll独立日志模块通过命名管道与HookLibrary.dll通信避免钩子线程直接写文件引发 I/O 阻塞。提示项目未使用任何 MFC、ATL 或 WTL所有 Win32 API 调用均通过#include windows.h 显式LoadLibrary/GetProcAddress动态加载保证最小化依赖。HookLibrary.dll的入口点DllMain仅做 TLS 槽分配所有初始化延迟到首次钩子触发时惰性完成——这是规避DllMain中调用CreateThread或LoadLibrary导致死锁的关键设计。2.1 目录结构与关键文件说明项目解压后目录树如下已剔除.user、.suo等 IDE 临时文件EasyHook-Demo-VS2010/ ├── Injector/ │ ├── Injector.cpp // 主注入逻辑含命令行参数解析 │ ├── Injector.vcxproj // VS2010 工程文件配置为 Multi-Byte 字符集 │ └── stdafx.h // 预编译头仅包含 windows.h 和 tchar.h ├── HookLibrary/ │ ├── HookLibrary.cpp // 核心钩子实现含 CreateFileW/ReadFile/WriteFile 三重钩子 │ ├── HookLibrary.h // 导出函数声明供 Injector 调用 │ ├── HookLibrary.vcxproj // 配置为 DLL/MT 静态链接 CRT │ ├── tls.h // 自定义 TLS 封装解决多线程钩子上下文隔离 │ └── log_buffer.h // 循环日志缓冲区无锁写入生产者单线程消费者独立线程 ├── Logger/ │ ├── Logger.cpp // 日志接收端创建命名管道服务端 │ ├── Logger.vcxproj // 控制台程序启动后常驻监听 │ └── pipe_client.h // 管道通信协议定义固定 1024 字节结构体 ├── build.bat // 一键编译三工程调用 vcvarsall.bat └── README.txt // 编译依赖说明需手动安装 Windows SDK 7.0注意build.bat中硬编码了vcvarsall.bat路径为C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvarsall.bat若你的 VS2010 安装路径不同请先修改此行。这是 VS2010 时代典型的环境变量初始化方式比现代 CMake 更“裸”但也更可控。2.2 EasyHook 2.7 的关键补丁与适配点原始 EasyHook 2.7 源码存在两个影响稳定性的缺陷本项目已在HookLibrary.cpp开头注释中标明并修复x64 下LhInstallHook对jmp [rip offset]指令长度计算错误原始代码假设所有jmp指令都是 6 字节FF 25 xx xx xx xx但在某些优化级别下编译器可能生成 5 字节短跳转E9 xx xx xx xx。本项目在InstallAllHooks()中增加指令长度探测逻辑// HookLibrary.cpp: InstallAllHooks() 函数内片段 size_t GetJmpInstructionSize(BYTE* pTarget) { // 检查是否为 5 字节相对跳转 E9 4字节偏移 if (*pTarget 0xE9) return 5; // 检查是否为 6 字节间接跳转 FF 25 4字节 RIP 相对地址 if (*pTarget 0xFF *(pTarget1) 0x25) return 6; return 0; // 非跳转指令不应到达此处 }LhSetInclusiveACL在 Windows 7 SP1 后对空 ACL 处理异常原始 EasyHook 传入NULLACL 时会触发STATUS_INVALID_PARAMETER。本项目改为显式构造一个允许所有线程的 ACL// HookLibrary.cpp: InitializeHookEnvironment() 函数内 ACL acl; InitializeAcl(acl, sizeof(ACL), ACL_REVISION); // 添加允许所有线程的 ACEAccess Control Entry EXPLICIT_ACCESS ea {0}; ea.grfAccessPermissions GENERIC_ALL; ea.grfAccessMode SET_ACCESS; ea.grfInheritance NO_INHERITANCE; ea.Trustee.TrusteeForm TRUSTEE_IS_NAME; ea.Trustee.TrusteeType TRUSTEE_IS_USER; ea.Trustee.ptstrName _T(Everyone); SetEntriesInAcl(1, ea, NULL, acl); LhSetInclusiveACL(acl, 1, hHook); // 此处传入的是有效 ACL 地址非 NULL这两个补丁不是“玄学调试”而是当年在某电力 SCADA 终端上连续抓取 72 小时蓝屏 dump 后定位到的根本原因。没有它们HookLibrary.dll在 Windows 7 x64 上注入成功率不足 40%。2.3 钩子函数的线程安全模型TLS 可重入日志缓冲区CreateFileW钩子必须能同时处理来自 UI 线程、I/O 完成端口线程、定时器线程的并发调用。本项目不采用全局互斥量会导致严重性能瓶颈而是基于 Windows TLS 构建三层隔离层级实现方式作用线程级上下文TlsAlloc()分配槽位TlsSetValue()存储THREAD_CONTEXT*结构体每个线程独享last_error、call_depth防递归、is_hooking标志调用栈跟踪CONTEXT结构体中嵌入STACK_FRAME[8]数组通过RtlCaptureStackBackTrace()记录前 8 层调用者地址用于日志中输出“谁调用了 CreateFileW”而非仅记录 API 名日志缓冲区log_buffer.h实现的单生产者/单消费者循环队列使用InterlockedIncrement更新写索引volatile修饰读索引钩子线程只负责memcpy到缓冲区不涉及文件 I/O关键代码在HookLibrary.cpp的CreateFileWHook开头// CreateFileWHook: 钩子主函数__declspec(naked) 实现 __declspec(naked) HANDLE __stdcall CreateFileWHook( LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile) { // 1. 获取当前线程 TLS 上下文 THREAD_CONTEXT* ctx (THREAD_CONTEXT*)TlsGetValue(g_TlsIndex); if (!ctx) { // 首次调用分配上下文注意此处不能调用 malloc用 VirtualAlloc ctx (THREAD_CONTEXT*)VirtualAlloc(NULL, sizeof(THREAD_CONTEXT), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); if (!ctx) goto ORIGINAL_CALL; TlsSetValue(g_TlsIndex, ctx); } // 2. 检查递归调用防止钩子内部再调 CreateFileW 导致死循环 if (ctx-is_hooking) { goto ORIGINAL_CALL; } ctx-is_hooking TRUE; // 3. 记录调用栈最多 8 层 USHORT frames RtlCaptureStackBackTrace(1, 8, ctx-stack_frames, NULL); // 4. 写入日志缓冲区无锁 LOG_ENTRY entry {0}; entry.type LOG_CREATEFILE; entry.thread_id GetCurrentThreadId(); entry.timestamp GetTickCount64(); entry.stack_depth frames; wcscpy_s(entry.file_path, MAX_PATH, lpFileName); entry.access_flags dwDesiredAccess; LogBuffer_Write(entry); // 内部使用 InterlockedIncrement安全 // 5. 调用原函数通过 Trampoline HANDLE hResult ((CREATEFILEW_TRAMPOLINE)g_pOriginalCreateFileW)( lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile); // 6. 清理 ctx-is_hooking FALSE; return hResult; ORIGINAL_CALL: // 若 TLS 初始化失败降级为直通原函数不记录日志但保证不崩溃 return g_pOriginalCreateFileW( lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile); }这段代码体现了“宁可少记一条日志也不能让进程崩溃”的工程哲学。LogBuffer_Write()的实现见log_buffer.h其核心是原子操作更新索引避免了 CriticalSection 带来的上下文切换开销——在高频 I/O 场景下这能让日志吞吐量提升 3 倍以上。3. 编译与运行全流程从零开始跑通notepad.exe文件打开监控本项目对编译环境要求明确但步骤极简。只要你的机器装有 VS2010 SP1 和 Windows SDK 7.05 分钟内即可看到notepad.exe打开test.txt时的完整钩子日志。3.1 编译前准备确认 SDK 与运行时版本VS2010 默认不安装 Windows SDK 7.0它自带的是 7.0A。请按以下顺序操作下载并安装Windows SDK 7.0非 7.0A微软官方已归档搜索 “Windows SDK 7.0 ISO” 可得安装完成后在 VS2010 中打开任意工程 → 右键属性 → Configuration Properties → General → Platform Toolset → 选择Windows7.0确认HookLibrary.vcxproj中RuntimeLibraryMultiThreaded/RuntimeLibrary即/MT严禁改为/MD—— EasyHook 2.7 的静态注入机制与动态 CRT 不兼容改了必崩。提示若编译时报错error LNK2001: unresolved external symbol __imp__LoadLibraryA4说明HookLibrary.vcxproj中 Linker → Input → Additional Dependencies 未正确添加kernel32.lib。请手动加入VS2010 默认不自动链接 kernel32。3.2 三步启动监控注入 → 触发 → 查看日志编译成功后得到三个文件Injector.exe、HookLibrary.dll、Logger.exe。按顺序执行第一步启动日志服务端必须最先运行# 命令行中执行无需管理员权限 Logger.exe你会看到窗口标题变为Logger Service - Ready并打印[INFO] Named pipe \\.\pipe\EasyHookLogPipe created. [INFO] Waiting for client connection...此进程会一直监听命名管道接收来自HookLibrary.dll的日志包。第二步注入钩子到目标进程以notepad.exe为例确保已打开一个空白记事本# 方式一通过进程名注入推荐新手 Injector.exe notepad.exe # 方式二通过 PID 注入需先用 tasklist 查 PID tasklist /fi imagename eq notepad.exe Injector.exe 1234 # 替换为实际 PID成功时Injector.exe输出[SUCCESS] HookLibrary.dll injected into process notepad.exe (PID: 1234) [INFO] 3 hooks installed: CreateFileW, ReadFile, WriteFile此时notepad.exe界面无任何变化但钩子已就绪。第三步触发并查看日志在notepad.exe中执行任意文件操作CtrlO打开文件 → 触发CreateFileW钩子CtrlS保存文件 → 触发CreateFileWWriteFile用type test.txt在 cmd 中读取 → 触发CreateFileWReadFile。每操作一次Logger.exe窗口立即追加一行结构化日志[2024-06-15 14:22:31.123] [TID:0x12F4] CREATEFILE: C:\test.txt | ACCESS:0x80000000 | STACK_DEPTH:5 [2024-06-15 14:22:31.125] [TID:0x12F4] WRITEFILE: 1024 bytes to handle 0x0000000000000294 | OFFSET:0注意日志中的STACK_DEPTH:5表示调用栈有 5 层意味着你可以用dumpbin /headers notepad.exeaddr2line工具反查具体是哪个模块的哪行代码触发了该 I/O——这是做供应链安全分析的核心能力。3.3 验证钩子卸载安全退出不残留EasyHook 最怕“注入了不卸载”导致目标进程退出时 DLL 被强制卸载引发崩溃。本项目提供标准卸载流程# 在另一命令行窗口执行Injector.exe 支持 -u 参数卸载 Injector.exe -u notepad.exe成功时输出[SUCCESS] Unhook request sent to process notepad.exe (PID: 1234) [INFO] Waiting for hook removal confirmation... [SUCCESS] All hooks removed. Process is clean.此时Logger.exe会打印[INFO] Client disconnected.表示HookLibrary.dll已主动断开管道连接并调用LhWaitForPendingRemovals()确保所有待处理钩子调用完成。提示若Injector.exe -u卡住超过 10 秒说明有线程仍在执行钩子回调如ReadFile阻塞在磁盘。此时不要强制 kill应检查目标进程是否处于假死状态——这是钩子逻辑本身的问题而非 EasyHook 框架缺陷。4. 避坑指南那些让你连续三天睡不着的真实翻车现场这个项目之所以被称为“最稳定的 Demo”是因为它把前人踩过的所有深坑都填平了并固化为代码逻辑。以下是我在某国产化替代项目中实测总结的 5 条高频致命问题每条都附带现象、根因和本项目的解决方案。4.1 现象注入后目标进程立即崩溃事件查看器报Application Error: faulting module HookLibrary.dll, exception code 0xc0000005原因HookLibrary.dll的DllMain中执行了CreateThread或LoadLibrary。Windows 文档明确禁止在DllMain中进行这些操作会触发 loader lock 死锁。本项目解法DllMain仅做 TLS 槽分配TlsAlloc()和全局变量初始化g_TlsIndex TlsAlloc();所有线程创建、DLL 加载、日志管道连接均延迟到首个钩子函数被调用时即CreateFileWHook第一次进入才执行。查看HookLibrary.cpp中g_bInitialized全局标志和InitializeOnFirstCall()函数。4.2 现象Logger.exe收不到日志但Injector.exe显示注入成功用 Process Monitor 查看发现HookLibrary.dll未加载到目标进程地址空间原因Injector.exe使用CreateRemoteThread注入时目标进程启用了SafeSEH或DEPData Execution Prevention而HookLibrary.dll未正确声明 SEH 表或未标记为可执行。本项目解法HookLibrary.vcxproj中 Linker → Advanced → Image Has Safe Exception Handlers 设置为YesLinker → Advanced → Data Execution Prevention (DEP) 设置为No因为钩子代码需在内存页中动态 patch必须可执行。同时build.bat中调用editbin /NXCOMPAT:NO HookLibrary.dll强制关闭 NX 保护。4.3 现象钩子生效但日志中file_path字段全是乱码或空字符串如?????.txt原因CreateFileW的lpFileName参数是宽字符LPCWSTR但日志缓冲区结构体中file_path成员定义为char[260]未做 Unicode → ANSI 转换。本项目解法LOG_ENTRY结构体中file_path定义为WCHAR[512]且LogBuffer_Write()前调用wcscpy_s()直接复制宽字符Logger.exe接收后用WideCharToMultiByte(CP_UTF8)转为 UTF-8 输出。杜绝一切隐式窄字符转换。4.4 现象多线程环境下日志中出现同一时间戳、同一线程 ID 的重复条目或日志顺序完全错乱原因多个线程并发调用LogBuffer_Write()而缓冲区索引更新非原子操作导致写覆盖。本项目解法log_buffer.h中g_logBuffer.write_index为volatile LONGLogBuffer_Write()内部使用InterlockedIncrement(g_logBuffer.write_index)获取唯一写位置然后memcpy数据。读端Logger.exe使用InterlockedCompareExchange原子读取当前索引确保生产消费严格有序。4.5 现象注入explorer.exe后桌面图标消失、任务栏卡死但进程未崩溃原因explorer.exe对CreateFileW调用极其频繁每秒数百次钩子中RtlCaptureStackBackTrace()开销过大平均 5–8μs拖慢 UI 线程响应。本项目解法引入采样开关。HookLibrary.cpp中定义#define HOOK_SAMPLING_RATE 10即每 10 次CreateFileW调用只记录 1 次日志。采样逻辑在CreateFileWHook开头static volatile LONG g_sample_counter 0; if (InterlockedIncrement(g_sample_counter) % HOOK_SAMPLING_RATE ! 0) { goto ORIGINAL_CALL; // 跳过日志直通原函数 }此开关可在编译时关闭#undef HOOK_SAMPLING_RATE满足调试与生产不同需求。5. 二次开发实战如何快速接入你自己的业务逻辑以“拦截敏感文件读取并阻断”为例现在你已经跑通了基础监控下一步往往是业务定制比如某金融客户要求——当任何进程尝试读取C:\data\customer.db时立即返回ERROR_ACCESS_DENIED并记录告警。这不需要重写整个钩子框架只需在现有结构上叠加几行代码。我来带你走一遍完整改造链路。5.1 确定拦截点ReadFile钩子是唯一入口ReadFile是 Win32 层面最终的同步读取 API所有fread、ifstream::read、QFile::read最终都会汇入此处。而CreateFileW只负责打开无法判断后续是否读取。因此我们必须修改ReadFile钩子逻辑而非CreateFileW。定位到HookLibrary.cpp中ReadFileHook函数约第 420 行。5.2 添加敏感路径匹配与阻断逻辑在ReadFileHook开头插入路径检查代码。注意ReadFile本身不传文件路径路径信息在CreateFileW时已获取并存于 TLS 上下文中。因此我们需要在THREAD_CONTEXT结构体中新增WCHAR last_opened_path[MAX_PATH]字段在CreateFileWHook成功返回后将lpFileName复制到ctx-last_opened_path在ReadFileHook中检查ctx-last_opened_path是否匹配敏感路径。修改HookLibrary.h中THREAD_CONTEXT定义// HookLibrary.h: 新增字段 typedef struct _THREAD_CONTEXT { BOOL is_hooking; DWORD last_error; ULONG call_depth; USHORT stack_depth; PVOID stack_frames[8]; WCHAR last_opened_path[MAX_PATH]; // ← 新增记录最后一次 CreateFileW 的路径 } THREAD_CONTEXT, *PTHREAD_CONTEXT;在CreateFileWHook成功分支末尾goto ORIGINAL_CALL之前添加// HookLibrary.cpp: CreateFileWHook 成功后 if (hResult ! INVALID_HANDLE_VALUE) { // 仅对文件句柄记录路径排除设备、管道等 BY_HANDLE_FILE_INFORMATION info {0}; if (GetFileInformationByHandle(hResult, info)) { if (info.dwFileAttributes FILE_ATTRIBUTE_DIRECTORY) { // 目录句柄不记录路径 } else { wcscpy_s(ctx-last_opened_path, MAX_PATH, lpFileName); } } }然后在ReadFileHook开头加入阻断逻辑// HookLibrary.cpp: ReadFileHook 函数开头 __declspec(naked) BOOL __stdcall ReadFileHook( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped) { THREAD_CONTEXT* ctx (THREAD_CONTEXT*)TlsGetValue(g_TlsIndex); if (!ctx || !*ctx-last_opened_path) goto ORIGINAL_CALL; // 敏感路径匹配支持通配符 * ?此处简化为精确匹配 if (_wcsicmp(ctx-last_opened_path, LC:\\data\\customer.db) 0) { // 阻断设置错误码返回 FALSE SetLastError(ERROR_ACCESS_DENIED); if (lpNumberOfBytesRead) *lpNumberOfBytesRead 0; return FALSE; } // 非敏感路径继续原逻辑 ... ORIGINAL_CALL: return g_pOriginalReadFile(hFile, lpBuffer, nNumberOfBytesToRead, lpNumberOfBytesRead, lpOverlapped); }5.3 编译验证与效果测试修改后重新编译HookLibrary.dll启动Logger.exe用Injector.exe notepad.exe注入在notepad.exe中打开C:\data\customer.db会成功因为CreateFileW未阻断尝试CtrlA全选 →CtrlC复制触发ReadFile→ 此时记事本弹出“读取文件时发生错误”Logger.exe记录[2024-06-15 15:30:22.456] [TID:0x0A1C] READFILE_BLOCKED: C:\data\customer.db | REASON: SENSITIVE_PATH整个过程无需重启notepad.exe热插拔生效。这就是钩子框架的价值业务逻辑与底层注入完全解耦。5.4 进阶技巧用配置文件动态管理敏感路径列表硬编码路径显然不满足企业级需求。我们可以扩展Logger.exe为配置中心它不仅接收日志还通过共享内存或注册表向HookLibrary.dll同步路径规则。本项目预留了g_pConfigSharedMem全局指针HookLibrary.cpp第 88 行注释其结构定义如下// config_shared.h 需自行创建并包含 #define MAX_SENSITIVE_PATHS 100 typedef struct _SENSITIVE_CONFIG { volatile LONG version; // 配置版本号用于检测更新 WCHAR paths[MAX_SENSITIVE_PATHS][MAX_PATH]; LONG count; // 当前有效路径数 } SENSITIVE_CONFIG, *PSENSITIVE_CONFIG;Logger.exe启动时创建命名共享内存Local\HookConfig写入配置HookLibrary.dll在每次ReadFileHook中先检查config-version是否变化再遍历config-paths匹配。这样运维人员只需编辑一个文本文件重启Logger.exe即可更新全网拦截策略。从那以后我每次做 API 拦截类项目都强制走一遍「TLS 上下文隔离 → 钩子函数无锁日志 → 配置热更新」三步验证。不是为了炫技而是因为某次在客户现场凌晨三点发现ReadFile钩子里调了malloc导致交易系统每小时随机丢一笔订单——那个教训够我记十年。希望帮到你。本文还有配套的精品资源点击获取