Modbus协议取证实战：从流量分析到内存排查的完整路径

先讲一个我自己经历过的场景。某天晚上接到电话，厂区一套老产线的上位机界面数据乱跳，远程连过去一看，PLC的保持寄存器被改得面目全非，最后排查下来，是有人从内网某个IP用脚本在持续写线圈和寄存器。当时最棘手的问题不是“怎么修”，而是“怎么证明发生过什么、改了哪些地址、在什么时间改的”。要回答这类问题，光会抓包不够，光会读PLC程序也不够，必须把Modbus协议的字节级细节和数字取证的手段结合起来。这篇笔记就是围绕这件事展开的，适合正在做工控安全、等保测评、事件响应或者纯粹对协议取证感兴趣的读者。整篇内容以Modbus为主轴，把流量取证、主机痕迹排查、内存取证三条线串起来，希望能给你一条可以直接上手的路径。

1. Modbus协议基础：先搞清你面对的是什么

1.1 一个79年的协议，凭什么还是工控取证的核心对象

Modbus诞生于1979年，最初是给PLC通信用的串口协议，后来扩展到TCP/IP网络。它的设计极其简单，没有认证、没有加密、没有复杂的会话管理，放在今天看几乎就是“裸奔”。但正因为简单，它成了工业控制系统里部署量最大的通信协议之一。从水处理、电力、楼宇自控到生产线上的伺服电机、变频器、仪表，几乎都能看到它的影子。

取证时面对Modbus，本质上面对的是“存量巨大+安全性极弱”的组合。攻击者一旦进入工控网络，优先探测的多半就是Modbus设备——因为只要知道功能码和寄存器地址，就可以直接读写PLC的内部数据。这是它在数字取证里地位特殊的原因：Modbus流量往往直接对应到物理世界的动作，比如电机启停、阀门开闭、温度设定值修改。流量里一个0x05功能码的请求，可能就对应现场一次真实的设备动作。

所以理解Modbus，不能停留在“知道它是串口协议”的层面，而是要能从帧结构、功能码、地址映射、响应时序这些细节里读出事件链条。

1.2 协议分层与四种数据模型

Modbus常被说成“协议栈”，实际上它更像一个应用层协议。在TCP传输模式下，它承载在TCP/502端口之上；在串口模式下，它直接跑在物理链路上。它的核心是四种数据模型，理解这四种模型，是后续分析流量的前提。

实际抓包时，地址区间经常用“起始地址”来表示，比如0x0064换算成10进制就是100。这里有个特别容易踩的坑：协议PDU里的地址是0开始的，而数据模型表格里的编号是1开始的，两者差1。而且不同厂商点位表可能从0、1或者40001开始标注，分析时必须先确认基准，否则一个寄存器地址就能算错。

1.3 RTU、ASCII、TCP三种传输模式，取证时差别很大

Modbus有三张“脸”：RTU、ASCII和TCP。取证时首先要判断自己抓到的是哪种。

RTU模式是串口上最常见的二进制模式，帧结构紧凑，用CRC16校验。一帧RTU报文包含：从站地址（1字节）、功能码（1字节）、数据（N字节）、CRC16（2字节，低字节在前）。RTU帧之间要求至少有3.5个字符时间的静默间隔，帧内部字符间隔不能超过1.5个字符时间。这个时间约束在取证时非常重要——它意味着我们可以通过时间戳把连续字节流切分成独立请求帧。

ASCII模式把每个字节拆成两个ASCII字符发送，帧以冒号开头、回车换行结尾，肉眼可读但效率低。现在实际场景中已经很少见，但老设备上仍有存量。

TCP模式则把RTU的从站地址替换成MBAP报文头。MBAP包含事务标识符（2字节）、协议标识符（2字节，固定为0）、长度（2字节）、单元标识符（1字节）。协议标识符为0表示Modbus协议，如果不是0，很可能不是标准Modbus通信。TCP模式下没有RTU那种帧间隔概念，因为TCP本身就是流式协议，每个请求/响应对靠事务标识符来匹配。

