Modbus协议在工控取证中的应用：报文分析、流量追踪与证据链重建

我之前梳理过不少工控相关的通讯协议，但真正让我对Modbus“另眼相看”的，是一次帮朋友排查上位机与PLC通讯异常的应急工作——抓包之后发现，整条链路的每一次寄存器读取、每一次频率设定、每一次启停控制，全部明明白白地躺在pcap文件里。那个瞬间我突然意识到，Modbus协议不仅是工控现场最普及的“普通话”，也是数字取证里极容易被低估的线索富矿。这篇学习笔记，就是把Modbus协议本身的报文结构、流量分析方法、常用调试工具，以及从PLC到PC的取证链路放在一起来写，给工控实施工程师、安全应急人员和数字取证从业者一份可以直接参考的实操记录。

我会尽量讲清两个方向：一是Modbus RTU/TCP的报文怎么读、怎么用Wireshark和tshark把关键操作从流量里捞出来；二是当需要追查“谁在什么时候对PLC做了什么”时，除了网络抓包，还有哪些证据源可以串成完整的证据链。内容偏实践，涉及工具的部分会带上具体配置思路和踩坑提醒。

1. 先搞懂Modbus协议：工控界的“普通话”

1.1 为什么这套老协议能活到今天

Modbus诞生于1979年，最初是Modicon公司给自己PLC产品设计的一套串行通讯协议。那个年代没有现在这么多复杂的总线标准，Modbus的初衷很简单：用尽量少的字节，让PLC能稳定地读写远程设备的数据。也正因为它简单——报文结构固定、功能码含义明确、实现成本极低——才从串口时代一路活到了今天，在PLC、变频器、仪表、传感器、HMI之间仍然是事实上的通用接口。

打个比方，Modbus就像是工控领域的“普通话”。某个设备可能内部是日语的思维方式，另一个设备是德语的思维方式，但只要它们都支持Modbus，就能通过这个统一的“普通话”完成数据交换。对工程师来说，这意味着不需要为每个品牌单独学一套协议，也就降低了集成和调试的门槛。

但这个“普通话”有一个致命缺陷：它完全不关心说话的人是谁。Modbus在设计时没有认证机制，没有加密机制，甚至没有防重放的机制。任何人只要能物理接入网络，或者能通过网络到达PLC的502端口，就能直接读取寄存器内容、改写线圈状态、下发控制指令。我们在取证时看到的绝大多数异常，都跟这个“信任一切”的设计有关。

1.2 RTU、ASCII、TCP：三种模式怎么选

Modbus按照传输载体和编码方式，主要分为三种模式：

RTU模式在串口总线上用得最广。它把每个字节直接以二进制形式发送，帧与帧之间通过至少3.5个字符时间的静默间隔来区分。为什么要有这个间隔？因为串口总线上没有“包边界”的概念，接收方只能靠时间间隔判断一帧数据的起止。如果间隔太短，接收方就会把两帧数据合在一起解析，导致乱码。

TCP模式则是把Modbus报文塞进TCP/IP网络里，默认监听的端口是502。相比RTU，它少掉了CRC校验——因为TCP本身可以提供可靠的传输和校验，再算一遍CRC属于重复劳动。同时TCP模式增加了一个MBAP报文头，用来标记事务ID、协议ID、报文长度和单元标识符。单元标识符这个字段很有意思，它其实是为了兼容“网关下挂多条串口总线”的场景，让TCP上的一个请求能够继续路由到某个具体串口从站。

选择哪种模式，取决于现场硬件条件。如果现场是老旧设备，只有RS-485接口，那基本就是RTU。如果是新上的PLC和变频器，且都在一个局域网内，直接走Modbus TCP最省事。不过取证分析中我们最常遇到的也是这两种，所以下面拆报文时我会以RTU和TCP为主。

1.3 报文到底长什么样：字节级拆解

这里我直接拿两个我实际拆过的报文来做例子，先把RTU帧结构摆出来：

举个例子，一条读取1号站保持寄存器、起始地址0x0000、数量2个寄存器的RTU请求，报文是：

01 03 00 00 00 02 C4 0B

这里01是从站地址，03是功能码（读保持寄存器），00 00是要读的起始地址，00 02是读取数量，C4 0B是CRC16校验值，低字节在前。响应报文则是：

01 03 04 00 01 00 A5 7A 66

