您对Modubs 中的RTU、ASCII 和TCP 感到困惑吗？这将是您见过的最全面的分析
浅谈MES、SCADA、PLC项目中的串口通信（232、485、422）及常见问题
MES下数据采集及——扫码器串口通讯
对于熟悉西门子的朋友来说，了解S7comm协议是必不可少的。今天我们就对S7comm进行简单的分析。
S7comm简介
西门子是德国一家非常大的企业，业务遍及能源、工业、医疗、基础设施等领域，在世界500强企业中也排名第66位。作为一家以电报公司起家的大型企业，它非常重视沟通。 S7comm是西门子公司设计的专有协议，用于其生产的PLC之间以及SCADA和PLC之间的通信。
与Modbus应用层协议不同，S7comm协议栈的修改程度较高。应用层组织的数据经过COTP协议和TPKT协议进一步处理后，最终通过TCP进行传输。以下是wireshark wiki给出的S7comm协议。堆：
OSI 层协议应用层S7 通信表示层S7 通信(COTP)会话层S7 通信(TPKT)传输层ISO-on-TCP (RFC 1006)网络层IP 数据链路层以太网物理层以太网
虽然我们谈论的话题是对S7comm的分析，但实际上是对整个协议栈的探索。鉴于数据包是由高层进行逻辑封装，然后逐级传输到下层，但我们收到数据包后，下层将其逐层拆解，交给上层。基于逆向思维，我们后续的分析应该是从下层到下层。高度扩展
TPKT协议
传输层以下的内容相信大家应该都很熟悉了。它们都是TCP/IP的基本内容。我就不细说了，直接看session层。
TPKT协议是上层COPT和下层TCP之间过渡的传输服务协议。我们常用的RDP协议（远程桌面协议，Windows远程桌面协议）也是基于TPKT的。 TPKT 的默认TCP 端口是102（RDP 是3389）。其实它本身并没有在payload中添加太多的数据，主要有以下几个。个人：
version，1byte，表示保留的版本信息，1byte，看到这个名字就知道是保留的。 length，2byte，总长度包括payload和这三部分。下面我们就使用之前分析过的2018年工控大赛的流量包。让我们看看它的实际效果
可以看到，版本号是3号，长度是31。除此之外，这一层没有任何有用的信息。
COPT协议
COPT协议的全称是Connection-Oriented Transport Protocol，即面向连接的传输协议。从这个名字就可以看出，它的传输必须依赖于连接，所以在传输数据之前必须有类似TCP握手建立链接的操作。
我们先来看看具体的流量套餐
首先是TCP三向握手。在192.168.25.146 和192.168.25.139 之间建立TCP 连接，随后建立两个COTP 数据包。注意，wireshark这里已经帮我们标记了CR和CC，后面的COTP数据包都是DT。这里的CR和CC实际上分别是connect request和connet recognize，也就是建立连接的过程。连接建立成功后，发送DT包，即数据，即发送数据。
我们看一下它们携带的数据
可以看到DT报文和连接报文有明显的区别。连接数据包的内容显然要多得多。这些实际上是COPT 数据包的两种形式：COTP 连接数据包和COTP 功能数据包。
首先我们看一下COPT连接包。通过上面的wireshark分析，我们可以看到它主要有以下几个字段：
length，1字节，数据的长度，但不包含长度字段（个人感觉很奇怪.） PDU类型，1字节，标识类型，图中0x0d是连接确认类型，而0xe也很常见。连接请求0x0d，连接确认0x08，断开请求0x0c，断开确认0x05，拒绝DST 参考，2byte，目标参考，可以认为是用来唯一标识目标SRC 参考，2byte，源参考，与选项相同，1byte ，可以看到wireshark将8位数字拆分为前四位和后两位：前四位标识类别，即标识类别的倒数第二位对应扩展格式，是否使用扩展样式，最后一位对应的是No明确的流量控制，是否有明确指定的流量控制参数和附加参数字段。可以有多个参数。每个参数由以下字段组成：0xc0，tpdu的大小。 tpdu是传输协议数据单元，即传输数据的大小。 （和前面的长度有重叠吗？）0xc1，src-tsap，翻译过来应该叫源端的端到端传输（在完整的TCP/IP协议栈中，这个字段代表应用程序之间的通信） ，我这里猜测可能是为），但是从西门子提供的手册来看，应该是标有机架号的，但是无论我怎么查，都找不到wireshark解析的字符串。那么我们反方向就找不到答案了，所以只能顺方向去做。在参数字段的最后，我们将详细解释这是什么。0xc2，dst-tsap，同上，接下来我们探讨一下code，1byte，标识类型，主要是：长度，长度后面跟COPT函数封装对应的数据。其实我个人感觉这两个包可以归为一类，但是看到文献后他们都分为两类，所以我们就分成两类吧。
length，1字节，length PDU type，1字节，图中0x0f，为数据传输。其他类型不太常用，这里就不说了（其实我没有找到相关的流量包.有这样的流量老大希望能完成下面的）选项，1byte，按位划分：第一位，标识是否是最后一个数据包（从这里可以看出，当COPT协议中数据较多时，会被分成几个单元进行传输。最后七位，标识TPDU的编号，有这个COPT数据包中已经分析过了，当然上面还留下了一个小问题，就是参数中的一些参数我们似乎不太明白，它是做什么用的呢？有可能的话，我们通过正向开发来看看是啥。 下面使用的是Simatic NET软件（做的时候忘记截图了……图片来自http://www.ad.siemens.com.cn）。
我们配置了一个本地OPC服务器（OPC服务器可以理解为协议转换的设备），目标是实现它和PLC之间的通信。我们选择使用以太网并分别配置机器的IP地址和子网。
然后我们输入地址的详细信息，发现两个重要的选项：TSAP和RACK/SLOT。经过实际操作我们发现，RACK是指CPU的机架号，SLOT是指CPU的槽位号。通过这两个参数我们可以唯一指定一个CPU。
那么说明书有错吗？这怎么可能？毕竟是大厂家，秘密就在这个TSAP上。事实上，它由三个部分组成：
连接号（我瞎编的，实在找不到这个东西叫什么）指的是连接方式，03是单向通讯，单向可以连接多个设备，10以上就是双向- way, two-way 没有办法拥有多个设备。机架号就是RACK槽位号，也就是SLOT。如图，我们配置的OPC服务器为12.11，为双向通讯，机架1，槽位1，而PLC为03.02，单向通讯，0号机架槽位2。那么问题又来了，这和我们流量中的数据包完全不一样！
数据包中包含SNOPCCxxxx，怎么解释呢？这根本不符合我们上面的解释。这实际上是另一种连接方法，称为S7优化连接。与之前的连接方法相比，这种连接可以以符号形式访问数据块。
它规定src-tsap是SNOPCC000x000xxx。作者不明白第一个它恰好对应了我们的数据包。所以我们分析的数据包应该是单向连接，连接数为1。
至此，我们可以说COPT 精确到每一位数字。虽然还存在一些缺陷，但总体来说没有问题。
S7通讯协议
最后，我们得出了最终的S7comm协议。它的结构非常简单，主要分为三个部分：
Header，主要是数据的描述信息，最重要的是表明PDU的类型Parameter，参数，不同类型的PDU会有不同的参数Data，具体数据
首先我们来仔细看看这个Header的奥秘。
Protocol id，1字节，即协议的id，为0x32ROSCTR，1byte，pdu的类型一般如下：0x01，job，表示开始工作。主设备通过job向从设备发送“工作”消息。命令，是读数据还是写数据由参数0x02，ack决定，0x02，确认0x03，ack数据，从设备响应主设备的jobReserved，2byte，保留PDU引用，pdu引用参数长度，参数error class ，错误类型，比如图中的0x00 表示没有错误，常见的请求错误是0x85 错误码，错误代码，结合错误类型来判断错误，图中的0x00 也表示没有错误。关于具体错误类型和错误码的信息大家可以自行搜索，因为太多了，这里就不一一解释了。这些参数取决于不同的pdu类型，这里不再赘述。我们来看看具体的流量套餐。
可以看到pdu是一个job，也就是主设备在发号施令，从参数上可以看到该功能是0x04 read，表示读取数据。 item count是指后面有多少个item，并且只有一个pdu。所以是1.这一项的结构需要单独讨论：
变量规范，1字节，通常是0x12（我没有看到其他的.）长度，以下地址规范的长度，数据的长度，语法ID，符号ID，一个标志，它确定一些格式问题，这里是0x10 是地址数据S7-Any 类指针DBx.DBXx.x 的意思。具体含义我们会在阅读完以下内容后提及。具体大家还是可以自己去查一下。主要是对后续的寻址起到一定的作用。限制传输大小也可以视为传输类型。本例中为4，即WORDDB号，即数据块号。 0 表示你要找的东西不在数据块区域，是你要操作的“东西”，比如0x82 ，它是读取设备的输出。通过这个位也可以看出我们要读取的数据不在DB中，所以DB号为0。如果是DB的话，这1byte应该是0x84地址。具体地址如下图所示。前五位不用，第六到二十一位是Byte地址，后三位是Bit地址。
首先，它定义格式为Address data S7-Any指针类DBx.DBXx.x，然后指定要读取的“东西”作为设备的输出，读取的大小为word。其实这个pdu的所有信息都在这里了。分析完了，但是为了让大家更好的理解上面定义的格式，我们还是继续看一下。
它读取的DB号为0，那么根据格式它是DB0.DBXx.x，而它读取的地址是Byte为0，Bit为0，即DB0.DBX0.0，如果我们指定的“东西”是一个数据块，按照这种格式读取就可以了。这就是格式的意义。另一个例子是0xb2，它被描述为S7-1200的符号地址模式。事实上，格式是一种符号地址，不再是这样的组织形式。
我们看一下之前的pdu的响应。此处的屏幕截图中未捕获标题。标头中最值得注意的是pdu 的类型。这里是0x03，这是对我们之前提到的作业的响应。
从参数部分可以看出，其功能与job pdu相同。 Data部分是传回的具体数据。 return code是返回码，用于标识作业的结果。这里是0xff，表示成功。除此之外，还有以下几点：
0x01，硬件错误0x03，你要访问的东西不允许访问0x05，地址越界0x06，你请求的数据类型与请求的“东西”的数据类型不一致，后面跟的长度data（是真实数据的长度，不包括（前面），最后是具体数据。可以看到这里读取的是0x0000。
至此，S7comm协议我们就了解的差不多了，那么我们进入正题吧。
2018工业信息安全技能大赛（东北赛区）工业协议数据分析
因为2019年的题涉及到S7comm，我们已经做过最后一题了，所以这次找的是个别题。我们先看一下流量套餐。
可以看到很多协议，但是总体思路还是很清晰的。首先是利用ARP协议来查找mac地址（如果你不懂arp，请刷新一下计算机网络知识……），然后是标准的TCP三路握手。然后就是COPT建立连接（以后是不是应该让他握手两次？），然后就到了S7comm和modbus来做具体的工作了。
我们可以看到，这份工作与我们之前的工作有所不同。打开它并仔细观察。
可以看到参数中的function为0xf0，表示建立通信。这其实和上面的TCP和COPT有些类似。它们都是在两个设备之间建立通信，参数的主要信息是MAX AMQ Calling和MAX AMQ Called。
ack_data后面的pdu自然是表示建立相应的通信。经过TCP握手、COPT建立连接、与S7comm建立通信后，设备间的通信正式建立。
以后S7comm可以看到是read，就是读取数据了。数据包和上面说的一样，不再赘述。经过查找，没有flag。
这时候就需要考虑modbus协议中是否有标志位。这时候就需要用到之前的modbus技巧了。功能码1、2、3、4不具备大规模取数据的能力，标志位一般在它们之外。进行简单的过滤，打印出对应的数据就可以了。
您仍然可以使用上一篇文章中的脚本。我不会把它放在这里。如果需要的话直接看上一篇文章即可（字数不算）。
最终标志是modbusICSsecurityWin
总结
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/3872.html
用户评论
西门子S7comm协议分析，MES和SCADA数据采集的利器，期待更多实战经验分享！
有16位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，干货满满，收藏了！
有13位网友表示赞同！
S7comm协议分析，对数据采集和控制系统了解更深了。
有18位网友表示赞同！
西门子S7comm协议，数据采集效率高，值得学习！
有5位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，值得点赞！
有18位网友表示赞同！
西门子S7comm协议，MES和SCADA数据采集，受益匪浅！
有13位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，技术含量高！
有20位网友表示赞同！
西门子S7comm协议，数据采集和控制系统的未来！
有15位网友表示赞同！
数据采集和控制，西门子S7comm协议分析，值得关注！
有12位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，学习了！
有9位网友表示赞同！
S7comm协议，数据采集的新方法，不错！
有18位网友表示赞同！
西门子S7comm协议分析，数据采集的关键，不容错过！
有14位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，干货满满！
有19位网友表示赞同！
西门子S7comm协议分析，数据采集技术发展趋势！
有18位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，值得研究！
有16位网友表示赞同！
西门子S7comm协议，MES和SCADA数据采集，未来可期！
有15位网友表示赞同！
数据采集，西门子S7comm协议分析，了解更深了！
有16位网友表示赞同！
MES和SCADA数据采集，西门子S7comm协议分析，很实用！
有18位网友表示赞同！
S7comm协议分析，数据采集技术进步！
有12位网友表示赞同！
西门子S7comm协议分析，MES和SCADA数据采集，加油！
有15位网友表示赞同！