适合读者：网络安全从业者、对"挖洞"好奇的非专业人士。看不懂没关系，本文尽量用人话讲。

一、先讲个痛点

做安全的朋友可能都有过这样的经历：

拿到一个目标软件，想找它的漏洞。于是你要干这些事——

• 逆向它的协议格式（一份规范文档都没有）；
• 手写一个"发包器"或者"解析器"；
• 再写个"变异器"，把合法报文改得乱七八糟；
• 跑一晚上，第二天早上看它崩了没有；
• 崩了，还得手动回放、定位是哪个字段搞崩的……

每一步都靠"老师傅的经验"。模糊测试（Fuzzing）原本是一门手艺，不是人人都玩得转。

而今天要介绍的 7884 Vibe Fuzzing，把上面整条流水线压缩成了一句话：

"分析这个目标，挖出崩溃，给出 PoC。"

你只需要说这一句，剩下的事，交给 AI。

二、先补个课：模糊测试到底是个啥？

用大白话说：

模糊测试 = 往软件里灌入大量"长得像、但故意不对劲"的数据，看它会不会崩。

比如一个网络服务，你不断往它的端口发各种改坏了的报文：

• 长度字段写个负数；
• 数量字段写成 999999；
• 在中间插几个乱码字节……

正常人的逻辑是"这算什么测试？"，但软件不是人——它一遇到不合预期的输入，可能就会把内存写坏、越界访问、指针悬空，"砰"地一声崩了。

而这个"崩"，往往就是漏洞的入口：栈溢出、越界读写、拒绝服务……所以安全圈有一句老话：

"崩溃是漏洞的入场券。"

传统模糊测试的问题在于：门槛太高。你得先"看懂"目标数据的格式，才能变出"有质量"的坏数据。纯随机乱改的坏数据，软件在解析第一层就把它扔掉了，根本走不到深处。

所以模糊测试的进化史，本质就是**"如何搞到更懂格式的坏数据"**的历史。

三、模糊测试的五代进化

第二代、第三代的共同痛点是：都需要"懂格式"——第二代要人懂，第三代虽然不用懂格式但要改目标代码插桩。

而第五代 Vibe Fuzzing 的思路是：格式的事交给专门的归纳引擎去"自学"，人只需要负责说人话。

四、Vibe Fuzzing 是什么？一句话版

Vibe Fuzzing = 大模型（手）× 归纳引擎（脑）。

• 大模型负责"表达"：听懂你说的人话、上网搜索目标、下载部署、把指令翻译给引擎、最后总结报告。它擅长"说话"，但不擅长"精确推理格式"。
• 7884 引擎负责"思考与执行"：纯黑盒地归纳结构、生成变异样本、在线发包、监测崩溃、回放取证。它不猜人话，只干实事。

分工有一句很形象的话：

"其他势力把大模型当大脑，7884 让自己做大模型的大脑。"

大模型永远不伪造格式，7884 永远不猜人话——格式的"形状"必须由引擎从真实样本里归纳出来。这就是这个范式的核心。

四-bis、引擎只是"大脑"，这个工程是"神经系统"

到这里你必须厘清一个关键事实：

7884_brain.exe 是核心引擎（大脑），但 Vibe Fuzzing 能真正"转起来"，靠的是包裹在引擎外的一整层工程。

打个比方：7884_brain.exe 像一个能力极强但只会干一件事的工人——你说"打这个协议"，它就埋头打，打完丢一堆 crash 文件给你。但它不会自己决定"下一轮该打哪个字段"，不会自己去重崩溃，不会把归纳出来的格式存起来下次复用，更不会自己拉起靶子、回收靶子。

这些"让引擎自主运转"的能力，全部由本工程在引擎外部搭建：

