给破解版Burp装上AI插件，我折腾了整整三天

起因很简单：挖洞太累了，每个请求都得自己盯着看参数猜漏洞，AI时代了就不能让机器干这些吗？

我的理想流程是这样：Hermes帮我搜集目标资产 → Burp抓包 → AI自动分析流量 → 我最后确认一眼是不是真洞。正好本机跑着Claude Code，于是让Hermes帮我找了一圈，发现了这个开源项目，GitHub上叫 burp-ai-agent，一千四百多星，在Burp的BApp Store里叫 Custom AI Agent。

项目主页写得挺诱人：支持一堆AI后端、几十种漏洞检测、能被动扫描也能主动发包验证。我就兴冲冲开始装了。

没想到这一装就是三天。

---

环境交代

先坦白一下：我用的是破解版Burp Pro，版本号2026.4.3。目录大概长这样：

D:\BurpSuite V2026.4.3\
├── Burp Suite_CN.bat       ← 中文版启动脚本
├── Burp Suite_EN.bat       ← 英文版
├── Burp_中文版(无CMD窗口).VBS ← 坑中之坑
├── burpsuite_pro.jar
├── BurpKeygenCN.jar
└── jre\                    ← 自带Java，不用另外装

正版用户可以直接从Burp里面的商店搜Custom AI Agent一键安装。但破解版嘛，得手动下JAR包，从GitHub的Releases页面拿 Custom-AI-Agent-full-0.9.0.jar，大概22MB。

---

第一天：装上了，但没完全装上

下载JAR，打开Burp，Extensions → Add → Java → 选JAR → 加载成功。Extensions列表出现Custom AI Agent，顶部多了个AI Agent标签页。我想着这不挺顺利的吗？

然后去Settings里配后端。Backend下拉菜单里有一堆选项，我第一反应选Anthropic——毕竟我用的是Claude嘛。结果切过去直接显示offline。想了想明白了：Anthropic后端需要填API Key（那种sk-ant-开头的），而我用的是claude login的OAuth登录，根本没申请过API Key。

没事，换一个。文档里说支持Claude CLI后端，正好我装了Claude Code。切过去——

CLI executable not found for claude-cli

找不到claude命令？我终端里跑claude --version明明好好的啊。第一天以失败告终。

---

第二天：和PATH死磕

冷静分析：Burp是Java程序，插件通过Java的ProcessBuilder调外部命令。它找不到claude，说明PATH有问题。

打开Burp的启动脚本Burp Suite_CN.bat，第二行就把我看傻了：

@SET Path=%JAVA_HOME%\bin;

这个分号后面是空的。它把整个系统PATH给覆盖了，只留了JRE的bin目录。外面装了什么软件、claude装在哪，Burp进程一概不知道。

修！把分号后面的空改成追加原PATH：

@SET Path=%JAVA_HOME%\bin;C:\Users\Administrator\AppData\Local\Microsoft\WinGet\Links;%Path%

保存，重启Burp。还报一样的错。

又排查了一圈。我用的是那个"无CMD窗口"的VBS启动器，点开一看：

ws.Run """Burp Suite_CN.bat""", 0

WScript.Shell.Run启动的子进程，环境变量继承不完整。也就是说，就算我在BAT里修了PATH，VBS传给BAT的PATH本身就是残缺的，%Path%展开来还是缺胳膊少腿。

行，不用VBS了，直接双击BAT启动。CMD窗口弹出来，Java版本显示正常，Burp启动——

还报错。

我心态有点崩。又查了一轮资料，发现Java的ProcessBuilder有自己的一套可执行文件查找逻辑，跟CMD窗口里的PATH不完全一致。就算CMD里claude能跑，Java进程也不一定找得到。

不纠结了，上物理外挂。在Burp的安装目录下直接扔一个claude.bat桥接文件：

@"C:\Users\Administrator\AppData\Local\Microsoft\WinGet\Links\claude.exe" %*

Java进程调用外部命令时，优先从当前工作目录找可执行文件，而Burp的工作目录恰好就是它自己的安装目录。这就绕开了所有PATH查找的问题。

保存，重启Burp，切Claude CLI——

没有报错。

它终于没有报错了。

---

第三天：真的能用了

配通之后试了一下。在Proxy History里右键一个请求，选Custom AI Agent → Analyze this request，弹了个警告框说检测到高熵值数据可能是密钥——查了一下这是插件自己的安全提示，确认无害点发送就行。

然后AI分析结果就回来了。我抓了一个登录接口的包，它自动分析出：

• 参数结构是AES-CBC前端加密（有key、iv、ciphertext三个字段）

• CSRF Token存在

• Origin和Referer一致，CORS没问题

• 标注了潜在风险：IV前缀看起来像固定值，可能存在Padding Oracle攻击面

这就是我想要的效果。以前看一个请求要自己逐行分析，现在右键一下AI就给报告，我只用盯着它标注的高危项去Repeater里手工验证。

---

总结：三个教训

回头想想，三天踩的坑其实就一个根因：破解版Burp的启动脚本把系统PATH清空了。连锁反应：

我做了什么	为什么没立刻生效
修了BAT的PATH	VBS启动不继承，白修
换BAT启动	Java的PATH解析跟CMD不同，还是找不到
放桥接bat文件	终于绕开了所有PATH问题

如果一开始就用BAT启动、直接扔桥接文件，可能十分钟就搞定了。但话又说回来，不踩这一圈坑我也不知道破解版Burp的启动链路有这么多层。

现在的工作流变成了：抓包 → 全选导出 → 丢给AI分析 → 看高危报告 → 手工验证。比我原来纯手搓的效率高了不是一点半点。

下一步想把这个流程再自动化一点——让AI能直接读Burp流量，不需要手动导出。插件的MCP功能理论上是做这个的，但当前版本SSE连接有bug，等后续版本修了再折腾。跑通了再写。

---

项目地址：GitHub搜 six2dez/burp-ai-agent，一千四百多星那个就是。