取证建议：遇到串口抓包，重点抓RTU的静默间隔；遇到网络抓包，重点看MBAP头的事务标识符和单元标识符。这两个特征是理解报文的第一步。

2. 功能码、异常响应与地址映射：取证前必须吃透的细节

2.1 常用功能码与证据价值

功能码是Modbus帧里最核心的字段，它告诉从站“你要干什么”。从取证角度，功能码直接说明攻击者的意图。

实际分析时，我会特别注意0x06和0x10。0x06每次只写一个寄存器，看起来动静小，但攻击者可以循环写多个地址；0x10一次能写一批寄存器，效率高，攻击特征也更明显。功能码的分布频率也值得统计：如果正常业务大多是0x03读保持寄存器，突然出现大量0x05或0x06，基本可以判定有异常。

2.2 异常帧与错误码：攻击失败和探测行为的证据

Modbus从站在无法处理请求时，会返回异常响应帧。异常帧的功能码是把原功能码最高位置1（比如0x83对应0x03的异常），后面跟一个异常码。

异常响应在取证时的价值容易被低估。正常业务中的异常通常很少，一旦某个时间段内异常码0x02或0x03大量出现，往往是攻击者在摸点位表、试寄存器范围。我曾经在一个案例里通过异常码0x02的分布规律，反推出攻击者扫描寄存器的起始地址和步长，进而定位到他真正想写的目标区域。

2.3 寄存器地址映射与点位表：从数据变化反推攻击意图

寄存器地址本身只是一串数字，要让取证结论有说服力，必须把地址翻译成业务含义。这一步依赖点位表。

点位表通常由设备厂商或集成商提供，它把协议层的寄存器地址映射到具体的物理量。比如某台伺服电机的点位表可能是：

• 0x0064：目标转速（单位0.1rpm）
• 0x0065：加速度（单位rpm/s）
• 0x0066：运行模式（0=停止，1=正转，2=反转）

如果流量里看到0x06写0x0064的值为0x03E8，结合点位表立刻能知道：这是把目标转速设置为1000（因为0x03E8=1000，单位0.1rpm，即100.0rpm）。如果不能把协议层数据映射到物理量，报告里就只能写“修改了寄存器0x0064”，这对客户来说基本没有说服力。

所以我在实操时，无论做流量分析还是做PLC固件分析，第一件事永远是找点位表。点位表可以从组态软件工程文件、设备手册、HMI项目里提取，也可以在线监测一段时间流量后根据数据变化规律反推。

2.4 时间参数里藏着的取证线索

Modbus协议的时间特性是很多人忽略的取证金矿。

RTU模式帧间必须大于3.5个字符时间，这个前面提过。计算方式很简单：假设波特率9600，一个字符包含1个起始位、8个数据位、1个停止位，共10位，一个字符时间约1.04ms，3.5个字符时间约3.65ms。在串口抓包里，如果两个请求之间的静默间隔远小于3.6ms，说明它们可能属于同一帧；如果间隔刚好是几十毫秒的整数倍，往往说明是程序化轮询，比如PLC循环扫描。

TCP模式下，请求和响应之间的事务标识符和时序可以还原通信节奏。攻击脚本通常是“发一个请求-等响应-再发下一个”的同步模式，而正常上位机组态软件往往是周期性批量轮询。通过统计请求间隔的方差，我经常能一眼区分出“机器在正常干活”还是“脚本在扫描”。

另外，Modbus TCP没有内置时间戳，时间信息完全依赖抓包工具和主机时间。所以取证时，第一件事就是确认抓包机、上位机、PLC侧的时间是否同步。时间不同步，后面所有时间线还原都是白搭。

3. 流量取证实操：用Wireshark还原一次Modbus攻击链

3.1 环境准备与识别Modbus流量的方法

流量取证最常用的工具是Wireshark。它原生支持Modbus TCP解析，也能通过外部解析器处理RTU over-TCP的场景。抓包位置一般选在核心交换机镜像口、上位机网卡、或者现场部署的工业防火墙旁路口。

打开抓包文件后，先做基础过滤：

tcp.port == 502

