正常报文测不出安全问题。 你的程序能正确解析Modbus功能码03的请求，能正确处理S7的DB块读写，能正确响应OPC UA的浏览请求——这些都是“正常路径”。安全漏洞几乎全部藏在“不正常路径”里。

模糊测试（Fuzzing）就是专门走不正常路径的方法：向目标设备发送畸形报文、非法功能码、超长字段、乱序序列，观察它会不会崩溃、重启、泄露信息、或者执行不该执行的操作。

工业协议模糊测试，比通用软件模糊测试难在哪？

现有模糊测试工具在分析私有工业协议时面临一个根本困难：缺少详细的协议规范。

Modbus、S7这些公开协议还好办，规范是公开的。但大量工业设备用的是私有协议——报文结构不公开、字段含义不公开、异常处理逻辑不公开。你没法基于规范去生成测试用例。

2026年的研究方向，是用AI来“推断”私有协议。

ICProFuzz用大语言模型来理解私有工业通信协议，在缺乏详细规范的情况下生成有效的测试输入。RRFuzzer专门针对工业控制系统的私有协议，用两级引导策略在报文层面改进测试用例的生成质量。ProtoFuzz-AI用Scapy、Wireshark/Tshark、Boofuzz和SQLite搭了一套AI辅助的模糊测试框架，不需要手写语法、不需要本地训练模型，就能对一个未知的工业协议发起模糊测试，有效输入率达到76%。

PLCFuzz是一个面向工业控制设备的自动化黑盒模糊测试框架，实验结果显示它在多个设备上发现了21个此前未知的拒绝服务漏洞。

模糊测试对普通工控开发者意味着什么？

你不需要成为安全研究员才能用模糊测试。最基本的模糊测试，你在办公室就能做。

用ProtoForge模拟一台虚拟设备，然后写一个脚本，向它发送格式错误、长度异常、功能码非法、字段值越界的报文。观察虚拟设备的响应：是正常返回异常码，还是直接断开连接？是保持运行，还是模拟“崩溃”？

你的上位机程序面对这些“不正常响应”时的行为，才是它真正的健壮性。

很多采集程序的正常路径写得很好，但一遇到设备返回异常码就崩溃、卡死、或者无限重试。模糊测试就是在办公室把这些“意外”提前制造出来，让你的程序在遇到真实设备的异常行为之前，就已经处理过一遍。

模糊测试不是“高级安全工具”，是一种工程习惯。

就像压测是验证系统在负载下的行为，模糊测试是验证系统在非预期输入下的行为。两者都是“在办公室把问题找出来”的手段，而不是“等到了现场再修”。

ProtoForge的28种协议仿真能力，可以作为模糊测试的执行环境——在虚拟设备上跑畸形报文，观察响应、记录异常，把健壮性问题挡在交付之前。

平时我也写写代码，维护两个开源项目：

ProtoForge（工业协议仿真平台，28种协议，130+设备模板）： 

GitHub：suoten/ProtoForge 

Gitee：suoten/ProtoForge

EdgeLiteGateway（AI物联网关，13种协议采集，边缘AI推理）： 

GitHub：suoten/EdgeLiteGateway 

Gitee：suoten/EdgeLiteGateway