构建 AI 逆向 MCP - 使用 MCP 辅助 JS 逆向

构建 AI 逆向 MCP - 使用 MCP 辅助 JS 逆向

前言

谷歌出了一个 chrome-dev-mcp,能够自动化浏览器操作。我发现这个 MCP 能抓包,于是想:能不能用于 JS 逆向分析?

但实际用下来发现,常规逆向需要的能力它都不支持:

  • ❌ 搜索代码
  • ❌ 追踪调用栈
  • ❌ 打断点调试
  • ❌ Hook 函数
  • ❌ 查看变量值

那能不能给它打补丁?当然可以。

Chrome DevTools Protocol(CDP)本身支持这些能力,只是谷歌的 MCP 没有封装。于是我基于 CDP 扩展了一套逆向专用工具:

扩展能力对应工具
代码搜索search_in_sourcesfind_in_script
调用栈追踪get_request_initiator
断点调试set_breakpointset_breakpoint_on_text
单步执行step_intostep_overstep_out
变量查看get_paused_infoevaluate_on_callframe
函数 Hookhook_functiontrace_function
XHR 拦截break_on_xhr

现在,AI 可以像人一样操作 DevTools 进行逆向分析了。

项目地址https://github.com/zhizhuodemao/js-reverse-mcp

下面是完整的工具集和使用指南。


一、什么是 MCP

MCP(Model Context Protocol)是 Anthropic 推出的模型上下文协议,允许 AI 直接调用外部工具。

传统逆向流程

1

人工操作浏览器 → 复制数据 → 粘贴给 AI → AI 分析 → 人工验证

MCP 辅助流程

1

AI 直接操作浏览器 → 自动分析 → 自动验证 → 输出结果

二、JS 逆向 MCP 工具集

2.1 页面管理

工具功能
list_pages列出浏览器所有页面
select_page选择要操作的页面
new_page新建页面并导航
navigate_page页面导航(URL/前进/后退/刷新)
take_snapshot获取页面 DOM 快照
take_screenshot页面截图

2.2 网络分析

工具功能
list_network_requests列出所有网络请求
get_network_request获取请求详情(Headers/Body/Response)
get_request_initiator获取请求调用栈 - 定位发起请求的代码
break_on_xhrXHR/Fetch 断点 - URL 匹配时暂停

2.3 脚本分析

工具功能
list_scripts列出页面加载的所有 JS 脚本
get_script_source获取脚本源码(支持行范围/字符偏移)
find_in_script在指定脚本中搜索字符串
search_in_sources全局搜索所有脚本

2.4 断点调试

工具功能
set_breakpoint设置行断点(支持条件断点)
set_breakpoint_on_text按代码文本设置断点 - 适合混淆代码
remove_breakpoint移除断点
list_breakpoints列出所有断点
pause立即暂停执行
resume继续执行
step_into单步进入
step_over单步跳过
step_out跳出当前函数

2.5 运行时分析

工具功能
get_paused_info获取暂停状态(调用栈/作用域变量)
evaluate_on_callframe在断点处执行表达式 - 查看变量值
evaluate_script在页面执行 JS 代码
inspect_object深度检查对象结构

2.6 Hook 与追踪

工具功能
hook_functionHook 函数 - 记录调用/参数/返回值
unhook_function移除 Hook
list_hooks列出所有 Hook
trace_function追踪函数调用 - 不暂停,只记录
monitor_events监听 DOM 事件

2.7 存储与控制台

工具功能
get_storage获取 Cookie/localStorage/sessionStorage
list_console_messages列出控制台消息
get_console_message获取控制台消息详情

三、实战场景

3.1 定位加密函数

目标:找到生成 w_tsfp 参数的代码

1

2

3

4

5

6

7

1. list_network_requests → 找到携带 w_tsfp 的请求

2. get_request_initiator → 获取调用栈,定位发起代码

3. get_script_source → 查看相关脚本

4. set_breakpoint_on_text → 在关键代码处设断点

5. 刷新页面触发断点

6. get_paused_info → 查看调用栈和变量

7. evaluate_on_callframe → 检查加密前后的值

目标:追踪 Cookie 的设置过程

1

2

3

4

5

1. hook_function → Hook document.cookie setter