如果端口是自定义的，先全流量跑一遍，再通过协议解析结果筛选。筛选到Modbus TCP流量后，Wireshark会自动标出协议为“Modbus/TCP”或“MODBUS”，此时可以进一步细化：

modbus.func_code == 0x03 # 只看读保持寄存器 modbus.func_code == 0x10 # 只看写多寄存器 modbus.exception_code == 0x02 # 只看非法数据地址异常

我一般还会用统计功能看“协议分级”和“会话列表”，快速找出通信量最大的几个IP对。工控流量最核心的特征是周期性，正常轮询的包间隔非常规律，如果某个IP对的请求模式杂乱无章，优先怀疑是扫描器。

3.2 逐帧拆解：一次完整攻击请求-响应过程

拿一个典型的攻击序列举例。某次事件中，攻击者从内网IP 192.168.10.66 尝试控制PLC，PLC地址是192.168.10.20，目标端口502。

第1步：设备探测。攻击者发送0x03读保持寄存器，起始地址0x0000，读取数量0x000A（10个寄存器）。Wireshark里显示的请求字段如下：

Modbus/TCP Transaction Id: 0x0001 Protocol Id: 0x0000 Length: 6 Unit Id: 0x01 Function Code: 0x03 (Read Holding Registers) Starting Address: 0x0000 Quantity of Registers: 0x000A

返回的响应如果正常，会带上寄存器数据和字节数。这一步的攻击意图是“看看你有哪些寄存器、是否允许读”。如果返回异常码0x02说明地址非法，攻击者会继续换地址探测。

第2步：参数改写。攻击者锁定目标后，发送0x06写单寄存器，把地址0x0064（对应转速设定）写入0x0000（停止）：

Function Code: 0x06 (Write Single Register) Register Address: 0x0064 Register Value: 0x0000

如果从站返回的响应与原请求完全一致，说明写入成功。这里有一个容易忽略的细节：响应帧的Transaction Id必须与请求一致。攻击脚本如果事务标识符处理不当，会在响应匹配上出问题，这也是定位脚本特征的方式之一。

第3步：批量篡改。攻击者改用0x10写多寄存器，一次写10个地址，把工艺参数全部改成预设值。请求里会带字节数0x14（20字节），随后是20个字节的寄存器值。

整个攻击链还原后，要立刻把关键请求做成表格，标注时间戳、源目IP、功能码、寄存器地址、数据值、对应业务含义。这比贴一堆原始包截图有用得多。

3.3 实战延展：基于Modbus RTU的伺服电机控制器抓包分析

TCP是最容易抓的，但实际产线里大量设备走的是Modbus RTU，比如伺服电机控制器、变频器。RTU跑在RS485总线上，抓包方式和网络抓包完全不同。

我常用的方法是RS485转USB设备，接到总线上监听，再用串口工具软件（如Modbus Poll附带的串口监视器）记录数据帧。关键参数必须确认：波特率、数据位、停止位、校验位，大多数设备是9600或19200，8位数据位、1位停止位、无校验或偶校验。参数不对，抓到的基本是乱码。

RTU帧分析时，先用3.5字符静默间隔切帧，再把每帧的第一字节当从站地址，第二字节当功能码。曾有一个伺服电机控制案例，流量里反复出现写寄存器0x0066（运行模式）的请求，值在0x0001（正转）和0x0002（反转）之间切换，频率极快，明显不是人工操作。结合现场工艺，确认这是恶意脚本在反复改变电机转向，导致机械机构频繁冲击。

RTU的CRC校验也要会算。Modbus CRC16的算法是：初始值0xFFFF，每个字节先异或到CRC低字节，再右移8次，遇到最低位为1则异或0xA001。比如要把从站地址1、功能码6、寄存器地址0x0064、数据0x0001组成一帧，CRC计算如下：

def modbus_crc16(data: bytes) -> int: crc = 0xFFFF for b in data: crc ^= b for _ in range(8): if crc & 1: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 return crc frame = bytes([0x01, 0x06, 0x00, 0x64, 0x00, 0x01]) crc = modbus_crc16(frame) print(hex(crc)) # 低字节在前：先发 crc & 0xFF，再发 crc >> 8

