从一个固件文件，到一份带复现证据的漏洞报告——中间的解包、架构审计、模拟环境搭建、IDA 逆向、PoC 验证、失败复审，全部由两个 AI Agent 分工协作完成。
友情提示，处理实战使用展示部分其余都是使用AI帮我生成滴(偷个懒)。
前面大部分都是我的项目的一些介绍，也可以直接看看框架然后直接跳到实战使用部分看看我实战使用的一些情况。

总体架构

iot_vlun_auto：双端 AI Agent 协作的 IoT 固件自动化漏洞挖掘平台

从一个固件文件，到一份带复现证据的漏洞报告——中间的解包、架构审计、模拟环境搭建、IDA 逆向、PoC 验证、失败复审，全部由两个 AI Agent 分工协作完成。
友情提示，处理实战使用展示部分其余都是使用AI帮我生成滴(偷个懒)。
前面大部分都是我的项目的一些介绍，也可以直接看看框架然后直接跳到实战使用部分看看我实战使用的一些情况。

一、为什么做这个项目

随着大模型的崛起，分析人员也是鸟枪换炮了，AI极大的加速了安全分析的工作，我也是一边学习一边想到将自己所学转化成一个切实能辅助到我的一份工具，虽然它还不够完善，但是对我来说它已经还算不错了，后续有时间我将继续弥补项目的不足之处。

本项目做的是：确定性代码做苦力，LLM 只做判断。全流程被拆成确定性阶段（解包 / 审计 / 攻击面 / 模拟 / 验证）和少量真正需要智能的决策点（疑点审计、模拟环境修复、exploit 构造、失败复审）。LLM 只出现在决策点上，且每一次"成功"的结论都必须留下可机器校验的证据——无证据的申报会被程序直接推回。

二、项目一览

平台由两个物理上分离的 AI Agent 组成，通过消息队列协作：

输入：任意 IoT 路由器/网关固件镜像（.bin/.chk/.img，squashfs 封装）。

输出：漏洞清单 + 可执行 exploit（纯 Python 自包含、载荷内嵌）+ QEMU 模拟复现证据（verdict.json + 证据包）+ 人类可读报告。即使一轮挖掘一无所获，也会产出一份含负结果分析的报告——分析投入不白费，结论可追溯。

为什么拆成两台机器？因为两个端的能力天然互补且天然隔离：逆向分析离不开 IDA Pro（Windows 生态），而 qemu/FirmAE 模拟链条只在 Linux 上可用。这个物理隔离随后被项目做成了安全特性——下文详述。

三、总体架构

3.1 Ubuntu 编排端：iot-agent 控制台

Linux 端只有一个入口：iot-agent 交互控制台。它不是命令行菜单，而是一个真正的 coding-agent 式智能体：你直接输入自然语言需求（比如"挖 targets/vigor2962 的栈溢出，最多 2 个，优先 web 服务"），背后的编排智能体自行推理、用 todo 规划步骤，再通过白名单 pipeline 工具调用平台的全部确定性阶段。运行中你可以随时插话改方向、切模型，或用 /next 开下一轮。

编排智能体手下还有两个专用子智能体：

• emu_agent（模拟子智能体）：负责把固件服务在 QEMU 里跑起来——优先 FirmAE、其次 qemu user/system，可写脚本、做汇编级补丁，卡住时自助排障或跨端求助；
• exp_agent（确认子智能体）：对 Windows 交付的 exploit 字节做动态确认（gdb/gdbserver 级验证），但它无权产出任何 exploit 工件。

3.2 Windows 分析端：ida-service

Windows 端只需保持 ida-service 运行。它轮询消息队列，收到分析请求后走一条"便宜在前、昂贵在后"的漏斗：

1. headless IDA 批量提取（idat -A -S）：函数、字符串、导入表，纯确定性，结果缓存；
2. 确定性疑点预筛（VulFi 式 suspect_scan）：危险导入 / 交叉引用 / 伪代码模式打分，外加厂商符号启发和二阶 sink 推导——名字不起眼、但调用了危险导入的包装函数会被判为 sink，其调用者自动进入审计范围；
3. LLM 只审计疑似点：初始提示词只带疑点列表 + 少量反编译样本，agent 需要更多细节时再通过 MCP 按需查询 IDA 活实例；
4. 产出 <vuln> 结构化结论 → 物化为 exploit.py + description.json → precheck 一致性门禁 → 上传。

对大二进制，find_first 模式只带 top-5 样本进首轮 prompt，体积缩减约 60%——这是分析速度的关键。

3.3 中间层：JSON 文件消息队列 + SFTP

双端通信没有引入任何消息服务器或 RPC 框架，而是JSON 文件 + SFTP