Windows API Hook实战：进程内拦截send获取明文协议

简介面向Windows网络编程与安全审计方向开发者的一份Win32 API钩子实践工程围绕拦截ws2_32.dll中的send()函数、把套接字发送内容写入OB文件展开涉及导入地址表替换、用户模式钩子与原始函数转发等关键环节适合具备C与Winsock基础、希望理解用户态Hook实现细节的中高级读者参考。压缩包共23个文件约898KB包含2份cpp源码、头文件与模块定义文件以及编译生成的dll、lib、obj、pdb、exp、ilk等产物另有dsp、dsw工程文件与说明文本可直接在VC6环境下打开、编译和调试完整保留的构建中间文件便于对照分析DLL导出与调试符号。目前已有1266人学习。通过源码可梳理send拦截的调用流程、数据落盘方式与钩子安装卸载逻辑并据此延伸出网络数据监控、协议分析等实验思路。1. 抓包工具看不见的明文为什么要在进程内拦 sendws2_32.dll 的 send 是所有 Windows socket 发包的必经口可抓包工具里往往只剩密文——加密在应用层就做完了。某次排查一个自有客户端的协议问题时我换了个方向不去链路上抓而是在进程内把这个函数拦下来把 buf 和 len 抄一份写进自定义的 .ob 文件。道理很朴素加解密函数总要拿到明文send 也总要拿到明文拦在 send 出口密文还没生成你看到的就是业务字段本身。这篇讲的就是这条路的完整复现四条拦截路线怎么选、trampoline 怎么写得不会当场崩、.ob 记录格式怎么定才不会把二进制内容写坏以及五个让我从能跑跌回不能用的细节。适合手上有自有程序要做协议调试、或者想真正搞懂 API Hook 底层的人——照着抄能出结果看判断依据能自己改。2. 四条拦截路线怎么选IAT、Inline、Detours 与内核层逐项对比选型这件事我一般不看别人用哪个库而是先问三个问题目标程序是自己写的还是第三方的、要不要覆盖 WSASend 这类变体、hook 要驻留多久。三个答案不同结论就完全不一样。2.1 先把调用链拆开send 到底经过哪几层写 hook 之前我强制自己先把这条链画清楚否则后面所有排查都是瞎猜。应用代码调用 send链接器把它解析到 ws2_32.dll 的导入表项ws2_32!send 内部并不真的发包它是个转发桩通过 WSPWinsock SPI把请求交给下层提供者Win7 之后这个提供者通常是 mswsock.dll再往下才是 afd.sys 和内核的 TCP 栈。这条链意味着三个事实。第一只要拦住 ws2_32!send绝大多数应用层调用都会经过你因为它是导入表里那个符号。第二mswsock 层也能拦但那一层的参数结构是 WSABUF 而不是裸指针处理起来更绕。第三afd.sys 只有驱动能碰属于另一个量级。还有一个经常被忽略的点send 不是唯一的出口。WSASend、WSASendTo、sendto、甚至是把 SOCKET 强转成 HANDLE 之后走 WriteFile 的重定向 socket都能把数据送出去。只 hook send 一个函数你会在一部分程序上看起来成功、实际漏抓。我通常会把 send 和 WSASend 一起挂上recv 和 WSARecv 按需再挂。提示先用 Process Monitor 或调试器确认目标程序实际调的是 send 还是 WSASend。很多异步框架清一色走 WSASend你挂 send 挂到天荒地老也不会有一次命中。2.2 四种方案的对比表与选型结论方案生效范围实现成本抗干扰能力典型适用IAT Hook只覆盖走导入表的那条调用路径低几十行代码弱。GetProcAddress 动态取址、延迟加载、模块自己转发全都会漏快速验证协议格式、单模块自有程序Inline Hook自写 trampoline所有调用 ws2_32!send 的代码包括动态取址中高要处理指令长度、线程同步、指令缓存强需要长期驻留的调试版客户端Detours / MinHook 这类库同 Inline中库替你处理大部分边界情况强但仍存在多线程竞争窗口工程化落地的首选内核层过滤WFP / TDI整机所有进程高要驱动签名、要处理 IRP最强需要覆盖多进程不适合单进程调试结论我分三档给。第一档只是想知道某个自有客户端发出去的 JSON 长什么样用 IAT Hook 就够了二十分钟能出结果不用碰指令解码。第二档要长期开着、要抓动态加载的插件模块、要覆盖 WSASend直接上 Inline自己写或者用 MinHook 都行我倾向用库因为指令长度解码这块自己写翻车概率太高。第三档要覆盖同机多个进程且不想往每个进程注入才考虑内核层那是另一篇文章的量。Detours 和 MinHook 的差别没那么玄学。Detours 需要编译 x86/x64 两份静态库、对大范围跳转的处理更成熟MinHook 更轻、API 更直白、改起来方便。我自己在调试工具里用 MinHook 居多原因是它的 MH_CreateHook 之后可以随时 MH_DisableHook 还原方便做 A/B 对比——同一个请求挂上 hook 和不挂 hook 各跑一遍比对 .ob 里的字节和实际收到的字节是否一致这是验证 hook 没写坏数据的最快办法。2.3 什么时候必须上 Inline Hook有三个信号出现就该放弃 IAT 方案了。第一个信号目标程序里有 GetProcAddress(LoadLibrary(ws2_32.dll), send) 这类写法说明它压根不走导入表你改 IAT 它看不见。第二个信号你发现 hook 装了但日志是空的而抓包工具显示确实有流量——八成就属于这种情况。第三个信号目标程序有多个模块各自静态链接了一份 socket 封装你要改的 IAT 不止一处。Inline Hook 的代价是同步问题。你要改 send 开头那几字节而此刻可能有别的线程正停在那几字节上准备执行。稳妥做法是枚举进程内所有线程、SuspendThread 之后再改改完 ResumeThread激进做法是在进程刚起来、业务线程还没创建时注入。我一般两个都做双保险。注意SuspendThread 之后如果目标线程正持有堆锁而你又在挂起期间调用了任何会分配内存的 API很容易死锁。挂起窗口里只做 VirtualProtect 和 memcpy别做别的。3. 把 send 拦下来注入、定位到 trampoline 的完整复现这一章是可以直接照着抄的部分。我按注入、定位、写跳板、接参数四步走每一步都给能编译的代码和失败时的判断依据。3.1 注入与定位拿到 ws2_32 的模块基址和 send 地址注入方式我常用两种调试期用 CreateRemoteThread LoadLibrary 把 DLL 塞进去简单直接如果目标程序自己会加载插件直接按插件方式加载更省事还避开了远线程注入被安全软件拦的问题。不管哪种DLL 的 DllMain 里不要做重活——在 DllMain 里调 LoadLibrary 或者等锁是经典的加载器锁死锁来源。我的习惯是 DllMain 只记一个 HANDLE另起线程做初始化。定位 send 的地址很直接#include windows.h #include stdio.h typedef int (WSAAPI *pfn_send)(SOCKET s, const char *buf, int len, int flags); static pfn_send g_real_send NULL; /* 在初始化线程里调用不要在 DllMain 里调 */ static int resolve_target(void) { /* ws2_32 在进程里通常已加载GetModuleHandle 比 LoadLibrary 安全得多 LoadLibrary 会加引用计数卸载时容易留下悬挂模块 */ HMODULE h GetModuleHandleA(ws2_32.dll); if (h NULL) { h LoadLibraryA(ws2_32.dll); if (h NULL) return 0; } g_real_send (pfn_send)GetProcAddress(h, send); return g_real_send ! NULL; }GetProcAddress拿到的地址就是跳板要跳回的原始入口。这里有个判断依据值得说清楚如果你拿到的地址落在 ws2_32.dll 的映像范围内说明是正常导出如果落在别的模块范围内说明这台机器上已经有别的东西先 hook 过了。这种情况你必须决定是绕开还是链式接上硬装会把前一个 hook 的跳板踩烂。3.2 写一个能安全跳转的 trampoline跳板的核心就两件事把目标函数开头的若干字节原样搬走再在原位置写一条跳转到你自己函数的指令。搬走的那几字节放在一块可执行内存里后面接一条跳回原函数 被搬走长度的指令形成完整的 trampoline。x64 上常用的是 14 字节绝对间接跳转/* x64: FF 25 00 00 00 00 8字节绝对地址 —— 共 14 字节 FF 25 是 jmp qword ptr [ripdisp32]disp32 填 0 表示读紧随其后的 8 字节作为目标地址不受 ±2GB 范围限制 */ static void build_abs_jmp(unsigned char *dst, void *target) { dst[0] 0xFF; dst[1] 0x25; *(DWORD *)(dst 2) 0; /* rip 相对偏移置 0 */ *(ULONGLONG *)(dst 6) (ULONGLONG)target; /* 目标绝对地址 */ }x86 上更省字节用 5 字节相对跳转/* x86: E9 rel32rel32 目标 - (当前位置 5) 局限是目标必须在 ±2GB 范围内同进程内一般成立 */ static void build_rel_jmp(unsigned char *dst, void *from, void *to) { dst[0] 0xE9; *(INT32 *)(dst 1) (INT32)((BYTE *)to - (BYTE *)from - 5); }真正麻烦的不是写跳转而是搬走几字节。你搬走的长度必须正好落在指令边界上否则跳回去执行的是半条指令程序当场就废了。send 的开头在不同系统版本上字节序列不一样可能是mov edi,edi的 hotpatch 双字节垫片也可能直接是sub rsp,xx。这就是我前面说自己写指令长度解码翻车概率高的原因——长度算错的表现是随机崩溃而且崩的地方离你的 hook 十万八千里排查成本极高。装的时候顺序不能乱VirtualProtect把目标函数开头改成PAGE_EXECUTE_READWRITE备份原始字节到unsigned char orig[16]长度按解码结果取先把 trampoline 完整构造好搬走的字节 跳回指令再动原函数写入跳转字节FlushInstructionCache(GetCurrentProcess(), addr, len)这步别省多核上漏掉它是玄学崩溃的常见来源恢复原来的内存保护属性卸载时严格反序先还原原始字节再释放 trampoline 那块可执行内存。3.3 x86 与 x64 的参数读取差异以及 recv 的特殊之处如果你的 hook 函数原型和原函数完全一致参数会由编译器按调用约定自动摆好你直接读形参就行这是最省事的写法/* WSAAPI 展开是 __stdcallx86/ 默认x64 原型必须和 ws2_32!send 完全一致否则栈会失衡 */ int WSAAPI Hook_send(SOCKET s, const char *buf, int len, int flags) { if (buf ! NULL len 0) { /* 见 4.2这里只做拷贝入队绝不碰文件 IO */ ob_push(g_queue, s, buf, (unsigned int)len); } return g_real_send(s, buf, len, flags); }只有在你需要读寄存器、或者要 hook 一个没法声明原型的函数时才需要区分 x86/x64。x64 上前四个整型参数依次在 rcx、rdx、r8、r9x86 的 __stdcall 上它们在栈里[esp4]是 s、[esp8]是 buf、[esp0xC]是 len、[esp0x10]是 flags。写 naked 函数手工取参数的时候一定要在ret后面补上正确的立即数send 是 4 个参数共 16 字节否则退栈退错一个字节崩溃点会跑到调用者的下一条指令上。WSASend 的签名不一样第二个参数是LPWSABUF数组加DWORD dwBufferCount你得遍历数组把每段都拷出来它的输出参数lpNumberOfBytesSent在调用返回后才有效所以记录要在调用之后写。recv 和 send 最大的差别就在这里send 的 buf 在调用前就是完整内容调用之后可能被调用方复用覆盖所以必须在调用前拷走recv 的 buf 在调用前是垃圾调用返回后才知道真实收了几个字节所以必须先调原函数拿到返回值再按返回值拷。这个顺序搞反.ob 里全是零字节或者上一轮的残留数据我见过不止一个人在这上面耗掉半天。4. 落盘才是难点.ob 记录格式与异步写入设计很多人以为 hook 装上了就完事了其实真正让工具能用的是落盘这半边。hook 函数执行在目标程序的 IO 线程里你在这里多花一毫秒业务行为就被改了一毫秒——调试工具污染被测对象这本身就违背了调试的目的。4.1 记录格式为什么不能直接 fwrite 原始 buffer最直接的写法是fwrite(buf, 1, len, fp)看起来没问题实测三个坑一起爆发。第一二进制内容里到处都是0x00和换行用文本模式打开会被截断或者打乱事后根本没法切分。第二没有长度前缀就没法区分这条记录结束了和下一条记录开始了一旦中间丢一段整份文件就废了。第三没有时间戳和 socket 句柄多条连接混在一起你就分不清哪段数据属于哪个会话。所以我用的格式是一个定长文件头加一串变长记录偏移长度字段说明08magic version4F 42 4C 4F 47 31 00 00即 OBLOG1 补零84magic每条记录重开一个0x4F424731用于错位检测124tick_ms从 DLL 初始化算起的毫秒数GetTickCount差值164sockSOCKET 句柄同一条连接自然分组204flags最高位置 1 表示 send置 0 表示 recv244length载荷字节数小端28lengthpayload原始字节不做任何转义每条记录都重开一个 magic 是我特意加的自愈设计。文件写一半断电、或者你手动截断了尾部解析脚本读到 magic 对不上就知道错位了可以跳过继续找下一个 magic而不是整份文件报废。这个字段只有 4 字节的代价换来的是永远能救回来一半数据很值。提示别用原始 SOCKET 值当唯一会话标识句柄会被系统回收复用。要精确区分会话在 hook 里补一个首次见到该句柄时分配的自增序号更可靠。4.2 无锁环形队列 独立写线程hook 函数里能做的事只有一件把字节拷进预分配好的缓冲区然后返回。禁止 malloc禁止 printf禁止任何文件 API理由都一样——它们内部会拿堆锁和 CRT 锁而你可能正中断了另一个持有同一把锁的线程死锁就这么来的。我的做法是初始化时一次性预分配 N 个固定大小的槽位hook 只做 memcpy 和一次原子写指针#define OB_SLOTS 4096 /* 必须为 2 的幂取模换成位与 */ #define OB_MAXLEN 65536 /* 单条载荷上限超了截断并标记 */ typedef struct { volatile LONG head; /* 写线程消费位置 */ volatile LONG tail; /* hook 线程生产位置 */ unsigned int len[OB_SLOTS]; unsigned char *slot[OB_SLOTS]; /* 初始化时全部 malloc 好 */ } ob_queue; static int ob_push(ob_queue *q, SOCKET s, const char *buf, unsigned int len) { LONG t q-tail; LONG n (t 1) (OB_SLOTS - 1); if (n q-head) return 0; /* 满了就丢绝不阻塞业务线程 */ if (len OB_MAXLEN) len OB_MAXLEN; memcpy(q-slot[t], buf, len); /* 预分配内存不 malloc */ q-len[t] len; MemoryBarrier(); /* 保证数据先于 tail 可见 */ q-tail n; return 1; }写线程是唯一碰文件的地方它把槽位顺序取出、写长度、写载荷、推进 head这里就是消费指针。调试期我会每次fflush保证崩溃前的数据不丢正式跑起来改成每秒刷一次减少 IO 抖动。队列满了直接丢数据这个策略要明确写进日志否则你会以为这段时间真的没发包。4.3 用 hex dump 复核与回放脚本.ob 是二进制光有格式定义不够还得有个能立刻看清内容的解析器。这个脚本我几乎每个项目都会重写一遍二十行足够import struct, sys REC struct.Struct(IIIII) # magic, tick_ms, sock, flags, length MAGIC 0x4F424731 def dump(path): with open(path, rb) as f: if f.read(8) ! bOBLOG1\x00\x00: sys.exit(文件头不对确认是不是 .ob) while True: head f.read(REC.size) if len(head) REC.size: break # 正常结束或尾部被截断 magic, tick, sock, flags, length REC.unpack(head) if magic ! MAGIC: sys.exit(记录错位偏移 %d % f.tell()) # 见 4.1 的自愈设计 body f.read(length) print([%8d ms] sock%d %s len%d % (tick, sock, send if flags 0x80000000 else recv, length)) for i in range(0, length, 16): chunk body[i:i 16] hx .join(%02X % b for b in chunk) tx .join(chr(b) if 32 b 127 else . for b in chunk) print( %04X %-47s %s % (i, hx, tx)) if __name__ __main__: dump(sys.argv[1])用IIIII而不是IIIII是刻意的小端定死换台机器读同一份文件结果一致。左侧 hex、右侧 ASCII 的排版和常见 hexdump 一致眼睛能直接扫。看到形如7B 22 61 63 74 22 3A的序列右边就是{act:说明你没抓到密文抓的就是明文——这一步验证比任何理论分析都直接。5. 五个当场翻车的细节hook 从能跑到能用的排查清单下面五条都是我真实踩过的按现象、原因、解决写遇到对应症状直接对号入座。5.1 现象hook 装了、日志是空的但抓包工具显示有流量原因目标程序走的是 WSASend不是 send。异步 IO 框架几乎清一色用 WSASend因为可以一次提交多个 WSABUF。你只挂了 send自然一次都不命中。解决先确认实际调用面。最简单是在 hook 初始化时把 send、sendto、WSASend、WSASendTo 全挂上各记一条带函数标识的记录跑一轮看哪个有数据再决定保留哪些。WSASend 要多一层遍历lpBuffers[0..dwBufferCount-1]别只拷第一段。5.2 现象静态调用能抓到某个插件模块发出去的包全漏原因IAT Hook 只改了主模块的导入表插件模块有自己的导入表指向的还是原始 send 地址。或者插件用 GetProcAddress 动态取址压根不查导入表。解决换 Inline Hook或者在 DLL 加载时通过LDR_REGISTER_MODULE_NOTIFICATION之类的机制给每个新模块补一遍 IAT 修改。前者一劳永逸后者要在模块加载的回调里做还得注意别在加载器锁里做重活很容易死锁。5.3 现象日志里第一条记录就是业务数据握手和认证包全没有原因注入时机太晚。等你 DllMain 跑起来目标程序的连接早就建好、认证也发完了。前面那几个包最关键的往往恰恰是认证和协商阶段。解决把注入提前。要么用调试器在入口点断下后注入要么让目标程序以加载插件的方式加载你的 DLL要么用 IFEO / AppInit 之类在进程早期生效的机制。判断依据很简单日志第一条记录的 tick_ms 应该在几百毫秒以内如果是好几秒说明注入晚了。5.4 现象一挂上 hook目标程序卡死或者过几秒闪退原因递归。你的 hook 里调用了某个会发包的 API比如某些日志上报、崩溃收集库或者调用了 printf/malloc 而正好另一线程持锁被挂起。前者造成无限递归直到爆栈后者是死锁。解决双重保护。一是用线程局部存储打标记进入 hook 先检查标记已置位就直接调原函数返回别记日志static __declspec(thread) int g_in_hook 0; int WSAAPI Hook_send(SOCKET s, const char *buf, int len, int flags) { if (!g_in_hook buf len 0) { g_in_hook 1; /* 重入直接跳过记录避免递归 */ ob_push(g_queue, s, buf, (unsigned int)len); g_in_hook 0; } return g_real_send(s, buf, len, flags); }二是记住 hook 内只用 memcpy 和原子操作任何带锁的东西都不许碰。5.5 现象x86 程序能跑x64 程序注入后立刻退出或者反过来原因位数不匹配。32 位 DLL 注入不了 64 位进程这是硬限制跟你的代码写得好不好没关系。另一种情况是同一个进程里既有 32 位也有 64 位模块少见但存在你只挂了一半。解决DLL 编译两份注入前用IsWow64Process判断目标位数再选对应版本。另外 64 位进程的跳板要注意 ±2GB 范围问题如果 trampoline 分配到的内存离目标函数太远5 字节相对跳转跳不过去必须改用 14 字节绝对间接跳转。分配 trampoline 内存时优先在目标地址附近找空闲区否则这个坑会随机出现非常隐蔽。6. 从能跑到可信一份自检清单和我固定的验证习惯把 hook 写出来只完成了三成剩下七成是证明它没骗你。我现在每次收工前都会跑一遍这套自检顺序固定缺一项不收工。检查项怎么验不通过说明什么数据完整性挂 hook 前后各跑一次同一业务比对 .ob 里的载荷与程序自己输出的请求体字节不一致说明 trampoline 搬字节或参数读取有问题覆盖度用 WSASend 和 send 各写一个最小客户端分别触发某一类没记录说明函数面没铺全时序正确检查 recv 记录里的载荷是不是上一轮的残留recv 记录写在调用前了顺序反了递归安全在 hook 里故意调一次会发包的 API进程卡死或爆栈说明重入保护没生效卸载干净卸载 hook 后再跑一轮对比行为差异崩溃或结果异常说明原始字节或内存属性没还原最后一章想落在一个具体技巧上因为它帮我省过最多时间先只写 recv不写 send。听起来反直觉但调试新 hook 时我一直这么干。原因很简单——recv 的输出你能立刻用业务逻辑验证服务端发一个固定内容的响应客户端收到的明文你应该一眼能认出来。send 不一样你看到的是自己刚发出去的东西容易陷入我以为是这个的自我确认实际上 hook 可能压根没生效你看到的只是缓冲区里的历史数据。先用 recv 把hook 到底有没有被调用这件事钉死再回头看 send能省掉大量自欺欺人的排查。还有一个习惯每次动 trampoline 相关代码我都会在装 hook 之前先把目标函数开头那 16 个字节打印成 hex 存一份改完再打印一次肉眼比对。这个动作只要十秒但救过我至少三次——其中一次是内存保护属性没恢复回去程序平时跑没问题一遇到代码完整性校验就崩事后靠这两张 hex 才能定位到是哪次修改留下的痕迹。回过头看这套东西真正难的地方从来不是怎么拦而是拦了之后怎么保证不改变被拦对象的行为。拦截本身二十行代码可靠地拦截是几百行让人相信你的拦截结果是真的是那份自检清单。从那以后我每次给工具加新的 hook 点都强制走一遍这六项检查哪怕只是改了个字段宽度。希望帮到你。本文还有配套的精品资源点击获取