目录

本文首发先知社区：https://xz.aliyun.com/t/6603

0x01 S7COMM协议

S7COMM 全称S7 Communication，是西门子专有协议，在西门子S7-300 / 400系列的PLC之间运行，用于PLC编程，PLC之间的数据交换。S7协议被封装在TPKT和ISO-COTP协议中，这里就不对 TPKT 和 ISO-COTP 进行介绍了，仅仅说一些关于 S7Comm 协议部分。
S7Comm协议包含三部分：

• Header
• Parameter
• Data
  Header 的内容包含8 个字段，如下图所示：

0 – 1 字节：

Protocol Id；即协议ID，通常为0x32；

1 – 2 字节：

ROSCTR：PDU type；即PDU的类型，一般有以下值：

• 0x01：JOB
  即作业请求，如，读/写存储器，读/写块，启动/停止设备，设置通信
• 0x02：ACK
  即确认相应，这是一个没有数据的简单确认
• 0x03：ACK_DATA
  即确认数据相应，一般是响应JOB的请求
• 0x07：USERDATA
  即扩展协议，其参数字段包含请求/响应ID，一般用于编程/调试、读取SZL等

2 – 4 字节：

Redundancy Identification (Reserved)，即冗余数据，通常为0x0000；

4 - 6 字节：

Protocol Data Unit Reference，即协议数据单元参考，它通过请求事件增加；

6 – 8 字节：

Parameter length，即参数的总长度

8 – 10 字节：

Data length，即数据长度，如果读取PLC内部数据，此处为0x0000；而对于其他功能，则为Data部分的数据长度；

10 – 12 字节：

Error class，即错误类型，其错误代码对应意思如下表：

12 - 14 字节：

Error code，即错误码，其具体意思参考附录一：错误码具体含义

以上为 header 的全部内容，而 S7comm 协议的Parameter 部分与Data 部分，则是根据header 中PDU type的功能码的不同、协议扩展（Userdata）的内容不同而变得不同。这里仅对 PDU type 的不同功能码进行简单介绍，更为复杂的协议扩展内容，暂不做解释。

当PDU类型是JOB和ACK_DATA时，常见的功能码，如下表：

以下内容会对这些功能码的结构进行简单介绍。

Setup communication（0xf0）

Setup communication会在每个会话开始时被发送，然后才可以交换任何其他消息，主要用于协商ACK队列的大小和最大PDU长度，双方声明它们的支持值（和计算机网络中的最大传送长度声明类似），ACK队列的长度决定了可以同时启动而不需要确认的并行作业的数量。PDU和队列长度字段都是大端。

Setup communication Parameter的结构如下：

0 – 1 字节：

Function: Setup communication (0xf0)，即Parameter/data 的函数声明

1 – 2 字节：

Reserved: 0x00，保留字节，一般为 0x00

2 – 4 字节：

Max AmQ (parallel jobs with ack) calling

4 – 6 字节：

Max AmQ (parallel jobs with ack) called

6 – 8 字节：

PDU length，即协商PDU长度

如下图所示的是PDU 类型为 Job 和 Ack_Data的实例

上图中的协商结果为：ACK队列的大小为1；最大PDU长度为240。

Read Var（0x04）

读数据操作，通过指定变量的存储区域，地址（偏移量）及其大小或类型来执行。
Read Var 的Parameter的结构以及item的结构如下：

0 – 1 字节：

Function: Read Var (0x04)，即Parameter/data 的函数声明

1 - 2 字节：

Item count，即 Item 的个数

2 – 14 字节：

Item [1]，即第一个 Item

14+12n – 14+12(n+1)字节：

Item[n]，即第 N 个 Item

一个item的结构如下：

0 – 1字节：

Variable specification，即结构标识，通常为 0x12 ，代表变量规范

1 – 2 字节：

Length of following address specification，即地址规范长度，主要是以此往后的地址长度

2 – 3 字节：

Syntax Id，全称Syntax Ids of variable specification，即IDS 的地址规范的格式类型，用于确定寻址模式和其余项目结构的格式。常见的变量的结构标识如下表所示：

