文章总结： 本文提出一种红队自动化攻击方案，利用ChromeMCP协议逆向提取前端加密密钥与逻辑，结合AI分析生成加密Payload，并通过BurpSuitejsrpc实现实时加解密。该方案将前端加密防线转化为攻击通道，有效解决传统工具因AES-CBC与SM2双重加密导致的爆破失效问题，提供端到端的自动化测试链路。 综合评分： 87 文章分类： 红队,WEB安全,安全工具,渗透测试,实战经验
基于Chrome MCP与AI的红队自动化加解密工作流
小猴 小猴
亿人安全
2026年6月16日 19:37 北京
在小说阅读器读本章
去阅读
原文首发在：奇安信攻防社区
https://forum.butian.net/ai_security/188
当目标登录接口被AES-CBC与SM2双重加密，传统爆破工具彻底失效。本文提出一种红队工作流：Chrome MCP自动化逆向提取密钥 + AI生成加密Payload + BurpSuite jsrpc实时加解密，将前端加密防线转化为进攻通道
基于Chrome MCP与AI的红队自动化加解密工作流
一、研究背景与攻击动机
随着前端加密技术的全面普及，红队测试正面临前所未有的挑战。目标系统的登录接口不再接收明文凭证，取而代之的是经过AES-CBC对称加密或SM2国密算法处理后的密文载荷。部分高安全等级系统甚至采用双重加密策略——先以SM2加密对称密钥，再以AES-CBC加密业务数据，形成多层防护体系。
这一趋势直接导致传统攻击工具体系的结构性失效：
| 工具/方法 | 失效原因 | 表现 | | — | — | — | | BurpSuite Intruder | 无法生成合法密文 | 所有爆破请求返回400/403 | | Hydra/Medusa | 不支持加密预处理 | 无法与目标协议握手 | | 自定义字典攻击 | 明文载荷被服务端拒收 | 无有效响应 | | 自动化扫描器 | 缺乏加密载荷生成能力 | 完全丧失探测功能 |
红队迫切需要一套能够穿透前端加密黑箱、自动化完成密钥提取与请求伪造的技术方案。本文基于Chrome DevTools MCP、AI逆向分析与BurpSuite jsrpc，构建了一条端到端的自动化加解密攻击链路，将前端加密防线转化为进攻通道。
二、双重加密的技术剖析
2.1 常见的双重加密架构
高安全等级系统通常采用混合加密方案，兼顾安全性与性能：
┌─────────────────────────────────────────────────────────────┐
│ 客户端加密流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 明文数据 ──→ AES-CBC加密 ──→ Base64编码 ──→ 请求体 │
│ ↑ │
│ │ │
│ AES密钥 ──→ SM2公钥加密 ──→ 密钥密文 ──→ 请求头 │
│ │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 服务端解密流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 密钥密文 ──→ SM2私钥解密 ──→ AES密钥 │
│ ↓ │
│ 请求体 ──→ Base64解码 ──→ AES-CBC解密 ──→ 明文数据 │
│ │
└─────────────────────────────────────────────────────────────┘
第一层：非对称加密（SM2/RSA） — 保护对称密钥的传输安全。前端使用服务端分发的公钥加密AES密钥，确保只有持有私钥的服务端能够解密。
第二层：对称加密（AES-CBC） — 保护业务数据的机密性与完整性。使用随机生成的AES密钥加密请求体，密钥本身被非对称加密保护。
这一架构的理论安全性在于：攻击者即使截获完整请求，在没有SM2私钥的情况下也无法解密AES密钥，进而无法还原明文数据。
2.2 攻击面的重新审视
然而，从红队视角看，这一架构存在一个根本性的脆弱点——加密过程完全发生在客户端。
这意味着：
- 加密算法实现、公钥、IV等所有密码学参数均存在于前端代码中
- 加密函数是JavaScript运行时中可被调用的公开接口
- 攻击者可以直接调用前端加密函数，而非自行实现算法
这一洞察构成了本文攻击方法论的核心：与其逆向算法，不如重用算法；与其提取密钥，不如调用函数。
三、自动化攻击架构
3.1 整体工作流
本文提出的自动化攻击链路由三个核心组件协同完成：
┌─────────────────────────────────────────────────────────────┐
│ 阶段一：密钥与逻辑提取 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Chrome MCP ──→ 自动导航登录页 │
│ ↓ │
│ AI自动分析 ──→ 定位加密函数、提取公钥/AES密钥/IV │
│ ↓ │
│ jsrpc注入 ──→ 将加密函数暴露为全局可调用接口 │
│ │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 阶段二：载荷自动生成 │
├─────────────────────────────────────────────────────────────┤
│ │
│ AI生成Payload ──→ SQL注入/XSS/越权测试载荷 │
│ ↓ │
│ 调用原生加密函数 ──→ 通过jsrpc调用浏览器内加密 │
│ ↓ │
│ 生成合法密文 ──→ 可直接提交的有效请求 │
│ │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 阶段三：BurpSuite集成 │
├─────────────────────────────────────────────────────────────┤
│ │
│ BurpSuite插件 ──→ 拦截请求，识别待加密字段 │
│ ↓ │
│ jsrpc调用 ──→ 将明文载荷发送至浏览器加密 │
│ ↓ │
│ 替换密文 ──→ 自动完成请求加密并转发 │
│ │
└─────────────────────────────────────────────────────────────┘
3.2 Chrome MCP：自动化逆向的抓手
Chrome DevTools MCP作为MCP协议的浏览器控制实现，使AI能够程序化地操作Chrome浏览器。在攻击流程中，MCP承担以下任务：
任务一：自动导航与状态准备
// AI通过MCP执行的自动化操作序列
1. navigate_to("https://target.com/login")
2. wait_for_element("#username", timeout=5000)
3. fill_input("#username", "test_user")
4. fill_input("#password", "任意测试密码")
5. click_button("登录")
6. capture_network_request("/api/login")
任务二：加密函数定位
// AI在控制台执行的代码
// 搜索加密相关全局对象
const cryptoKeys = Object.keys(window).filter(k =>
k.toLowerCase().includes('encrypt') ||
k.toLowerCase().includes('sm2') ||
k.toLowerCase().includes('aes')
);
console.log('候选加密对象:', cryptoKeys);
// 遍历Vue/React组件树查找加密服务
const app = document.querySelector('#app').__vue_app__;
const cryptoService = app.config.globalProperties.$crypto;
任务三：参数提取
// 断点提取密钥与IV
debugger;
// 在加密函数入口处执行
console.log('AES Key:', key);
console.log('IV:', iv);
console.log('SM2 Public Key:', publicKey);
3.3 AI驱动的加密逻辑分析
AI模型在接收到MCP捕获的请求和源码后，执行以下分析流程：
第一步：加密类型识别
| 特征 | 判定 | 后续动作 |
| — | — | — |
| 密文以04开头，长度130+字符 | SM2 | 提取公钥，准备SM2加密调用 |
| 密文为Base64，解码后长度16倍数 | AES-CBC | 提取Key和IV，确认填充模式 |
| 同时存在两种密文 | 双重加密 | 定位密钥封装与数据加密的两层逻辑 |
第二步：调用链追踪
AI通过MCP的evaluate_script能力，在浏览器中执行JavaScript以追踪加密调用栈：
// 注入Hook，拦截所有加密相关调用
const originalEncrypt = window.encryptFunction;
window.encryptFunction = function(...args) {
console.trace('Encrypt called with:', args);
debugger; // 触发断点，供AI分析上下文
return originalEncrypt.apply(this, args);
};
第三步：自动化脚本生成
AI根据分析结果，自动生成jsrpc注入脚本，将加密函数暴露给外部BurpSuite调用。
3.4 jsrpc：浏览器与BurpSuite的加密桥梁
jsrpc技术的核心是在浏览器内维持一个常驻的加密服务，通过WebSocket或HTTP与BurpSuite插件通信。
浏览器端注入脚本：
// 通过Chrome MCP注入
(function() {
// 定位原始加密函数
const aesKey = "7f3a8b2c5d1e9f4a";
const iv = "3c5f7a9b1d3e5f7a";
const sm2PublicKey = "04b9364f5c8a3e2d...";
// 封装加密接口
window.encryptService = {
// AES-CBC加密
aesEncrypt: function(plaintext) {
const encrypted = CryptoJS.AES.encrypt(plaintext,
CryptoJS.enc.Utf8.parse(aesKey), {
iv: CryptoJS.enc.Utf8.parse(iv),
mode: CryptoJS.mode.CBC,
padding: CryptoJS.pad.Pkcs7
});
return encrypted.ciphertext.toString(CryptoJS.enc.Base64);
},
// SM2加密
sm2Encrypt: function(plaintext) {
return SM2Utils.encrypt(sm2PublicKey, plaintext);
},
// 双重加密：SM2封装密钥 + AES加密数据
doubleEncrypt: function(plaintext) {
const sessionKey = this.generateSessionKey();
const encryptedKey = this.sm2Encrypt(sessionKey);
const encryptedData = this.aesEncryptWithKey(plaintext, sessionKey);
return {
key: encryptedKey,
data: encryptedData
};
}
};
// 启动RPC服务
const ws = new WebSocket("ws://localhost:8080/encrypt");
ws.onmessage = function(msg) {
const request = JSON.parse(msg.data);
const result = window.encryptService[request.method](request.payload);
ws.send(JSON.stringify({ id: request.id, result: result }));
};
})();
BurpSuite插件端：
插件拦截请求后，识别需要加密的字段，将明文通过WebSocket发送至浏览器加密，接收密文后替换原请求内容。
四、实战案例：突破双重加密登录接口
4.1 目标分析
某企业后台系统的登录接口采用双重加密架构：
请求格式：
POST /api/auth/login HTTP/1.1
Host: admin.target.com
Content-Type: application/json
{
"key": "04a3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4",
"data": "xK8rP4sL2mN9qR5tY7uW1iE3aG6bH8jK0lZ2xC4vB6nM8pQ0rS2tU4vW6xY8zA0bC2dE4fG6hI8jK0lL2mN4oP6qR8sT0uV2wX4yZ6",
"timestamp": 1704067200
}
其中：
-
key字段：SM2加密的AES会话密钥
-
data字段：AES-CBC加密的业务数据（包含username/password）
-
timestamp：时间戳（明文）
4.2 红队工作流执行
步骤一：Chrome MCP自动化逆向
使用以下提示词驱动AI完成自动化分析：
使用 Chrome DevTools MCP + js-reverse-automation Skill 对目标站点进行深度登录逆向分析。
目标：
完整分析登录接口的双重加密逻辑，包括SM2公钥提取、AES密钥生成方式、参数构造流程。
目标站点：
https://admin.target.com/login
任务：
1. 自动打开登录页，填写测试账号 admin / 123456
2. 抓取登录请求，识别 key 和 data 字段的生成逻辑
3. 在 Sources 中定位加密函数，判断是否使用 SM2 + AES-CBC 双重加密
4. 提取 SM2 公钥、AES 密钥生成算法、IV 固定值或生成方式
5. 自动生成 jsrpc 注入脚本，将加密函数暴露为外部可调用接口
步骤二：AI自动定位加密逻辑
AI通过MCP执行以下定位代码：
// 搜索SM2相关对象
window.sm2; // 输出: {encrypt: ƒ, decrypt: ƒ, utils: {…}}
// 搜索AES加密调用
// 在network面板的initiator中追踪到 encryptRequest 函数
functionencryptRequest(params) {
const sessionKey = generateRandomKey(16); // 随机AES密钥
const encryptedKey = sm2.encrypt(publicKey, sessionKey);
const encryptedData = aesCbcEncrypt(JSON.stringify(params), sessionKey, iv);
return { key: encryptedKey, data: encryptedData };
}
关键发现：
- AES密钥每次请求随机生成，无法通过静态提取获得
- 但加密函数完全暴露在客户端，可被直接调用
- IV为固定值
3c5f7a9b1d3e5f7a
步骤三：jsrpc注入与BurpSuite集成
AI自动生成注入脚本，将encryptRequest函数暴露为RPC服务：
// 注入脚本
window.rpc = {
encryptLogin: function(username, password, timestamp) {
const params = {
username: username,
password: password,
timestamp: timestamp
};
returnwindow.encryptRequest(params);
}
};
BurpSuite插件配置为：拦截登录请求 → 提取明文字段 → 通过WebSocket调用rpc.encryptLogin → 替换key和data字段。
步骤四：自动化攻击测试
完成集成后，红队可以在BurpSuite Intruder中直接使用明文词典：
| 明文字典 | 自动加密后 | 攻击效果 |
| — | — | — |
| admin' OR '1'='1 | 合法SM2+AES密文 | SQL注入探测 |
| admin + 密码字典 | 每个请求独立加密 | 身份爆破 |
| ../../etc/passwd | 合法密文 | 路径遍历测试 |
五、攻击技术深度解析
5.1 为什么“调用加密函数”优于“复现加密算法”
| 对比维度 | 传统逆向复现 | jsrpc调用原生函数 | | — | — | — | | 算法复杂度 | 需完整逆向算法实现 | 无需理解算法细节 | | 密钥提取 | 需从内存/源码提取 | 函数内部自动处理 | | 动态密钥 | 无法处理随机生成场景 | 原生支持，每次调用自动生成 | | 维护成本 | 目标更新需重新逆向 | 浏览器自动加载最新版本 | | 准确率 | 可能存在实现偏差 | 100%与真实请求一致 |
5.2 绕过加密边界的本质
这一方法论的本质在于：将加密边界从“客户端-服务端之间”重新定义为“浏览器-攻击工具之间”。
传统视角下，加密边界是客户端与服务端的协议边界，攻击者被隔离在密文空间之外。而通过jsrpc，攻击工具被“接入”浏览器内部，与加密函数处于同一信任域，从而获得明文操作能力。
传统攻击模型：
攻击工具 --(明文)--> [加密边界] --(密文)--> 服务端
↑
攻击者无法穿透
本文攻击模型：
攻击工具 --(明文)--> jsrpc --(明文)--> 浏览器加密函数 --(密文)--> 服务端
↑
攻击工具与加密函数同处信任域
5.3 对抗前端混淆与代码加密
面对经过Obfuscator.io等工具混淆的前端代码，AI可通过以下策略突破：
-
运行时追踪而非静态分析
：通过MCP触发实际加密调用，观察输入输出关系
-
Hook关键API
：拦截
Function.prototype.call、eval等动态执行函数 -
内存快照分析
：在加密函数执行后读取闭包变量值
六、防御视角的思考
从蓝队角度，理解这一攻击手法有助于构建有效的防御措施：
6.1 服务端加固方案
| 问题 | 攻击方式 | 防御方案 | | — | — | — | | 加密函数可被外部调用 | jsrpc远程调用 | 增加环境指纹校验（检测WebSocket外连） | | 请求可被重放 | 拦截合法请求并替换载荷 | 绑定请求时间戳+一次性Nonce | | 加密算法完全暴露 | 攻击者直接调用 | 将核心加密逻辑迁移至服务端（如WebCrypto + 签名） |
6.2 检测jsrpc攻击的特征
蓝队可通过以下指标检测自动化加密攻击：
-
WebSocket外连
：浏览器向localhost或非业务域名发起WebSocket连接
-
异常的函数调用模式
：加密函数在短时间内被高频调用（超出正常用户行为）
-
Headless浏览器特征
：检测
navigator.webdriver、--headless等自动化标记
七、总结
本文提出并验证了一套突破前端双重加密防线的自动化红队工作流。核心结论如下：
| 组件 | 作用 | 关键价值 | | — | — | — | | Chrome MCP | 自动化导航、代码定位、断点调试 | 将人工逆向转化为程序化操作 | | AI分析引擎 | 加密类型识别、函数定位、脚本生成 | 数分钟完成数小时的逆向工作 | | jsrpc + BurpSuite | 保持浏览器加密上下文，实时加解密 | 将明文攻击载荷自动转换为合法密文 |
这一工作流的根本性突破在于：不再试图“破解”加密，而是“接入”加密。通过将攻击工具置于与加密函数相同的信任域，前端加密防线被转化为进攻通道。
对于红队而言，这意味着即使面对SM2+AES-CBC双重加密、随机密钥、代码混淆等高级防护，攻击链路依然可自动化完成。对于蓝队而言，这提醒我们：真正的安全边界不在于前端加密的强度，而在于服务端对请求合法性校验的完备性——包括环境指纹、行为模式、请求完整性的多维度验证。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：亿人安全 小猴 小猴《基于Chrome MCP与AI的红队自动化加解密工作流》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论