┌─────────────────────────────────────────────────────────┐│                    AI（大模型 / CodeBuddy /TRAE ）       ││         听人话 → 决策 → 读建议 → 改方向 → 出报告           │└───────────────┬─────────────────────────┬───────────────┘                │ 调用                     │ 读 vibe_loop_result.json                ▼                         │┌──────────────────────┐    ┌──────────────▼──────────────┐│  tools/collect_      │    │  examples/                   ││  protocols/          │    │  弹药库 + 靶场               ││                      │    │  · 1000(42类) 个测试靶子     ││  · vibe_loop.py      │    │  ·                          ││    闭环编排器        │    │  ·  工控 +  汽车知识库         ││  · ai_fuzz_loop.py   │    │  ·                          ││    反馈迭代          │    │  · 10 个 Protobuf schema     ││  · crash_report.py   │    │  · 4 个真实漏洞靶子          ││    崩溃汇总          │    │  · 证书/固件/航天样本           ││  · crash_triage.py   │    └──────────────────────────────┘│    去重 + 最小化     ││  · ai_import_        │    ┌──────────────────────────────┐│    protocol.py       │◄──►│           (十万级知识库)      ││    知识写回          │     │                              ││  · protocol_         │    │  （识别 → 归纳 → 写回 → 复用）  ││    recognizer.py     │    └──────────────────────────────┘│    协议识别          │└────────┬─────────────┘         │ subprocess 调用         ▼┌─────────────────────────────────────────────────────────┐│              7884_brain.exe（结构归纳推理AI  核心引擎）    ││    结构归纳 / 变异发包 / 崩溃监控 / 取证落盘                │└─────────────────────────────────────────────────────────┘

这张图里有四层，缺一不可：

1. 核心引擎层（7884_brain.exe）：干活的肌肉。归纳结构、生成变异、发包、监控崩溃、落盘 crash 文件。它不知道"下一轮该怎么走"。
2. 闭环工具层（tools/collect_protocols/）：神经系统。把引擎的"一轮输出"变成"下一轮的输入"——编排多轮、读报告、归因、去重、最小化、写回知识库。这是把"一次性 Fuzz"升级为"自主闭环 Fuzz"的关键。
3. 弹药库与靶场层（examples/）：后勤。1000 个靶子让你随时有东西可打，35 个协议 XML 让你随时有格式可用，17 种工控协议知识库让你 --proto 直连免建模。
4. 十万级知识库层：记忆。归纳出来的格式写回这里，下次遇到同类协议直接复用，越用越聪明。

没有第 2~4 层，7884_brain.exe 只是一个"很强的解析引擎+发包器"，远谈不上"一句话开工"。下面逐层拆开看。

五、它是怎么工作的？一条流水线拆开看

整个 Vibe Fuzzing 是一个闭环，大致分六步：

第 1 步：建模——搞懂目标的"格式长什么样"

模糊测试要变出"有质量"的坏数据，前提是知道目标格式的结构：哪里是魔数（magic）、哪里是长度字段、哪里是校验和、哪里是载荷。

传统做法是人工逆向。7884 给你三条路，按省事程度排：

1. 协议库直连（免建模）：内置了 17 个工控协议（Modbus、DNP3、IEC104、OPC UA……）的字段级定义，说一句 --proto Modbus 就能直接开打，连建模都省了。
2. 样本自动归纳（零先验）：你丢给它 3~5 个同格式的样本（抓包文件、二进制文件都行），它自己用启发式算法推断字段布局、字段关系、校验和算法，输出一份"结构说明书"。不需要任何格式文档，不需要任何硬编码解析器。
3. 人工建 XML：实在不行还能手写一个结构描述文件，格式是公开的。

绝大多数场景走第 2 条就够——这是它区别于传统工具最大的杀手锏：以前是"人读懂格式才能测"，现在是"几个样本就能开工"。

第 2 步：冒烟验证——先确认链路是通的

正式开打前，先小规模发 20 个包试试水：目标回不回包、监控的进程名对不对、模型有没有报错。相当于打靶前先校一下枪。

第 3 步：正式打靶——55 种变异策略 + 自动修复

这是重头戏。引擎知道格式结构后，会按字段边界做"语义级"变异，而不是粗颗粒度地乱改字节。Pro 引擎内置 55 种变异策略，比如：

• 把数字字段改成边界值、负数、超大数；
• 把长度字段和实际内容错开；
• 在字符串中间插入畸形字节……

更厉害的是自动修复：

• 改了数据，CRC 校验和会自动重算——变出来的样本是"合法的坏数据"，能穿透目标的第一层合法性检查，走到深处的解析逻辑；
• 压缩载荷会重新编码，ZIP/GZIP 容器能透明穿透，连嵌套 16 层的容器都能解包再变异；
• 关键的魔数、结构标识会被自动保护，不会改得面目全非让目标在第一层就丢包。

