西門子S7comm協議解析 —— 利用Wireshark對報文逐字節進行解析詳細解析S7comm所含功能碼以及UserData功能（path3）

好了開始搞UserData這一塊了。

接着上一篇繼續

西門子S7comm協議解析 —— 利用Wireshark對報文逐字節進行解析詳細解析S7comm所含功能碼以及UserData功能（path2）

 

提及這個UserData是屬於西門子後期加的一些功能，也就是這些功能讓S7這個協議變得更加豐富，也是由於這些功能讓S7變得很臃腫，也不利用使用。

雙刃劍沒辦法去評判。

 

這個我就按照我抓包的順序進行介紹吧，可能不會介紹完，可是基本上你明白一個其餘的也就差很少了。

能夠利用它明白它的某塊字段的含義就好了，暫時我不必去深刻的去了解他的原理，因此有些地方講的不會太細請見諒。

一、讀系統狀態 — 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不一樣罷了。

二、時間設置 —— 47 1 

47 1對應的也就是讀時間

發包

 能夠看出基本與讀SZL狀態是同樣的我在總體標記一下吧

回包

Parameter部分

Data部分

 三、寫時間 47 2

發包

與讀時間是同樣的只不過data部分是在發包階段。

由於要寫時間 那麼確定發包的時候會攜帶時間信息對吧，這個也很容易去理解。

回包

這麼一看是否是基本是同樣。

本身比對一下就OK了

 

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