01是站地址，03还是功能码，04表示后续数据有4个字节，00 01和00 A5就是两个寄存器的值，最后的7A 66是CRC。这套规则非常机械，但取证时就怕这种“机械”——因为它意味着只要报文完整，我们就能百分百还原当时的读写动作。

Modbus TCP的帧结构稍微多了一层MBAP头：

相应的TCP读保持寄存器请求是：

00 01 00 00 00 06 01 03 00 00 00 02

00 01是事务ID，00 00是协议ID，00 06表示从单元标识符开始还有6个字节，01是单元标识符，03是功能码，后面00 00 00 02同RTU。TCP模式没有CRC，是因为校验责任已经交给了TCP/IP协议栈。

1.4 寄存器模型与功能码：协议的核心地图

Modbus把设备内部的数据分成了四个区域，这也是理解取证证据的“地图”：

这张表看着简单，但取证时特别容易栽在一个坑上：数据模型地址和协议报文地址不相等。比如保持寄存器的数据模型地址是40001，但在报文里对应的协议地址偏移是0x0000。再比如变频器说明书里写“设定频率地址是4x100”，换算成报文里的偏移地址就是99（0x63，因为40001对应偏移0，4x100对应偏移99）。很多工程师和取证人员在这个“差1”的问题上翻过车，分析报文时一定要把说明书的地址体系转成协议偏移地址，再在流量里比对。

功能码就更直接了。0x03和0x04是读寄存器，0x06和0x10是写寄存器，0x05和0x0F是写线圈。在正常工况下，上位机的轮询以0x03、0x04为主，写寄存器操作相对低频且会对应具体的操作行为。一旦流量中出现大量集中式的0x06、0x10、0x05、0x0F写操作，基本可以断定有人在“动手脚”了。这是我做流量分析时第一个会去看的指标。

2. 取证视角下的Modbus流量分析

2.1 工控流量为什么比传统IT流量更好“说话”

做传统IT取证时，我们看HTTP、看DNS、看数据库查询，大量的交互都是加密的或者语义模糊的。工控流量恰恰相反——Modbus没有加密，没有会话认证，每条报文都赤裸裸地告诉你“我要读哪个地址、要写什么值”。这让我觉得，工控取证某种程度上比IT取证更“直观”。

另一点好处在于：Modbus通讯有很强的周期性规律。上位机通常以固定周期（比如100ms或500ms）去轮询PLC的寄存器，这意味着正常流量里会出现均匀分布的同功能码报文。异常行为要么打破这个节奏（比如突然出现大量写操作），要么打破流量方向（比如从不常见的IP发起连接），要么打破数据范围（比如写入数值超过合理工艺区间）。我们不需要看懂每个寄存器的业务含义，单从流量模式上就能快速圈出可疑时间窗口。

当然，这种“好说话”也有代价——Modbus本身不能提供用户身份，它只显示IP和端口。所以流量取证只能告诉我们“某个IP的某个端口对PLC做了什么”，至于“是哪个人操作的”，还需要结合主机取证和日志来补全。这也是为什么我坚持把流量、主机、PLC三方证据放到一起看。

2.2 用Wireshark把Modbus报文从pcap里捞出来

Wireshark对Modbus的支持是原生且完善的。只要流量走的是标准502端口，打开pcap后就能直接在协议列看到Modbus/TCP标签。我常用的操作步骤如下。

第一步，先看全局过滤，确认有多少流量跟Modbus相关：

modbus

如果你抓到的流量里没有出现过滤建议，可能是端口被改过，或者报文在非标准端口上，这时候可以改成：

tcp.port == 502

第二步，按功能码快速定位写操作，这是找“异常动作”最快的方法。比如我要看所有写多寄存器的请求：

modbus.func_code == 16

0x10写多寄存器的十进制是16，0x06写单寄存器的十进制是6，0x05写单线圈的十进制是5。这样过滤之后，屏幕上剩下的通常就是整个事件里最关键的操作报文。

第三步，定位到可疑报文后，我会右键选择Follow TCP Stream，直接看某条TCP连接里的完整Modbus交互。这时候要按HEX方式看，因为单纯的ASCII视图下，二进制值全都是乱码，根本看不出寄存器内容。

如果pcap文件特别大，用Wireshark的图形界面翻起来很慢。我更喜欢直接用tshark做预处理。比如把pcap里所有的写单寄存器操作导出成可读文本：