3 – 4 字节：

Transport size，即数据传输大小，常见值如下表：

4 – 6 字节：

Length，即数据的长度

6 – 8 字节：

DB number，即 DB 编号，如果访问的不是DB区域，此处为0x0000，如下图所示：

8 – 9 字节：

Area，即区域，常见的区域如下表所示：

9 – 12 字节：

Address，即地址。

举个简单的例子可以说明下 Item 数据包的核心内容：

如上图所示，这是一个 PDU 类型为 Job，功能码为 Read Var的数据包，其主要内容为 Item[1]读取DB1类型为 BYTE 的0x00000000地址的值。

需要注意的是，PDU 类型为 Ack_Data，功能码为 Read Var的数据包，其Parameter结构和PDU 类型为 Job，功能码为 Read Var的Parameter结构是不一样的。如下图所示：

可以看到，其Parameter只有function和item count两个字段，但其多了一部分内容，即 data，在 PDU 为 Job 的数据包中，是没有这个内容的。Data 的结构如下图所示：

0 – 1 字节：

Return code，即返回码，响应报文中Data部分的常见返回码如下表：

1 - 2 字节：

Transport size，即数据传输大小，常见的 data 中数据传输大小的值如下表：

2 – 4 字节：

 Length:，即数据的长度

4 – 4+length(未定义) 字节：

Data，即数据。

4+length(未定义) – 5 字节：

Fill byte，即填充字节，如果数据的长度不满足 2-4 字节中的Length的话，填充0x00

Write Var（0x05）

写数据操作，通过指定变量的存储区域，地址（偏移量）及其大小或类型来执行。Write Var中Parameter的结构和 Read Var 中的 parameter 的结构一致，但是由于是写数据，因此和读数据相比，多了写的data结构：

Write Var的结构如下：

如上图所示，这就是一个向地址为0x000000的Flags（M）写入0x77100002的作业请求。
与此对应，其Ack_Data 功能码结构也很类似：

与 Read Var 的结构相比，Write Var 在Data中只有一个Return code字段。
上图中的Item1，表示向地址为0x000000的Flags（M）写入0x77100002成功！

Request download（0x1a）

Request download，即请求下载功能码，说这个之前不得不说一下整个下载的流程。因为这个内容与 Download block、Download ended 内容其实是连贯的，三个功能码构成了一个完整的下载流程。
其流程如下：

说了上面的流程后，就可以来正式开始谈request download，Request download的Parameter的结构如下：

0 – 1 字节：

Function: Request download (0x1a)，即Parameter/data 的函数声明

1 – 2 字节：

Function Status，即功能状态，包含错误是否发生、是否使用另一个检索块/文件来请求的更多数据

2 – 4 字节：

Unknown byte(s) in blockcontrol，无意义

4 – 8 字节：

Unknown byte(s) in blockcontrol，无意义，一般为0x00000000

8 – 9 字节：

Filename Length，即文件名长度

9 – 18 字节：

Filename，文件名，其结构如下：

0 – 1 字节：

File identifier，即文件标识符，有_ (Complete Module)、$ (Module header for up-loading)两种文件标识符；

1 – 3 字节：

Block type，即块类型，在西门子设备中有8种不同类型的功能块，如下表：

3 – 8 字节：

Block number，即请求的块编号

8 – 9 字节：

Destination filesystem，即请求目标的文件系统，有三种：

• P（Passive (copied, but not chained) module)：被动文件系统
• A (Active embedded module)：主动文件系统
• B (Active as well as passive module)：既主既被文件系统

18 – 19 字节：

Length part ，即参数的第二部分长度，也就是接下来的字段长度；

19 – 20 字节：

Unknown char before load mem，即加载mem之前的未知字符

20 – 26 字节：

Length of load memory，即装载长度

26 – 32 字节：

Length of MC7 code，即 MC7 代码长度

以上即为 request download的结构，其实也就是要告诉 PLC，我要下载块了，如下实例：

