西门子S7comm协议解析 —— 利用Wireshark对报文逐字节进行解析详细解析S7comm所含功能码以及UserData功能(path3)

2019/04/10 10:10
阅读数 29

好了开始搞UserData这一块了。

接着上一篇继续

西门子S7comm协议解析 —— 利用Wireshark对报文逐字节进行解析详细解析S7comm所含功能码以及UserData功能(path2)

 

说起这个UserData是属于西门子后期加的一些功能,也就是这些功能让S7这个协议变得更加丰富,也是因为这些功能让S7变得很臃肿,也不利用使用。

双刃剑没办法去评判。

 

这个我就按照我抓包的顺序进行介绍吧,可能不会介绍完,但是基本上你明白一个其他的也就差不多了。

可以利用它明白它的某块字段的含义就行了,暂时我没必要去深入的去了解他的原理,所以有些地方讲的不会太细请见谅。

1、读系统状态 — 44 1

为什么我把44 1 专门的写上去呢 其实UserData也有对应的功能码 但是太杂乱

44 是功能的大体方向 1 是具体功能

发包

 

 

这个Header头部跟其他的都一样  我就直接把上一篇的复制过来,重点还是参数部分。

Byte[0] 为 协议ID  这个只要是S7comm协议一般都是指定0x32

Byte[1] 为 PDU类型  这个只要是Userdata都是07

Byte[2]Byte[3] 冗余数据,通常为0×0000

Byte[6]Byte[7] 参数的总长度也就是parameter的长度

Byte[8]Byte[9] 数据的长度、也就是data部分数据的长度如果无即为0

Parameter部分

Byte[0] Byte[1] Byte[2] 00 01 12 参数头部信息

Byte[3] 04 为之后的数据个数

Byte[4] 11 对应的是Request 也就是请求的意思

Byte[5] 44 这个因为wireshark 帮我们解析了8位前四位 0100 对应的就是Request请求

说明PDU是从主机请求设备的后四位0100 对应的是所属类型也就是CPU功能

Byte[6] 01 前面44是规定了大的方向这个01就是具体要干什么了图中01就是read szl

在这里解释一下szl 是什么ssl缩写是系统状态 S7协议是德国西门子的德国状态的是Z开头的所以缩写为 szl

Byte[7] 字面意思由主机指定顺序

Data部分

Byte[0] FF 返回码 返回码常见如下表

0x00       Reserved 未定义,预留

0x01       Hardware error   硬件错误

0x03       Accessing the object not allowed 对象不允许访问

0x05       Invalid address     无效地址,所需的地址超出此PLC的极限

0x06       Data type not supported     数据类型不支持

0x07       Data type inconsistent 日期类型不一致

0x0a       Object does not exist    对象不存在

0xff     Success  成功

Byte[1] 09 指的数据类型,通常有bit、byte等 常见数据类型如下表

0     NULL

3     BIT bit access, len is in bits

4     BYTE/WORD/DWORD     byte/word/dword access, len is in bits

5     INTEGER    integer access, len is in bits

6     DINTEGER  integer access, len is in bytes

7     REAL    real access, len is in bytes

9     OCTET STRING octet string, len is in bytes

Byte[2]Byte[3] 00 04 后面数据的个数

SZL部分

前四位为操作的对象是什么 0000 为CPU 1100为cp 1000为fm 0100为im

中间0000 0000 0000 0000是wireshark解析错了按照官方的应该为四位

后八位 表明的是局部列表的序号 我们只需要关注最后两位就行(0x00)下面是各类的序号图

 这么一来是不是看起来UserData这一块也没那么难对吧,继续来看回包吧。

回包

Header头部不做描述了与之前都相同的自己对比就可以

Parameter部分

00 01 12 与发包一致

08  长度

12  对应的Response 回应请求

84  前四位1000 对应的就是 Response  后四位 0100就是要读CPU

01  读系统状态SZL

00  与发包一致

00  数据的编号

00  字译最后一个数据单元

00  错误码

Data部分

FF 返回码

09  指的数据类型

00 e8 后面数据个数

SZL-ID 和 Index 跟发包是一样的不做介绍了

00 02   是一个数据占用多少bytes

00 70   转换为10进制为112 代表了有112个SZL_data_tree (图太大就没截下去)

后面的PDU就不在分析了都是做读取相关类的相关信息、只不过是指定的局部列表不同、index不同罢了。

2、时间设置 —— 47 1 

47 1对应的也就是读时间

发包

 可以看出基本与读SZL状态是一样的我在整体标记一下吧

回包

Parameter部分

Data部分

 3、写时间 47 2

发包

与读时间是一样的只不过data部分是在发包阶段。

因为要写时间 那么肯定发包的时候会携带时间信息对吧,这个也很容易去理解。

回包

这么一看是不是基本是一样。

自己比对一下就OK了

 

未完待续..... 有一些眼酸了先放着吧明天在添加

 

原文出处:https://www.cnblogs.com/Db2k/p/12391974.html

展开阅读全文
szl
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部