tshark -r capture.pcap -Y "modbus.func_code == 6" -T fields -e frame.time -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport -e modbus.unit_id -e modbus.reg -e modbus.value -E header=y

这样出来的表格会清晰列出每一笔写操作的时间、源IP、目标IP、单元标识符、寄存器地址和写入值。后续做时间线对齐、异常数据筛选都可以直接在这个表格上进行。

2.3 功能码时序分析：从“正常轮询”里挑出“异常动作”

我最早分析Modbus流量时犯过一个错误——想把每一帧报文都看懂。后来经验告诉我，最高效的方法是先看功能码的分布和时序，把“节奏”看明白了，再对可疑点做精细化解析。

一个典型的正常工位流量，功能码分布大概是这样的：

一旦流量变成下面这样：

基本可以判定异常。尤其是在非操作时间段，出现大量写寄存器指令，优先级就非常高了。

这里分享一个真实经验：有一次排查一条水处理产线的变频器频率被异常修改的事件，我抓包后按功能码统计，发现异常时间段内0x10写多寄存器的数量是全天正常写操作的几十倍，而且写入地址跨了0x30个偏移——正常工程师操作是单个参数微调，不可能一次写这么多地址。顺着这个线索去查源IP，很快就定位到了一台临时接进网络的调试笔记本。很多时候，功能码的“量变”早就先于业务影响暴露了问题。

2.4 实操：从抓包到还原一次寄存器写入操作

下面我完整演示一遍，遇到一条可疑的Modbus TCP报文时，怎么把它彻底“读透”。

假设pcap里有这么一条请求（HEX显示）：

00 01 00 00 00 06 01 10 00 0A 00 02 04 00 64 00 C8

先按MBAP头切开：00 01是事务ID，00 00是协议ID，00 06是长度，01是单元标识符。前7个字节是TCP模式的固定头。

接下来是PDU：功能码是10（十六进制），也就是十进制的16——写多寄存器。地址偏移是00 0A，也就是10。数量是00 02，表示一次写了2个寄存器。数据字节数是04，即4个字节。寄存器值分别是00 64和00 C8，转成十进制就是100和200。

结合PLC或变频器的寄存器映射表，如果有人说偏移地址10对应的是“1号泵频率设定”，偏移地址11对应“2号泵频率设定”，那么这条报文的意思就是：某台设备在某个时间点，把1号泵频率设成了100（可能对应10.0Hz），把2号泵频率设成了200（可能对应20.0Hz）。

响应报文通常是：

00 01 00 00 00 06 01 10 00 0A 00 02

注意响应是“回显”模式，返回事务ID、单元标识符、功能码、地址和数量，但没有寄存器值。所以在取证分析时，要以请求报文里的数据为准。

这个过程看似简单，但实际在pcap里翻报文时很容易被两个问题干扰。一是事务ID不是一层不变的：上位机软件会递增或复用事务ID，不能拿它当唯一标识来排序。二是地址和数据的字节序：不同设备可能用大端或小端表示寄存器值，遇到多字节数据时，要结合具体设备手册确认字节序，否则会把高位和低位搞反。

3. Modbus取证工具箱：Poll、Slave与开源替代

3.1 Modbus Poll：主站模拟器怎么用于取证复现

Modbus Poll是Witte Software出品的一款主站模拟工具，在工控调试圈里几乎人手一份。它模拟的是一个Modbus主站，可以主动去连接从站设备（比如PLC或变频器），并按照你配置的寄存器地址和功能码持续读取数据。

在取证场景中，Modbus Poll有两个很实际的用途。第一个用途是复现与验证：如果现场还在，且我们拿到了寄存器映射表，可以用Poll模拟当时上位机的轮询逻辑，确认某个寄存器地址对应的实际设备参数，以及正常值应该在什么范围。第二个用途是判断“如果按攻击者的报文再发一遍，设备会有什么行为”，这可以在隔离的测试环境里做，用于验证异常写入是否会导致现场故障。

配置上很简单：选择Connection Mode为TCP/IP或者串口，填上设备IP和端口502，或者选择串口号和波特率；然后在Setup菜单里选择功能码（比如0x03读保持寄存器）、起始地址和读取数量。Poll的显示区域会自动刷新读取到的数值，还能按你设置的格式（十进制、十六进制、浮点数）展示。

这里有个关键提醒：Poll在发起读操作时，发出的是周期性的轮询，而不是单次请求。所以在接现场设备测试前，务必确认不会影响到生产流程。我在做测试时，一般只允许接在停机的设备或者独立的测试从站上，绝不直接挂在运行的PLC上试。