上图中，请求的文件标识是_ (Complete Module)，请求块类型为DB，块的编号为00001，目标块的文件系统是P (Passive (copied, but not chained) module)，所以文件名为_0A00001P，用于将DB1复制到被动文件系统或从被动文件系统复制。

与读写文件类似，这里PDU类型是Job ，而PDU类型是 Ack_Data时，Request download 的结构如下：

可以看到，其 Parameter 内容仅有一个function 确认，因此在 request download 的job和 ack_data 完成后，就可以进行download block了。

Download block（0x1b）

Download block的Parameter的结构如下：

可以看到，Download block的Parameter内容是和request download的内容重合的，只不过与后者相比，少了18 – 32 字节的内容（Length part、Unknown char before load mem、Length of load memory、Length of MC7 code），上图的内容也就是下载块 _0A00001P 的作业请求。

PDU类型为Ack_Data时，其Parameter的结构如下图所示：

Parameter 内容仅有function确认和function 状态，但是多出了 Data 结构，内容主要为数据长度、未知字节以及数据内容，数据内容的长度。

需要注意的是，一个完整的下载块，可能会通过几次请求，如下所示：

Download ended（0x1c）

Download ended的Parameter的结构如下：

从上图中可以看到Download ended跟Download block的Parameter和Request download的Parameter的第一部分相同，仅是少了18 – 32 字节的内容（Length part、Unknown char before load mem、Length of load memory、Length of MC7 code），这里的意思也就是结束下载0A00001P的作业请求。

当PDU类型为Ack_Data时，Download ended的Parameter结构如下：

只有一个function确认，返回后即确定结束下载_0A00001P的响应，整个下载过程也就完成了。

Start upload（0x1d）

Start upload，即开始上传功能码，和请求下载功能码类似，说这个之前也不得不说一下整个上传的流程。因为这个内容与 Upload、End upload 内容其实是连贯的，三个功能码构成了一个完整的上传流程。

其流程如下：

说了上面的流程后，就可以来正式开始谈Start upload，Start upload的Parameter的结构如下：

可以看到，Start upload 的结构和Request Download 的前部分结构一致，如上图所示的内容，其实就是告诉 PLC 一个文件名，文件标识是 _ (Complete Module)，块类型为0B（SDB），块的编号为00000，目标块的文件系统是A (Active embedded module)，所以文件名为_0B00000A

PDU类型为Ack_Data时，其结构如下图：

0 – 1 字节：

Function: Start upload (0x1d)，即Parameter/data 的函数声明

1 – 2 字节：

Function Status，即功能状态，包含错误是否发生、是否使用另一个检索块/文件来请求

2 – 4 字节：

Unknown byte(s) in blockcontrol，即blockcontrol中的所有未知字节

4 – 8 字节：

UploadID，即上传文件会话的 ID

8 – 9 字节：

Blocklengthstring Length，即块长字符串后的字节长度

9 – 16 字节：

Blocklength，完整上传块的长度（以字节为单位），可以拆分为多个PDU

Upload（0x1e）

当PDU类型为Job时，Upload 结构中没有Data，其Parameter的结构，如下：Upload的Parameter的结构如下：

0 - 1 字节：

Function: Upload (0x1e)，功能码状态；

1 – 2 字节:

Function Status，即功能状态，包含错误是否发生、是否使用另一个检索块/文件来请求

2 – 4 字节:

Unknown byte(s) in blockcontrol，blockcontrol中的所有未知字节

4 – 8 字节：

UploadID，即上传的会话ID，主要是告诉Step7上传会话ID；

这是 JOB 型的结构，当PDU类型为Ack_Data时，Upload有Data，其Parameter的结构，如下：

在parameter 中仅有 function确认以及 function status，多出的 data 中字节长度主要看 data 的长度，这个结构和 download block 是一致的。

End upload（0x1f）

上传结束的会话过程，当所有上传块上传结束后，Step7对 PLC发送结束上传的作业请求，PLC收到后就关闭会话，然后返回一个Ack_Data响应。

End upload的Parameter的结构如下：

