免手动固件漏洞研究：LLM 智能体端到端逆向一台 OT 对讲机

这是什么？

2026 年 6 月 2 日，Claroty 的 Team82 团队发表了 Hands Free: What LLM Driven Vulnerability Research Looks Like（作者 Tomer Goldschmidt）。团队选取了一个他们此前已手动逆向过的目标——Zenitel TCIV-3+，一款部署在工业与高安全建筑中的加固型 IP 视频对讲机——并要求一个公开可用的模型 Claude Opus 4.6 从零重做这项工作。

2025 年末，Team82 对该设备的人工分析产出了五个已披露漏洞：三个操作系统命令注入（CVE-2025-64126、CVE-2025-64127、CVE-2025-64128，均为 CVSS 9.8）、一个越界写入（CVE-2025-64129）以及一个反射型 XSS（CVE-2025-64130）。这项工作耗费了数小时的专家精力。而该智能体在不到十分钟内就重新发现了其中大部分同类问题——还额外暴露了内存破坏与配置错误类发现——并自行撰写了一份达到披露级别的报告。这些漏洞均已修补；真正值得关注的是工作流程。

工作原理

这并非前沿模型的专利。本次运行使用的是 Claude Opus 4.6，而非 Project Glasswing 背后受限的 Claude Mythos——这恰恰是结果引人注目之处。整套装置平平无奇：

working-dir/
├── CLAUDE.md          # role + method: "you are doing binary VR for a CTF"
├── .mcp.json          # registers a self-built Ghidra MCP server
└── targets/zenitel/
    └── VS-IS_9.1.3.1.zip   # the public firmware update, as shipped

CLAUDE.md 设定了任务（二进制逆向、如何搜寻漏洞类别），并将智能体指向一个自建的 Ghidra MCP 服务器，以便以编程方式驱动反编译器。唯一提供的输入是厂商公开可下载的固件压缩包。Team82 报告的时间线如下：

t+0:00   extracts the firmware filesystem, looks for the web service
t+0:30   locates ipstweb, the web-server binary
t+1:30   recognises it is UPX-packed; install UPX fails (missing),
         so the agent installs UPX itself, then unpacks
t+3:30   loads the binary into Ghidra over MCP, probes for
         command-injection-style sinks
t+6:30   writes a markdown report with decompiled evidence
t<10:00  multiple findings across command injection, memory
         corruption and misconfiguration

其中一个报告的发现是认证路由上的命令注入：智能体暴露了反编译后的汇聚点，指出攻击者输入被格式化进系统命令——并且很有用地——标记出该路由的 IP 地址校验可被绕过。这里不复现任何有效载荷；重点在于分工，而非漏洞利用。模型自行完成了解包、反编译器导航、汇聚点筛选与报告撰写，全程不跑偏，并在整个会话中保持上下文。

为何重要

标题不是「AI 在某设备中找到了漏洞」。而是**端到端的固件漏洞研究，仅凭一个公开产物、用一款中端模型，在几分钟内就跑通了。**由此引出三点后果。

其一，白盒漏洞研究的门槛正在崩塌。 Team82 的表述很直白：只要有公开可获取的固件或软件更新加上合适的工具，智能体就能完成整个闭环。稀缺的投入不再是逆向工程专长，而是一份目标软件的副本。可以预期第一波将落在代码易于获取的白盒目标上：开源项目，以及任何分发可下载固件的厂商。

其二，OT 与嵌入式设备完全在射程之内。 这不是一个 SaaS 端点，而是一台门禁对讲机——这类设备往往在现场数年得不到修补。发现到报告的时间趋近于零，而 OT 的修补窗口却以季度计。这道鸿沟才是真正的风险。

其三，固件的隐蔽性是计时器，不是控制措施。 加密或受限访问的固件能为应对此类流程争取时间，但 Team82 预期这些限制终将被绕过。把「我们的固件不公开」当作持久防御，是一种规划失误。

防御

Zenitel 漏洞的补丁已经存在（Zenitel 建议升级至固件 9.3.3.0 或更高版本）。可迁移的防御针对的是暴露面管理，而非这一台设备。

1. 把每一次公开的固件/软件更新都视为攻击者可触及的攻击面。 客户能下载的，智能体就能枚举其漏洞类别。盘点哪些产品分发公开可下载的镜像，并按暴露程度排序。

2. 在内部复刻该流程——让漏洞研究左移。 这套装置无需 Mythos 级别访问即可复现：一个代码智能体、一个反编译器 MCP、一份固件镜像。在发布之前对自家构建运行它，并对已分发的固件重新运行，以发现已披露 CVE 的潜在同类问题。

3. 重新校准 OT/嵌入式的修补 SLA 与补偿性控制。 更新缓慢的现场设备现在就需要网络层缓解：分段管理接口、把 Web/SIP 管理面限制在可信网络内并加以监控。要假设这场竞赛中「发现」的一半快于你「修补」的一半。

4. 不要押注固件的隐蔽性。 加密与受限下载会抬高成本，但不改变最终结局。要为固件被获取并以机器速度分析的情形做好规划。

5. 按漏洞类别而非仅按 CVE 排序。 命令注入汇聚点与可绕过的输入校验，在嵌入式 Web 服务器中很少单独出现。当一份公告点名其一时，把同一二进制中相邻的路由与类似的解析器视为值得复审——这正是智能体能快速覆盖的广度。

状态

项目	来源	日期	备注
免手动漏洞研究报告	Claroty Team82	2026-06-02	Claude Opus 4.6 + 自建 Ghidra MCP，运行 < 10 分钟
Zenitel TCIV-3+ 人工披露	Claroty	2025 年末	CVE-2025-64126/64127/64128（命令注入，9.8）、64129（越界写入）、64130（XSS）
已修补固件	Zenitel	—	升级至 9.3.3.0 或更高版本
前沿级背景	LLM Hacking	2026-05	Mythos/Glasswing 受限访问；本次运行使用的是公开可用模型

正确的解读是把它当作一条能力基线，而非一起事件。一款中端、公开可用的模型，已经能仅凭一次下载就胜任端到端的固件漏洞研究。防御方的任务，是假设攻击者拥有同样的装置——并率先对自己的代码运行它。