前端JS逆向是个体力活尤其是碰上大型SPA应用、压缩混淆得面目全非的bundle文件再加上动态加载、VM保护这些反调试手段手动在浏览器断点里泡一整天是常有的事。我做逆向也有些年头了从最早的charles抓包、Fiddler改请求到后面用rewriters、patch代码、写油猴脚本一直在跟各种防护较劲。这两年大模型工具链成熟之后我开始琢磨一件事既然AI能理解代码上下文能不能让AI自己去找加密函数、自己断点、自己跑参数答案就是现在这整套流程的核心——MCP协议加Skill封装把浏览器调试能力、请求改包能力和Crypto算法识别能力一起暴露给模型让AI当执行者我做审核和兜底。这篇文不聊空洞概念直接把我在实际项目里跑通的MCPSkill前端JS逆向自动化链路摊开讲包含架构设计、关键节点拆解、Agent指令书写、踩坑记录以及我打包好的一套工具适合已经会用chrome devtools手动找加密参数的逆向工程师或者正在做AI自动化测试、想要把AI Agent落到真实业务里的开发。## 1. 为什么前端JS逆向会成为AI自动化的最佳试验场 做过逆向的人都清楚真正的难点不是看不懂代码而是面对一个动态、混淆、无限分支的真实前端环境找不到正确的断点位置。传统手动流程里70%的时间花在定位上打开Sources面板、搜索关键字、下断点、看调用栈、切到Console验证输出结果然后重来。真正写加密函数提取逻辑、写Hook脚本的时间只占30%。所以当AI Agent出现时第一反应就是它能不能帮我干那70%的活。 ### 1.1 手动逆向的重复性痛点 以常见的登录接口为例它通常会在早于XHR请求十几步的调用链里完成加密参数构造而你从Network面板只能看到最后的payload。手动跟踪的方式无外乎三件事——在Call Stack里逐层点进去找可疑函数名、在Sources里搜关键词比如sign、encrypt、token、md5、用自带的格式化工具处理压缩的minified代码。每个接口都要重复这套流程每换一个站点或者接口改版又得从头走一遍。 更费精力的是参数构造的验证环节。你在一个断点上下文里手动执行了encrypt(12345)输出结果符合预期但当你把它整理成独立的静态代码段时发现代码里还引用了全局对象、请求实例、甚至页面初始化时的配置项。这就是上下文依赖逆向工程里的常客。AI Agent在执行任务时同样会碰到它必须有能力在浏览器上下文里持续运作而不是只在静态代码里做分析。所以自动化方案的前提是Agent必须有一双手能够在目标页面环境里做动态操作。 ### 1.2 AI Agent能切入的四个关键环节 我把前端JS逆向的完整流程拆成四个环节**入口定位**找到加密函数在哪个JS文件里、**逻辑还原**分析函数内部的运算流程确定参数来源、**Hook验证**不修改源码的情况下捕获运行时的真实参数值、**脚本复用**把还原的算法提取成独立模块给后续自动化接口调用使用。 这四个环节里入口定位和Hook验证对AI来说最难因为它们需要与浏览器实时交互打开DevTools、在指定文件行下断点、单步执行、读取Scope里的变量快照。以前这些操作只能靠人来做但有了MCP协议之后情况就变了——它让模型可以直接调用浏览器调试协议甚至执行Playwright的页面操作和抓包工具的请求转发。Skill则负责把一套完整的逆向方法论封装成可复用的流程AI拿到任务后会按照这套Skill里的步骤来行动而不是凭空发挥。这其实就是我把整个方案落地时最核心的架构思路。2. MCP协议与Skill机制的完整拆解不先把MCP和Skill讲清楚后面的实操步骤理解起来会比较吃力。先说MCP这个协议解决的是AI模型与外部工具之间的连接问题。它不是新造了一套通信方式而是用JSON-RPC标准把工具调用封装起来让模型在生成回复的同时能够调用一系列由MCP Server提供的工具函数并拿到返回值作为上下文继续推理。2.1 MCP Protocol到底做了什么类比一下最直观以前的AI是只有脑子没有手不管推理能力多强输出只能是文字要让它操作浏览器、发请求、写文件就得靠我们写代码把它的输出结果转成指令。MCP就相当于给大脑接上了一副手套和一套传感器——手工管理时需要的各种专业技能比如浏览器网络监控、JS代码执行、DOM操作封装成一个个工具函数配置在MCP Server端模型通过协议去调用拿到执行结果再继续下一步推理。举个例子MCP Server里注册了一个叫execute_js_code的工具参数是你要在页面里执行的JS代码字符串返回的是执行结果。AI Agent在逆向分析过程中如果需要在目标页面里执行document.querySelector(input[nameusername]).value test它会直接调用这个工具而不需要我们写任何额外的胶水代码。这里重量级的应用场景是将**Chrome DevTools ProtocolCDP**的能力变成MCP工具。通过CDP我们能拿到目标页面的所有调试信息源码列表、断点命中事件、Scope变量、Network请求详情、Console输出甚至可以直接修改页面JavaScript执行环境里的对象和方法。把这些能力变成MCP工具后AI就不只是说了而是真正在浏览器里动手。2.2 Skill是如何把逆向方法论沉淀下来的Skill在MCP体系里是另一层抽象——它负责把一个完整的任务流程编排成模型可执行的步骤清单。你可以把它理解为给AI的操作说明书。好的Skill里面会写清楚遇到一个任务时要先做什么、再做什么、什么时候调用哪个MCP工具、遇到什么情况要停下来询问用户以及哪些常见坑位需要规避。我这套逆向Skill里定义了标准作业流程SOP核心是四个阶段阶段Skill内规定的动作涉及MCP工具入口分析从Network请求出发追溯发起者JS使用Sources搜索关键词network_capture, source_list, search_in_file断点定位在可疑函数处下断点触发请求检查命中情况set_breakpoint, reload_page, check_call_stack参数还原读取Scope变量分析调用流程必要时修改变量值观察响应get_scope_values, execute_js_code, manipulate_stack脚本生成还原加密算法到独立Node/Python模块与项目对接generate_code, run_node_script, diff_code这套Skill的价值在于它把资深逆向工程师的经验转移成了结构化的指示让AI Agent能够在没有人工频繁介入的情况下按部就班地执行任务的探路与验证部分。而人工负责的是审核与兜底——也就是真正难啃或模糊的部分以及最后算法还原的确认。2.3 模型是如何把两者组合起来的在实际运行时我通过两套MCP Server来支撑这套链路一套对接本地的浏览器实例通过CDP暴露协议一套对接请求改包和JS执行环境。Skill则会以系统提示词或独立知识库文件的形式被加载进模型上下文里。AI在拿到一个具体逆向目标时它会检索Skill里的SOP条目然后开始调用MCP工具执行操作。举个例子AI收到任务找出某个登录时sign参数的生成本地算法。它第一步是调用network_capture工具去监听即将发生的登录请求同时调用search_in_file在Sources里搜索含sign关键字的代码片段。找到了目标函数后它会在这一行设置断点然后执行页面里的登录操作通过调用page_click或execute_js_code等断点命中后再调用get_scope_values把Scope里所有变量的值抓取出来。最终它会把这些变量和代码逻辑组装成一段Node.js脚本在本地跑通验证输出结果。我实测下来这一套组合非常顺滑尤其是AI对上下文的记忆能力被充分发挥不需要我们像教新手那样每一步都告诉它怎么做。不过这也对Skill本身的结构化程度提出了很高要求写得含糊AI执行起来就会到处飘。## 3. 自动化逆向的整体架构设计与Agent指令编排 直接进入落地环节。我在真实项目里完整跑通的自动化平台分成四层**浏览器操控层**、**协议转发层**、**Agent决策层**、**验证执行层**。四层之间通过MCP工具的调用串联起来核心编排任务交给Skill定义好的流程。 ### 3.1 浏览器操控层CDP Playwright MCP 这一层负责让AI真正拥有手和眼睛。我用的方案是用Playwright封装一个MCP Server对外暴露工具打开页面、点击元素、输入文本、填写表单、执行JS、等待网络请求。这些工具底层全部走Playwright的API而Playwright本身可以无缝对接Chromium实例并开启CDP支持。 关键配置点在于必须以非headless模式启动浏览器并且关闭自动化控制提示。启动参数我推荐用--remote-debugging-port9222这样便于通过CDP直接连接。另一个重要参数是--disable-blink-featuresAutomationControlled它能把window.navigator.webdriver标志隐藏掉避免一些站点检测浏览器环境。对于逆向场景环境一致性和自动化隐藏同样重要否则目标站点可能会在早期就中断操作。 实际配置示例我用的运行脚本 javascript const { chromium } require(playwright); const browser await chromium.launch({ headless: false, args: [ --remote-debugging-port9222, --disable-blink-featuresAutomationControlled, --no-sandbox ] }); const context await browser.newContext({ viewport: { width: 1366, height: 768 }, userAgent: Mozilla/5.0 ... Chrome/120.0 Safari/537.36 });3.2 协议转发层抓包改包工具转成MCP能力这一层的作用有两个一是录制完整请求链路二是把请求拦截下来做修改让AI可以研究请求参数的具体生成逻辑。市面上的抓包工具很多我最终选择把BurpSuite和基于Node的自研抓包工具同时接入MCP。原因很简单Burp的拦截和重放功能非常成熟但它的UI交互不适合AI我用一个Node脚本把Burp的API封装成MCP工具包括intercept_request、modify_request_header、resend_request、get_request_detail。另一个重点是需要主动构造参数的场景。有些加密参数手动断点很难捕获上下文AI需要反复修改请求体来观察服务端是否返回不同的报错信息从而推断加密参数的规则。把这个能力也封装进MCP工具后AI的执行链条就完整了从浏览器里引发请求、从代理层拦包改包、从服务端响应推断算法约束。3.3 Agent决策层模型如何理解任务并根据Skill执行Agent决策层的核心是Claude或GPT-4系列模型在系统提示词里注入了全套Skill配置。需要注意的是模型默认行为是想到哪做到哪它不会天然按照你定义的逆向方法论执行。所以我设计了一套分层指令框架第一层是全局目标描述告诉模型当前项目的最终产出是什么第二层是Skill的通用步骤告诉模型拿到任何一个任务后应该从哪几个方面切入第三层是具体任务参数比如当前要逆向的接口地址、要提交的表单字段。举个例子在Skill配置文件中我会写global_goal: 还原目标登录接口的sign生成算法输出独立Node.js模块 skill_steps: - name: 入口追踪 action: 从Network面板中找到/login请求的Initiator JS文件 - name: 关键字搜索 action: 在该JS文件中搜索sign相关的字符串 - name: 断点调试 action: 在包含sign赋值的代码处设置断点触发请求 - name: 参数检查 action: 断点命中后收集Scope里的关键变量名与实际值 - name: 逻辑还原 action: 基于变量名和值推测并验证加密逻辑生成代码3.4 验证执行层自动化跑通算法脚本最后一层解决的是AI生成的算法脚本是否正确的问题。AI在分析之后会生成一段Node.js或Python代码这段代码不能直接认定为可用必须拿到本地环境里跑用真实输入的明文参数算出结果再和目标请求里的密文参数比对。因为Skill里定义好了流程AI会自动调用run_node_script工具执行代码再用compare_result工具比对输出。如果比对不一致它会回到参数检查环节重新分析。这整个循环就不需要人工盯着你只需要设定最大循环次数和单步超时时间防止AI在一处卡死。我实测里单接口的完整自动化逆向平均循环次数在3-6次之间可以跑出一个可靠结论耗时大约8-12分钟。## 4. 关键断点定位的实战链路从加载器到加密函数 这一章我用一个真实示例来演示链路怎么走通。目标是一个比较典型的加密传输站点所有API请求都会携带一个cipher参数参数值是固定字符串时间戳随机数经加密后的结果。手动定位这类参数通常要花大半个小时但在这套自动化体系里AI的定位速度非常快。 ### 4.1 从触发点回溯到加载器JS AI收到任务后第一步是调用network_capture开始监听。我给定任务参数点击登录按钮时捕获Network中login接口的请求详情拿到Initiator JS路径。这一步对应Skill里的入口追踪阶段。 实测中AI会通过page_click点击真实的登录按钮我预先通过execute_js_code把账号密码填进表单然后network_capture会捕获到login请求的完整信息。返回结果里通常包含initiator.url字段它指向发起这个请求的JS文件路径一般是/static/js/app.bundle.js这类产物。拿到这个路径后AI调用search_in_file找到该文件在Sources里的实际内容。 ### 4.2 在压缩文件中定位可疑函数调用栈 如果有sourcemap这步会轻松很多没有sourcemap也问题不大靠的是对特征代码的识别。AI会在加载器JS文件中搜索cipher、封装工具函数常见命名的相关字符串然后顺着这些字符串所在的代码行向上追溯找到最外层的调用点。 这里特别值得注意的是在高压缩比代码里变量名是a、b、c函数名也是短的没有语义的拼写。如果AI只凭变量名猜测逻辑很容易被带偏。所以Skill里明确要求**优先找那些从全局对象上取值的代码**。比如代码里出现window.cryptoJS或者从某个模块初始化对象里读取成员这通常是密钥或算法库的入口。 ### 4.3 Hook验证技巧与断点计算的复用 定位到候选加密函数后AI会做一个Hook注入操作这比直接在函数内部下断点更高效。它的做法是执行JS代码 javascript var originalFunc candidateModule.cipher; candidateModule.cipher function(...args) { console.log(cipher hook args:, args); window.__capturedCipherArgs args; return originalFunc.apply(this, args); };紧接着触发真实请求通过get_console_logs工具读取捕获的参数值。这相当于把整个加密函数的入口参数完整摊在AI面前它不需要单步跟踪就能拿到真实运行时数据。在拿到这些参数之后Skill会让AI反向拼接逻辑先把参数传给某个加密库的函数比如CryptoJS.AES.encrypt(...)再通过execute_js_code在页面里执行相同运算对比输出。如果一致说明定位正确不一致就会调整推测方向重新来。4.4 逆向结果输出与自动化对接最后一步是让AI把验证通过的算法还原成独立模块我不允许它直接用浏览器内的对象必须生成一个脱离页面的Node.js版本。AI会自动读取Skill里脚本生成的规则输出标准CommonJS模块并提供可执行命令示例。这一步自动化之后我原先需要手动做一天的还原算法工作现在只需要对AI生成的代码做个代码审查然后直接挂到接口自动化脚本里。## 5. 从零搭建这套方案的完整操作步骤 关于怎么把这个平台搭起来我会把整个步骤完整写出来保证新手按照路径也能跑通基本链路。但我先提醒一句这套方案对环境的稳定性要求比较高尤其是MCP Server和浏览器调试端口的稳定性稍微没配好就会导致AI中途断掉。 ### 5.1 环境准备与基础依赖 建议使用MacOS或Linux系统Windows也能跑但是在进程管理和路径配置上会有一些坑需要提前规避。下面是我建议的依赖清单 | 依赖 | 版本 | 作用 | |------|------|------| | Node.js | 18 | 运行Playwright及MCP Server | | Python | 3.10 | 运行部分辅助脚本 | | Playwright | latest | 浏览器自动化控制 | | modelcontextprotocol/sdk | latest | 搭建MCP Server | | Claude Desktop或者自建Agent框架 | latest | 挂载MCP工具执行Agent逻辑 | 安装基础依赖没什么太多好说重点在于你选哪一个Agent框架来挂MCP工具。我建议使用Claude Desktop或者能自定义工具加载的Agent框架因为它对系统提示词的注入限制比较少方便我们完整交付Skill配置。 ### 5.2 三步完成Playwright MCP Server接入 第一步全局安装Playwright并下载浏览器 bash npm install -g playwright npx playwright install chromium第二步写一个最简单但能行的MCP Server脚本。这个脚本里我注册了三个工具打开页面、执行JS、获取页面标题。跑通整个链路后再扩展const { Server } require(modelcontextprotocol/sdk/server/index.js); const { StdioServerTransport } require(modelcontextprotocol/sdk/server/stdio.js); const { chromium } require(playwright); let browser, page; const server new Server( { name: browser-mcp-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); server.setRequestHandler({ method: tools/call }, async (request) { const { name, arguments: args } request.params; if (name open_page) { if (!browser) browser await chromium.launch({ headless: false }); page await browser.newPage(); await page.goto(args.url); return { content: [{ type: text, text: 页面标题: ${await page.title()} }] }; } if (name execute_js) { return { content: [{ type: text, text: 执行结果: (await page.evaluate(args.code)).toString() }] }; } }); const transport new StdioServerTransport(); server.connect(transport);第三步在Claude Desktop的MCP配置文件中一般在claude_desktop_config.json里注册这个Server{ mcpServers: { browser-mcp: { command: node, args: [/path/to/your/browser-mcp-server.js] } } }配置完成之后你在对话里让模型打开百度并搜索MCP协议如果调试模式能看到AI调用open_page工具说明链路打通了。5.3 挂载Skill配置文件的三种方式Skill配置可以以三种粒度加载第一种最简单直接放在系统提示词里适合临时一次性任务第二种写成独立的Markdown文件用#! /path/to/skill.md的语法挂载到模型上下文适合按项目区分的多次复用第三种用专门的Skill管理插件像管理代码库一样管理一堆不同的Skill文件在执行不同逆向任务时动态选择对应Skill。我实际操作中强烈推荐第二种方式。原因在于系统提示词越长模型决策时的指令冲突概率越大独立文件挂载能做到按需加载并且在任务边界清晰时效率更高。你可以为登录加密参数还原和前端字体反爬还原分别建立两个独立的Skill文件在对话开始时通过全局目标指令决定调用哪个Skill。5.4 测试驱动整个流程整套环境搭好之后不要一上来就跑真实目标站点先用一个完全可控的测试页面验证链路。我会在本地起一个简单的Node HTTP服务器构造一个带加密参数的表单提交逻辑模拟场景让AI去跑。通过之后再把目标切换到真实站点上。这个测试习惯帮我避开了大量环境问题因为我最先暴露的错误往往是MCP工具注册了但Agent没有正确调用或者JS执行时变量作用域写错。这些在可控环境里很快就能定位。## 6. 踩坑实录三类高频问题与完整排查链路 自动化链路跑起来之后我遇到过不少问题其中有三类踩得最深。我按实际排查顺序写出来能帮你在落地的过程中省掉大量的排查时间。 ### 6.1 MCP工具调用超时与CDP连接被抢占 现象AI在执行execute_js_code时偶尔返回请求超时而且浏览器窗口变得卡顿后续所有页面操作全部失败。 排查过程我先确认问题是否可稳定复现点击一次登录触发问题时看浏览器控制台有没有报错。然后看MCP Server的日志发现是CDP连接被多个进程同时占用导致的。原来Playwright启动的浏览器是持久化进程我后续又用curl访问了9222端口的调试接口挤掉了原先的连接会话。这种情况下MCP Server里的page.evaluate调用自然就超时了。 修复方案给MCP Server配置增加连接互斥机制不允许多个调试客户端同时挂载同一个浏览器实例。关闭9222端口的外部占用在MCP Server内部通过context.connection()单例模式管理浏览器会话。此后超时问题再没出现过。 ### 6.2 模型在决策流程中跳过验证直接给出结论 现象AI经过十几次工具调用后给出了一个算法脚本我拿真实数据一比密文完全不匹配。 排查过程我回看了Agent的完整推理日志发现它在参数检查环节只读取了两三个变量就跳到了逻辑还原环节中间完全没有做语义对比验证。原因是我的Skill文件里验证步骤语气太模糊写的是若有必要可进行多组参数比对模型在上下文窗口压力大时就会选择性地忽略一些不太重要的指示。 修复方案把Skill文件里所有模糊性描述改为强约束式条款明确写出在生成最终脚本之前必须至少对5组不同的输入参数执行加密并比对输出比对不一致时禁止提交脚本。同时把比对工具设置成无法跳过的前置条件。修正之后AI生成的算法脚本准确率有明显提升。 ### 6.3 浏览器环境特征暴露导致目标站点阻断 现象目标站点在登录前返回了环境验证的报错且无法通过常规手段绕过。 排查过程我用CDP的Page.addScriptToEvaluateOnNewDocument注入反检测脚本同时用Playwright的createExtraHTTPHeaders设置了与正常浏览器一致的请求头发现仍然被阻断。进一步查看Network请求发现对方检测了WebDriver相关特征与Canvas指纹的稳定性。 修复方案肯定不能为了一个逆向前端任务去上那些可疑的代理工具正确解法是使用基于真实浏览器内核的持久化配置同一浏览器用户数据目录多次复用保证Canvas指纹等环境参数稳定同时完全隐藏--enable-automation参数并且通过启动Blink特性禁用自动化标志。这类操作我们做自动化时合法性前提是自己拥有或已获授权测试的目标环境绝不鼓励对未授权系统越权操作。7. 工具链清单与下一步演进方向全流程能够跑通依赖下面这条完整工具链。我把它整理成一个可以直接照着配置的清单方便你拆开来看每一环的作用与替代选择。环节主选工具备选方案核心作用浏览器操控Playwright MCPPuppeteer MCP页面操作、表单填写、触发操作调试协议Chrome DevTools ProtocolWebDriver BiDi断点、Scope读取、Console捕获抓包改包BurpSuite MCPFiddler 自研桥接请求录制、参数修改、响应重放Agent框架Claude Desktop自建LangGraph链路决策编排、Skill加载、工具调度Skill管理独立Markdown挂载知识库检索逆向方法论沉淀与复用验证执行Node.js脚本Python脚本算法复现、比对验证说到下一步演进我个人最看好的一条线是让Skill具备自我学习和迭代能力。现在的Skill还是静态的遇到新类型的防护手段需要我手动修改SOP。理想状态是AI在一个任务里学到的新技巧能自动提炼成新的Skill子条目沉淀下来下一次任务直接复用。我这边已经开始实验的方式是在每次任务收尾时让AI生成一份本次任务的经验补丁格式也是Markdown内容包括新遇到的防护特征、有效应对策略、断点定位技巧。然后用脚本把这些补丁合并回主Skill文件。跑了两轮之后Master Skill文件的覆盖范围确实比手动维护时扩了一大圈。另外还有一个方向是结合多Agent协同。逆向前端加密函数、还原字体反爬、过滑块验证这些不同的子任务完全可以拆给不同的Agent并发执行。每个Agent只负责自己Skill覆盖的窄域最后在主Agent汇总结果。这样做的好处是上下文质量更高因为每个Agent不会因为关心太多无关操作而让决策被稀释。不过我实测下来这种方案对Agent间的通信机制设计要求比较高目前还在打磨中。从整个趋势来看AI配合MCP和Skill这套体系确实把前端JS逆向从纯手工的体力活变成了半自动化的协作任务。它会替代掉工程师吗至少在我实际体验里没有。它替代掉的是那70%重复性的定位与验证工作把人的精力释放出来去处理真正有挑战性的复杂防护逻辑和业务架构理解。如果你也在做逆向或者自动化测试我的建议是趁早把这条链路搭起来从一个小接口的加密参数还原开始你会在跑通第一个完整流程的时候就感受到这种协作方式带来的效率提升。最后说一句配置层面最容易踩的细节测试环境和真实目标之间至少要保留一套隔离的浏览器实例和网络环境千万不要在自动逆向同一个站点的时候混用会话否则环境上下文一旦错乱排查起来反而比手动逆向更痛苦。这是我在实际运行里用一次次折腾换来的教训希望对你有用。