3.2 Modbus Slave：搭一个安全的测试从站

Modbus Slave是配套的从站模拟工具，可以把自己的电脑模拟成一个Modbus从站，监听502端口或串口，并主动维护一份寄存器数据表。

取证时我会这么用Slave：把从pcap里还原出的“异常写入值”填进Slave的寄存器列表，然后用Modbus Poll去读，直观查看在外部视角下读到的数据长什么样。这种方法特别适合向不熟悉报文的业务同事解释——你不用跟他讲功能码和字节序，只要让他看到屏幕上某个频率值从50变成了5000，他就能明白问题在哪。

两个工具联调也简单：一台电脑开Slave监听TCP端口，另一台电脑开Poll去连，就能在不出网络、完全不碰现场设备的前提下，把报文交互跑通。对初学者来说，这是练习Modbus报文理解最安全的环境。

3.3 关于工具授权和“注册码”的一点提醒

这里必须多嘴一句：Modbus Poll和Modbus Slave官网提供评估版，足够日常学习和基础测试使用。免费版可能在功能或使用时间上有一些限制，但用来跑通协议流程、做小规模的报文验证完全够用。

网上确实能搜到各种“密钥”“注册码”之类的东西，我对这类文件的态度是：不要碰，也不要用。原因有两个：一是来源不明，极大概率被捆绑了木马或后门，取证人员在分析工具上中招，那是搬起石头砸自己的脚；二是这类序列号属于灰色地带，没必要为了一个调试工具给自己惹上合规风险。老老实实用评估版，或者用下面说的开源方案，安全且省心。

3.4 开源替代与脚本化解析

如果你不想受评估版的限制，或者需要在Linux服务器上批量分析报文，开源工具是更好的选择。

QModMaster是老牌的开源Modbus主站模拟工具，界面简单，支持TCP和RTU，适合快速测试。mbpoll是命令行工具，适合在脚本里调用，比如定时去读一个设备的寄存器值。modpoll也是类似的命令行工具，功能差不多。

但在取证分析里，我最常用的其实是Python的pymodbus库。它不只是用来“发起请求”，更重要的是能解析Modbus报文。配合前面tshark导出的关键字段，我可以写个几十行的小脚本，把pcap里所有写寄存器的操作批量转成结构化的CSV，包含时间、源IP、目标地址、寄存器偏移、写入值。

这里给一个简化版的思路，方便理解整个批处理流程：

import csv import pyshark capture = pyshark.FileCapture('capture.pcap', display_filter='modbus.func_code == 16') with open('modbus_write.csv', 'w', newline='') as f: writer = csv.writer(f) writer.writerow(['time', 'src', 'dst', 'unit', 'start_reg', 'quantity', 'values']) for pkt in capture: modbus_layer = pkt.modbus writer.writerow([ pkt.frame_time, pkt.ip.src, pkt.ip.dst, modbus_layer.unit_id, modbus_layer.reference_number, modbus_layer.word_count, modbus_layer.value ])

这个脚本只是演示逻辑，实际使用时要根据tshark版本调整字段名。核心思路是：把重复性的字段提取交给程序做，人只需要专注在异常值识别和业务含义判断上。

4. 从PLC到PC：完整证据链怎么串

4.1 证据源清单：别只盯着网络流量

很多刚接触工控取证的人会有一个误区：以为抓个包、看看Modbus协议就完事了。实际上，一次完整的事故调查需要把分散在多个位置的证据拼起来。我在现场排查时，习惯按这张清单去收集：

PLC本身的数据很容易被忽略，但它其实非常关键。PLC内部有时间戳，能记录最后修改程序的时间、某些寄存器值发生变化的时间，虽然粒度不像Wireshark那样到毫秒级，但足以和网络流量互证。另一个重点是从PLC上传出的工程文件里带有寄存器映射表——这个映射表是解读报文的“字典”，没有它，流量里的偏移地址就只是一堆无意义的数字。

4.2 Windows主机痕迹排查：上位机里留下的Modbus痕迹

绝大多数工控上位机是Windows系统，主机取证可以回答流量取证回答不了的问题：到底是哪个用户、哪个程序执行了操作。

排查时我会优先看这几类痕迹：

