Burp Suite解密插件实战：从识别前端AES/RSA加密到自定义规则

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、padding
RSA 非对称加密	JSEncrypt、encryptlong、forge	密文很长，Base64 长度通常为 172、256、344 等	公钥、私钥、填充方式
自定义变种	XOR、Base64 换表、AES 后再二次编码	看起来像乱码，长度不规整，等号数量异常	编码表、异或 key、加密流程顺序

注意一个容易理解错的点：RSA 加密的场景里，前端用公钥加密，后端用私钥解密。测试者不需要也不可能在客户端拿到私钥去还原原始密码。真正需要做的是在请求里构造一段“合法的、能被后端解密”的新密文。也就是说，插件对 RSA 字段有时候不是“解密给你看”，而是“帮你把明文替换成新密文”。这也是很多人不理解“解密插件为什么还要支持加密”的原因。插件必须双向支持，你才能一边看明文、一边改参数、一边让后端不报错。

2.2 插件的核心工作流程：识别、解密、回填

我用的这款插件，本质上是一个IHttpListener类型的 Burp Java 扩展。每当有 HTTP 请求或响应经过 Burp 时，插件会先做一遍规则匹配，大致流程如下：

1. 根据请求 URL、Host、Content-Type 过滤候选流量。
2. 在请求体或响应体里扫描指定字段，比如 JSON 里的data、username、password。
3. 匹配到密文字段后，根据规则里的算法、密钥、IV 或自定义脚本完成解密。
4. 在原始消息旁边生成一个新的Decrypted标签，展示明文内容。
5. 如果你在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，按照下面几步操作：

1. 进入Extender标签页，选择Extensions子页。
2. 点击Add按钮。
3. 在Extension Details里把Extension Type选为Java。
4. 点击Extension File后面的Select file...，找到插件 jar 包。
5. 点击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": "Abc@123456"}

说明插件已经成功识别并解密。再试一下修改明文，比如把user改成另一个手机号，发送后看后端是否能正常收到加密后的新密文。只要后端不报“解密失败”，说明回填加密也生效了。

如果第一次没有识别出来，先检查规则是不是只作用于/api/login这类路径，Demo 接口路径可能没命中。打开插件的 Debug 日志，看它是否扫描到了这段密文。确认密文确实被扫描后，再去补一条匹配当前接口的自定义规则。

3.4 为什么说“即插即用”不等于“不动脑”

插件默认规则能处理很多常见场景，但“即插即用”四个字不等于你完全不需要理解业务。你至少要知道四件事：

1. 目标接口用的是前端加密，还是服务端加密。服务端加密不经过前端，插件无法介入。
2. 密文所在的字段是什么，是 JSON 字段还是表单参数，或者直接在 URL Query 里。
3. 加密结果是 Base64 还是十六进制。很多插件默认按 Base64 处理，遇到 hex 输出就会失败。
4. 密钥是固定写死，还是每次登录动态获取。动态密钥需要单独配置提取规则。

把这四件事搞清楚，等于把插件的边界摸清了。否则就算插件再“万能”，你也只能停留在“好像能解几个接口”的水平，换个加密方式就不知道怎么办了。

4. 想在不同端上抓加密流量：代理、证书与 SSL Pinning

解密插件本身处理的是 HTTP 层的数据，但要让它能解到数据，前提是 Burp 能抓到流量。Burp 抓包涉及代理设置、CA 证书和 SSL Pinning 三个环节，任何一个没打通，插件都是空转。

4.1 浏览器端和 Burp 内置浏览器的踩坑点

最简单的方式是直接用 Burp 顶部的Open Browser。这个内置浏览器会自动走 Burp 代理，也自动信任 Burp 的 CA 证书，省去很多环境配置问题。

如果你用的是系统外部的 Chrome 或 Edge，需要手动设置代理：

1. 浏览器设置里找到“代理”相关选项，把 HTTP 和 HTTPS 代理设置为127.0.0.1。
2. 端口设置成 Burp Proxy 监听器的端口，默认是8080。
3. 访问http://burp，在页面里点击下载 CA 证书。
4. 把证书导入到操作系统的“受信任的根证书颁发机构”。

