jshook：给 AI Agent 配一套前端逆向工程「手术刀」

图：jshook 项目图标（来自项目仓库 docs/public/favicon.png）

一、一个具体的场景

你拿到一个压缩混淆过的 JS bundle，想搞清楚它到底做了什么：加密算法在哪、签名怎么算、有没有反调试。用 AI Agent 分析听起来很美，但现实是——传统 MCP 服务器给 Agent 暴露几十个手工搓的工具，每个都要模型填一大坨参数，token 成本爆炸，能力却零散。

vmoranv 的 jshook 给出的答案是：735 个工具，36 个领域，但默认不让模型一次看全。

二、它是什么

官方定位："A search-first, profile-aware reverse-engineering workspace for AI agents — 735 tools across 36 domains in one MCP server."

作者自己给出的类比很贴切：它不是「几个包装好的工具」，而是**「一个前端逆向工程的操作系统」**。

关键设计是 search-first + profile-aware：

Profile	暴露内容	token 成本
search	BM25 + 混合向量排名的检索元工具	约 3K tokens
workflow	复合脚本	中等
full	全部 735 个工具	约 109K tokens

作者在 README 里明确标注了测量日期（2026-10-10）并提醒这个数字随工具增长要重测。Agent 按任务复杂度在 search → workflow → full 之间切换，而不是第一轮就被 schema 淹没。

三、一个类比：手术室里的器械柜

传统做法相当于给模型一份 735 件器械的清单，让它自己想该拿哪把——结果就是每轮对话都拖着整个柜子的重量。

jshook 的做法像手术器械柜配了一个语音检索助手：你说「我要找签名算法」，检索助手（search_tools + BM25 + 向量混合排序）只把最相关的几件递到手边；真需要全套时才打开整个柜子（full profile）。

这不是简单的「少给点上下文」——它把工具发现本身变成了一个可被检索的问题。

四、核心能力

能力覆盖得相当硬核，一句话概括就是「Hook the page, capture the network, deobfuscate the bundle, disassemble the WASM, instrument the process」：

• 浏览器自动化：Chromium 与 Camoufox，经 CDP attach 到已存在的目标，反检测预设，显式输入的 CAPTCHA 求解器（不做内置页面/特征探测），按需签发的自签 HTTPS 拦截 CA，HTTP/2 帧构造
• 网络拦截：HTTP/1.1 + HTTP/2 帧构造、自动生成 CA 的 MITM 代理、WebSocket 抓包、GraphQL 内省辅助、Burp Suite 桥接
• JS Hook 与分析：LLM 驱动的反混淆、加密例程检测、AST 理解、source map 重建、脚本与 scriptlet 提取与重放
• WASM 逆向：wabt 反汇编与 C 转译（wasm2wat/wasm-decompile/wasm-objdump/wasm2c）、Binaryen wasm-opt、纯 TS section 解析、函数级二进制 diff、函数与基本块级插桩
• 进程与内存取证：原生 FFI 扫描、交叉引用图、硬件断点、PE 内省、活进程 attach、内存读写与区域守卫
• 二进制插桩：Frida 桥、Ghidra 与 IDA 桥、syscall hook、TLS keylog 与会话工具、Mojo IPC 分析
• Android / APK 分析：静态 triage、manifest 导出与查询、apktool 解包与回编、jadx 反编译与代码搜索、DEX 扫描、APK 签名、unidbg 模拟、运行时 DEX dump
• 编码与变换：URL/Base64/Hex/JWT/Protobuf 编解码、AST 变换、流式解码管线
• 协调能力：带进度、取消与异步模式的后台任务队列、多 Agent 协作、覆盖率报告

还有一组「schema 优先」的元工具：describe_tool、带参数校验的 call_tool、coverage_report、search_tools——调用工具前先查 schema，这是减少模型幻觉式参数填错的机制。

运行时恢复与会话隔离

Streamable HTTP 会话在重连后能恢复已激活的领域、浏览器 attach 状态和覆盖率状态；每个客户端的浏览器侧状态相互隔离，两个 Agent 不会踩到彼此的 CDP 会话。

动态可扩展

热重载插件、声明式工作流、自动发现领域——扩能力不用重新部署。

五、上手门槛

技术栈：TypeScript strict，Node.js 22.22.2+ 或 24.15+，pnpm 10.x workspace，MIT/AGPL 双许可文件（README 标注 AGPLv3）。MCP 当前版本协议。

需要额外外部依赖的部分要注意：WASM 反汇编依赖 wabt（wasm2wat 等），反编译与插桩依赖 Frida、Ghidra、IDA——这些是可选的外部工具，不是开箱即用。

无 Web UI：本质是一个 MCP server，通过 stdio 或 Streamable HTTP 接入 Agent 宿主，没有独立界面（docs/ 是 VitePress 文档站）。

硬件要求不高，但浏览器自动化与 WASM 分析会吃内存：建议 4GB 以上内存，磁盘 1GB 起。CPU 2 核以上更稳。不需要 GPU。

六、争议与局限

AGPL-3.0 协议。 对企业内部使用无碍，但任何「提供网络服务」的场景需要格外注意 AGPL 的开源义务。

能力边界取决于外部工具。 宣称支持 Ghidra/IDA/Frida/Burp 桥接，意味着一半的深度能力要用户自己装这些工具并配好环境——「735 个工具」里有相当比例是这些工具的胶水层。

逆向与安全用途的伦理边界。 具备反检测、CAPTCHA 求解、进程注入、内存读写能力，任何合法使用都需要遵守所在司法辖区的法律与授权范围。项目里有 SECURITY.md 和 DISCLOSURE 文件，说明作者对这类边界有意识，但使用者自己的合规责任不会因此减轻。

版本激进。 Node.js 版本要求卡得很死（22.22.2+ / 24.15+），且明确说明「Node.js 22.22+ 或 24.15+」这种精度通常意味着踩过版本坑。

项目很新、贡献者极少。 仓库只有 2 位贡献者，735 个工具的维护广度存疑；.fallowrc.json、.lychee.toml 等配置文件显示工程规范在位，但人力是瓶颈。

七、行业意义

MCP 生态正在快速膨胀，但多数 MCP 服务器是「把现有 CLI 包一层」。jshook 走的是另一条路——把一个完整的专业领域（前端逆向）整体建模成 36 个领域、735 个工具的目录结构，并且用检索机制解决「工具太多会淹死模型」这个 MCP 的核心矛盾。

它揭示了一个重要趋势：MCP 服务器的竞争维度正在从「有多少工具」转向「工具多了之后怎么让模型用得动」。search-first profile 加 BM25 + 混合向量排序，是把 RAG 思路应用到工具选择上的直接尝试，这个模式会被后续的 MCP 服务器大量借鉴。

另一个值得关注的设计是 describe_tool + call_tool 的 schema-first 调用——把「先看说明书再动手」变成协议层强制，而不是靠提示词祈祷。

对安全研究员：它把分散的工具链（wabt、Frida、jadx、apktool、Burp）整合成一个 Agent 可直接调用的工作台；对 AI Agent 基础设施开发者：它是「大规模工具集如何不压垮上下文」的一个可参考实现。