曾经有人拿错误CRC的报文让我分析，一查编码逻辑写反了，低字节高字节顺序不对。这种事在工控现场不少见，建议自己写个脚本验一遍所有RTU帧的CRC，能筛掉大量无效噪音。

3.4 证据链整理：从原始包到可提交的报告

流量取证到最后，核心产出是一份时间线清晰、字段完整的证据链。我的固定套路是：

1. 先按流会话分组，统计每个会话里Modbus请求的总数、功能码分布。
2. 再按时间排序，把所有写操作单独提取出来，标注寄存器地址和值。
3. 结合点位表，把寄存器地址翻译成业务参数。
4. 最后生成一张汇总表，把流量证据和现场反馈的设备异常时间对齐。

时间线表格我通常包含这些列：时间（UTC+时区）、源IP、目标IP、功能码、寄存器起始地址、数据值、操作类型、业务含义。如果需要提交司法鉴定或合规报告，还要保留原始pcap文件的哈希值，确保从取证到报告全流程可追溯。

4. 主机侧取证：Windows上位机里留下的Modbus痕迹

4.1 为什么上位机比PLC本身更容易留下证据

PLC本身的计算资源有限，日志能力也很弱，很多老型号根本不记录谁写过哪些寄存器。但上位机不一样，它运行着组态软件、Modbus调试工具、历史数据库，这些软件会在Windows系统里留下大量痕迹。

攻击者要改PLC参数，通常不是直接抓包发裸报文，而是借助工具：要么用Modbus Poll、ModScan这类调试软件，要么用组态软件的脚本功能，要么自己写Python脚本。无论哪种方式，都会在上位机上留下文件痕迹、注册表记录、进程痕迹。所以事件响应时，生产网内的Windows上位机是优先级很高的取证对象。

4.2 关键痕迹位置：配置文件、日志与工程文件

主机侧排查，我一般按下面的顺序来：

• 最近打开的文件列表。组态软件（组态王、WinCC、Intouch）会在注册表或配置文件里记录最近打开的工程路径，路径本身就能提示攻击者访问过哪个工艺段。
• 工程文件修改时间。工程文件（如PLC程序、HMI项目）的创建时间、修改时间、访问时间，能帮你锁定操作发生的窗口。文件系统的USN日志和$MFT记录提供的信息更精确，需要时直接上取证工具。
• 日志文件。组态软件自带的操作日志、报警日志、通信诊断日志，往往记录了登录用户、操作时间、操作类型。比如WinCC的报警记录里会包含变量变化事件，和Modbus写入能对上。
• 预取文件与快捷方式。如果攻击者运行过Modbus Poll、Python等工具，Windows会生成对应的预取文件，快捷方式也会更新。这些可以还原“他运行了什么程序”。
• 命令历史与PowerShell历史。如果攻击者用脚本命令行操作，PowerShell历史文件和cmd历史可能残留有效内容。

注意事项：上位机排查时要先做只读保护，最简单的手段是使用硬件写保护器或先对磁盘做镜像，再在镜像上分析。没有镜像就直接在原始盘上翻文件，容易破坏时间戳。

4.3 用时间线把主机痕迹和网络流量串起来

主机痕迹单独看是孤立的，要和网络流量结合才有说服力。我曾经办过一个案例：上位机的预取文件显示某个脚本在14:32:10被运行过，而pcap里14:32:12开始出现针对502端口的写寄存器请求，时间高度吻合。再查组态软件日志，发现同一个时间段内有个非值班账号登录过。三者一交叉，攻击路径基本就定了。

时间线还原时要注意几个坑：Windows文件时间一般记录为本地时间或UTC，抓包时间戳是UTC还是本地时间也要确认。最好统一换算成UTC再比对，否则差8小时这种情况会直接毁掉证据链。

5. 内存取证：当Modbus通信变成进程行为

5.1 内存取证在Modbus场景中的适用时机

有些攻击不落盘，脚本直接通过PowerShell或内存加载执行，这时候磁盘里可能挖不到东西。还有的情况是攻击者把恶意DLL注入到了组态软件进程里，通过上位机的合法进程收发Modbus报文。这两种场景都得上内存取证。

