MCPModel Context Protocol这个词今年在 AI 工程圈里已经被聊烂了但大多数案例都停留在“给 AI 挂个数据库”“让 AI 查个文档”这种工具层面。我最近三个月一直在试一个更野的路子把 MCP 当成 JS 逆向工程里的“AI 调度中枢”让大模型不再只靠猜和翻代码而是通过标准协议直接操纵抓包、断点、AST 分析、运行时插桩这些逆向老底子工具。这套工作流跑通之后我再回头看传统的“人肉定位加密函数 → 啃混淆代码 → 手写还原脚本”的流程真的有一种降维打击的错觉。这篇文章我会把完整的思路、架构设计、核心代码、踩坑记录和合规边界一次性讲清楚适合对 JS 逆向有一定基础、正在研究 AI Agent 落地场景的工程师也适合想给大模型扩展“动手能力”的技术爱好者。1. 为什么逆向工作流里需要一个“AI 调度中枢”1.1 传统 JS 逆向的三个老大难先说最真实的痛点。做过 JS 逆向的朋友应该都有这种体验拿到一个站的 sign、token 生成逻辑第一件事是 CtrlShiftF 全局搜参数名然后把可疑的 JS 文件一段段拷进本地重命名变量、格式化、删死代码再看有没有 eval、Function 构造器、obfuscator 痕迹。这一套流程最大的问题不是“难”是“碎”——你的注意力要在 DevTools、文本编辑器、控制台、抓包工具之间来回切而且绝大多数时间都花在了“看不懂这段代码到底在干什么”上。第二个痛点是混淆代码。现在前端工程里用 JavaScript obfuscator、webpack 压缩、字符串数组移位都是标配遇到控制流平坦化之后代码读起来跟天书一样。传统解法无非是插桩打点、Hook 关键函数、在运行时把真实逻辑“钓”出来但这又依赖你对目标框架的熟悉程度——很多新手直接卡在第一步不知道该在哪个位置打断点。第三个痛点是还原脚本的编写。就算你定位到了加密函数要把它翻译成 Python、Go 或者别的语言的调用逻辑里面还有一堆浏览器环境特有的兼容问题比如window.btoa、crypto.getRandomValues、Canvas 指纹在 Node 或者 Python 里根本不存在。这一环节需要的是“经验翻译官”而这恰恰是 AI 最擅长的事情。1.2 MCP 把 AI 从“聊天框”变成“工作台”MCP 这个协议解决的核心问题是让大模型不再活在对话框里。它把外部能力封装成“工具Tools”“资源Resources”“提示词Prompts”三类接口AI 通过标准协议去调用这些接口就像你在命令行里敲命令一样。打个比方之前你用 ChatGPT 做逆向等于请了一个只会看代码、不会动手的军师接了 MCP 之后这个军师长出了手和脚能自己抓包、自己跑脚本、自己验证假设干完活再把结果汇报给你。回到 JS 逆向这个场景MCP 能做的事情就很具体了AI 可以直接调用一个fetch_js_source工具把目标 JS 拉到本地调用run_js_snippet工具在模拟环境里执行一段代码并返回结果调用search_ast_nodes工具在抽象语法树里精准定位某个函数。这些操作全部由大模型根据当前分析进度动态决定不需要你在边上一直指挥。实际体验下来原来“定位加密入口”这一步通常要花 1~2 小时现在 AI 在十几分钟内就能完成第一轮假设并且给出可信度很高的结论。所以这篇文章要构建的东西本质上是一个“AI 逆向工作台”——一个专门为 JS 逆向场景设计的 MCP Server配合上大模型客户端形成一套可以反复使用、不断扩展的半自动逆向流水线。2. 整体架构面向 JS 逆向的 MCP Server 选型与设计2.1 技术选型Node 还是 Python实现 MCP Server 的主流方案有两个官方 TypeScript SDK 和 Python SDK。我个人的建议是如果你要做的辅助对象是 JS优先选 NodeTypeScript方案。原因是 JS 逆向过程中大量环节都绕不开“跑 JS”这件事用 Node 做 MCP Server 可以用同一个运行时对外暴露vm、child_process、jsdom这些模块能少踩很多跨语言通信的坑。Python 方案的优势在于数据处理和分析库丰富比如tree-sitter、capstone如果你后续打算深度做 AST 模式识别或者二进制层面的分析Python 会更顺手。我目前的主力是 Node TypeScript下面所有代码示例也以这个技术栈为准。MCP Server 和客户端的连接方式有两种stdio 和 HTTPSSE。本地调试、配合 Cline / Claude Desktop 这类桌面客户端用 stdio 最简单——客户端直接起一个子进程通过标准输入输出走 JSON-RPC 消息。如果你想做远程共享或者让 Agent 跑在服务器上那就得走 HTTP 传输配置上稍微多一点。我的建议是先按 stdio 跑通再考虑暴露成 HTTP 服务。2.2 工具Tools怎么划分才能让 AI 用起来顺手这是整个设计里最关键的环节。MCP Server 暴露给大模型的 Tools 如果粒度太粗AI 会频繁“犯迷糊”不知道怎么组合粒度太细工具列表刷屏token 消耗也撑不住。我最终收敛成了七组核心工具按职责划分如下工具分组工具名作用调用时机抓取层fetch_url下载目标 URL 内容HTML、JS、JSON自动处理编码刚开始分析一个目标站点时静态分析find_in_files在本地 JS 文件集合中按关键字/正则搜索定位某个参数名、特征字符串静态分析parse_ast解析 JS 文件生成语法树支持查询函数、变量、调用关系需要理解代码结构时动态执行run_js在沙箱环境执行 JS 片段返回执行结果和 console 日志验证某个函数的输出、测试算法片段动态执行mock_dom在 jsdom 环境执行依赖 DOM/BOM 的代码遇到window、document相关逻辑时辅助分析hook_trace对目标函数插桩记录参数和返回值需要追踪运行时真实传参辅助分析gen_restore_script结合上下文自动生成 Redis / Python / Node 复刻脚本算法逻辑基本明确之后这里有个非常重要的原则每个工具的description一定要写得非常详细最好带上“何时用”“怎么组合用”的提示。比如我在fetch_url的 description 里写了一句“如果目标页面是 SPA请先尝试获取它的 JS 入口文件列表再逐个下载”这就等于在教大模型怎么排分析顺序。同一个工具描述词写得是不是够“保姆级”直接决定了大模型用它时是稳准狠还是瞎试。2.3 Resources 和 Prompts 也不能省很多人建 MCP Server 只管 Tools其实 Resources 和 Prompts 对逆向场景同样重要。Resources 可以理解为给 AI 预置一批“可读资料”比如你在 server 启动时把目标 JS 文件的元信息、加密算法指纹库、常用混淆特征库挂载进去AI 碰到不认识的特征就可以直接查。Prompts 则是预置好的“操作模板”比如“分析某个函数是否为 MD5 变体”“给出把浏览器加密逻辑改写成 Python 的步骤清单”可以让 AI 少走弯路。我后来实际使用中Prompts 用得比预期频繁很多它相当于把老师傅的“套路”固化成模板遇到新目标直接调用。3. 实操从零搭建一个 AI 逆向 MCP Server3.1 初始化项目与安装依赖先说明环境Node.js 20npm 或者 pnpm。我习惯用 pnpm依赖安装快磁盘占用小。mkdir ai-reverse-mcp cd ai-reverse-mcp pnpm init pnpm add modelcontextprotocol/sdk zod jsdom vm2 axios # vm2目前有维护问题,生产环境可以用 isolated-vm pnpm add -D typescript tsx types/node注意一点vm2这个库已经停止维护了如果你用的是最新的 Node 版本里面很多 API 会报错。我后来换成了isolated-vm隔离性比 vm2 好一个档次不过它的 API 是异步的在 MCP 工具函数里要处理好await。如果你不想引入太重的东西Node 自带node:vm也够用但要注意它只能做逻辑隔离无法做资源限制遇到恶意死循环会把整个进程拖死。我在下面的示例代码里用 Node 原生vm方便大家直接跑通。3.2 搭建最小 MCP Server先实现三个核心工具MCP SDK 里写一个工具核心就是调用server.registerTool注册工具说明和回调函数。为了不让文章被代码淹没我先展示一个“最小可运行版本”里面只放三个工具fetch_url、run_js、find_in_files这三个就能覆盖很多分析场景。import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; import vm from node:vm; import fs from node:fs/promises; import path from node:path; import axios from axios; const server new McpServer({ name: ai-reverse-mcp, version: 0.1.0 }); server.registerTool(fetch_url, { description: 下载指定 URL 的原始内容并返回。注意只能访问目标站点或您明确授权的域名。适用于抓取 JS 文件、HTML 页面。, inputSchema: { type: object, properties: { url: { type: string, description: 完整的 URL 地址 }, }, required: [url], }, async execute(args: { url: string }) { const resp await axios.get(args.url, { timeout: 15000, headers: { User-Agent: Mozilla/5.0 }, }); return { content: [{ type: text, text: resp.data.slice(0, 100000) }] }; }, }); server.registerTool(run_js, { description: 在沙箱 VM 中执行一段 JavaScript 代码返回其执行结果或 console 日志。适合测试加密函数、算法片段。代码中可以使用 console.log 输出调试内容。, inputSchema: { type: object, properties: { code: { type: string, description: JavaScript 代码内容 }, }, required: [code], }, async execute(args: { code: string }) { const logs: string[] []; const sandbox { console: { log: (...args: unknown[]) logs.push(args.map(String).join( )), }, setTimeout, clearTimeout, }; vm.createContext(sandbox); const script new vm.Script(args.code, { timeout: 3000 }); const result script.runInContext(sandbox); return { content: [{ type: text, text: stdout:\n${logs.join(\n)}\n\nresult:\n${String(result)} }] }; }, }); server.registerTool(find_in_files, { description: 在指定目录下的 JS 文件中按关键字或正则搜索返回文件名、行号和匹配内容。适合快速定位参数名、加密特征。, inputSchema: { type: object, properties: { rootDir: { type: string, description: 本地目录路径 }, pattern: { type: string, description: 正则表达式或普通字符串 }, }, required: [rootDir, pattern], }, async execute(args: { rootDir: string; pattern: string }) { const files await walk(args.rootDir, [.js, .mjs, .cjs]); const results: string[] []; const regex new RegExp(args.pattern, i); for (const file of files) { const content await fs.readFile(file, utf-8); const lines content.split(\n); lines.forEach((line, idx) { if (regex.test(line)) { results.push(${file}:${idx 1}: ${line.trim().slice(0, 200)}); } }); } return { content: [{ type: text, text: results.slice(0, 50).join(\n) }] }; }, });walk函数是一个递归遍历目录的小工具代码不算核心这里就不贴了你用fs.readdir配合递归很容易实现。跑起来也很简单加上这段const transport new StdioServerTransport(); await server.connect(transport);然后npx tsx src/index.ts就能启动。至此一个 MCP Server 已经在 stdio 上运行了。3.3 把 Server 接到 AI 客户端里MCP Server 建好之后要接进能调用 MCP 的客户端才能让 AI 用起来。目前我常用的客户端有两个Claude Desktop 和 ClineVS Code 插件配置方式差别不大。以 Claude Desktop 为例在配置文件claude_desktop_config.json里加上{ mcpServers: { ai-reverse-mcp: { command: npx, args: [tsx, /绝对路径/ai-reverse-mcp/src/index.ts] } } }Cline 的话直接在设置页面的 MCP Server 配置里新增一个 stdio 类型命令填npx tsx /绝对路径/ai-reverse-mcp/src/index.ts即可。重启客户端之后AI 的工具栏里就会出现这三个工具。你随便发一句“帮我看一下这个网站的资源怎么加载”它就会自己调fetch_url去抓内容而不用你手动给代码。如果你打算把 Server 跑在远程机器上或者需要多个客户端共用那就改用 HTTP 模式。SDK 提供了StreamableHTTPServerTransport本质上是把 stdio 的传输层换成了 HTTPSSEServer 端需要处理跨域和鉴权。在逆向这种偏敏感的场景我强烈建议不要裸奔 HTTP至少得加一层 Token 鉴权或者只允许本机访问。3.4 设计一套“逆向下发任务”的提示词模板有了工具还得教会 AI 怎么一套组合拳下来做逆向。我的办法是在 MCP Server 里预置一个 Prompt名字叫js-reverse-workflow。大模型读取这个 Prompt 之后会按顺序执行下面的流程用fetch_url下载目标 URL 下所有 JS 文件。用find_in_files在文件集合中搜索目标参数名称、算法特征词如md5、sha256、encrypt、sign。对疑似加密函数的代码片段用parse_ast或直接用find_in_files拿原始片段提取函数细节。在run_js中手动构造输入验证这个函数在隔离环境下的真实输出。遇到浏览器特有 APIwindow、document等改用mock_dom工具跑。最终把还原出的算法整理成 Python 或 Node 复刻脚本并给出测试用例。这个 Prompt 模板我放在 Server 的注册代码里了server.registerPrompt(js-reverse-workflow, { description: 标准的 JS 逆向分析流程提示词, async execute(args) { return { messages: [ { role: user, content: { type: text, text: 请按照以下标准工作流程进行 JS 逆向分析 1. 获取目标页面及 JS 资源列表。 2. 在 JS 文件中搜索目标参数相关的特征字符串。 3. 提取可疑函数代码分析其内部控制流。 4. 在沙箱中运行函数片段构造输入验证输出。 5. 如遇 DOM/BOM 环境依赖使用 jsdom 模拟。 6. 最终输出可独立运行的还原脚本并附带测试示例。 当前目标 URL${args.target ?? 未指定} 已知目标参数${args.param ?? 未指定}, }, }, ], }; }, });这样每次开启一个新目标分析只要触发这个 PromptAI 就有了明确的操作路径而不是漫无目的地瞎试。4. 实战案例用 MCP 还原一个站点的签名算法4.1 场景搭建与合规说明为了演示整个工作流我自己起了一个模拟站一个极简 SPA前端在请求详情页时会对参数做签名签名格式是timestamp nonce sha256(secret_key params)。部署在 localhost 上完全没有真实业务。之所以强调这一点是因为接下来要展示的每一个步骤都只服务于“你自己搭建的、明确授权的测试目标”。做安全研究的时候边界一定得先划清楚目标是不是你拥有授权的是否涉及第三方敏感数据如果没有授权这篇文章里的所有操作请直接换个环境教学用别往真实站点上招呼。4.2 让 AI 自己“读”页面和资源我打开客户端给 AI 下一句话“请分析 http://localhost:5173 页面里的 sign 参数是怎样生成的按 js-reverse-workflow 执行。”AI 第一件事是调fetch_url。拿回 HTML 后它发现页面里引用了/assets/index-9a8f0.js于是又调了一次fetch_url把主 JS 拉下来。之后它把下载的代码存到了本地target/目录再调find_in_files搜sign关键字。很快它就定位到一个函数generateSign(params)代码如下function generateSign(params) { const secret demo-secret-key; const sortedKeys Object.keys(params).sort(); const query sortedKeys.map((key) ${key}${params[key]}).join(); const timestamp Date.now(); return sha256(${timestamp}${query}${secret}); }这里sha256在浏览器环境里是 Web Crypto API 的实现代码里直接crypto.subtle.digest调用。AI 看懂了大概逻辑但是并不知道sha256函数的具体实现于是它继续往上层追溯调用关系用find_in_files搜sha256的定义。搜索结果里出现了crypto.js文件里面封装了 Web Crypto API。4.3 动态执行验证让 AI 自己跑 JS 验证假设如果到这里就收工那跟拿搜索引擎搜谁都能做。真正的价值在下一步AI 要确认自己的理解是对的。它从crypto.js里剪出了sha256的实现构造了一段只依赖crypto.subtle的测试代码往run_js里一丢const params { b: 2, a: 1 }; const secret demo-secret-key; const sortedKeys Object.keys(params).sort(); const query sortedKeys.map((key) ${key}${params[key]}).join(); const timestamp 1720000000000; const input ${timestamp}${query}${secret}; console.log(待签名串:, input);结果运行时报错了crypto is not defined。因为 Node 的vm环境里默认没有window.crypto。AI 自己判断出来这段代码依赖浏览器 Web Crypto API然后它改用了mock_dom工具在 jsdom 环境里把crypto.subtle补齐后再跑。执行成功返回了sha256的结果字符串。这个过程看起来平淡但实际上是整个逆向流程里最有含金量的一步。传统流程中你要对这种“浏览器 API 缺失”问题做环境修补至少要写一堆 polyfill而 AI 现在能根据报错信息自己决定换工具、补环境、再执行省掉了一个非常烦琐的调试循环。4.4 生成可独立运行的复刻脚本所有逻辑都验证通过之后AI 开始调用gen_restore_script工具。这个模板工具会把“确认无误的算法逻辑”组织成一份 Python 脚本脚本里不依赖浏览器环境直接使用hashlibimport hashlib import time def generate_sign(params: dict, secret: str demo-secret-key) - str: sorted_keys sorted(params.keys()) query .join(f{key}{params[key]} for key in sorted_keys) timestamp int(time.time() * 1000) input_str f{timestamp}{query}{secret} return hashlib.sha256(input_str.encode()).hexdigest() if __name__ __main__: demo_params {a: 1, b: 2} print(generate_sign(demo_params))同时在返回结果里附带了一组测试用例用前面run_js验证过的输入输出做对拍证明 Python 和 JS 两份实现结果一致。这一步我以前手动做少说二十分钟现在 AI 在几分钟内就给出了可运行的脚本而我的工作从写代码变成了审代码。顺带说一句真正复杂的案例里签名算法不会这么直白但整套流程是通用的定位入口 → 理解数据流 → 动态验证 → 跨语言复刻。MCP 起到的作用是让 AI 可以亲自走完这条链路而不是把代码片段贴来贴去全靠猜。5. 实战会遇到的问题与排查技巧这部分是我三个多月里踩坑最多的地方也最想分享。5.1run_js运行超时或死循环第一次跑的时候我拿node:vm直接跑一段带while(true)的代码整个 MCP 进程卡死AI 那边一直等不到结果。后来我加了timeout参数但原生vm.Script的 timeout 对很多异步死循环无效。解决方案是两步一是改用isolated-vm它支持真正的外部资源限制二是把工具回调放在单独的 worker 线程里跑超时就 kill不拖垮主进程。如果只是 demo 教学最轻量的办法是在沙箱里注入一个“安全轮子”比如限制循环次数的包装函数但这种方式无法覆盖所有场景严谨性不够。5.2 AI 一次读不完大 JS 文件现在前端打包出来的 JS 动不动就一两兆fetch_url返回前 10 万字符根本不够。解决办法是给fetch_url增加一个start和length参数支持分片读取AI 如果要分析整份文件它会先取头部理解入口再按需分片拉取。这个工具描述里也得写清楚“大文件请使用分片参数”。5.3 工具返回结果太长还是把 AI 的上下文撑爆了AI 上下文窗口再大也架不住往里面塞几兆纯文本。我在工具层做了两件很重要的事一是命中分析只返回关键片段比如函数名、参数名、前 N 行代码而不是整段源码二是对搜索结果做去重和摘要先在服务端筛选一遍只把疑似命中的几行发给模型。这样既省 token也让模型的注意力更集中。5.4 浏览器环境依赖window、document、navigator真实站点的加密代码里几乎不可能不碰浏览器 API。vm沙箱里没有这些跑起来就报 ReferenceError。我用 jsdom 做了mock_dom之后情况好了很多但 jsdom 对 Canvas、WebGL、Service Worker 这些也是缺的。经验法则是先把纯逻辑函数扣出来跑遇到浏览器 API 再逐步补齐不要一上来就想完整模拟整个页面。更讲究一点的做法是把检测到的浏览器 API 依赖自动上报到 AI让它决定是 mock 还是绕过。5.5 重连后 MCP Server 状态丢失stdio 模式下客户端重启意味着 MCP Server 子进程也重启了。你之前下载到本地target/目录的文件是在的但 Server 内存里的沙箱状态、上下文缓存会清空。我吃了几次亏之后养成了一个习惯所有中间分析结果都写成文件落盘工具调用时优先读盘而不是重新抓。这样即使断连AI 重启后也能接着上次的进度干活。5.6 权限与授权边界一定要在 Prompt 里写死这个问题我放在最后但分量最重。我经历过 AI 顺着 “搜索关键字” 的指令去访问内网地址、去抓没有授权的域名的操作虽然只是发生在测试环境但也吓出一身冷汗。后来我在 Server 端加了一个硬编码的allowedDomains列表凡是fetch_url的目标域名不在列表里一律拒绝。这个行为准则同时写进了 Prompt 和工具 description 里让 AI 在没有明确授权的情况下不要尝试任何越界访问。做逆向研究工具能力越强越要在条例层面把护栏打牢。6. 我个人的几点收尾体会玩这一整套东西我自己最有触动的不是“AI 能代替人做逆向”而是“AI 把逆向里最消耗耐心的部分接管了过去”。定位模糊的逻辑、反复试错、翻译成另一门语言这些事 AI 都可以很快给出版本而人只需要做最终的判定和调试。给我带来的直接变化就是一个中等复杂度的签名算法我以前从拿到 JS 到交出可运行脚本大概要一个下午现在只要目标不涉及冷门混淆方案基本压缩到一个小时以内。但我也要泼一盆冷水不要把它的能力想得太神。遇到高度商业化的混淆框架、VMP 级别的保护、需要动态跟踪大量 WebAssembly 的场景目前的 MCP 大模型组合还是会有很大的理解障碍工具层面也需要继续扩展比如把内存堆快照、调用栈回放、浏览器 CDP 协议接进来。AI 逆向 MCP 这套架构真正的价值是给了所有人一个把“AI 辅助”从聊天框拽进真实工作流的样板——往后的灵活玩法本质上都取决于你到底愿意给 AI 接上哪些工具。最后分享几个我沉淀下来的经验也算给后来者提个醒工具粒度一定要按“逆向流程”设计而不是按“文件目录”设计。AI 需要的是分析能力不是文件管理能力。别一开始就追求全自动化。先把 fetch → find → run 三个工具跑通让 AI 辅助你完成一条链路再用实战数据反推还需要哪些工具。用 MCP 做逆向第一原则永远是合规。只在得到授权的目标上做研究不要因为 AI 能快速干活就去碰不该碰的站点。如果你也在折腾类似的 AI Agent 工具欢迎顺着这套思路去扩展自己的 MCP Server后续可以考虑接入 CDP 调试器、AST 重构引擎、甚至是运行时的堆栈回溯能力。工具链还很年轻但方向是靠谱的。