这正是"好样本"和"垃圾样本"的区别——变出来的每个包，都像是"一个合法用户的手抖了"，而不是"一群疯子扔石头"。

第 4 步：崩溃判定——只看一条铁律

跑了几千、几万个变异包之后，怎么算"命中"？

7884 的答案是：只看MONITOR: target process crashed这一行。

引擎会实时监控目标进程是否存活，一旦检测到目标进程崩了，立刻把触发崩溃的那一个报文原样落盘保存。这条铁律的意义是防止"把网络超时当崩溃"这种低级误判——崩，就得是进程真崩了。

第 5 步：取证复现——把崩溃变成证据

找到崩溃只是开始，还得能复现、能定位：

• 崩溃触发包自动落盘（crash_N.bin）；
• --replay
   一键回放：把当时的那个包重新发一次，确认目标再次崩溃；
• 崩溃去重：同一类崩溃合并，不浪费精力；
• 崩溃最小化：把触发崩溃的报文尽可能改小、改短，找到"最小触发条件"，这对写漏洞报告和 PoC 非常有价值。

第 6 步：闭环迭代——越测越聪明

到这里还不算完。7884 引擎本身只跑一轮，"多轮自动迭代"是本工程的vibe_loop.py在引擎外部编排出来的。

闭环工具（tools/collect_protocols/vibe_loop.py）把整个过程"自动滚起来"：

• 多轮自动迭代：vibe_loop 每轮自动拉起靶子 → 调 7884_brain 跑一轮 Fuzz → 回收靶子 → 读 report.json 分析这一轮覆盖了哪些字段、有没有新崩溃、哪个字段是"崩溃重灾区"，然后生成机器可读的"下一步建议"；
• 崩溃去重：每轮新崩溃按触发报文 SHA1 签名去重，同一类崩溃不重复计数；
• 定向补枪：如果发现某些字段还没被覆盖，下一轮的 recommendation 字段会明确指出"建议用 --mutation-target  定向打这些字段"；
• 收敛判据：连续 N 轮（默认 2 轮）既无新覆盖、也无新崩溃，自动判定收敛并停止——不浪费算力；
• 知识写回：把收敛出来的字段定义通过 ai_import_protocol.py 写回 protocols.db。下次再测同类协议，起点更高，越用越聪明。

整个闭环的指挥权始终在 AI 手里：AI 读 vibe_loop 产出的 vibe_loop_result.json → 改方向 → 再跑一轮，直到收敛，最后交出一份结构化漏洞报告：崩溃样本、复现步骤、字段级归因，直接可以进 CI 当质量门禁。

一句话：7884_brain 是"一轮打靶的枪"，vibe_loop 是"让枪自己一轮一轮打、还会总结的指挥官"。

六、它和传统模糊测试的区别

七、闭环编排器 vibe_loop.py：把"一轮打靶"变成"自主迭代"

上面流水线的第 6 步是整个 Vibe Fuzzing 的灵魂，而它的具体实现就是 tools/collect_protocols/vibe_loop.py。这个文件不长（不到 300 行），但它的设计思路值得单独拆开看——因为它回答了一个核心问题：引擎只会跑一轮，怎么让它"自己一轮一轮跑下去"？

7.1 它干了什么

vibe_loop 的工作循环，每一轮都是这个序列：

拉起靶子进程 → 调 7884_brain 跑一轮 --NetGen → 回收靶子进程    → 读 report.json 提取覆盖指标 → 扫描 crash_*.json 做去重    → 判断是否收敛 → 生成 recommendation（下一步建议）

关键细节：

• 靶子生命周期管理：每轮自动 _start_target() 拉起靶子 exe，跑完后 _stop_target() 用 taskkill /F /T 回收进程树。如果靶子自己崩了（proc.poll() is not None），跳过 kill——纯黑盒，不注入、不插桩，只负责拉起和回收。
• 崩溃去重签名：优先对触发报文 .bin 做 SHA1；如果 bin 文件缺失，退化为结构签名（state_path + mutated_field + mutation_offset + changed_bytes + sent_len）。同一个崩溃不重复计数。
• 收敛判据：连续 --converge-rounds（默认 2）轮既无新字段覆盖、也无新崩溃，判定收敛，自动停止——不空转浪费算力。