结构比较简单，没有什么特殊地方，共有8 字节内容，UploadID 最大，有4 个字节。

当PDU类型为Ack_Data时，其结构如下：

仅有一个功能确认的结构。到这里，一个上传的过程就结束了。

PI-Service（0x28）

PI-Service 即程序调用服务 ，它用于PLC修改执行/内存状态的日常工作。这些命令可以用于启动或停止PLC控制程序、激活或删除程序块。

PI-Service的Parameter的结构如下：

0 – 1 字节：

Function: PI-Service (0x28)，即功能码状态

1 – 8 字节：

Unknown bytes，即未知字节

8 – 10 字节：

Parameter block length，即参数块长度

10 -12 字节：

Parameter block，即参数块

12 -13 字节：

String length，即PI service的字符串长度

13 -22 字节：

PI (program invocation) Service，程序调用服务名，具体见附录二

需要注意的是，如果服务调用的参数是块的话，Parameter block的结构是不同的，如下图所示：

上图中主要含义如下：

服务名称：_INSE
参数：0800001P [OB 1]
请求内容：激活OB 1

请求的结果如下图所示：

function确认，请求成功

PLC Stop（0x29）

PLC STOP其实和PI -Service 是一致的，PLC Stop的Parameter的结构如下：

唯一和 PI-Service有区分的地方可能就是 PLC Stop 中不存在Parameter block结构，其他结构，包括 PDU类型为Ack_Data时也是一样，如下图所示：

小结

上面介绍的S7Comm中PDU类型为JOB和ACK_DATA的相关知识，还有最复杂的UserData的内容就不再介绍了（因为真的太多，太复杂，有兴趣可以自己查询相关资料，这里仅作JOB 和 ACK_DATA 的入门内容介绍），它的用处很广，比如TIME functions、NC programming、CPU functions、Cyclic data、Security等。

0x02 MODBUS 协议

Modbus是Modicon公司推出的协议，ModbusRTU和Modbus ASCII诞生于此。后来施耐德电气（SchneiderElectric）收购了Modicon公司，并在1997年推出了ModbusTCP协议。

2004年，中国国家标准委员会正式把Modbus作为了国家标准，开启了Modbus为中国工业通信做贡献的时代。

MODBUS是一种应用层消息传递协议，位于OSI模型的第7级，提供在不同类型的总线或网络上连接的设备之间的客户端/服务器通信。自1979年以来，作为业界系列上的标准，MODBUS继续使数百万自动化设备能够进行通信。

MODBUS是一种请求/回复协议，提供功能代码指定的服务。 MODBUS功能代码是MODBUS请求/回复PDU的元素。 本文不对 modbus 协议的传输方式、错误检测方法、物理层方面等进行描述，仅对MODBUS内使用的功能代码进行简单介绍。

MODBUS功能码主要分为有效功能码、异常功能码和错误功能码。有效功能码有二十几种，但是一般使用上都以1、2、3、4、5、6、15、16等八种最为常用，以及另外特殊使用的20、21两种，此为General Reference Register，绝大部份的Modbus设备并不会提供此Register。

MODBUS 本来想说很多的，但是发现官方有这方面的文档，因此就不在细说了

文档下载地址：见最下方链接
英文版：

中文版

这个里面详细说明了 modbus 的功能码，相关工作原理等，有兴趣的可以下载下来研究一下。

0x03 实例分析

实例一：S7comm 协议分析

题目说明

分析 S7 流量中的异常，在异常数据包中找到 flag

题解

打开文件如下图：

由于题目已经说明是 S7 协议，因此可以排除掉非 S7 协议的内容：

由于包很多，不能确定使用了哪些PDU 类型，将该分组导出：

用以下脚本来判断使用的 PDU 类型和次数：

#!/usr/bin/env python
#encoding=utf-8

import pyshark

captures = pyshark.FileCapture("cotp.pcapng")
pdu_types = {}
for c in captures:
    for pkt in c:
        if pkt.layer_name == "cotp":
            if hasattr(pkt, "type"):
                type = pkt.type
                if type in pdu_types:
                    pdu_types[type] += 1
                else:
                    pdu_types[type] = 1