第一，软件和执行痕迹。Prefetch文件、Amcache.hve、SRUM数据库、UserAssist键值，能帮你还原某台机器上跑过哪些程序、什么时候跑的。如果异常流量来自一台来历不明的台式机，先在它硬盘上找这些痕迹，往往能直接指向某个第三方调试工具或者远程控制程序。

第二，事件日志。应用程序日志、系统日志、安全日志都要看。有些组态软件会在自己的日志里记录“用户登录”“工程下载”“参数修改”等操作，这些记录虽然不包含Modbus报文内容，但能给出操作人的账号和操作时序。

第三，配置文件和历史趋势文件。WinCC、组态王、InTouch的工程目录下，往往有通讯配置、变量表和趋势记录。这些文件能告诉我们这台工控机管理哪些PLC或变频器、用什么寄存器地址、历史趋势里有没有数值突变。

第四，网络连接痕迹。如果事发时机器的流量没有被完整抓到，可以用日志里留下的TCP连接记录，或者内存镜像中的网络连接信息，补全一部分“这个机器连过哪些IP的502端口”的证据。

4.3 内存取证：在镜像里挖出通讯记录

内存取证在工控场景里经常被忽视，但它能挖出普通硬盘分析看不到的东西。最典型的是网络连接记录——即使网络抓包没有覆盖事发时间段，只要拿到了嫌疑主机的内存镜像，就有可能还原出当时的TCP连接状态和缓冲区内残留的报文数据。

在Windows上，Volatility 2的netscan插件就是干这个的。它的原理是扫描内存中的TCP端点对象和端口对象，把所有活跃的、甚至已经关闭的连接信息枚举出来。输出的信息包括本地IP、本地端口、远程IP、远程端口、连接状态和关联进程ID。我一般先跑：

vol.py -f image.mem windows.netscan

或者老版本的：

vol.py -f image.mem netscan

拿到结果后，重点过滤远程端口为502的记录。一旦发现某个进程与某台PLC的502端口保持长连接，这个进程基本就是通讯程序的候选者。再用pslist、cmdline、dlllist等插件去确认该进程的映像路径和启动命令，就能把“哪个程序在操作PLC”这条证据坐实。

另外，Volatility 3时代的插件语法和Volatility 2有差异，有些团队会自己做一套GUI封装方便复盘和汇报。封装固然友好，但我还是建议至少会跑命令行——毕竟不同内存镜像的符号表、版本匹配问题，命令行下排查起来最直接。

4.4 三源时间线重建：让证据“咬合”起来

单独看流量、单独看日志、单独看PLC时间戳，都只能给出片段。取证结论的可靠性，来自于时间线重建之后的互相印证。

我的做法是，把三套时间数据分别拉出来，再统一到同一时区、同一时间基准下做对齐：

• 网络抓包时间：来自pcap文件，精确到秒甚至毫秒。
• 主机事件日志时间：来自Windows事件时间戳，可能会有时区偏差或时钟漂移。
• PLC内部记录时间：来自PLC的时间戳，现场很多PLC的时钟并不同步，偏差可能在几十秒到几分钟。

对齐时我会特别注意时区问题。很多抓包工具默认记录的是本地时间，而事件日志可能是UTC。如果直接拿未换算的时间做比对，很容易把“同时发生”误判成“先抓包后记日志”。稳妥做法是统一转成UTC再对齐。

对齐之后，把每个关键事件画成一条时间线：例如15:02:03.112，某主机向PLC发起0x10写多寄存器请求，写入偏移0x0A和0x0B，值为100和200；15:02:03.150，PLC响应成功；15:02:05.230，PLC内部故障记录触发；15:02:06.110，上位机报警窗口弹出。每一步都能对上，这个结论就很有说服力。

5. 实战复盘：一起Modbus写入异常的排查取证

5.1 事件背景与初步判断

某水处理项目现场，一台西门子PLC通过Modbus TCP与32台变频器通讯，控制多台水泵和风机的启停与频率。某天下午，操作员发现3号泵频率突然跳出正常设定范围，系统随即联锁停机。上位机操作日志里没有对应的操作记录，操作员也否认动过参数，项目方委托我们做分析。

初步判断矛盾点在于：频率设定值如果是从HMI或其他上位机下发的，一定会留下操作记录；既然操作日志干净，那异常写入极可能来自上位机之外的节点，或者上位机本身被植入了自动任务。这时就需要用网络流量确认“到底谁在什么时候写了什么值”。

5.2 排查与取证全过程

