西门子S7comm协议解析 —— 利用Wireshark对报文逐字节进行解析详细解析S7comm所含功能码以及UserData功能（path3）
Db2k 人气:0好了开始搞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/wordhttps://img.qb5200.com/download-x/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了
未完待续..... 有一些眼酸了先放着吧明天在添加
加载全部内容