print(pdu_types)

确定使用了三种 PDU 类型功能码，分别为 0x0f（3696 次），0x0e（12 次），0x0d（8次）

上文中没有对 cotp 进行介绍，但其实也仅仅是功能和传输格式上的区别，这三种功能码说明如下：

PDU Type: DT Data (0x0f)：

主要用于数据传输，Parameter中含有 data 结构

PDU Type: CR Connect Request (0x0e)

主要用于发起连接请求

PDU Type: CC Connect Confirm (0x0d)

主要用于连接确认

从三种 PDU 协议功能码的出现频率来看，0x0d 和0x0e出现 flag 的概率最大，因此来分析这两种功能码：

注意到：

每一次发起请求连接对应着一次请求确认，在前三个协议包中，连续三次发起了请求，可能存在问题，查看发现：

在第三个包中，发现有意义的内容：NESSUS

又看了其他数据包的内容，并未发现有意义内容，因此该字符串即为 flag

实例二：modbus 协议分析

题目说明

没有给什么提示，就是单纯的协议分析题

题解

打开文件发现：

非正常的协议包，对比正常协议包发现是文件头尾被篡改，因此使用010 Editor编辑修改文件头和文件尾：

正常 pcap 包

下载文件的 pcap 包：

删除文件的头三个尾三个字节，修改后打开：

因为协议很多，其他协议内容不是本文的重点，这里只对 modbus 协议进行分析（实际上 flag 也就在 modbus里面），使用筛选器筛选出 modbus 协议，然后分组导出，使用以下脚本确定存在的功能码：

#!/usr/bin/env python
#encoding=utf-8

import pyshark

captures = pyshark.FileCapture("modbus-ics.pcapng")
modbus_func_code = {}
for c in captures:
    for modbus in c:
        if modbus.layer_name == "modbus":
            if hasattr(modbus, "func_code"):
                type = modbus.func_code
                if type in modbus_func_code:
                    modbus_func_code[type] += 1
                else:
                    modbus_func_code[type] = 1
print(modbus_func_code)

发现只存在功能码为 3 的协议包，共计 274 条。
上文中也提到了，modbus 协议以1、2、3、4、5、6、15、16等八种最为常用，
下表为 modbus 的功能码简单说明：

功能码为3 的主要作用是读取寄存器，因此我们只需要确定读取寄存器的内容，即可确定 flag。
观察流量包：

发现只要寄存器1的数据在不断变化，因此按照传输顺序提取寄存器1的数据并转成ASCII码，得到数据：

0x39,0x65,0x32,0x33,0x32,0x61,0x62,0x39,0x65,0x30,0x63,0x32,0x65,0x31,0x37,0x33,0x35,0x39,0x64,0x37,0x61,0x64,0x37,0x61,0x64,0x65,0x61,0x30,0x61,0x33,0x30,0x37,0x31,0x38,0x65,0x00,0x33,0x35,0x32,0x66,0x63,0x36,0x31,0x31,0x33,0x66,0x64,0x62,0x61,0x33,0x32,0x36,0x64,0x34,0x39,0x38,0x37,0x37,0x63,0x37,0x33,0x38,0x33,0x34,0x35,0x34,0x65,0x37,0x00,0x61,0x65,0x62,0x66,0x62,0x61,0x34,0x35,0x32,0x33,0x63,0x64,0x66,0x30,0x33,0x64,0x64,0x66,0x65,0x38,0x65,0x66,0x38,0x64,0x66,0x36,0x32,0x30,0x66,0x66,0x35,0x30,0x00,0x61,0x33,0x64,0x65,0x62,0x39,0x65,0x65,0x32,0x37,0x32,0x35,0x37,0x36,0x33,0x33,0x66,0x35,0x39,0x30,0x35,0x37,0x63,0x35,0x36,0x35,0x34,0x64,0x66,0x66,0x65,0x36

使用以下脚本将其转化为字符串：