内存取证的目标是还原“某个进程在当时做了什么”。放在Modbus场景里，具体就是：哪个进程在监听502端口、哪个进程发起了到PLC的连接、进程内存里有没有Modbus报文片段、有没有被注入的可疑代码。

5.2 Vol2可视化内存取证GUI的基本使用流程

Volatility2是内存取证老牌工具，命令行有很多参数，对新手不太友好，所以有团队做了vol2可视化内存取证GUI，封装了镜像识别、进程枚举、网络连接提取等常用功能。操作上比命令行直观很多，但原理还是一样的。

第一步是加载内存镜像，比如memory.raw或.dmp文件。第二步做镜像识别，等价于命令行里的imageinfo，主要是判断操作系统类型和profile。profile不对，后面所有插件输出都很奇怪。我遇到最多的坑是老镜像里装过杀毒软件，导致profile识别出多个候选，这时要多试几个版本对比输出，以进程数量和内核结构最合理者为准。

第三步按需跑插件。排在最前面的通常是：

volatility -f memory.raw imageinfo volatility -f memory.raw --profile=Win7SP1x64 pslist volatility -f memory.raw --profile=Win7SP1x64 pstree volatility -f memory.raw --profile=Win7SP1x64 netscan volatility -f memory.raw --profile=Win7SP1x64 malfind -p [PID]

pslist看进程列表，pstree看父子关系，malfind扫注入代码。对Modbus场景，netscan是压倒性的重点。

5.3 netscan：直接定位502端口连接

netscan插件能从内存中提取系统的网络连接信息，包括TCP和UDP会话。在Modbus取证里，它最大的价值是直接定位到“哪个进程连着PLC的502端口”。

实际操作时，我通常会先跑netscan，然后过滤端口502的行。假设输出里有这样一条：

0x1a2b3c4d TCP 192.168.10.66:49183 192.168.10.20:502 ESTABLISHED -1 1234

最后一列的1234就是进程PID。拿到PID后回头查pslist，直接就知道是哪个进程在跟PLC通信。如果是svchost.exe这类系统进程在连502端口，基本可以判定为进程注入或恶意DLL加载。

netscan还能提取UDP连接，有些工控场景用Modbus UDP网关，同样需要关注。另外，如果内存镜像是从被入侵的上位机取的，还可以配合dlllist查看该进程加载了哪些模块，配合malfind检查目标进程是否存在可疑指令模式。

5.4 内存证据与流量证据的交叉验证

内存取证最怕“单点证据”，一个netscan结果只能说明“有连接”，无法证明“发过什么”。所以要把内存证据和流量证据交叉验证：

• 内存里某个进程连着502端口，时间点和pcap里的会话起始时间是否一致。
• 进程内存里是否残留Modbus请求字节，比如 0x00 0x00 0x00 0x06 0x01 0x10 这种典型的写多寄存器报文头，可以在进程内存转储里直接搜索。
• 恶意脚本如果驻留在内存，它的配置里可能写了PLC的IP、寄存器地址、写入值，这些和流量里的目标一比对，直接形成闭环。

做交叉验证时建议做一个“三表对齐”：内存连接表、pcap会话表、主机文件时间线表。三个表里相同时间窗口内能互相印证，证据链就站得住。

6. 常见问题与排查技巧实录

6.1 抓不到Modbus TCP包怎么办

抓包最常见的问题是镜像口配了但没流量，或者抓到了全是广播包。先确认交换机镜像是否生效，最简单的办法是拿一台测试机在镜像口连着的网段里主动ping一下PLC，看pcap里有没有ICMP包。没有，说明镜像口没配对。

另一个坑是端口不是502。很多PLC和上位机软件的Modbus TCP端口被改成了5000、5001之类，Wireshark如果按502过滤自然什么都没有。全流量抓包后按IP寻找通信对，或者用“modbus”协议过滤器让Wireshark自动识别，虽然Wireshark对非标准端口支持有限，但能识别出大部分。如果实在识别不出，就根据MBAP头特征手动解析：协议标识符为0x0000、报文长度小于256、事务标识符递增，这三个特征几乎不会有假。