证书装好后，浏览器访问 HTTPS 站点就不会再报证书错误。这里有一个常见坑：Chrome 和 Edge 从某个版本开始，会忽略系统代理里的局部配置，导致 Burp 抓不到部分扩展程序或内部服务的流量。解决方案是改用 Burp 内置浏览器，或者使用代理插件单独配置。

4.2 Android 和 iOS 的证书信任

移动端抓包比浏览器麻烦一些。以 Android 为例，基本的步骤是：

1. 手机和电脑连同一个局域网。
2. 在手机的 WiFi 设置里手动配置 HTTP 代理，指向电脑的局域网 IP 和 Burp 端口。
3. 手机浏览器访问http://burp下载 CA 证书。
4. 在系统设置里安装证书。

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这类参数，从而给出更有意义的漏洞提示。

业务逻辑测试更是依赖明文。比如：

• 身份认证绕过：登录参数改成admin=true，需要把修改后的明文重新加密再发出去。
• 越权测试：把订单查询接口的orderId换成别人的订单号，同样需要重加密。
• 金额篡改：提交订单时把totalAmount改成0.01，要看后端是否信任前端传值。

我在实际测试里，最喜欢把目标站点的“加密登录 + 加密响应”逻辑先摸清楚，然后固化到插件规则里。这样后面所有接口测试都可以在明文视角下进行，效率和准确率都高很多。

5. 实战验证与翻车修复：从正常解密到完全解不开

通过这么多次测试，我可以负责任地讲：插件不是每次都能一次解开的。大部分“看起来简单”的加密实战里，隐藏着不少翻车点。这里把常见的问题和排查链路完整记录一下。

5.1 推荐的验证工作流

当你拿到一个加密接口，不要上来就直接跑 Intruder。我建议按下面这个顺序来：

1. 先用浏览器或测试工具正常操作一遍目标业务，让 Burp 里产生原始请求。
2. 打开插件Decrypt标签，看看请求和响应是否都已经出现明文。
3. 如果只解了请求没解响应，优先检查响应体里密文所在的字段名，补一条响应解密规则。
4. 如果明文中能看到全部字段，尝试修改其中一个字段，观察插件是否自动重新加密。
5. 确认重加密后的密文能被后端接受，再继续做深度测试。

这套流程走下来，插件是否正常工作、规则是否匹配、双向加解密是否完整，基本都验证到了。不要跳过第 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 完整的排查链路

遇到解不开的情况，我一般按照下面的链路排查，效率最高：

1. 确认密文确实已经到达 Burp，页面没有启用双向 TLS 或私有协议绕过代理。
2. 打开插件 Debug 日志，查看目标请求是否被扫描，是否命中规则。
3. 如果没命中，先确认字段名和规则的field配置是否一致。
4. 如果命中了但解密失败，把密文复制到插件内置的“测试解密”工具里手动验证。
5. 打开浏览器开发者工具，在加密函数调用处下断点，确认算法和密钥的真实值。
6. 如果密钥是动态的，看看它来自接口响应还是本地计算，再用正则或脚本规则提取。
7. 如果密文看起来像标准 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，密钥是1234567890abcdef，IV 是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 生态里开始有 MCP（Model Context Protocol）联动方案，可以把解密后的 HTTP 日志交给 AI 辅助分析。思路是：插件负责还原明文，AI 负责在明文基础上理解业务逻辑、寻找可疑参数、生成测试思路。比如解密后看到一个couponId和amount，AI 可以很快提醒你可能存在优惠券重复使用、金额篡改等业务逻辑风险。

不过需要提醒的是，AI 分析和 MCP 联动属于锦上添花。核心还是先把规则维护好，让明文数据干净、完整、可重放。否则 AI 拿到的全是密文和碎片，再聪明的模型也帮不上忙。

我实际用下来的体会是，解密插件能不能“万能”，很大程度上取决于你对规则的维护程度和对目标业务的理解深度。一开始我也是见一个接口解一个接口，规则零散堆在一起。后来把所有加解密函数单独抽象成规则，放进公共配置里管理，再遇到同类型前端加密，基本拖进去就能解。希望这篇能帮你在 Burp 解密这条路上少踩几个坑。