#!/usr/bin/env python
#encoding=utf-8
data = 0x39,0x65,0x32,0x33,0x32,0x61,0x62,0x39,0x65,0x30,0x63,0x32,0x65,0x31,0x37,0x33,0x35,0x39,0x64,0x37,0x61,0x64,0x37,0x61,0x64,0x65,0x61,0x30,0x61,0x33,0x30,0x37,0x31,0x38,0x65,0x00,0x33,0x35,0x32,0x66,0x63,0x36,0x31,0x31,0x33,0x66,0x64,0x62,0x61,0x33,0x32,0x36,0x64,0x34,0x39,0x38,0x37,0x37,0x63,0x37,0x33,0x38,0x33,0x34,0x35,0x34,0x65,0x37,0x00,0x61,0x65,0x62,0x66,0x62,0x61,0x34,0x35,0x32,0x33,0x63,0x64,0x66,0x30,0x33,0x64,0x64,0x66,0x65,0x38,0x65,0x66,0x38,0x64,0x66,0x36,0x32,0x30,0x66,0x66,0x35,0x30,0x00,0x61,0x33,0x64,0x65,0x62,0x39,0x65,0x65,0x32,0x37,0x32,0x35,0x37,0x36,0x33,0x33,0x66,0x35,0x39,0x30,0x35,0x37,0x63,0x35,0x36,0x35,0x34,0x64,0x66,0x66,0x65,0x36

ret=''
for i in data:
    if i == 0:
        ret+='\n'
    else:
        ret += chr(i)

print (ret)

可以得到四行字符串：

9e232ab9e0c2e17359d7ad7adea0a30718e
352fc6113fdba326d49877c7383454e7
aebfba4523cdf03ddfe8ef8df620ff50
a3deb9ee27257633f59057c5654dffe6

其中后面3个字符串可以直接破解md5，为_love_this_game!
第一个发现多出来三个字符，观察发现在第 19 位置到第 24 位置，存在重复，删除多余的d7a，解密md5 可得pcl_i
最终得到 flag 为 pcl_i_love_this_game!

实例三：工控系统操作1

要求

• 调节某阀门开度，使其数值从35变到大于60，数值稳定、持续时间大于3秒。
• 完成时间：30分钟

已知条件

• 工控设备（虚拟机）的IP地址。
• 设备支持Modbus通信协议，端口号502
• PLC上有以下寄存器和线圈：
  ** 状态寄存器 0x0000~0x0009，供监视用。

** 控制寄存器 0x000A~0x0014，供控制用。
** 状态线圈 0x0000~0x0009，供监视用。
** 控制线圈 0x000A~0x0014，供控制用。
** 附加寄存器 0x1000~0x1063，供提交FLAG用。

• 阀门开度对应的状态寄存器为0x0008，对应的控制寄存器为0x0010。

完成标准

操作成功后，附加寄存器0x1000~0x1007中会自动出现一组（8个）非0数值，这些数值对应的ASCII码即为任务完成的FLAG

题解

因为现在已经没有环境可以复现，因此只做简单说明。

这题刚开始很久没人做出来，后来官方给出了 tips：

• 设定值的前提条件之一是系统处于维护模式
• 控制寄存器0x00B是系统工作模式，值为3代表维护模式、值为0代表运行模式。
• 为防止误操作，正常运行时工作模式是锁定的。如要改变工作模式，须先操作某控制线圈来进行解锁。

根据提示，我们首先要将进入系统维护模式，测试发现可改的线圈只有 15，因此需要调整 15 线圈，将其写入 Bool 型数据 true，然后调整工作模式，由11 切换到 3 ，再对控制器进行操作，在地址16写入值 为 100（其他也行，但是要大于 64），最后将系统的工作模式复原，先将线圈 11 改为 0，然后把控制器 15 改成 false 即可。
最后可以从4096[+10]得到ascii，如下图：

转换后得到flag： 06E6B72D

实例三：工控系统操作2

要求

• 以正常通信方式打开PLC设备的报警使能开关；
• 读取PLC系统生成的一条日志，分析日志中记录的报警时间。
• 完成时间：30分钟。

已知条件

