西门子S7协议介绍

据我所知，S7协议没有公开的文档，由于没有官方文件，S7协议不存在官方术语。但是有几个开源的项目可以帮助我们处理S7。

S7 protocol指的是以太网S7通信，主要用于将PLC连接到（I）PC工作站（PG/PC-PLC通信）。这不应与西门子设备使用的不同现场总线协议混淆，例如MPI、Profibus、IE和Profinet（这是一种基于以太网的协议，用于将PLC连接到IO模块，而不是设备的管理协议）

大多数情况下，西门子通信遵循传统的主从模式(master-slave)或者CS模式(client-server )。其中PC（master/client）将S7请求发送到现场设备（slave/server)。这些请求用于从设备查询或向设备发送数据或发出某些命令。当PLC作为通信主站时（master）有一些例外，通过FB14/FB15设备可以向其他设备发起GET和PUT请求。

在S400系列中，实现了所谓的循环数据I/O功能，这类似于传统的发布者 - 订阅模型。PC可以订阅某些事件，而不是PLC 定期推送所请求的数据送到网络。还有一个合作伙伴（Partner ）或点对点模型，当一个活动的合作伙伴请求连接并调用阻止发送（Block Send），与此同时被动合作伙伴调用阻止接收（Block Receive）方法。

有关S7通信概述的更多信息，请参阅西门子Simatic Net和Snap7文档。 

S7协议TCP/IP实现依赖于面向块的ISO传输服务,S7协议包含在TPKT和ISO-COTP协议中，允许PDU（协议数据单元）通过TCP承载。ISO overTCP通信定义在RFC1006中，ISO-COTP定义在RFC2126其是基于ISO 8073协议（RFC905）。该结构如下图。

S7协议是面向功能/命令的，这意味着传输由S7请求和适当的应答组成（极少数例外）。在连接建立期间协商 传输的数量和PDU的最大长度。

S7 PDU 由三个主要部分组成：

报文长度为10-12个字节，应答报文包含两个额外的错误代码字节。除此之外，标头格式在所有PDU中是一致的。

字段：

 通常以Function Code  开头 占一个字节，

后面的报文因Function Code和Message Type而有很大差异 

消息的其余部分在很大程度上取决于Message Type和Function Code

这里分析仅针对Message Type为：

通常每个Job Request求都会产生一个 Ack-Data数据回复。

Job Reques和Ack-Data报文的参数(Parameters)都是以功能代码开头，其余字段的结构取决于此值。

此消息对（Job Reques和Ack-Data）在每个会话开始时发送，然后才能交换其他任何消息。它用于协商Ack queues 的大小和max PDU length，双方都声明其支持的值。Ack queues 的长度决定了可以在没有应答的情况下同时启动的并行Job Reques的数量。

max PDU length和Ack queues字段都是 Big-Endian。

参数结构如下图所示：

字段：

在配置CPU期间，可以设置三种保护模式。

必须注意的是，即使启用了读/写保护，也会允许某些操作，例如读取SZL列表、读\写M区。其他操作（如读取或写入对象/功能/数据块）返回权限错误。

有两个与CPU关联的保护级别，他们是：分配保护级别和实际保护级别。

在正常操作期间，在配置通讯(Setup Communication)之后，客户端通过查询SZL reads（SZL ID: 0x0132 SZL Index: 0x0004）得到读写权限，查询实际保护级别和分配保护级别。

如果需要认证的密码以用户数据消息被发送到设备，这会降低有效的保护水平。

认为这至少提供了一点点安全性之前，但它不是。密码是六个字节，几乎以明文形式发送（与常量进行异或并移位）。它是可重放的，可以强制执行。该协议还不提供完整性或机密性保护，可以进行消息注入和修改。S7安全性的一般经验法则是，如果您可以ping设备，则可以拥有它。

这里必须注意的是，S7-1200/1500系列设备使用略有不同的方法，保护级别处理稍有不同，发送的密码明显更长（实际上是密码的哈希），但它仍然是不变的，可重放。

数据读写操作通过指定变量的Memory Area、address (offset)、Size or Type来操作。在进入协议细节之前，先简要介绍一下S7寻址模型。

如前所述，通过指定地址来访问变量，该地址由三个主要属性组成。

Memory Area：

还有其他不太常见的存储区域（例如本地数据[L]和外设访问[P]等）。

变量的type 决定了它的长度以及应该如何解析它。

DataType:

示例：

变量的示例地址是DB123X 2.1，

它访问DB块123的第三个Byte的第二个Bit。

在这个简短的介绍之后，回到协议的变量读/写的实现。S7协议支持使用不同的寻址模式在单个消息中查询多个变量读/写。主要有三种模式：

对于每种寻址模式，参数(Parameters)头的结构方式相同：

S7 PDU 的数据(Data) 部分根据消息的类型（read/write）和方向（Job/Ack Data）而变化：

总之，Request Item总是包含变量的描述，并且可以在Job request中发送多个变量，而Data Item包含所描述变量的实际值。Data Item结构必须以偶数字节开始，因此如果它们的长度是奇数，并且有一个后续的Data Item，则用零字节填充它们。

下图显示了Request Item和Data Item结构：

Request Item的字段：

Data Item字段

下图显示了Reques Itemt和Data Item结构

Request Item字段：

            Size： 指定从选定地址读取或写入的Byte数量。

            DB Number： 地址变量所在的DB快。

            Address： 指定DB快的  byte 偏移量。