我到达现场后做的工作分四步。第一步是抓包。在交换机上做了端口镜像，把PLC所在VLAN的502端口通讯镜像到取证笔记本，连续采集了两小时。虽然事发时段已经过了，但周期性的轮询流量仍然能帮助我们建立“正常基线”。

第二步是离线分析。用tshark先按功能码统计了一遍，发现当前流量以0x03和0x04读操作为绝对主导，0x10写操作极少。这个基线很重要，它说明此刻网络上是“干净”的，而事发时段如果真的有过大量写操作，一定很突兀。

第三步是调取历史流量。项目方保留了一部分网管设备的抓包记录，我将事发前后1小时的pcap提取出来，过滤0x10和0x06。结果看到了完整的异常写入序列：来自IP 192.168.x.100的主机，在极短时间内连续发送了多条0x10写多寄存器请求，写入的起始地址正对应3号泵变频器的设定频率寄存器偏移，写入数值转换成工程单位后，超出了正常设定值数倍。

第四步是主机取证。192.168.x.100最终被定位到现场仓库里一台临时调试笔记本，系统是Windows 7。内存镜像里用netscan插件找到了与PLC 502端口的连接记录，进程列表里有一个与通讯相关的可执行文件，阿其残留的路径位于临时目录下。结合prefetch和用户最近打开文件记录，可以证明这台笔记本在事发前约半小时接入了生产网络，并且运行过能够下发Modbus指令的工具。至此，异常写入来源一条线全部打通。

5.3 复盘得到的几点经验

这次排查让我印象最深的一点是：如果项目方没有保留网管设备的抓包记录，这次取证会非常被动。所以对工控现场来说，常驻的流量记录本身就是最重要的时间机器。

另一个经验是：寄存器映射表一定要提前归档。那位变频器厂家的手册是电子版PDF，里面虽然有寄存器地址表，但技术人员过去从未按“偏移地址”归档过。我们在现场临时翻阅手册，花了将近一小时才确认3号泵频率对应的协议偏移地址。如果做过标准化的映射表归档，取证时间能缩短大半。

最后一点：现场时钟问题非常现实。PLC和抓包电脑的系统时间差了大概40秒，如果只靠肉眼硬对齐，我们可能无法把写入时间与设备报警时间精确对上。后来是把三套时间先统一换算成UTC再对齐，才消除了分歧。

6. 常见问题与避坑指南

6.1 高频问题速查表

6.2 独家避坑经验与注意事项

第一，一定要养成“先建立正常基线，再看异常”的习惯。如果没有基线，你会连正常轮询里的大量0x03报文都觉得可疑；有了基线，异常功能码、异常源IP、异常写入频率就会自动浮出来。

第二，抓包位置决定证据效力。最好把镜像口设在靠近PLC的汇聚层交换机上，这样既能看到上位机的操作，也能看到其他未经管理的节点接入。如果镜像口选错了层级，可能漏掉关键流量。

第三，分析Modbus报文时，字节序和缩放因子最容易被忽略。很多寄存器值不是“裸数”，需要通过设备手册里的公式换算成物理量。比如频率寄存器的单位可能是0.01Hz，那么5000代表的才是50.00Hz。算错缩放因子，结论会完全跑偏。

第四，授权和取证工具的安全本身就是取证工作的一部分。我之前反复说，不要用来路不明的破解版、注册机。取证设备上的工具如果被种了木马，不仅结果没有公信力，还会给项目引入新的安全问题。

写在后面

我在处理过几起Modbus相关的异常事件之后，最大的体会是：这套老协议的“简单”恰恰让它成为取证分析的最佳对象。它的报文不加盐、不加密，功能码和寄存器数据都直接暴露在网络中；它的通讯节奏规律性强，正常与异常很容易区分；它没有身份认证，但同时意味着，只要我们掌握了寄存器映射表，就能从流量里完整地还原出“谁、在何时、对哪个参数、执行了什么操作”。

如果你正在做工控安全或者准备进入这个方向，建议先用Modbus Poll和Modbus Slave在自己电脑上搭一套虚拟环境，把读保持寄存器、写寄存器、写线圈这几类操作亲手跑一遍，再用Wireshark看报文变化。这个过程不需要昂贵的设备，也不需要冒风险去碰生产环境，但能让你的协议直觉快速建立起来。之后再去分析真正的pcap，你会发现，那些十六进制的字节流不再是天书，而是一条条清晰可读的操作记录。