S7協議介紹

S7comm（S7 通信）是西門子專有協議，可在西門子 S7-300/400 系列的可編程邏輯控制器 (PLC) 之間運行。

它用於 PLC 編程、PLC 之間的數據交換、從 SCADA（監控和數據采集）系統訪問 PLC 數據以及診斷目的。

S7comm 數據作為 COTP 數據包的有效載荷出現。第一個字節總是 0x32 作為協議標識符。

要建立與 S7 PLC 的連接，有 3 個步驟：

1.通過 TCP 端口 102 連接到 PLC
2.在 ISO 層連接（COTP 連接請求）
3.在 S7comm 層連接（s7comm.param.func = 0xf0，Setup 通信）

步驟 1) 使用 PLC/CP 的 IP 地址。

步驟 2) 用作兩個字節長度的目標 TSAP。目標 TSAP 的第一個字節編碼通信類型（1=PG，2=OP）。目標 TSAP 的第二個字節編碼機架和插槽號：這是 PLC CPU 的位置。插槽編號在位 0-4 中編碼，機架編號在位 5-7 中編碼。

步驟 3) 用於協商 S7comm 的具體細節（如 PDU 大小）。

S7抓包分析

TPKT協議

TPKT協議是一個傳輸服務協議，它為上層的COPT和下層TCP進行了過渡。我們常用的RDP協議（remote desktop protocol，windows的遠程桌面協議）也是基於TPKT的，TPKT的默認TCP端口為102（RDP為3389），其實它本身為payload增加的數據並不多，主要就是以下幾個：

version，1byte，表明版本信息
reserved，1byte，保留
length，2byte，包括payload和這三部分在內的總長度

COTP

COTP協議的全稱是Connection-Oriented Transport Protocol，即面向連接的傳輸協議，從這個名字就可以看出，它的傳輸必然是依賴於連接的，所以在傳輸數據前必然有類似TCP握手建立鏈接的操作。
這里wireshark為我們標注出了CR和CC，后面的COTP包都是DT，這里的CR和CC其實分別是connect request和connet confirm的，也就是建立連接的過程，之后連接建立成功后，發送DT包，也就是data，是在發送數據。

接下來我們看一下COTP的連接包：

第一部分：

包含：length、PDU type、DST reference、SRC reference
length ：標識長度（但是length這個標識位不計入長度）
PDU type：標識類型，常見的值有:

0x01: ED Expedited Data，加急數據
0x02: EA Expedited Data Acknowledgement，加急數據確認
0x04: UD，用戶數據
0x05: RJ Reject，拒絕
0x06: AK Data Acknowledgement，數據確認
0x07: ER TPDU Error，TPDU錯誤
0x08: DR Disconnect Request，斷開請求
0x0C: DC Disconnect Confirm，斷開確認
0x0D: CC Connect Confirm，連接確認
0x0E: CR Connect Request，連接請求
0x0F: DT Data，數據傳輸

DST reference: 目標標識
SRC reference：源標識

第二部分（option）

可以看到在wireshark中將這部分（1個byte拆成了前四位和后兩位），其中：

前四位標識class，也就是標識類別
倒數第二位對應Extended formats，是否使用拓展樣式
倒數第一位對應No explicit flow control，是否有明確的指定流控制

第三部分（parameter）

分為三部分:parameter code、parameter length、data,
parameter code:標識類型，主要有：

0xc0，tpdu的size，tpdu即傳送協議數據單元，也就是傳輸的數據的大小
0xc1，src-tsap （源設備號）
0xc2，dst-tsap （同上）
parameter length：長度
data：對應數據

COPT功能包

可以看到COTP功能包的PDU type為0X0f，只有三部分：length，type，opt

以上便是TPKT和COTP協議的解析過程。

S7COMM

S7Comm數據作為COTP數據包的有效載荷，第一個字節總是0x32作為協議標識符。
S7Comm協議包含三部分：

Header
Parameter
Data
根據實現的功能不同，S7comm協議的結構會有所不同

在Header中最重要的字段就是ROSCTR，它決定了后續參數的結構。ROSCTR的類型常見有以下值：

0x01 - JOB(Request： job with acknowledgement)：作業請求。由主設備發送的請求（例如，讀/寫存儲器，讀/寫塊，啟動/停止設備，設置通信）；
0x02 - ACK(acknowledgement without additional field)：確認響應，沒有數據的簡單確認（未遇到過由S7 300/400設備發送得）；
0x03 - ACK_DATA(Response： acknowledgement with additional field)：確認數據響應，這個一般都是響應JOB的請求；
0x07 - USERDATA：原始協議的擴展，參數字段包含請求/響應ID（用於編程/調試，讀取SZL，安全功能，時間設置，循環讀取...）

Parameter部分：

Parameter的第一個字段為function，根據Header中ROSCTR的類別和Parameter中function的不同，parameter的結構，目的也會有所不同。
下面根據不同的功能碼（function的值）講解parameter的字段的構成：

0XF0(建立通信)

建立通信在每個會話開始時被發送，然后可以交換任何其他消息。它用於協商ACK隊列的大小和最大PDU長度，雙方聲明它們的支持值。ACK隊列的長度決定了可以同時啟動而不需要確認的並行作業的數量。PDU和隊列長度字段都是大端。
當PDU類型為Job（ROSCTR的值為0x01），function為0xf0時，Paramter的結構為：

具體的Parameter結構，如下：

1 (Unsigned integer, 1 byte): Parameter part: Reserved byte in communication setup pdu，保留字節；
2 (Unsigned integer, 2 bytes): Max AmQ (parallel jobs with ack) calling；
3 (Unsigned integer, 2 bytes): Max AmQ (parallel jobs with ack) called；
4 (Unsigned integer, 2 bytes): Parameter part: Negotiate PDU length。協商PDU長度。

從響應包可以看出ack隊列為1，PDU最大長度為240
（不同的function的值，parameter的結構不一樣，以下只列出結構信息，不一一詳述）