Data Item的字段：

        Error Code： 与Subitem请求关联的返回值。

        Data：要读取或写入的实际数据，解析数据需要相应的Subitem。

在西门子的术语中，下载（download ）是主设备向从设备发送块数据，上传(upload )是另一个方向。在西门子设备上，程序代码和大部分程序数据存储在块中，这些块有自己的头和编码格式，这里不详细讨论。从协议的角度来看，它们是需要传输的二进制blob（对于感兴趣的读者，snap7源提供了有关块头及其编码的信息）。

西门子设备认可七种不同类型的块：

 西门子文档中详细描述了这些模块的用途。

这些块在uploda/download请求中使用特殊的ASCII文件名进行寻址。此文件名的结构如下：

示例: 

文件名是 _0800001P，用于将OB 1复制到被动文件系统或从被动文件系统复制OB1。

Let me make a quick note on block encoding and content protection. There are two measures in place to protect the content of programs and data on the devcies and allow the distribution of program libraries. The first one is called know-how protection, which if set prevents STEP7 or TIA showing the actual content of the block. Unfortunately, this is trivial to bypass, as it is just two bits set in the header of the blocks and can easily be cleared. The other protection measure is block “encryption”, which in reality is just an obfuscation with linear transformations (bytewise xoring and rotating with constants), again should be trivial to bypass. So do not rely on these “security” mechanisms to protect your know-how. Otherwise the data blocks contain the raw, initialized image of the memory. Program blocks contain the MC7 (Machine Code 7) binary instructions. 

 让我简要说明一下块编码和内容保护。有两种措施可以保护设备上程序和数据的内容，并允许分发程序库。第一种称为专有技术保护，如果设置了该保护，则会阻止STEP7或TIA显示块的实际内容。不幸的是，这是琐碎的绕过，因为它只是两位设置在头的块，可以很容易地清除。另一种保护措施是块“加密”，它实际上只是一种线性变换的模糊处理（字节xoring和常数旋转），同样应该是可以忽略的。所以不要依赖这些“安全”机制来保护你的技术。除此以外，数据块包含内存的原始初始化镜像。程序块包含MC7（机器代码7）二进制指令。

上传和下载块涉及3-3种不同类型的消息对。下面列出了相关的功能代码：

这些消息的结构非常简单，但是消息序列（特别是下载）需要一些解释。

上传块序列非常直观，如下所示：

在Ack Data - Start Upload消息中，slave告知块的长度，然后主设备继续发送Job - Upload Block消息，直到接收到所有字节。最后，它使用Job - End Upload消息关闭上传序列。块的实际数据由从Ack Data - Upload Block消息中发送。

Job - Start Upload  参数头：

Ack Data - Start Upload   参数头：

Job - Upload  参数头：

Ack Data - Upload   Parameter and Data Parts：

                Length： [2b] Block Data的长度。

                Unknown： [2b] 总是  0x00fb。

                Block Data：上传数据块的一部分。

Job - End Upload  Parameter Header：

Ack Data - End Upload  Parameter Header：

 Upload 和Download 的关键区别在于，在下载过程中，通信的方向发生了变化，slave变成了master（有点像）。在初始Request Download exchange之后，slave发送 Job messages，而master回复Ack Data，这是“slave only replies”规则的唯一例外。发送完所有字节后，master（原始）发送 Download Ended Job以关闭下载会话。请参见下面的序列图。

实际消息的结构与上传消息非常相似，所以这里只介绍差异。

 Job - Request Download 消息中包含了两个附加字段，下载块的Block Length 和 Payload Length（不包含块头的长度）​​​​​​​。这两个字段都是编码为ASCII字符串的十进制数字。响应 Ack Data - Request Download 仅包含Function Code。

另一个显着的区别是，虽然Session ID字段存在,但不使用（仍为0x00000000）而是在每个 Job - Download Block传输文件名。其余消息的结构与前面讨论的相同。

（尝试使用s7comm.param.func==0x28 wireshark筛选器查找PLC控制消息） 

PLC控制消息用于在从属设备上执行不同的命令，以修改其执行/内存状态。此类命令用于启动或停止PLC控制程序的执行，激活或删除设备上的程序块，或将其配置保存到永久存储器中。这些消息的结构相当简单，将在不讨论确切细节的情况下对其进行解释。

ob - PLC Control消息由两个主要部分组成，即被调用方法的ASCII名称和参数（也被编码为ASCII字符串）。方法名的结构与块传输部分中引入的文件名类似。参数取决于方法类型，可以将其视为方法类型的参数。 Ack Data消息仅包含PLC Control功能代码。

一些示例函数名称及其相关参数：

所述PLC Stop消息是基本相同的PLC Control 消息。唯一的区别是消息中没有参数，并且例程部分始终设置为P_PROGRAM。不知道为什么它有单独的类型而不是使用参数来确定它是一个开始或停止消息。

嗯，这篇博文比我最初计划的要长得多，但我希望它对一些人有用。这可能是显而易见的，但S7协议不是一个设计良好的协议。它最初是为了简单地查询寄存器值而创建的，它做得还不错，但后来不断添加功能，直到它变成了这个怪物。它充满了不一致性和不必要的冗余，而且用户数据消息只会变得更糟。在尝试为协议编写解析器时，这些不规则和设计缺陷变得更加明显（而且令人讨厌）。

如果S7是一辆汽车，它可能会像这样：