第一次去工控现场做取证是什么感觉？我当时盯着一份满是502端口报文的PCAP，心里既兴奋又发怵。兴奋是因为Modbus协议明文传输，寄存器地址、写入值全部裸奔在流量里，攻击者干了什么几乎一眼就能看到；发怵是因为这些报文背后的设备状态、工艺参数、从站映射我完全陌生，单纯把包“提出来”并不等于拿到了结论。后来我把Modbus协议以及围绕它的流量取证、内存取证、主机痕迹排查完整梳理了一遍，才慢慢摸到门道。这篇笔记就是那段时间的记录，聊聊Modbus协议的结构、报文分析思路、上位机侧的取证手段，以及传统IT取证思路在工控场景里为什么会失灵。
1. 工控取证为什么绕不开Modbus：先理解这个协议的“裸奔”本质
1.1 一个上世纪70年代的老协议，为什么现在还站在取证中心
Modbus是Modicon公司在1979年提出的通信协议，最初就是为了PLC之间、PLC和上位机之间通信而设计的。后来因为实现简单、协议开放，几乎所有工控设备都支持它，PLC、DCS、HMI、变频器、伺服驱动器、智能仪表，基本都能找到Modbus接口，它成了工控圈事实上的“通用语”。
从分层角度看，Modbus属于应用层协议，下面可以跑串口（RTU/ASCII），也可以跑TCP/IP。这也是热搜里经常把“modbus协议分层”单独拿出来讲的原因。经典模型中有一个主站和多个从站，主站通常是上位机或PLC主站，从站是各种现场设备。主站通过功能码和寄存器地址去读写从站的“数据面”，这个数据面分成四类：线圈、离散输入、保持寄存器、输入寄存器。线圈和离散输入是位（bit）数据，保持寄存器和输入寄存器是字（word）数据，区别主要在于读写权限和数据类型。
对取证来说，这个协议有个非常“友好”的特点：明文、无认证、无加密。Modbus出生在工业以太网还没普及的年代，当时考虑的是可靠性和实时性，压根没想过安全。所以报文里的一切都是明文的，只要抓到包，谁在读、谁在写、读了哪个地址、写了什么值，全部摊在桌面上。这也是为什么Modbus取证的上手门槛不高，但真正要做好，上限又非常高——你不仅要懂协议，还得懂现场工艺。
1.2 取证对象不只是PCAP：寄存器、线圈、设备状态才是终点
很多人一听说“Modbus取证”，第一反应就是掏出Wireshark抓包分析。这个思路没错，但如果只停留在“抓到流量”这一步，会丢掉一半证据。工控取证真正要回答的问题通常是：某个寄存器在某个时间被谁写入了什么值，这个值对应现场哪个物理量，是否造成了设备动作，动作后果是什么。
所以PCAP只是证据链的起点。一个完整的Modbus取证项目，数据源至少包括：
- 工业交换机镜像流量、工控防火墙/网关日志
- PLC程序备份和寄存器映射表，也就是地址到物理量的对应关系
- 上位机数据库历史、操作员日志、报警记录
- HMI工程文件、组态软件历史趋势
- 上位机主机内存镜像和磁盘镜像
- 现场设备快照，比如PLC程序、诊断计数器、故障记录
传统数字取证关注的是文件、进程、网络连接，而工控取证还要把报文对应到物理世界。同样是写了一个寄存器值，在IT系统里可能只是数据变化，在工控场景里可能意味着电机转速突变、阀门开度被改、温度设定值被拉高。这是Modbus取证和普通网络取证最大的区别。
1.3 简单协议带来的三个取证难点
Modbus简单，但“简单”不等于“好取”。我在实操里最头疼的是下面三件事。
第一，Modbus没有会话概念。它的请求和响应靠事务标识符一一配对，如果中间经过网关做协议转换，这个对应关系可能被重置。你会在流量里看到一堆孤零零的请求，找不到响应，或者响应乱序，分析起来非常费劲。
第二，寄存器地址必须靠工程文件才能还原成物理量。报文里写的是0x0010，这个地址在某个水处理项目里可能代表“加药泵频率设定”，在另一个项目里可能完全是别的含义。没有寄存器映射表，你只能判断“有人改了地址0x0010”，无法判断“他把加药量改大了”。
第三，PLC和上位机的时钟往往不准。工控设备常年运行，很多根本不启用NTP时间同步，日志时间可能偏移几个小时甚至几天。如果一开始不记录设备时间与标准时间的偏差，后面做时间线对齐会非常痛苦。
2. 取证视角的Modbus报文拆解：TCP与RTU该怎么看
2.1 Modbus TCP的MBAP头：事务标识符、长度字段和单元标识符
Modbus TCP的报文结构是MBAP头加PDU。MBAP头一共7个字节，PDU由功能码加数据组成。具体字段见下表。
| 字段 | 长度 | 取证价值 |
|---|---|---|
| 事务标识符 Transaction ID | 2字节 | 请求与响应配对的关键，大量“孤儿请求”说明可能有人伪造响应或中间设备做了缓存 |
| 协议标识符 Protocol ID | 2字节 | 正常必须为0，如果出现非0值，优先怀疑畸形报文探测 |
| 长度 Length | 2字节 | 等于单元标识符长度加PDU长度，如果与实际载荷不符，可能是畸形包或主动探测 |
| 单元标识符 Unit ID | 1字节 | 相当于从站地址，很多系统默认是1，扫描器会遍历1到247，特征非常明显 |
| 功能码 Function Code | 1字节 | 本次操作的具体动作，读写还是诊断 |
| 数据 Data | N字节 | 寄存器地址、数量、写入值等核心内容 |
实际报文长这样：
0x0001 0x0000 0x0006 0x01 0x03 0x0000 0x000A TransID ProtoID Length Unit FC StartAddr Quantity这个报文的含义是：事务ID为1，访问单元标识符为1的从站，读取起始地址0x0000开始的10个保持寄存器。这里有个容易踩坑的细节，协议里的寄存器地址是“零基地址”，也就是从0开始算，而很多HMI和组态软件里显示的是“PLC地址”，比如保持寄存器40001。对应关系是：协议地址0x0000等于PLC地址40001。做地址映射的时候，这个“1的偏移”必须反复核对。
为什么长度字段值得关注？因为很多基于Modbus的漏洞利用或协议探测工具会故意构造长度不匹配的包。正常上位机组态软件发出来的报文格式非常规整，长度字段几乎不会出错。一旦看到长度不对、协议标识符非0、事务标识符重复使用等情况，就要提高警惕。
2.2 Modbus RTU：没有IP的串口总线，CRC是重要抓手
Modbus RTU跑在RS-232、RS-485这类串口总线上，报文结构比TCP更加紧凑：一个字节从站地址、一个字节功能码、N字节数据、两个字节CRC16校验。CRC采用Modbus CRC-16算法，多项式0x8005，初始值0xFFFF，低字节在前。
RTU报文示例：
01 06 20 00 00 64 [CRC_LOW] [CRC_HIGH]含义是：从站地址01，功能码06写单个保持寄存器，寄存器地址0x2000，写入数据0x0064。这串字节里的CRC校验位必须正确，从站才会响应。
串口总线没有IP地址，取证时无法像TCP一样直接看到“源IP”。但有几个抓手：
- 从站地址可以区分设备，比如地址01是1号伺服驱动器，地址02是2号变频器。
- CRC校验可以判断报文是否完整，也能用来推断攻击者是否使用了现成的Modbus调试工具。如果大量报文的CRC分布高度规整，说明攻击者很可能不是手写字节，而是用了某个工具库。
- RTU靠3.5个字符时间的静默间隔来分帧，如果总线上出现异常的时间间隔，可能存在数据插入或误码。
现场抓RTU流量比TCP麻烦得多。RS-485总线没有交换机镜像口，要监听就得用串口监听器、RS-485转USB的旁路设备，或者直接看工业网关/串口服务器的日志。我在第五章会详细展开。
2.3 功能码不是只有读写：用“行为映射”快速定位攻击意图
Modbus的核心功能码其实不多，但每一个都对应一种操作能力。下面是我整理的功能码行为映射表，取证时基本可以对照着看。
| 功能码 | 名称 | 取证意义 |
|---|---|---|
| 0x01 | 读线圈 | 读取开关状态，扫描阶段常用 |
| 0x02 | 读离散输入 | 读取外部输入状态，侦查行为常用 |
| 0x03 | 读保持寄存器 | 读取运行参数，最常用的正常读操作 |
| 0x04 | 读输入寄存器 | 读取模拟量输入，扫描阶段常用 |
| 0x05 | 写单个线圈 | 控制单个开关，可能用于启停设备 |
| 0x06 | 写单个寄存器 | 修改单个参数，最常见的篡改行为 |
| 0x0F | 写多个线圈 | 批量控制开关，可能用于区域断电或批量启停 |
| 0x10 | 写多个寄存器 | 批量修改参数，可能用于一次写入全部设定值 |
| 0x07 | 读异常状态 | 读取从站异常状态字，侦查行为 |
| 0x08 | 诊断 | 子功能0x00回送查询，常被用来探测设备在线情况 |
| 0x2B | 封装接口传输 | 常用于读设备标识，可以获取厂商和产品型号 |
攻击行为一般会呈现出三个阶段。侦察阶段多用0x03、0x04读操作，扫描大量地址；识别阶段用0x08、0x2B获取设备型号和诊断信息；控制阶段才出现0x05、0x06、0x0F、0x10这类写操作。在分析的时候，不要看到写功能码就认定是攻击，先建立正常基线。正常上位机写参数往往集中在少数几个寄存器、周期固定、值范围有限；异常写入则常常表现为突发、跨地址、非工作时间、数值超出物理范围。
3. 流量取证实操：从PCAP里还原一次Modbus攻击过程
3.1 抓包位置选不对，分析再细也白搭
Modbus TCP默认跑在502端口，抓包位置直接决定证据完整性。最理想的位置是上位机与PLC之间的链路上，通过核心交换机的镜像端口或专用TAP抓包。如果现场有工控防火墙，也尽量在防火墙的镜像口或旁路口抓，这样既能看见原始请求，也能对照防火墙日志里是否有拦截记录。
一个容易被忽略的问题是抓包机的时间同步。很多工控现场为了稳定运行，不允许随便接NTP，那你至少要在开始抓包前记录抓包机与上位机、PLC之间的时间差。方法很简单，同时看三台设备的时钟，记下偏差。后面分析时会发现，这几分钟的偏差足以让整个时间线乱掉。
抓包时长也有讲究。如果是事后取证，尽量从事故发生前48小时开始回溯，抓包窗口开到足够大。如果是做安全建设，平时就定期抓一份正常工况的基线流量存档，关键时刻拿出来对比，效果立竿见影。
3.2 用Wireshark和tshark快速导出会话与功能码统计
Wireshark自带Modbus解析器，显示过滤器非常方便。常用的几条：
modbus tcp.port == 502 modbus.func_code == 0x06 modbus && modbus.func_code >= 0x05第二条只看写操作，第三条会把所有写单寄存器报文筛出来。如果条件允许，我更推荐用tshark做批量提取，尤其是PCAP文件很大的时候。下面这行命令可以把报文的字段全部导成CSV：
tshark -r capture.pcap -Y "modbus" -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e tcp.srcport \ -e tcp.dstport \ -e modbus.func_code \ -e modbus.regnum \ -e modbus.value \ -E header=y -E separator=,这里提醒一句，不同Wireshark版本里Modbus字段名可能略有差异，比如写入值字段有的版本叫modbus.value，有的叫modbus.value_16。最稳妥的办法是Wireshark里打开一条报文，右键目标字段，选择Copy Field Name，以那个为准。
导出CSV后，用Excel透视表统计功能码分布，几秒钟就能看出整体轮廓。正常系统里0x03占比通常极高，因为上位机一直在周期轮询；如果0x06、0x10突然变多，或者出现了大量0x08、0x2B，那就有问题了。
3.3 一个完整的攻击链拆解：扫描、写入、恢复
举一个我在笔记里反复用来练手的例子。某个水处理厂，正常上位机以5秒周期读保持寄存器0x0000到0x000F，偶尔对0x0100地址写PID参数。某天凌晨流量出现了明显的三阶段模式。
| 阶段 | 时间 | 行为 | 特征 |
|---|---|---|---|
| 扫描 | 01:33:01 | 一个新IP发大量0x03读请求 | 寄存器地址从0x0000一路遍历到0x0100，速度远超正常轮询 |
| 写入 | 01:34:22 | 同IP发送0x06写请求 | 寄存器地址0x0010，写入值0xFFFF |
| 伪装 | 01:34:23起 | 恢复读请求 | 频率和正常轮询接近，试图融入基线流量 |
用tshark把所有写操作提取出来：
tshark -r water.pcap -Y "modbus.func_code == 0x06" -T fields \ -e frame.time -e ip.src -e modbus.regnum -e modbus.value发现整个PCAP里只有两次写操作，一次在01:34:22，一次在02:12:47。对照寄存器映射表，地址0x0010对应“2号沉淀池加药泵频率设定”，正常设定值在0x0020到0x0060之间，0xFFFF直接超出了物理量程。而且0xFFFF如果被解析为有符号数就是-1，对变频器来说可能意味着反向最大频率或者错误状态，无论哪种解释都指向恶意操作。这个判断不是靠单个报文得出来的，而是靠“扫描特征加异常写入值加非工作时间”三件事叠加。
3.4 从报文列表到案件叙事：时间线重建技巧
把报文变成时间线，是流量取证里最体现功力的环节。我的做法分几步走。
先把tshark导出的CSV按时间升序排列。然后标记五个锚点：第一个来自陌生IP的TCP SYN包、第一次异常功能码、第一次写操作、最后一次交互、连接断开时间。接着把主机侧的日志拿过来，以5分钟为窗口对齐。比如PCAP里01:34:22写入，而Windows安全日志里01:34:20恰好有一条powershell.exe进程创建记录，这个时间窗口就非常可疑。
做时间线时要注意一个细节，写寄存器指令发出后，PLC要等下一个扫描周期才会真正执行，现场设备动作还要再延迟几十到几百毫秒。所以当天的报警记录比PCAP里的写操作晚几秒，完全正常，别因为时间不完全一致就否认关联。
提示：做时间线时永远先统一时区。抓包机显示UTC时间，上位机显示北京时间，日志里再混进一个本地时间，三个时间不做偏移直接对比，必然乱套。
4. 别只看网线：HMI与上位机里的内存、进程和Windows痕迹
4.1 内存取证的价值：攻击者可能就坐在“发包进程”后面
流量取证只能告诉你“某个IP在某个时间发了写寄存器报文”，但它没法直接告诉你：这个报文是哪个软件发的？是操作员正常操作，还是恶意脚本，还是被人远程控制的上位机在自动发包？
很多攻击根本不会留下传统意义上的恶意文件。攻击者拿到一台HMI后，可能会直接用系统里已经装好的Modbus调试工具去写寄存器，也可能写一段PowerShell脚本调用第三方库发包，脚本运行完就删掉。这时候你在磁盘上找不到病毒，但内存里会留下线索：进程命令行、网络连接、加载的DLL、打开的工程文件路径、甚至明文密码。
所以工控取证不能只盯着PCAP。对HMI和上位机做内存取证，往往才是把“流量里的IP”变成“坐在屏幕前的嫌疑人”的关键一步。取证时要注意，工控主机通常配置老旧，很多还在跑Windows 7甚至XP，尽量用FTK Imager这类工具在线固定内存，不要直接拔电，避免丢失内存中的证据，也避免生产中断。
4.2 Volatility实操：从镜像里挖出网络连接、进程和注入痕迹
内存取证的主流工具还是Volatility。第二版需要先判断profile，第三版用起来更顺手。下面几条命令是我每次必跑的：
vol -f memory.raw windows.info vol -f memory.raw windows.netscan vol -f memory.raw windows.pslist vol -f memory.raw windows.cmdline vol -f memory.raw windows.malfind vol -f memory.raw windows.filescanwindows.info用于确认镜像的操作系统版本和系统时间；netscan会列出网络连接，重点关注连接到远端502端口的established连接，记录PID和创建时间；pslist查这个PID对应的进程名；cmdline看完整启动参数。如果看到powershell.exe后面跟着一长串-base64或-enc参数，那基本可以直接判定为可疑。
现在很多团队喜欢用可视化内存取证GUI，就是热搜词里那种封装好的前端。我的建议是，可以先靠GUI快速出报告，但遇到关键结论一定要回到命令行手工验证。因为工控机上老系统很多，profile匹配一旦出错，GUI可能给出一个看似合理但完全错误的解析结果，命令行至少能让你看到原始数据结构。
4.3 Windows主机痕迹排查：事件日志、Prefetch与组态工具
内存取证跑完，接下来就是Windows主机的痕迹排查，也就是安全事件处置里最常见的主机安全取证。下面是我常用的检查清单。
| 痕迹来源 | 位置/事件ID | 取证价值 |
|---|---|---|
| 登录日志 | 安全日志4624、4648 | 谁在什么时间登录过系统，是否使用显式凭据 |
| 进程创建 | 安全日志4688 | 哪个进程被启动，命令行参数是什么 |
| 服务创建 | System日志7045 | 是否安装了新的可疑服务 |
| PowerShell日志 | 事件日志4104 | 记录PowerShell脚本块内容 |
| 预读取文件 | C:\Windows\Prefetch*.pf | 程序运行痕迹，能看出工具执行时间 |
| 兼容性缓存 | Amcache.hve、Shimcache | 程序执行过的历史记录 |
| 用户近期文件 | %UserProfile%\Recent | 最近打开过什么文档或工程文件 |
| 持久化位置 | Run键、启动文件夹、计划任务 | 攻击者是否设置了开机自启动 |
对Modbus场景来说，特别要关注一类痕迹：Modbus调试工具的运行记录。Modbus Poll、ModScan、QModMaster这类工具很多是绿色免安装的，不会出现在“安装程序列表”里，但会留下Prefetch文件、Recent目录记录和文件系统残留。只要在上位机上找到这些工具的运行痕迹，再结合流量分析里的IP和功能码分布，基本就能锁定攻击者使用的手段。
4.4 把PCAP、netscan和进程列表串成一条线
这步是重点，也是我一开始最常翻车的地方。
假设抓包机用的是UTC时间，上位机系统时间是UTC+8，内存镜像里的SystemTime显示的是本机时间。如果不对齐，PCAP里的01:34:22和内存里的09:34:22，看上去差了8小时，你可能会误判为两个独立事件。
对齐方法不复杂。先用windows.info确认镜像的SystemTime，然后计算镜像时间与UTC的偏移量，再把PCAP时间统一换算到同一时区。对齐之后，重点看netscan结果里的时间和PCAP时间的对应关系。比如内存里PID 3888的进程从01:33:00开始不断连接PLC的502端口，而PCAP里恰好01:33:01出现了来自该源IP的扫描报文，这个进程就可以精确定位到攻击入口。接下来再用pslist和cmdline确认这个PID是哪个程序，用4688日志看它什么时候被启动，最后用Prefetch判断它是不是第一次运行。整个链条就闭环了。
5. 串口侧的现场实录：伺服电机控制里的Modbus RTU取证
5.1 伺服控制场景的RTU报文长什么样
伺服驱动器通过RS-485串口接入PLC或网关，PLC用Modbus RTU轮询和写入，这是非常常见的控制方式。控制的参数多数是保持寄存器：速度设定、位置设定、加减速时间、使能状态等。典型报文如下：
01 06 20 00 00 64 [CRC_LOW] [CRC_HIGH]拆开看：地址01是1号伺服驱动器；功能码06是写单个保持寄存器；寄存器地址0x2000；数据0x0064。假设工程文档里把0x2000定义为“1号伺服速度设定值”，单位是0.1转每分，那0x0064等于100，对应10转每分。正常工况下，这个值会跟随工艺要求在合理范围内变动。
一旦出现异常写入，比如数据被改成0x7FFF或0xFFFF，设备可能立刻发生转速突变甚至飞车。这类生产事故往往伴随设备报警和急停，但报警记录通常只记录“设备故障”，不会记录“谁写了什么地址”。这时候唯一能还原真相的，就是总线侧数据。
5.2 没有交换机镜像的总线，怎样找到“谁写了速度设定值”
RS-485总线没有交换机镜像口，取证思路和以太网完全不同。我按优先级排一下可行方案。
首选是Modbus网关或串口服务器的日志。如果PLC侧通过网关把RTU转成TCP，网关通常会记录源IP、目标从站地址、功能码和数据。检查网关管理界面和syslog，往往能直接找到关键报文。我曾处理过一个包装线伺服速度被篡改的案例，最终就是通过网关日志看到UnitID=2、功能码0x06、寄存器地址0x2001、值0x7FFF，日志时间比设备报警早了3秒。再调出网关后台的记录，发现源IP指向一台操作员站，顺着这条线进入Windows取证。
次选是PLC诊断缓冲区。很多PLC会保存最近一段时间的通信错误记录，如果异常写入导致从站响应异常，PLC的通信诊断可能留下痕迹。虽然这类日志通常很短，但作为旁证非常有用。
再次是现场旁路监听。用RS-485转USB监听设备并线抓包，不中断生产。但要注意总线负载、终端电阻和电气隔离，接错可能导致通信故障，风险不小。如果条件允许，优先选高阻抗的监听方案，模拟成总线上的接收者，不参与发送。
最后是上位机侧排查。即使RTU报文里没有IP，发起写操作的进程在主机内存里一定留有网络连接记录，就算连接目标是网关而非PLC，也能锁定操作来源。
5.3 串口取证的边界：只好认到从站地址，不认IP
串口取证的局限也很明显，必须提前说清楚。RTU报文里能确定的只有“从站地址被写入”，没有源地址概念，因此无法直接从报文判断主站侧是谁在操作。要补全链条，必须靠网关日志、PLC诊断日志或上位机进程记录。
另一个痛点是没有时间戳。RTU帧本身不带时间，时间只能来自监听设备或网关日志。如果现场没有网关，也没提前做旁路监听，事后想从裸字节流反推精确时间几乎不可能。所以对于纯串口直连的场景，我的建议是优先做PLC诊断和上位机进程排查，不要寄希望于事后能抓到总线流量。
CRC在这里反而是一个有用的分析点。Modbus RTU的CRC计算有固定算法，攻击者如果手搓报文，几乎必然用现成工具库，生成的CRC分布会有工具特征。通过比较CRC计算逻辑和报文生成规律，可以反向推断攻击者用了哪一类调试工具，这对缩小嫌疑人范围很有帮助。
6. 我的Modbus取证工具链和踩坑清单
6.1 现场取证工具箱
整理一份工具清单，都是我实际用过的。不一定都是重型工具，但关键时刻都救过场。
| 工具 | 用途 | 备注 |
|---|---|---|
| Wireshark / tshark | 流量解析、批量导出 | 最核心的流量分析工具 |
| Scapy / pyshark | 脚本化处理大批量PCAP | 适合做自定义统计和关联 |
| Volatility 3 / 2 | 内存镜像分析 | 老系统记得配合profile |
| MemProcFS | 在线内存分析 | 适合Win10以上环境，读内存像读文件 |
| FTK Imager | 内存与磁盘固定 | 在线固定内存首选 |
| KAPE | Windows痕迹快速收集 | 一小时能收集完关键证据 |
| 各类PLC工程软件 | 读取寄存器映射、上传程序 | 需要厂商授权，提前准备 |
| Modbus Poll / ModScan | 复现验证、模拟主站 | 取证时用于验证报文是否会导致设备动作 |
| HxD / 010 Editor | 十六进制查看 | 分析原始帧和文件头 |
| 串口监听工具 / 工业网关管理后台 | RTU现场取证 | 主要走网关日志路线 |
6.2 最容易翻车的五个细节
第一是时钟偏移。抓包机、上位机、PLC，三套时钟很可能都不一样。取证第一步先把时间偏差记录下来，统一换算到UTC，再做任何比对。
第二是抓包点错误。曾经有一回我在核心交换机镜像口抓了一整天，回来一分析，发现相关设备全是串口接入的，流量根本不上核心交换机，等于白抓。去现场之前，先梳理清楚通信拓扑：哪些设备走以太网，哪些走串口，网关在哪里。
第三是Wireshark字段名的版本差异。modbus.value在部分版本里叫modbus.value_16，modbus.regnum也可能变成modbus.regnum_16。别死记字段名，用鼠标右键复制最保险。
第四是寄存器地址“1偏移”陷阱。HMI显示40001，协议报文里是0x0000。做地址映射时一定要反复核对，否则你会把“写入了40002”误判成“写入了40001”，差了整整一个点。
第五是现场操作规范。取证过程中尽量别直接改动设备运行状态。能备份就备份，能拉镜像就拉镜像，能把PLC程序上传出来就上传出来。一旦动了设备状态，原始证据可能被破坏，后面出具的结论就会被人质疑合法性。
6.3 一个可以带走的小建议：先建正常基线
整理这篇笔记的过程中，我最大的体会是“基线先行”。没有正常流量基线，任何写操作都显得可疑；有了基线，你才能快速判断某次写入是工艺需要的例行操作，还是真正的异常。建议每个维护团队都定期做两件事：导出PLC寄存器映射表并存档，抓一份正常工况的流量样本作为基线保存。这两样东西平时看起来不起眼，真到取证那天，它们比任何高级工具都值钱。
后来我自己练习时，通常用一台Windows虚拟机装Modbus Poll，再配合虚拟串口软件连接一个模拟从站，自己造几帧扫描和异常写入的流量，一遍遍对比Wireshark和Volatility的输出。纸上得来终觉浅，你自己亲手把异常报文造出来，再回头去看那些协议细节，很多疑问就自动解开了。