• 工控设备（虚拟机）的IP地址。
• 设备支持Modbus通信协议，端口号502。
• PLC上有以下寄存器和线圈：
  ** 状态寄存器 0x0000~0x0009，供监视用。

** 控制寄存器 0x000A~0x0014，供控制用。
** 状态线圈 0x0000~0x0009，供监视用。
** 控制线圈 0x000A~0x0014，供控制用。
** 状态寄存器 0x100~0x163，供报警日志用。

• 报警日志使能开关的对应的控制线圈地址为0x000D

完成标准

取得报警时间后，该时间值即为任务完成FLAG，格式为yyyy-mm-dd hh:mm:ss

题解

这题完成的基础是在上题的基础上。
根据已知条件，首先打开日志使能开关，即将线圈13 改为 true
Fuzzing了几个寄存器后，发现256[+100]能看到报错数值，因此读取该地址的数值：

[18:25:10] [256] 25
[18:25:12] [257] 13
[18:25:16] [258] 84 T
[18:25:19] [259] 224
[18:25:23] [260] 92 /

[18:25:26] [261] 115 s
[18:25:29] [262] 119 w
[18:25:32] [263] 105 i
[18:25:34] [264] 116 t
[18:25:37] [265] 99 c
[18:25:39] [266] 104 h
[18:25:41] [267] 32 space
[18:25:44] [268] 49 1
[18:25:46] [269] 51 3
[18:25:50] [263] 105 i
[18:25:56] [270] 49 1
[18:25:59] [271] 32 space
[18:26:02] [272] 116 t
[18:26:06] [273] 114 r
[18:26:08] [274] 105 i
[18:26:10] [275] 112 p
[18:26:13] [276] 32 space
[18:26:15] [277] 111 o
[18:26:18] [278] 102 f
[18:26:20] [279] 102 f
[18:26:23] [280] 46 .
[18:26:26] [281] 0
[18:26:28] [282] 76 L
[18:26:33] [283] 0 
[18:26:37] [284] 0
[18:26:39] [285] 0

通过对上面的数据分析，发现190d54e05c可能是时间戳。

拆分后大小端重排为‭5CE0540D‬，然后转换为10进制 ‭1558205453‬，转换为unix时间戳：‬‬‬‬

提交flag: 2019-5-19 2:50:53

其实还有第三题工控系统操作，但是由于到最后我们没时间计算校验码，因此没有拿到 flag，这里也就不说了

0x04 总结

S7协议没有公开的官方文档，在S7协议方面也没有官方术语，我了解的也不算深入，只是通过网上一些分享结合自己理解写成的一篇入门文章，如有错误，还望指出，另外，工控安全其实很吃工控设备，如果能有实际/仿真/模拟设备，对于工控安全的学习很有帮助。此文仅作工控安全入门参考文章，希望对你有所帮助。

0x05 参考

西门子通信协议S7Comm
https://laucyun.com/3aa43ada8cfbd7eca51304b0c305b523.html#6-8

Siemens SIMATIC Step 7 Programmer's Handbook
http://www.plcdev.com/book/export/html/373

S7 Communication (S7comm)
https://wiki.wireshark.org/S7comm

wireshark dissector plugin sources
http://gmiru.com/resources/s7proto/constants.txt

PI service names
https://laucyun.com/static/upload/file/2018/01/PI_service_names.txt

工业控制系统安全之——Modbus学习笔记
https://www.freebuf.com/articles/ics-articles/148637.html

Modbus TCP流量分析
http://www.vanimpe.eu/2015/12/07/introduction-to-modbus-tcp-traffic/

0x06 附录一：错误码具体含义

0x07 附录二：PI server name

0x08 Modbus 中一些缩写含义

0x07 附录三：一些工控协议包及 modbus 的资料

工控数据包：

链接:https://pan.baidu.com/s/1lkr4bsoCJTACzVwzgHcgdQ
密码:tp1u

modbus 资料：
链接:https://pan.baidu.com/s/1Au0HBlGNHGN0JIzl5Iwf8g 密码:gp3b