1. 流量里全是密文手工解到怀疑人生前一阵做授权测试打开 Burp 想看登录接口的参数结果请求体长这样POST /api/login HTTP/1.1 Host: app.example.com Content-Type: application/json {username:U2FsdGVkX1/d0T...,password:U2FsdGVkX1/...}响应里的data字段也全是Base64密文。看到这一幕第一反应是“登录功能又被前端加密了”。这几年我碰到的业务系统十有六七都会给敏感字段套一层 AES、RSA 之类的加密。对测试者来说密文意味着你看不到真实参数改不了关键字段业务逻辑测试、越权测试、身份认证绕过全都无从下手。后来装上这款“万能”解密插件Burp 的请求包和响应包里终于能直接看到明文比如username、password、timestamp还有后端返回的真实业务数据。整个过程基本是即插即用不需要到处复制 JS 代码也不用手工写脚本一包一包去解。今天我把这套插件的原理、安装、配置和实际测试中会踩的坑完整梳理一遍。1.1 一个典型的加密接口长什么样先看一个最常见的 AES-CBC 登录场景。前端 JS 里通常会有类似这样的代码const key CryptoJS.enc.Utf8.parse(1234567890abcdef); const iv CryptoJS.enc.Utf8.parse(abcdef9876543210); function encryptLoginInfo(data) { return CryptoJS.AES.encrypt(JSON.stringify(data), key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }).toString(); }请求发出去后Burp 的 HTTP History 里看到的就是U2FsdGVkX1开头的一长串字符。这串字符的特点很明显标准 Base64长度按 16 字节对齐模式固定结果是 32、44、64 这类常见长度。再比如有些网站用 RSA 加密登录密码const encryptor new JSEncrypt(); encryptor.setPublicKey(MIGfMA0GCSqGSIb3DQEBAQUAA4...); const encPwd encryptor.encrypt(123456);这种密文更长通常是 128 字节或 256 字节的 Base64 串。如果前端还做了自定义 Base64 变表、先压缩后加密、或加密完再转十六进制那 Burp 里看到的就是完全不知道是什么的乱码。这些问题不是偶然出现的而是业务系统为了防抓包、防重放、防自动化工具扫描而做的常见手段。所以做接口测试不能假设所有参数都是明文必须有一套能处理加解密链路的方法。1.2 手工抄 JS 为什么是时间黑洞没有解密插件的时候常规做法是打开浏览器开发者工具在 Sources 里搜索encrypt、AES、setPublicKey、JSEncrypt这些关键词找到加密函数再一步步把逻辑抄到 Python 或 Node 脚本里。这套流程本身不复杂但真正执行起来非常费时间前端代码通常经过混淆、压缩变量名全是a、b、c可读性极差。加密逻辑可能分散在多个文件里有的 key 是固定写死的有的 key 是接口下发到 localStorage甚至每隔一段时间就刷新一次。后端响应也可能加密需要再找一个decrypt函数逻辑和请求加密完全不一样。就算你把加解密都跑通了重放请求时还要处理时间戳、随机数、签名等额外字段手工脚本维护成本很高。换一个接口可能加密方式又不一样前面的脚本全部作废。我也见过比较极端的情况一个 APP 的加密逻辑写在 native 层前端只传密文Burp 里完全看不到明文。这种情况靠手工抄 JS 根本无解必须借助静态分析和动态 hook。而一个好的解密插件至少能把常规的 AES、RSA、Base64 变种这类前端加密统一接管让抓包工具重新回到“能看到业务参数”的状态。1.3 插件不是“破解算法”而是把前端逻辑接入代理链路有朋友一听“解密插件”就觉得是暴力破解其实不是。密码学上 AES 和 RSA 本身是安全的插件并没有去攻击算法而是复用了前端已经暴露出来的密钥和算法流程。前端的加解密逻辑不管怎么混淆最终还是要运行在用户的浏览器或 App 里。无论是CryptoJS.AES.encrypt还是自定义的encodeData只要在页面上能正常执行就说明算法、密钥、IV 这些关键参数都在客户端存在。解密插件做的事情就是把这段已经存在的前端逻辑通过内置规则或注入脚本的方式接入到 Burp 的代理链路里。它相当于一个“翻译官”把密文还原成可读的明文再把修改后的明文重新加密成合法的密文放回请求里。所以“万能”是相对的。它解决了 80% 常规前端加密问题但遇到 WebAssembly、native 层加密、非标准私有协议时仍然需要针对业务去定制。这也是我后面要重点说的部分即插即用只是起点想真正提高效率得会自己写规则。2. 解密插件到底在解什么前端加密模型的拆解要理解插件的工作方式先得搞清楚前端加密流量常见的形态。Burp 解密插件不是凭空猜出明文它必须先识别出这一段密文用了什么算法、密钥在哪、输出格式是什么然后才能做对应处理。2.1 前端加密三件套与识别特征我遇到的加密流量绝大多数可以归到下面三种类型里。插件内置的规则也主要围绕这些类型在写加密类型常见实现流量特征关键参数AES 对称加密CryptoJS、crypto-js、Web Crypto API标准 Base64 或十六进制长度按块对齐常出现U2FsdGVkX1前缀key、iv、mode、paddingRSA 非对称加密JSEncrypt、encryptlong、forge密文很长Base64 长度通常为 172、256、344 等公钥、私钥、填充方式自定义变种XOR、Base64 换表、AES 后再二次编码看起来像乱码长度不规整等号数量异常编码表、异或 key、加密流程顺序注意一个容易理解错的点RSA 加密的场景里前端用公钥加密后端用私钥解密。测试者不需要也不可能在客户端拿到私钥去还原原始密码。真正需要做的是在请求里构造一段“合法的、能被后端解密”的新密文。也就是说插件对 RSA 字段有时候不是“解密给你看”而是“帮你把明文替换成新密文”。这也是很多人不理解“解密插件为什么还要支持加密”的原因。插件必须双向支持你才能一边看明文、一边改参数、一边让后端不报错。2.2 插件的核心工作流程识别、解密、回填我用的这款插件本质上是一个IHttpListener类型的 Burp Java 扩展。每当有 HTTP 请求或响应经过 Burp 时插件会先做一遍规则匹配大致流程如下根据请求 URL、Host、Content-Type 过滤候选流量。在请求体或响应体里扫描指定字段比如 JSON 里的data、username、password。匹配到密文字段后根据规则里的算法、密钥、IV 或自定义脚本完成解密。在原始消息旁边生成一个新的Decrypted标签展示明文内容。如果你在Decrypted标签里修改参数插件会用同一套规则重新加密把新的密文回填到原始请求里。这个过程非常关键。很多新手以为只要能把密文“看明白”就行但实际测试里你经常需要改明文然后重新发包否则无法测试越权、爆破、业务逻辑绕过。比如登录接口的用户名是加密的你想改成另一个账号来测越权就必须重新加密。插件如果能自动完成“明文到密文”的回填那Repeater、Intruder都可以继续按明文操作效率会高很多。2.3 离线规则与在线 Hook 两种模式插件为了兼顾不同的使用场景一般会同时支持“离线规则”和“在线 Hook”两条路线。离线规则适合在 Repeater、Intruder 里批量改包你预先配置好算法和密钥插件在流量经过时自动解密不依赖浏览器环境。这种模式稳定、可控、适合重复测试但对动态密钥支持较弱。在线 Hook 则适合在 Burp 内置浏览器里边点边看插件会给页面注入一小段脚本在CryptoJS.AES.encrypt这类函数被调用时拦截参数记录下明文、密钥和加密结果再把记录汇总到插件的Decrypt标签页。这种模式对动态密钥特别友好因为密钥是在页面实际运行中生成的Hook 脚本能拿到最准确的上下文。它的缺点是性能开销大并且如果页面启用了严格 CSP 或者SRI注入可能失败。理解这两种模式后你就明白“即插即用”是什么意思了插件默认带了一套常用加密库的识别规则和 Hook 脚本打开就能处理大多数CryptoJS和JSEncrypt加密的流量。但如果碰到自定义加密算法还是得靠离线规则自己设计解密脚本。3. 安装与即插即用5分钟让 Burp 多一个 Decrypt 标签页这套解密插件最常见的分发形式是一个 jar 包。与 Python 扩展不同Java 扩展不依赖 Jython也不需要额外配置 Python 环境下载后直接加进 Burp 就能用。我用的是 Burp 2023 以上版本社区版和专业版都能正常加载不影响插件功能。3.1 插件形态、版本与运行环境先确认几个基础条件Burp 版本建议 2023.1 或更高旧版本可能在加载扩展时出现接口不兼容。插件是.jar文件放到本地任意目录路径不要太深避免中文路径导致异常。本机最好已经安装 JDK 17 或更新版本Burp 自带 JRE 也能运行但某些插件要额外编译自定义脚本时还是独立 JDK 更省心。如果拿到的是.py后缀的脚本那说明它是 Python 扩展需要先配置 Jython 环境我一般避坑优先选 jar 版本。有人会问社区版能不能用可以。Burp 社区版同样支持 Extender 扩展只是限制了并发扫描和部分功能解密插件本身不涉及这些限制所以测试环境完全够用。3.2 具体安装步骤打开 Burp按照下面几步操作进入Extender标签页选择Extensions子页。点击Add按钮。在Extension Details里把Extension Type选为Java。点击Extension File后面的Select file...找到插件 jar 包。点击Next等待下方Output窗口输出加载日志。加载成功的标志是看到类似这样的日志Loading extension from: /path/to/burp-decrypt-plugin.jar Loaded 12 decryption rules. Registering tab: Decrypt日志里提到的Decrypt标签页就是插件的核心控制台。你点开之后能看到请求解密记录、规则命中情况、Hook 脚本状态和自定义规则编辑器。如果日志里出现了异常最常见的几个原因jar 包损坏或版本不兼容重新下载对应版本。Java 版本过低升级 JDK。插件和另一个扩展冲突先禁用其他扩展再试。3.3 第一次验证用一个 AES 加密的 Demo 接口确认生效装完插件后我建议不要直接上生产目标先自己在本地搭一个登录接口验证效果。可以用 Python 写个简单服务前端用 CryptoJS 加密后端只判断请求里是否有加密字段。比如请求长这样POST /api/demo_login HTTP/1.1 Host: 127.0.0.1:8081 Content-Type: application/json {user:U2FsdGVkX1/d0T...,pass:U2FsdGVkX1/d0T...}在 Burp 里把这个请求发到 Repeater打开插件生成的Decrypted标签如果能看到{user: 13800138000, pass: Abc123456}说明插件已经成功识别并解密。再试一下修改明文比如把user改成另一个手机号发送后看后端是否能正常收到加密后的新密文。只要后端不报“解密失败”说明回填加密也生效了。如果第一次没有识别出来先检查规则是不是只作用于/api/login这类路径Demo 接口路径可能没命中。打开插件的 Debug 日志看它是否扫描到了这段密文。确认密文确实被扫描后再去补一条匹配当前接口的自定义规则。3.4 为什么说“即插即用”不等于“不动脑”插件默认规则能处理很多常见场景但“即插即用”四个字不等于你完全不需要理解业务。你至少要知道四件事目标接口用的是前端加密还是服务端加密。服务端加密不经过前端插件无法介入。密文所在的字段是什么是 JSON 字段还是表单参数或者直接在 URL Query 里。加密结果是 Base64 还是十六进制。很多插件默认按 Base64 处理遇到 hex 输出就会失败。密钥是固定写死还是每次登录动态获取。动态密钥需要单独配置提取规则。把这四件事搞清楚等于把插件的边界摸清了。否则就算插件再“万能”你也只能停留在“好像能解几个接口”的水平换个加密方式就不知道怎么办了。4. 想在不同端上抓加密流量代理、证书与 SSL Pinning解密插件本身处理的是 HTTP 层的数据但要让它能解到数据前提是 Burp 能抓到流量。Burp 抓包涉及代理设置、CA 证书和 SSL Pinning 三个环节任何一个没打通插件都是空转。4.1 浏览器端和 Burp 内置浏览器的踩坑点最简单的方式是直接用 Burp 顶部的Open Browser。这个内置浏览器会自动走 Burp 代理也自动信任 Burp 的 CA 证书省去很多环境配置问题。如果你用的是系统外部的 Chrome 或 Edge需要手动设置代理浏览器设置里找到“代理”相关选项把 HTTP 和 HTTPS 代理设置为127.0.0.1。端口设置成 Burp Proxy 监听器的端口默认是8080。访问http://burp在页面里点击下载 CA 证书。把证书导入到操作系统的“受信任的根证书颁发机构”。证书装好后浏览器访问 HTTPS 站点就不会再报证书错误。这里有一个常见坑Chrome 和 Edge 从某个版本开始会忽略系统代理里的局部配置导致 Burp 抓不到部分扩展程序或内部服务的流量。解决方案是改用 Burp 内置浏览器或者使用代理插件单独配置。4.2 Android 和 iOS 的证书信任移动端抓包比浏览器麻烦一些。以 Android 为例基本的步骤是手机和电脑连同一个局域网。在手机的 WiFi 设置里手动配置 HTTP 代理指向电脑的局域网 IP 和 Burp 端口。手机浏览器访问http://burp下载 CA 证书。在系统设置里安装证书。Android 7 之后有个默认策略普通 App 不信任用户安装的 CA 证书。也就是说即使你装了证书很多 App 照样会报“网络无法连接”或“SSL 连接失败”。解决思路是测试机如果是可调试环境把用户证书复制到系统证书目录或者用一个可以修改/system的模拟器/设备来测试。 iOS 端流程类似但还需要在“设置 - 通用 - 关于本机 - 证书信任设置”里手动开启完全信任开关这一步经常被忽略。4.3 SSL Pinning、小程序与授权边界证书信任配置好后另一个问题是 SSL Pinning。很多 App 会在客户端把服务器的证书或公钥写死导致代理 CA 无法通过校验。这个场景下最常见的做法是用 Frida 或 objection 在运行时 Hook 掉证书校验逻辑。比如 objection 的命令比较简单objection --gadget com.example.app explore android sslpinning disable或者写一个 Frida 脚本Hook 常见的SSL_CTX_set_verify、X509_verify_cert函数让 App 接受任何证书。这里必须强调所有绕过 SSL Pinning 和抓包手段只允许在你自己拥有或已经获得书面授权的设备、应用和系统上进行。未授权测试很可能触犯法律这一点不是套话是我见过真实案例后的忠告。关于“小程序抓包”微信小程序的数据流本质上也是 HTTPS。PC 端小程序可以尝试设置系统代理移动端小程序则需要证书信任和绕过 Pinning 的配合。成功抓到包以后加密字段的明文还原仍然依赖解密插件。你会发现流量到手只是第一步把业务参数看清才是关键。4.4 解密后如何喂给被动扫描器和业务逻辑测试流量解密后的价值不只是让你“看得爽”。Burp 的被动扫描器在扫描请求时如果看到的是密文很多基于参数名、参数类型、值特征的安全规则都无法命中。解密插件把明文还原之后被动扫描器才能真正识别出id、role、amount、callback这类参数从而给出更有意义的漏洞提示。业务逻辑测试更是依赖明文。比如身份认证绕过登录参数改成admintrue需要把修改后的明文重新加密再发出去。越权测试把订单查询接口的orderId换成别人的订单号同样需要重加密。金额篡改提交订单时把totalAmount改成0.01要看后端是否信任前端传值。我在实际测试里最喜欢把目标站点的“加密登录 加密响应”逻辑先摸清楚然后固化到插件规则里。这样后面所有接口测试都可以在明文视角下进行效率和准确率都高很多。5. 实战验证与翻车修复从正常解密到完全解不开通过这么多次测试我可以负责任地讲插件不是每次都能一次解开的。大部分“看起来简单”的加密实战里隐藏着不少翻车点。这里把常见的问题和排查链路完整记录一下。5.1 推荐的验证工作流当你拿到一个加密接口不要上来就直接跑 Intruder。我建议按下面这个顺序来先用浏览器或测试工具正常操作一遍目标业务让 Burp 里产生原始请求。打开插件Decrypt标签看看请求和响应是否都已经出现明文。如果只解了请求没解响应优先检查响应体里密文所在的字段名补一条响应解密规则。如果明文中能看到全部字段尝试修改其中一个字段观察插件是否自动重新加密。确认重加密后的密文能被后端接受再继续做深度测试。这套流程走下来插件是否正常工作、规则是否匹配、双向加解密是否完整基本都验证到了。不要跳过第 5 步很多人只验证了“能解密”没验证“能回填”结果在 Intruder 里发了一堆后端解密失败的包白白浪费时间。5.2 解不动的三种典型翻车场景翻车场景一请求解开了响应还是密文。原因是请求和响应用了不同的加密参数。很多系统请求用 AES-CBC 加密参数响应却用 AES-ECB 或者自定义编码再加密一次。你需要找到响应解密函数把响应规则单独配上。翻车场景二Burp 里是密文但页面却能正常显示。这种情况常见于加密逻辑发生在 Web Worker、gRPC、WebSocket 里或者页面用crypto.subtle异步加解密。插件注入的 Hook 脚本没有覆盖到 worker 线程导致在线 Hook 失效。解决办法是在 JS 源码里找到真正的调用链用离线规则手动处理。翻车场景三在Decrypted标签里改了明文后端却报“解密失败”。这通常不是插件的问题而是请求里除了加密字段还有其他校验字段比如签名sign、随机码nonce、时间戳timestamp。你改了明文但没有同步更新签名后端自然拒绝。排查时先看前端加密函数是否在密文生成后计算了sign如果有插件还需要一个额外的脚本逻辑来同步签名。5.3 完整的排查链路遇到解不开的情况我一般按照下面的链路排查效率最高确认密文确实已经到达 Burp页面没有启用双向 TLS 或私有协议绕过代理。打开插件 Debug 日志查看目标请求是否被扫描是否命中规则。如果没命中先确认字段名和规则的field配置是否一致。如果命中了但解密失败把密文复制到插件内置的“测试解密”工具里手动验证。打开浏览器开发者工具在加密函数调用处下断点确认算法和密钥的真实值。如果密钥是动态的看看它来自接口响应还是本地计算再用正则或脚本规则提取。如果密文看起来像标准 Base64但解密出来全是乱码考虑是不是先做了字符集转换或二次编码。这个链路我用了很多次绝大多数问题都出在第 3 步和第 5 步不是插件不够强而是规则没跟上业务实现。5.4 性能与稳定性建议在生产环境或大型 SPA 站点上插件如果默认对所有流量开启自动解密Burp 会变得很卡。我的做法是配置 URL 过滤规则只对目标域名的敏感接口开启解密。关闭不必要的在线 Hook 注入只在需要自动提取密钥时开启。在 Intruder 发起大量请求前先确认响应解密不会占用过多 CPU。定期清理Decrypt标签页的历史记录避免内存累积。保存插件规则到独立文件不要每次都重新配置。如果你在测试过程中发现 Burp 内存飙升优先检查是不是 Hook 脚本被重复注入到每个响应里了。给插件加上 URL 白名单之后这个问题一般会立刻缓解。6. 从“万能”到“自用”按业务定制自己的解密规则说到底内置规则只能覆盖通用场景真正让你解决复杂问题的能力是学会自己定制规则。这部分的思路比插件本身更重要。6.1 万能插件的边界与规则抽象每一条业务加密规则本质上是一组“元信息”的组合包括请求或响应的 URL 特征。密文所在的字段路径。加密算法、工作模式、填充方式。密钥和 IV 的来源。密文输出使用的编码格式。加解密前后是否需要额外的字符替换或脚本处理。把这些信息抽象出来就形成了一条可复用的规则。你会发现很多业务虽然域名不同、接口不同但加密方式大同小异。维护一个规则库越到后面越轻松。6.2 写一条简单的 AES 规则并验证假设目标接口是这样的POST /api/user/info HTTP/1.1 Content-Type: application/json {data:U2FsdGVkX1/d0T...}前端加密用的是 AES-CBC密钥是1234567890abcdefIV 是abcdef9876543210输出为标准 Base64。那么插件里的规则可以写成类似这样的 JSON{ name: user-info-aes, url: .*/api/user/info.*, direction: request, field: data, algorithm: AES/CBC/PKCS7, key: { source: fixed, encoding: utf8, value: 1234567890abcdef }, iv: { source: fixed, encoding: utf8, value: abcdef9876543210 }, output: base64 }保存规则后再发一次请求插件就应该能自动解密data字段。如果解出来还是乱码先检查密钥长度是否符合 AES-128 的 16 字节要求再检查输出到底是 Base64 还是十六进制。6.3 用自定义 JS 处理非标准加密有一些站点不会直接告诉你“用了 AES-CBC”而是把整个加密过程封装成一个自定义方法比如function buildData(input) { let str xorEncode(JSON.stringify(input), mykey); return customBase64Encode(str); }这种场景下固定的“算法 密钥”配置已经不够用了。插件一般会开放一个脚本入口让你自定义处理函数。常见写法类似function customDecrypt(meta, body) { let obj JSON.parse(body); let decoded customBase64Decode(obj.data); obj.data xorDecode(decoded, mykey); return JSON.stringify(obj); }脚本里可以调用插件暴露的通用工具函数也可以自己实现。把这段逻辑调试通过后再绑定到指定 URL插件就能按照你的方式处理这种非标准加密。注意插件帮你做的是原子化接入具体算法逻辑得你来写。6.4 规则沉淀与团队协作我见过不少测试者每次碰上加密接口都从零开始写脚本效率极低。实际更合理的做法是建立一个公共规则文件用版本管理工具保存下来。每条规则都加上适用站点、加密算法、密钥来源和验证样本。团队里有人遇到新加密方式把规则补充进共享库其他人就能直接复用。规则库需要定期清理针对已经下线的业务要移除避免误命中。把规则沉淀下来之后你会发现“万能”插件才真正变成你自己的万能插件。很多同类系统用的加密框架都来自同一套开源库规则一导入立刻就能解。6.5 后续扩展MCP 联动与 AI 辅助分析最近 Burp 生态里开始有 MCPModel Context Protocol联动方案可以把解密后的 HTTP 日志交给 AI 辅助分析。思路是插件负责还原明文AI 负责在明文基础上理解业务逻辑、寻找可疑参数、生成测试思路。比如解密后看到一个couponId和amountAI 可以很快提醒你可能存在优惠券重复使用、金额篡改等业务逻辑风险。不过需要提醒的是AI 分析和 MCP 联动属于锦上添花。核心还是先把规则维护好让明文数据干净、完整、可重放。否则 AI 拿到的全是密文和碎片再聪明的模型也帮不上忙。我实际用下来的体会是解密插件能不能“万能”很大程度上取决于你对规则的维护程度和对目标业务的理解深度。一开始我也是见一个接口解一个接口规则零散堆在一起。后来把所有加解密函数单独抽象成规则放进公共配置里管理再遇到同类型前端加密基本拖进去就能解。希望这篇能帮你在 Burp 解密这条路上少踩几个坑。