2. 刷新页面

3. list_console_messages → 查看 Hook 日志

4. 从日志中获取调用栈

5. get_script_source → 定位生成逻辑

3.3 XHR 断点调试

目标:在特定 API 请求时暂停

1

2

3

4

5

1. break_on_xhr → 设置 URL 匹配断点(如 "/api/sign"

2. 触发请求

3. get_paused_info → 获取完整调用栈

4. step_into/step_over → 单步调试

5. evaluate_on_callframe → 查看签名参数

3.4 VM 字节码分析

目标:追踪 VM 执行过程

1

2

3

4

5

1. search_in_sources → 搜索 VM 解释器特征

2. find_in_script → 定位具体位置

3. set_breakpoint → 在 VM 循环处设断点

4. get_paused_info → 获取 PC、寄存器等状态

5. trace_function → 追踪关键函数调用

四、AI 对话示例

4.1 定位加密入口

1

2

3

4

5

6

7

8

用户:帮我找到这个页面 w_tsfp 参数的生成位置

AI:

1. 调用 list_network_requests 找到相关请求

2. 调用 get_request_initiator 获取调用栈

3. 分析调用栈,定位到 probe.js 第 XXX 行

4. 调用 get_script_source 获取上下文代码

5. 输出:w_tsfp 在 RC4 加密后通过 btoa 编码,入口函数是 ...

4.2 动态调试

1

2

3

4

5

6

7

8

9

用户:在 RC4 加密函数处设断点,我想看加密前的明文

AI:

1. 调用 search_in_sources 搜索 "RC4" 或特征代码

2. 调用 set_breakpoint_on_text 设置断点

3. 提示用户刷新页面

4. 断点命中后调用 get_paused_info

5. 调用 evaluate_on_callframe 获取参数值

6. 输出:加密前明文是 {"loadts":...,"fingerprint":...}

4.3 批量 Hook

1

2

3

4

5

6

7

8

9

10

11

用户:Hook 所有可能的加密函数,看哪个被调用

AI:

1. 调用 hook_function 依次 Hook:

   - btoa

   - atob

   - JSON.stringify

   - encodeURIComponent

2. 提示用户操作页面

3. 调用 list_console_messages 查看 Hook 日志

4. 输出:btoa 被调用,参数是 RC4 加密后的数据...

五、优势总结

5.1 效率提升

传统方式MCP 方式
手动打开 DevToolsAI 直接操作
复制粘贴数据自动获取
人工搜索代码search_in_sources
反复设断点调试AI 自动迭代
手写 Hook 代码hook_function 一键 Hook

5.2 适合场景

  • 混淆代码分析:AI 可以快速搜索、设断点、查看变量
  • VM 逆向:自动追踪执行流程,记录状态变化
  • 加密算法定位:Hook + 调用栈分析,快速定位入口
  • 批量测试:自动化执行多轮测试

5.3 局限性

  • 需要浏览器配合(DevTools Protocol)
  • 某些反调试可能检测 CDP 连接
  • 复杂异步逻辑仍需人工判断
  • AI 理解能力有限,核心决策仍需人工

六、搭建指南

6.1 环境要求

  • Chrome/Chromium 浏览器
  • Node.js 运行时
  • Claude Desktop 或支持 MCP 的客户端

6.2 核心原理

1

Claude ←→ MCP Server ←→ Chrome DevTools Protocol ←→ 浏览器

MCP Server 封装 CDP 协议,暴露为 AI 可调用的工具函数。

6.3 关键能力

  1. 页面控制:导航、刷新、截图
  2. 网络拦截:请求列表、调用栈追踪
  3. 脚本调试:断点、单步、变量查看
  4. 代码注入:Hook、Trace、执行任意 JS

七、最佳实践

  1. 先观察再动手:用 list_network_requests 了解请求模式
  2. 善用搜索search_in_sources 比手动翻代码快
  3. 断点要精准set_breakpoint_on_text 比行号更可靠
  4. Hook 优先:先 Hook 观察,再设断点深入
  5. 保存上下文:让 AI 记录关键发现,避免重复分析
  6. 分步验证:每一步都验证结果,避免错误累积

MCP 让 AI 从"分析助手"变成"操作助手",显著提升逆向效率

Read more

前端环境配置(nvm、nodejs、npm)

前端环境配置(nvm、nodejs、npm)

一、安装nvm 1. 下载vnm url: https://nvm.uihtm.com/doc/download-nvm.html 2. 解压文件后双击exe文件进行安装 3. 选择nvm的安装地址,我是安装在D:\App\nvm 4. 选择nodejs的安装地址,我是安装在C:\Program Files\nodejs 5. 点击next 一直点击 完成安装; 6. 找到nvm的settings.txt文件打开后: 给该文件添加这两行命令: node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/ 二、环境变量配置 1.

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

本文为DeepSeek R1 7B 以qwen为底座的LLM在瑞芯微RK3588 SoC上的完整部署流程,记录从开发板驱动适配烧录开始,到最终的开发板终端访问模型和局域网web访问模型的完整流程,有不足之处希望大家共同讨论。 文章目录 * 一、项目背景介绍 * 二、所需工具介绍 * 1.硬件工具 * 1.X86 PC虚拟机Ubuntu20.04 * 2. 准备NPU驱动为0.9.8的RK3588开发板 * 2.软件工具 * 三、获取.safetensors模型权重 * 四、safetensors转RKLLM * 1.转换环境搭建 * 2.模型转换 * 五、RKLLM模型板端部署及推理 * 六、集成开源gradio工具实现web访问 一、项目背景介绍 先来介绍下项目背景吧,目前有一个空闲的firefly出厂的搭载瑞芯微RK3588 SoC的arm64开发板,样式如图所示: 博主之前主要进行CV领域的模型的RK开发板部署,对于LLM和VLM的接触并不算多,但现在大模型是趋势所向,并且瑞芯微及时的完成了针对各开源

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案 你有没有遇到过这样的情况:手头有个跨境项目,要同时处理日语产品说明、西班牙语用户反馈、维吾尔语政策文件,甚至还有藏文古籍数字化需求——可翻来翻去,不是翻译质量差强人意,就是部署起来像在解一道高数题?在线工具不敢传敏感数据,本地跑模型又卡在CUDA版本、依赖冲突、显存爆炸上……最后只能靠人工硬啃,进度一拖再拖。 Hunyuan-MT-7B-WEBUI 就是为这种真实困境而生的。它不讲大道理,不堆参数,不做“实验室里的冠军”,而是把腾讯混元团队打磨出的最强开源翻译模型,连同网页界面、一键脚本、预装环境,全打包进一个镜像里。你不需要懂Transformer结构,不用查PyTorch兼容表,甚至不用打开终端敲命令——点一下,等两分钟,就能在浏览器里开始翻译38种语言。 这不是又一个“需要调参、需要写代码、需要配环境”的AI工具。这是你今天下午就能用上的多语言工作台。 1. 为什么这款翻译镜像值得你立刻试试? 1.1 它真能覆盖你没想过的语言 很多翻译模型标榜“支持多语言”,但实际打开列表一看:英、法、

前端实现Word文档在线编辑与导出:基于mammoth.js与Blob对象的完整解决方案

如何在浏览器中直接编辑Word文档并导出?本文将深入探索一种基于mammoth.js和Blob对象的完整技术方案。 在当今的Web应用开发中,实现文档的在线编辑与导出已成为常见需求。无论是企业内部系统、教育平台还是项目管理工具,都迫切需要让用户能够在浏览器中直接编辑Word文档,而无需安装桌面软件。本文将详细介绍如何利用mammoth.js和Blob对象实现这一功能,并对比其他可行方案。 一、为什么选择mammoth.js与Blob方案? 在Web前端实现Word文档处理,主要有三种主流方案:浏览器原生Blob导出、mammoth.js专业转换和基于模板的docxtemplater方案。它们各有优劣,适用于不同场景。 mammoth.js的核心优势在于它能将.docx文档转换为语义化的HTML,而非简单复制视觉样式。这意味着它生成的HTML结构清晰、易于维护和样式定制。配合Blob对象,我们可以轻松将编辑后的内容重新导出为Word文档。 与直接使用Microsoft Office Online或Google Docs嵌入相比,mammoth.js方案不依赖外部服务,能更好地