7.2 它吐出什么

跑完后，vibe_loop 在 workspace 下写一个 vibe_loop_result.json，这是给 AI 看的"归因契约"：

{  ”tool”: ”7884 vibe_loop V18”,  ”converged”: false,              // 是否收敛  ”rounds_run”: 5,                 // 跑了几轮  ”final_coverage”: {    ”unique_state_paths”: 42,      // 覆盖的唯一状态路径数    ”unique_fields”: 7             // 覆盖的唯一字段数  },  ”crashes”: [”crash_001.json”, ”crash_002.json”],  ”attribution”: {    ”top_fields”: [”function_code”, ”length”],     // 崩溃归因字段（频次降序）    ”top_mutation_types”: [”boundary”, ”overflow”] // 命中变异类型  },  ”recommendation”: ”发现崩溃 -> crash 归因字段: function_code, length;                     命中变异类型: boundary, overflow;                     已落盘 2 个崩溃样本, 可用 --replay 复现 + crash_triage 最小化;                     尚未覆盖字段: unit_id”}

这个recommendation字段是整个闭环的"交接棒"——AI 读它来决定下一步：是定向补枪未覆盖字段，还是进入崩溃取证阶段，还是换 seed 重来。

7.3 为什么它不固化"一键脚本"

一个重要的设计哲学：vibe_loop 只负责"跑轮次 + 出建议"，它不替 AI 做决策。AI 拿到 recommendation 后，可能：

• 照建议走（--mutation-target unit_id 定向打未覆盖字段）；
• 不照建议走（AI 判断这个方向没前途，换协议、换引擎参数、换靶子）；
• 直接收敛收工，进入 crash_triage.py 做崩溃最小化。

这种"引擎出事实、工具出建议、AI 出决策"的分工，正是 examples/README.md 里强调的那条理念：

★ 7884 不提供"一键完成 Fuzz 全程"的脚本。Fuzz 的编排（选协议/引擎/迭代数/取证）是 LLM + 7884 共同决策的过程，由 LLM 按决策卡动态决定，不做脚本固化。

7.4 闭环工具链全景

vibe_loop 不是孤军作战，它和兄弟工具组成一条完整的"崩溃下游流水线"：

一条完整的闭环路径长这样：

vibe_loop 跑 5 轮 → 产出 vibe_loop_result.json + crash_*.bin    → crash_report.py 汇总归因（哪些字段是崩溃重灾区）    → crash_triage.py 去重 + ddmin 最小化（200 个崩溃 → 3 个最小 PoC）    → ai_import_protocol.py 把收敛格式写回知识库    → AI 汇总成漏洞报告

这条链上的每一个环节，都是本工程在 7884_brain.exe 之外搭建的。引擎只负责"打"，这整条链负责"打完之后怎么办"。

八、弹药库与靶场：examples 生态

光有引擎和闭环工具还不够——你得有靶子可打、有协议格式可用、有样本可归纳。这些全部预置在examples/目录里，构成了 Vibe Fuzzing 的"弹药库 + 靶场"。

8.1 一千个靶子，随时开打

examples/servers/ 提供了1000 个测试靶子：

• 9 个已编译的 exe（HTTP / FTP / Modbus / DNS / TFTP / SNMP / Echo / Silent / 确定性崩溃靶），覆盖 TCP/UDP 两种传输、值域崩溃（0x5B 除零）和长度崩溃（strcpy 栈溢出）两类埋点；
• 991 个 C 源码（947 个网络服务 + 44 个文件解析器），跨 40+ 行业（电力、水利、交通、制造、医疗……），用 _build_all.bat 一键编译。

这意味着什么？你不需要自己找靶子、自己编译、自己搭环境——AI 说一句"测 Modbus"，靶子已经现成：

start /b servers\modbus_server.exe# 启动靶子7884_brain.exe --NetGen protocols\modbus_net.xml -i 20000 --host 127.0.0.1 --port 502taskkill /f /im modbus_server.exe# 清理

每个靶子都有对应的 scripts\start_*.bat 启动脚本（1000 个靶子 = 1000 个脚本），但脚本只负责启动，Fuzz 编排不固化——由 AI 按决策卡动态决定。

8.2 三十五个协议 XML，开箱即用

examples/protocols/ 提供了35 个 NetGen 协议建模 XML：

• 通用协议 13 个：HTTP / FTP / DNS / TFTP / SNMP / Echo / TCP / UDP / 状态机 / DataSet 多样本 / Relation 字段关系……
• 工控协议 17 个：Modbus / DNP3 / IEC 60870-5-104 / S7comm / OPC UA / EtherNet/IP / BACnet / PROFINET / EtherCAT / KNX / HART-IP / DF1 / FINS / MELSEC / CC-Link / DLMS-COSEM / GOOSE；
• 汽车协议 4 个：UDS / DoIP / SOME/IP / CAN；
• TLS 加密载体 1 个（V19 新增）：TLS 1.2 + Schannel，配套 https_server.py 靶子。

这些 XML 既是教学示例（展示 7884-net 格式怎么写），也是实战起点（直接 --NetGen 开打）。正式测试还可以用 --proto auto 让引擎自动生成，连 XML 都不用手写。

8.3 结构归纳的样本粮仓

--proto 协议库直连和手写 XML 都不是 7884 最强的能力——最强的能力是"丢几个样本自动归纳格式"。而本工程的 examples/ 预置了大量样本供归纳引擎"吃"：

一条命令就能对任意样本做结构归纳：

7884_brain.exe -i examples\formats\custom_format -o out --cuda-disable

8.4 四个真实漏洞靶子：不是模拟，是真漏洞

examples/real_targets/ 收录了 4 个官方验证报告实测出真实漏洞的软件：

这些不是"埋了 bug 的教学靶子"，是真实开源软件的真实漏洞——验证的是 7884 在真实战场上的杀伤力，不是沙盒里的演习。

更广泛的靶场索引见 examples/links/，包含官方 asm64.com 和 GitHub/Gitee 第三方下载地址。

九、知识飞轮：越用越聪明的秘密

Vibe Fuzzing 最容易被忽略的一层，是它的知识沉淀机制。这不是"跑完就忘"的一次性工具，而是一个会积累知识的系统。

9.1 知识库：13 万级协议字段，预置在引擎里

7884_brain.exe 内嵌了一个 protocols.db（SQLite），预置了13 万级协议字段定义——覆盖 17 种工控协议、4 种汽车协议、TLS、IoT、通用协议的字段级布局、字段关系、校验和算法。

用 --proto Modbus 直连时，引擎就是从这个库里取字段定义，连建模都省了。用 --proto auto 时，引擎先识别流量属于哪个协议，再从库里取对应模型。

9.2 协议识别：三级匹配，零硬编码

tools/collect_protocols/protocol_recognizer.py 实现了DB 驱动的三级协议识别（对齐文件格式的 magic + content_probe 思路）：

1. 传输层 + 端口缩小范围（protocol_ports 表）——比如 TCP:502 基本就是 Modbus；
2. Magic 匹配（protocol_messages.magic / protocol_fields.is_magic）——比如 Modbus 的事务 ID + 协议标识符；
3. Content probe 消歧（字符串/二进制特征）——多个候选时用内容特征打分排序。

返回候选协议列表（按 confidence 降序），同时支持协议栈递归识别（transport / protocol_dependencies）——比如先识别出 TCP，再识别 TCP 之上的 Modbus。

9.3 知识写回：归纳 → 沉淀 → 复用，正循环

这是整个飞轮的"合龙"环节。流程是这样的：

样本 → 引擎归纳出 structure_report.json    → ai_import_protocol.py 按 (proto_id, name, offset) 做 UPSERT 合并写回 protocols.db    → 下次 --proto <协议名> 直连时，起点更高（字段更全、关系更准）    → 再跑一轮 Fuzz → 新的归纳结果再写回 → 知识越来越精确

ai_import_protocol.py 的合并语义很关键：默认--mode merge（UPSERT），只更新/新增本次归纳到的字段，不清空既有知识。这意味着每次写回都是在已有知识上"叠加增量"，不会因为一次归纳不完整而丢掉历史积累。

注意：写回必须打到仓库主库（core/model_manager/protocols.db），而不是在发布目录新建稀疏库——否则会覆盖单 exe 内嵌的 13 万级协议知识。工具检测到新建库时会打 WARNING 提醒。

9.4 知识库的构建脚本链

tools/collect_protocols/ 下的 001_create_db.py ~ 015_cleanup_shadow.py 是知识库的构建与维护脚本链，从建表 → 种子数据 → 工控/汽车/无线/IoT 协议入库 → 分层 tier → 状态机 → CRC 算法库 → 版本戳 → Wireshark 元数据戳 → 自动 XML 生成 → 阴影清理，一步步把 protocols.db 从空库构建成 13 万级知识库。这些脚本本身就是知识库演进的版本记录。

一句话总结这一层：7884 不是"跑完就忘"的工具，它有一个会成长的知识库——每跑一次 Fuzz，知识库就更精确一分。

十、实测战绩（有据可查）

这些是官方验证报告里实测出的真实结果：

• 工控 · 电力 SCADA：IEC 60870 协议库 lib60870 —— 199 次真实进程崩溃；
• 无人机数据链：MAVLink v2 协议库 —— 第 2 次迭代就命中 CWE-121 栈溢出，复现率 100%；
• 汽车诊断：UDS（ISO 14229）协议库 —— 快速挖出高危 DoS；
• 航空航天：CCSDS 空间包 + ECSS PUS 遥测协议 —— 命中 CWE-121 栈溢出，复现率 100%；
• 大模型自写代码：LLM 自写的协议服务 —— 纯黑盒、无源码、无插桩，快速命中崩溃。

注意：以上都是本地授权的测试环境。挖洞这件事，永远是授权优先——没有授权，再好的工具也不能乱打别人的系统，这是底线。

十一、诚实地说：它不是什么都能干

再好的工具也有边界，不吹牛：

• 只支持 Windows x64，没有 Linux 版(没精力)；
• 加密协议的载荷内容对引擎是"黑盒"：它能把变异后的明文加密发出去，但应用层的签名、HMAC、JWT 这类字段变异后无法修复（密钥是应用层机密，CA 私钥也救不了）；
• CAN、BLE、Zigbee 等无线协议没有原生链路层，不承诺真实无线发包；(有兴趣可以参考 4320 项目 http://www.asm64.com/）
• 纯黑盒意味着不插桩，所以拿不到覆盖率数据——它靠"结构归纳 + 语义变异"来保证有效性，而不是靠覆盖率。（正因如此，我们的适用性远大于插装方案）

一句话总结它的适用面：凡是"有格式、有输入、能发包或喂文件"的目标，尤其是格式未知的私有协议和冷门文件格式，都是它的主场。

十二、最后

模糊测试38年，从"专家手艺"走到"一句话开工"。

Vibe Fuzzing 想表达的理念其实很简单：

你不需要成为格式逆向专家，才能找到别人找不到的漏洞。

大模型负责听懂你，归纳引擎负责想明白目标——你只管说出目标，从一句话到漏洞报告，全程无人值守。

但要让这套理念真正落地，光有一个"很强的引擎"远远不够。7884_brain.exe 是大脑，本工程是神经系统：

• vibe_loop.py
   让引擎从"跑一轮"变成"自主多轮迭代"；
• crash_report.py
   + crash_triage.py 把"一堆 crash 文件"变成"少数可复现的最小 PoC"；
• ai_import_protocol.py
   + protocol_recognizer.py + 13 万级 protocols.db 构成知识飞轮，越用越聪明；
• examples/
   的 1000 个靶子 + 35 个协议 XML + 海量样本粮仓 + 4 个真实漏洞靶子，让 AI 说完一句话就有东西可打。

四层叠加，才是"从一句话到 0day，全程无人值守"的完整答案。

"新范式的起点不是覆盖率，而是一句话：你描述目标，AI 自动上网搜、下载、部署，7884 自动归纳、变异、跑崩——从一句话到 0day，全程无人值守。"

本文基于 7884 Fuzz Agent V19 官方文档与源码编写，涵盖核心引擎（7884_brain.exe）、闭环工具链（tools/collect_protocols/）与弹药库靶场（examples/）。不包括全部信息，工具仅供授权测试使用。

7884 数学工作室 ·www.asm64.com