6.2 RTU流量的帧边界判断与超时问题

RTU抓包常见的问题是字节流连成一串，分不清帧从哪里开始。这在波特率较高、总线流量较密时尤其明显。判断帧边界不能只看CRC，要结合时间戳。方法是用软件把每个字节的到达时间间隔标出来，间隔大于3.5字符时间的点就是帧边界。具体操作可以在Wireshark里给串口数据加“时间显示”列，或者写个小脚本遍历字节间隔。

还有一种情况是总线被其他厂家设备抢占，比如某些仪表每次响应要几百毫秒，导致帧间隔异常大。这种时候不要急着切帧，先统计所有间隔分布，找出明显的分界点，再按分界点切帧。

6.3 时间戳对不上，证据链断在哪里

做过几个案子后我养成了习惯：每次取证先对照一下抓包机时间和目标主机时间。曾经遇到抓包机是UTC时间，上位机是本地时间，差了8小时，导致流量里的写入时间点与现场工艺记录对不上，差点漏掉关键证据。处理方法是统一用UTC做基准，报告里同时标注时区，并且把换算方式写清楚。

另一个问题是虚拟机能耗管理导致时间漂移，上位机时间和真实时间差几分钟，这在长时间取证的场景里非常麻烦。建议有条件的话，在取证机接入前先和NTP服务器对时，并在报告里记录时间偏差值。

6.4 遇到加密或私有化Modbus隧道怎么处理

现在不少厂商在Modbus外层套了加密隧道，比如在TCP层做TLS封装、或者在应用层插入私有加密字段。这种情况下直接抓包只能看到乱码，功能码和寄存器地址都在密文里，无法直接分析。

应对思路有两条。一是尽量在通信两端取证据，比如在PLC侧或者上位机侧安装代理类采集器，在加密前的数据流上做记录。二是检查设备自身日志，部分较新的PLC和网关会记录通信日志和诊断信息，虽然粒度不如抓包细，但能提供操作时间、操作账号等关键线索。

另外多说一句，现在很多人用手机APP远程运维工控系统，APP和云端之间的通道通常有TLS保护，这类场景的重点取证对象是手机端和云端API日志，和传统的抓包取证思路不太一样。如果案件涉及移动端，建议尽早考虑手机取证，别等到流量分析完再回头发现漏了终端证据。

6.5 大流量环境下如何快速提取Modbus会话

产线网络里除了工控协议，还有视频流、办公流量，就算过滤了端口502，也可能有大量设备轮询数据，一抓就是几十GB。这时候不要硬翻，先用统计功能找出“哪些IP对之间通信频率最高”、“哪些功能码出现频次异常”，缩小范围。

实际操作里，我会先用抓包工具导出“会话统计”和“端点统计”，再把含502端口的会话单独导出成小pcap，最后针对小pcap做深度分析。这样处理百GB级别的包文件也能在十几分钟内锁定关键会话。

还有个小技巧，Wireshark支持tshark命令行批量统计，比如一条命令直接统计所有写寄存器请求的来源IP和次数：

tshark -r capture.pcap -Y "modbus.func_code == 0x06 || modbus.func_code == 0x10" -T fields -e ip.src -e ip.dst -e modbus.reg_num -e modbus.reg_val

这条命令输出的每一行就是一个写操作记录，再配合awk、sort统计，几秒钟就能得到完整的写操作清单。这个习惯帮我节省了大量时间，值得一试。

在实际取证这条路上，我个人的体会是：难的不是Modbus协议本身，而是“把字节翻译成业务后果”这一步。同样一个0x10写多寄存器请求，如果不知道寄存器对应的是温度设定值还是电机转速，那它永远只是一串十六进制数字。所以每次开工前，先拿到点位表，先建立正常通信基线，再分析异常，这样整个取证过程会顺畅很多。

最后再分享一个小习惯：做Modbus取证时，永远把抓包机、上位机、PLC的时间先强制对齐，然后在报告里把时间基准写清楚。时间线一旦乱了，其他证据再扎实也很难自圆其说。希望这篇笔记能帮你在Modbus取证这条路上少踩一些坑。