简介这是一款基于Hook机制实现的微信机器人项目面向具备一定Python基础、希望搭建个人或社群自动化工具的开发者与爱好者。项目经过一年迭代功能更贴近日常使用场景支持AI对话GPT、星火、千帆、关键词拉人进群、自动群发、入群欢迎等并会不定期维护有代码能力者也可自行二次开发。资源包共76个文件以34个png截图、12个py源码、9个pyc编译文件为主另含xml配置、yaml参数文件及少量jpg、gif素材整体约4.93MB目录按Bot_Server、Db_Server、Api_Server、Push_Server、Config等模块划分结构清晰便于理解消息接收、分发、数据库与推送的协作逻辑。目前已有846人学习下载适合想研究Hook机制、微信消息处理流程或搭建社群管理机器人的读者参考可从中获取完整源码、配置示例与模块化设计思路。1. 基于HOOK机制的微信机器人为什么它比协议模拟更抗封做微信自动化的人大多经历过一个阶段先用 Web 协议、再用 iPad 协议最后发现账号还是保不住。基于 HOOK 机制的微信机器人走的是另一条路——不伪造客户端而是把代码注入到真实运行的微信进程里直接调用它内部的函数、拦截它的消息回调。微信自己怎么收消息机器人就怎么收微信自己怎么发消息机器人就怎么发。从服务端看流量特征和真人客户端几乎一致。这套方案解决的核心问题是「稳定性」和「功能深度」。协议模拟只能做服务端暴露出来的接口而 HOOK 能碰到客户端本地的所有能力本地数据库、通讯录缓存、朋友圈、群操作、甚至 UI 层的点击模拟。适合谁适合需要长期挂机、对账号存活率有要求、又愿意折腾逆向工程的开发者。代价是门槛高——你得懂一点 C/C、懂进程注入、懂逆向工具。下面把我踩过的路拆开讲。2. 先搞清楚 HOOK 到底钩在哪里三种注入点与选型2.1 消息接收链路从网络回调到本地入库微信收到一条消息大致经过网络层收包 → 解密 → 分发到消息处理模块 → 写入本地 SQLite → 通知 UI 刷新。HOOK 的黄金位置在「分发到消息处理模块」这一步因为此时消息已经解密成明文结构体又还没落库你能拿到最原始的数据。常见做法是找到消息分发的导出函数或虚表入口用 inline hook 替换函数头几个字节跳转到自己的处理逻辑处理完再跳回去。这样微信自身的流程不受影响你只是「旁听」了一遍。// 伪代码inline hook 的基本骨架x86 为例 // 1. 保存原始函数头 5 字节 BYTE originalBytes[5]; memcpy(originalBytes, targetFunc, 5); // 2. 构造跳转指令jmp 到我们的 hook 函数 // 计算相对偏移 hookFunc - targetFunc - 5 DWORD offset (DWORD)hookFunc - (DWORD)targetFunc - 5; BYTE jmpCode[5] { 0xE9 }; memcpy(jmpCode 1, offset, 4); // 3. 修改内存保护并写入 DWORD oldProtect; VirtualProtect(targetFunc, 5, PAGE_EXECUTE_READWRITE, oldProtect); memcpy(targetFunc, jmpCode, 5); VirtualProtect(targetFunc, 5, oldProtect, oldProtect); // 4. hook 函数里先恢复原始字节调用原函数再重新 hook // 这叫 trampoline是 inline hook 的标准套路逻辑说明这段代码做的是「偷梁换柱」——把目标函数开头改成跳转指令。参数上targetFunc是你逆向找到的消息处理函数地址hookFunc是你的回调。关键点是第 4 步的 trampoline调用原函数前必须把原始字节写回去否则会无限递归。这是新手最容易翻车的地方表现为微信直接崩溃。2.2 发送链路主动发消息要绕过的两个校验收消息相对简单发消息才是坑。微信发送消息前会做两层校验一是登录态校验二是消息内容合法性校验。如果你直接调用底层发送函数很可能因为缺少上下文而失败。稳妥的做法是 HOOK 发送函数的入口在微信自己触发发送时「搭便车」或者构造完整的调用上下文再调用。我一般会先逆向出消息结构体的内存布局按字段填好再调用发送函数。// 伪代码构造并发送一条文本消息 struct WxMessage { int type; // 消息类型1文本 char wxid[64]; // 接收方 wxid char content[4096]; // 消息内容 int msgId; // 消息 ID可填 0 让微信自己生成 }; void sendText(const char* toWxid, const char* text) { WxMessage msg {0}; msg.type 1; strncpy(msg.wxid, toWxid, sizeof(msg.wxid) - 1); strncpy(msg.content, text, sizeof(msg.content) - 1); msg.msgId 0; // sendMsgFunc 是逆向得到的发送函数地址 sendMsgFunc(msg); }参数说明type字段不同版本微信可能不同需要自己逆向确认wxid是微信内部 ID不是微信号content长度要留足超长消息微信会自己分片。这里最大的坑是结构体对齐——不同编译选项下字段偏移会变一定要用逆向工具实际确认别照抄网上的偏移量。2.3 选型对比inline hook、虚表 hook、导入表 hook方式适用场景稳定性难度inline hook普通导出函数高中虚表 hookC 类成员函数中中高导入表 hook系统 API 调用高低消息钩子Windows 消息循环高低选型建议优先找导出函数做 inline hook最稳。虚表 hook 适合钩 C 对象的方法但要先定位对象实例。导入表 hook 只能钩系统 API对微信内部逻辑无能为力。消息钩子适合做 UI 层自动化不适合做业务逻辑。3. 从零跑通一个最小 HOOK 机器人注入、定位、回调3.1 进程注入把 DLL 送进微信进程HOOK 代码必须以 DLL 形式注入到微信进程。最经典的是CreateRemoteThreadLoadLibrary组合。// 伪代码远程注入 DLL BOOL injectDll(DWORD pid, const char* dllPath) { HANDLE hProcess OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid); if (!hProcess) return FALSE; // 1. 在目标进程申请内存写入 DLL 路径 SIZE_T pathLen strlen(dllPath) 1; LPVOID remoteMem VirtualAllocEx(hProcess, NULL, pathLen, MEM_COMMIT, PAGE_READWRITE); WriteProcessMemory(hProcess, remoteMem, dllPath, pathLen, NULL); // 2. 拿到 LoadLibraryA 地址kernel32 在各进程地址一致 LPVOID loadLib (LPVOID)GetProcAddress( GetModuleHandleA(kernel32.dll), LoadLibraryA); // 3. 创建远程线程执行 LoadLibraryA HANDLE hThread CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)loadLib, remoteMem, 0, NULL); WaitForSingleObject(hThread, INFINITE); // 4. 清理 VirtualFreeEx(hProcess, remoteMem, 0, MEM_RELEASE); CloseHandle(hThread); CloseHandle(hProcess); return TRUE; }逻辑说明核心思路是让目标进程自己调用LoadLibraryA加载你的 DLL。参数上pid是微信进程 IDdllPath必须是目标进程能访问的绝对路径。注意如果微信是 64 位你的 DLL 也必须是 64 位位数不匹配注入会静默失败——这是最常见的翻车点表现为CreateRemoteThread返回成功但 DLL 没加载。3.2 定位关键函数用特征码而不是硬编码地址微信每次更新函数地址都会变。硬编码地址的机器人活不过一次更新。正确做法是用特征码signature扫描。// 伪代码特征码扫描 // 特征码是一段字节序列用 ?? 表示通配 BYTE pattern[] { 0x55, 0x8B, 0xEC, 0x83, 0xEC, 0x??, 0x53, 0x56 }; char mask[] xxxxxx?xx; DWORD scanPattern(BYTE* moduleBase, DWORD moduleSize, BYTE* pattern, char* mask) { DWORD patLen strlen(mask); for (DWORD i 0; i moduleSize - patLen; i) { bool found true; for (DWORD j 0; j patLen; j) { if (mask[j] ! ? moduleBase[i j] ! pattern[j]) { found false; break; } } if (found) return (DWORD)(moduleBase i); } return 0; }参数说明pattern是你要找的字节序列mask里x表示精确匹配、?表示通配。特征码要选函数入口附近、且不随版本变化的字节。我一般会选「函数序言 一段独特逻辑」的组合太短容易误匹配太长容易随版本失效。扫描范围是整个模块的代码段用GetModuleInformation拿到基址和大小。3.3 回调处理把消息转成自己的数据结构HOOK 到消息函数后参数是微信内部的结构体指针。你需要按逆向出的布局解析它。// 伪代码消息回调 void __stdcall onMessage(void* msgPtr) { // 按逆向布局解析 WxRawMsg* raw (WxRawMsg*)msgPtr; if (raw-type ! 1) return; // 只处理文本 // 转成 UTF-8 char utf8Content[4096] {0}; WideCharToMultiByte(CP_UTF8, 0, raw-content, -1, utf8Content, sizeof(utf8Content), NULL, NULL); // 交给业务逻辑 handleMessage(raw-fromWxid, utf8Content); // 调用原始函数保证微信自身流程继续 callOriginal(msgPtr); }逻辑说明WxRawMsg是你根据逆向结果定义的结构体字段顺序必须和内存布局一致。WideCharToMultiByte做编码转换微信内部多用 UTF-16。最后一定要调用原始函数否则微信自己的消息处理会断掉表现为消息不显示、UI 卡死。4. 避坑指南五个让机器人当场翻车的细节4.1 注入后微信闪退现象注入成功瞬间微信进程消失。原因DLL 里在DllMain做了太多事比如创建线程、加载资源。DllMain在加载锁内执行任何阻塞操作都会死锁。解决DllMain里只做最轻量的初始化把 HOOK 逻辑放到一个独立线程里延迟执行。4.2 消息重复处理现象一条消息触发了两次回调。原因inline hook 的 trampoline 写错或者同时 hook 了多个入口。解决检查 trampoline 是否在调用原函数前恢复了原始字节用日志确认回调次数只保留一个 hook 点。4.3 特征码更新后失效现象微信更新后机器人找不到函数。原因特征码选得太靠近版本相关逻辑。解决多准备几组特征码做冗余或者用「函数调用关系」定位——先找一个稳定的调用者再顺着调用链找目标。4.4 发送消息无响应现象调用发送函数返回成功但消息没发出去。原因缺少登录态上下文或者结构体字段偏移错误。解决用逆向工具实际确认结构体布局优先在微信自己发送时搭便车而不是凭空构造。4.5 多开时 hook 串号现象开了两个微信消息发错账号。原因DLL 是进程级注入但你的全局变量是模块级共享。解决所有状态用线程局部存储TLS或者按进程 ID 隔离别用全局单例。5. 进阶用消息队列解耦业务与 HOOK 层HOOK 层最忌讳写业务逻辑。回调函数里做数据库查询、网络请求会阻塞微信主线程轻则卡顿重则崩溃。我的习惯是HOOK 层只负责「收消息、丢队列」业务层从队列里取。// 伪代码无锁队列解耦 #include atomic struct MsgNode { char from[64]; char content[4096]; MsgNode* next; }; std::atomicMsgNode* g_head{nullptr}; // HOOK 回调只入队不做业务 void onMessage(void* msgPtr) { WxRawMsg* raw (WxRawMsg*)msgPtr; MsgNode* node new MsgNode(); strncpy(node-from, raw-fromWxid, sizeof(node-from) - 1); // ... 填充 content node-next g_head.load(); while (!g_head.compare_exchange_weak(node-next, node)) {} callOriginal(msgPtr); } // 独立线程出队处理 void workerThread() { while (true) { MsgNode* node g_head.load(); if (node g_head.compare_exchange_weak(node, node-next)) { handleMessage(node-from, node-content); delete node; } else { Sleep(10); } } }逻辑说明用无锁栈做单生产者单消费者队列HOOK 回调只做入队耗时操作全在 worker 线程。参数上Sleep(10)是空转间隔太短浪费 CPU太长增加延迟10ms 是个平衡点。注意内存管理——new出来的节点必须有人delete否则长时间运行会内存泄漏。验证方法跑一个压测脚本每秒往机器人发 100 条消息观察微信内存占用和消息延迟。如果内存持续上涨就是队列泄漏如果延迟飙升就是 worker 线程处理不过来需要加线程或优化业务逻辑。最后说个血泪教训别在 HOOK 层用异常。微信进程里抛异常如果没有正确的栈展开信息整个进程直接挂掉连日志都留不下。所有可能失败的操作都用返回值判断别图省事用 try-catch。这个习惯帮我省了无数次「微信突然消失但不知道为什么」的排查时间。希望帮到你。本文还有配套的精品资源点击获取
