Understanding the S7COMM and Modbus Industrial Protocols

First published on the Xianzhi community:https://xz.aliyun.com/t/6603

0x01 S7COMM Protocol

S7COMM stands for S7 Communication. It is Siemens' proprietary protocol for programming and exchanging data between S7-300/400 PLCs. S7 is carried over TPKT and ISO-COTP; this article focuses only on S7Comm. S7Comm contains three parts:

• Header
• Parameter
• Data The Header contains eight fields, shown below:

Bytes 0–1:

Protocol ID, normally 0x32;

Bytes 1–2:

ROSCTR, or PDU type, generally has the following values:

• 0x01: JOB A job request, such as reading or writing memory or blocks, starting or stopping a device, or setting up communication
• 0x02: ACK A simple acknowledgment with no data
• 0x03: ACK_DATA Acknowledgment with data, normally a response to a Job request
• 0x07: USERDATA Extended protocol whose parameters include request and response IDs, commonly used for programming, debugging, and reading SZL data

Bytes 2–4:

Redundancy Identification, reserved data normally 0x0000;

Bytes 4–6:

Protocol Data Unit Reference, incremented for each request event;

Bytes 6–8:

Parameter length: total length of the parameters

Bytes 8–10:

Data length: 0x0000 when reading internal PLC data; for other functions it is the length of the Data section;

Bytes 10–12:

Error class: the meanings of its error codes appear in the following table:

Bytes 12–14:

Error code; see for its meaningAppendix I: Error-Code Meanings

This completes the header. S7Comm Parameter and Data vary according to the PDU-type function code and protocol extensions in UserData. This article briefly introduces the PDU function codes and leaves the more complex extensions unexplained.

Common function codes for Job and ACK_DATA PDUs appear in the following table:

The following briefly introduces the structures of these function codes.

Setup communication（0xf0）

Setup Communication is sent at the start of every session before other messages. It negotiates the ACK queue size and maximum PDU length; both sides declare supported values, similar to maximum transmission units in networking. The queue length determines how many parallel jobs may start without acknowledgment. PDU and queue-length fields use big-endian order.

The Setup Communication Parameter structure is:

Bytes 0–1:

Function: Setup communication (0xf0) — the function declaration of Parameter/data.

Bytes 1–2:

Reserved: 0x00 — a reserved byte, normally 0x00.

Bytes 2–4:

Max AmQ (parallel jobs with ack) calling

Bytes 4–6:

Max AmQ (parallel jobs with ack) called

Bytes 6–8:

PDU length — the negotiated PDU length.

The following shows example Job and Ack_Data PDUs

The negotiation above produces an ACK queue size of 1 and a maximum PDU length of 240.

Read Var（0x04）

Read Var reads data by specifying a variable's memory area, address or offset, and size or type. Its Parameter and Item structures are:

Bytes 0–1:

Function: Read Var (0x04), the function declaration for Parameter/Data

Bytes 1–2:

Item count — the number of Items.

Bytes 2–14:

Item [1] — the first Item.

14+12n – 14+12Byte n+1:

Item[n] — the Nth Item.

One Item has the following structure:

Bytes 0–1:

Variable specification — the structure identifier, normally 0x12, meaning a variable specification.

Bytes 1–2:

Length of following address specification — the length of the address specification that follows this field.

Bytes 2–3:

Syntax Id, in full "Syntax Ids of variable specification" — the format type of the IDS address specification, which determines the addressing mode and the layout of the rest of the item. Common variable structure identifiers are listed below:

Bytes 3–4:

Transport size — the transport size of the data. Common values are listed below:

Bytes 4–6:

Length — the length of the data.

Bytes 6–8:

DB number — the DB number. If the access does not target a DB area this field is 0x0000, as shown below:

Bytes 8–9:

Area — the memory area. Common areas are listed below:

Bytes 9–12:

Address — the address.

A simple example shows the core content of an Item packet:

This is a Job PDU with the Read Var function. Item[1] reads a BYTE from DB1 at address 0x00000000.

For Read Var, the Ack_Data Parameter structure differs from the Job Parameter structure, as shown below:

Its Parameter contains only function and item count, but the response also includes Data, which is absent from a Job PDU. The Data structure is shown below:

Bytes 0–1:

Return code — the return code. Common return codes in the Data part of a response are listed below:

Bytes 1–2:

Transport size — the transport size of the data. Common transport size values inside data are listed below:

Bytes 2–4:

 Length: — the length of the data.

Bytes 4 through 4+length, undefined:

Data — the data itself.

Bytes 4+length through 5, undefined:

Fill byte — padding. If the data length does not reach the Length given in bytes 2-4, it is padded with 0x00.

Write Var（0x05）

Write Var writes data by specifying a variable's memory area, address or offset, and size or type. Its Parameter structure matches Read Var, but it includes an additional Data structure for the values being written:

The Write Var structure is:

The diagram shows a Job request writing 0x77100002 to Flags (M) at address 0x000000. The corresponding Ack_Data structure is similar:

Compared with Read Var, Write Var Data has only a Return Code field. Item 1 indicates that 0x77100002 was successfully written to Flags (M) at address 0x000000.

Request download（0x1a）

Request Download begins a download. It is part of a complete flow with Download Block and Download Ended; together the three function codes form the full download process. The flow is:

With the overall flow established, we can examine Request Download. Its Parameter structure is:

Bytes 0–1:

Function: Request download (0x1a) — the function declaration of Parameter/data.

Bytes 1–2:

Function Status — the function status: whether an error occurred, and whether more data is requested through another retrieval block/file.

Bytes 2–4:

Unknown byte(s) in blockcontrol — no meaning.

Bytes 4–8:

Unknown byte(s) in blockcontrol — no meaning, normally 0x00000000.

Bytes 8–9:

Filename Length — the length of the filename.

Bytes 9–18:

Filename — the filename. Its structure is:

Bytes 0–1:

File identifier — the file identifier. There are two: _ (Complete Module) and $ (Module header for up-loading).

Bytes 1–3:

Block type — the block type. Siemens devices have eight different function block types, listed below:

Bytes 3–8:

Block number: number of the requested block

Bytes 8–9:

Destination filesystem — the target filesystem of the request. There are three:

• P, Passive copied but not chained module: passive file system
• A, Active embedded module: active file system
• B, active as well as passive module: both active and passive file system

Bytes 18–19:

Length part — the length of the second part of the parameter, that is, the length of the fields that follow.

Bytes 19–20:

Unknown char before load mem — the unknown character preceding the load memory field.

Bytes 20–26:

Length of load memory — the load length.

Bytes 26–32:

Length of MC7 code — the length of the MC7 code.

This is the Request Download structure. It tells the PLC that a block download is about to begin, as in the following example:

In the diagram, the requested file identifier is _ for Complete Module, the block type is DB, the block number is 00001, and the target file system is P for Passive module. The filename is therefore _0A00001P, used to copy DB1 to or from the passive file system.

As with file reads and writes, the request uses a Job PDU. For Ack_Data, the Request Download structure is:

Its Parameter contains only a function acknowledgment. After the Request Download Job and Ack_Data complete, Download Block can begin.

Download block（0x1b）

The Download Block Parameter structure is:

We can see thatDownload blockofParametercontent is the same asrequest downloadoverlaps with the content of, but lacks bytes 18–32 compared with the latter（Length part、Unknown char before load mem、Length of load memory、Length of MC7 code）; the diagram above is the download block _0A00001P job request.

For an Ack_Data PDU, the Parameter structure is shown below:

Parameter contains only the function acknowledgment and status, while the additional Data structure contains the data length, unknown bytes, the data content, and its length.

A complete block download may require several requests, as shown below:

Download ended（0x1c）

The Download Ended Parameter structure is:

The preceding diagram showsDownload endedandDownload blockofParameterandRequest downloadofParametermatches the first part of, but lacks bytes 18–32（Length part、Unknown char before load mem、Length of load memory、Length of MC7 code）, meaning that the download has ended0A00001Pjob request.

For Ack_Data, the Download Ended Parameter structure is:

The response contains only a function acknowledgment, confirming the end of the _0A00001P download and completing the process.

Start upload（0x1d）

Start Upload begins an upload and is similar to Request Download. It must be understood as part of the complete upload flow: Start Upload, Upload, and End Upload together form one upload session.

The flow is:

With the overall flow established, we can examine Start Upload. Its Parameter structure is:

We can see thatStart upload structure andRequest Download has the same initial structure. The content above tells the PLC a filename whose identifier is _ (Complete Module), and the block type is0B（SDB）, and the block number is00000, and the target block's file system isA (Active embedded module), so the filename is_0B00000A

For an Ack_Data PDU, the structure is shown below:

Bytes 0–1:

Function: Start upload (0x1d) — the function declaration of Parameter/data.

Bytes 1–2:

Function Status — the function status: whether an error occurred, and whether the request goes through another retrieval block/file.

Bytes 2–4:

Unknown byte(s) in blockcontrol — all the unknown bytes inside blockcontrol.

Bytes 4–8:

UploadID — the ID of the file upload session.

Bytes 8–9:

Blocklengthstring Length — the byte length that follows the block length string.

Bytes 9–16:

Blocklength — the length of the complete upload block in bytes; it may be split across several PDUs.

Upload（0x1e）

When the PDU type is Job, Upload contains no Data. Its Parameter structure is shown below:

Bytes 0–1:

Function: Upload (0x1E), function-code status;

Bytes 1–2:

Function Status — the function status: whether an error occurred, and whether the request goes through another retrieval block/file.

Bytes 2–4:

Unknown bytes in blockcontrol: all unidentified blockcontrol bytes

Bytes 4–8:

UploadID — the upload session ID, which tells Step7 which upload session this is.

That is the JOB-type structure. When the PDU type is Ack_Data, Upload carries Data, and its Parameter is structured as follows:

Parameter contains only the function acknowledgment and status. The byte count in the additional Data depends on its data length. This structure matches Download Block.

End upload（0x1f）

At the end of an upload session, after all blocks have been uploaded, STEP 7 sends an End Upload Job. The PLC closes the session and returns an Ack_Data response.

The End Upload Parameter structure is:

The structure is simple: eight bytes total, with UploadID the largest field at four bytes.

When the PDU type is Ack_Data, its structure is:

The structure contains only a function acknowledgment. This completes the upload process.

PI-Service（0x28）

PI-Service means Program Invocation Service. It supports routine PLC changes to execution and memory state, including starting or stopping the control program and activating or deleting program blocks.

The PI-Service Parameter structure is:

Bytes 0–1:

Function: PI-Service (0x28) — the function code status.

Bytes 1–8:

Unknown bytes — unknown bytes.

Bytes 8–10:

Parameter block length — the length of the parameter block.

Bytes 10–12:

Parameter block — the parameter block.

Bytes 12–13:

String length — the string length of the PI service.

Bytes 13–22:

PI (program invocation) Service — the program invocation service name; see Appendix 2 for details.

If a service-call parameter is a block, the Parameter Block structure differs, as shown below:

The principal meanings in the diagram are:

Service name: _INSE Parameter: 0800001P [OB 1] Request: activate OB 1

The request result is shown below:

Function acknowledged; request succeeded

PLC Stop（0x29）

PLC STOP is essentially the same as PI-Service. Its Parameter structure is:

The main difference from PI-Service is that PLC Stop has no Parameter Block structure. Other structures, including Ack_Data, are the same:

Summary

The preceding sections introduced Job and ACK_DATA PDUs in S7Comm. The more complex UserData format is omitted because of its breadth and complexity; interested readers can consult other material. This is only an introduction to Job and ACK_DATA. UserData supports many operations, such asTIME functions、NC programming、CPU functions、Cyclic data、Securityand related values.

0x02 MODBUS Protocol

Modbus was introduced by Modicon, producing Modbus RTU and Modbus ASCII. Schneider Electric later（SchneiderElectric）acquired Modicon and introduced Modbus TCP in 1997.

In 2004, China's National Standardization Administration formally adopted Modbus as a national standard, beginning its contribution to Chinese industrial communication.

MODBUS is an application-layer messaging protocol at layer 7 of the OSI model, providing client/server communication between devices on different buses or networks. Since 1979, it has remained an industry standard that enables millions of automation devices to communicate.

MODBUS is a request/reply protocol providing services identified by function codes. A MODBUS function code is an element of the request or response PDU. This article does not cover transport, error detection, or the physical layer; it only introduces common function codes.

MODBUS function codes fall into valid, exception, and error codes. There are more than twenty valid codes, but common use primarily centers on1、2、3、4、5、6、15、16are the eight most commonly used, plus the special function codes 20 and 21 for General Reference Registers, which most Modbus devices do not provide.

I originally planned to cover MODBUS in depth, but the official documentation already does so, so I will not repeat it here.

Documentation download: see the link at the end English version:

Chinese version

This document explains Modbus function codes and their operation in detail. Interested readers can download and study it.

0x03 Example Analysis

Example 1: S7Comm Protocol Analysis

Challenge Description

Analyze anomalies in S7 traffic and find the flag in a malformed packet.

Solution

Open the file as shown below:

Because the challenge specifies S7, non-S7 traffic can be excluded:

There are too many packets to identify the PDU types directly, so export the group:

Use the following script to identify PDU types and counts:

#!/usr/bin/env python
#encoding=utf-8

import pyshark

captures = pyshark.FileCapture("cotp.pcapng")
pdu_types = {}
for c in captures:
    for pkt in c:
        if pkt.layer_name == "cotp":
            if hasattr(pkt, "type"):
                type = pkt.type
                if type in pdu_types:
                    pdu_types[type] += 1
                else:
                    pdu_types[type] = 1
print(pdu_types)

Three PDU function codes are present: 0x0F 3,696 times, 0x0E 12 times, and 0x0D 8 times.

COTP was not introduced above, but the difference is largely one of function and transport format. The three function codes are:

PDU Type: DT Data (0x0f)：

Primarily used for data transfer; Parameter includes a Data structure

PDU Type: CR Connect Request (0x0e)

Primarily used to initiate a connection request

PDU Type: CC Connect Confirm (0x0d)

Primarily used to acknowledge a connection

By frequency, function codes 0x0D and 0x0E are most likely to contain the flag, so analyze those two:

Notice:

Each connection request has a corresponding acknowledgment. The first three packets contain three consecutive requests, which is suspicious. Inspection shows:

The third packet contains meaningful data: NESSUS

No other packet contained meaningful data, so this string is the flag.

Example 2: Modbus Protocol Analysis

Challenge Description

No hints were provided; this was simply a protocol-analysis challenge.

Solution

Opening the file reveals:

The packet is malformed. Comparing it with a normal packet shows that its header and footer were altered, so use 010 Editor to repair them:

Normal pcap packet

Download the pcap file:

Remove the first three and last three bytes, then open the modified file:

The capture contains many protocols, but this article focuses only on Modbus—the flag is also in Modbus. Filter and export the Modbus packets by group, then use the following script to identify the function codes present:

#!/usr/bin/env python
#encoding=utf-8

import pyshark

captures = pyshark.FileCapture("modbus-ics.pcapng")
modbus_func_code = {}
for c in captures:
    for modbus in c:
        if modbus.layer_name == "modbus":
            if hasattr(modbus, "func_code"):
                type = modbus.func_code
                if type in modbus_func_code:
                    modbus_func_code[type] += 1
                else:
                    modbus_func_code[type] = 1
print(modbus_func_code)

Only function code 3 appears, in 274 packets. As noted earlier, the Modbus protocol uses1、2、3、4、5、6、15、16are the eight most commonly used. The following table briefly describes Modbus function codes:

Function code 3 reads registers, so finding the register content reveals the flag. Inspect the traffic:

Only register 1 changes continuously. Extract its values in transmission order and convert them to ASCII to obtain:

0x39,0x65,0x32,0x33,0x32,0x61,0x62,0x39,0x65,0x30,0x63,0x32,0x65,0x31,0x37,0x33,0x35,0x39,0x64,0x37,0x61,0x64,0x37,0x61,0x64,0x65,0x61,0x30,0x61,0x33,0x30,0x37,0x31,0x38,0x65,0x00,0x33,0x35,0x32,0x66,0x63,0x36,0x31,0x31,0x33,0x66,0x64,0x62,0x61,0x33,0x32,0x36,0x64,0x34,0x39,0x38,0x37,0x37,0x63,0x37,0x33,0x38,0x33,0x34,0x35,0x34,0x65,0x37,0x00,0x61,0x65,0x62,0x66,0x62,0x61,0x34,0x35,0x32,0x33,0x63,0x64,0x66,0x30,0x33,0x64,0x64,0x66,0x65,0x38,0x65,0x66,0x38,0x64,0x66,0x36,0x32,0x30,0x66,0x66,0x35,0x30,0x00,0x61,0x33,0x64,0x65,0x62,0x39,0x65,0x65,0x32,0x37,0x32,0x35,0x37,0x36,0x33,0x33,0x66,0x35,0x39,0x30,0x35,0x37,0x63,0x35,0x36,0x35,0x34,0x64,0x66,0x66,0x65,0x36

Use the following script to convert it to a string:

#!/usr/bin/env python
#encoding=utf-8
data = 0x39,0x65,0x32,0x33,0x32,0x61,0x62,0x39,0x65,0x30,0x63,0x32,0x65,0x31,0x37,0x33,0x35,0x39,0x64,0x37,0x61,0x64,0x37,0x61,0x64,0x65,0x61,0x30,0x61,0x33,0x30,0x37,0x31,0x38,0x65,0x00,0x33,0x35,0x32,0x66,0x63,0x36,0x31,0x31,0x33,0x66,0x64,0x62,0x61,0x33,0x32,0x36,0x64,0x34,0x39,0x38,0x37,0x37,0x63,0x37,0x33,0x38,0x33,0x34,0x35,0x34,0x65,0x37,0x00,0x61,0x65,0x62,0x66,0x62,0x61,0x34,0x35,0x32,0x33,0x63,0x64,0x66,0x30,0x33,0x64,0x64,0x66,0x65,0x38,0x65,0x66,0x38,0x64,0x66,0x36,0x32,0x30,0x66,0x66,0x35,0x30,0x00,0x61,0x33,0x64,0x65,0x62,0x39,0x65,0x65,0x32,0x37,0x32,0x35,0x37,0x36,0x33,0x33,0x66,0x35,0x39,0x30,0x35,0x37,0x63,0x35,0x36,0x35,0x34,0x64,0x66,0x66,0x65,0x36

ret=''
for i in data:
    if i == 0:
        ret+='\n'
    else:
        ret += chr(i)

print (ret)

This produces four lines of text:

9e232ab9e0c2e17359d7ad7adea0a30718e
352fc6113fdba326d49877c7383454e7
aebfba4523cdf03ddfe8ef8df620ff50
a3deb9ee27257633f59057c5654dffe6

The final three strings can be cracked directly as MD5 values:_love_this_game! The first value has three extra characters. Positions 19 through 24 are duplicated, so remove the duplicate.d7a; cracking the MD5 values givespcl_i The final flag is pcl_i_love_this_game!

Example 3: Industrial-Control System Operation 1

Requirement

• Adjust a valve opening from 35 to above 60 and keep it stable for more than three seconds.
• Completion time: 30 minutes

Known Conditions

• IP address of the industrial-control device or virtual machine.
• The device supports Modbus on port 502
• The PLC exposes these registers and coils: ** Status registers 0x0000–0x0009 for monitoring. ** Control registers 0x000A–0x0014 for control. ** Status coils 0x0000–0x0009 for monitoring. ** Control coils 0x000A–0x0014 for control. ** Additional registers 0x1000–0x1063 for submitting the flag.
• The valve opening uses status register 0x0008 and control register 0x0010.

Completion criterion

After success, registers 0x1000–0x1007 automatically contain eight nonzero values. Their ASCII representation is the flag.

Solution

The original environment is no longer available, so only a brief explanation is possible.

Nobody solved this challenge for a long time, so the organizers eventually provided a hint:

• One prerequisite for setting the value is that the system be in maintenance mode
• Control register 0x000B stores the operating mode: 3 means maintenance and 0 means run.
• To prevent accidental operation, the working mode is locked during normal runtime. Changing it first requires unlocking through a control coil.

The hint requires entering system maintenance mode. Testing showed that only coil 15 can be changed, so write Boolean true to coil 15, change operating mode from 11 to 3, then write 100 to controller address 16—another value above 64 also works. Restore normal mode by setting coil 11 to 0 and controller 15 to false. ASCII can then be read from 4096[+10], as shown below:

After conversion, the flag is 06E6B72D

Example 3: Industrial-Control System Operation 2

Requirement

• Enable the PLC alarm switch through normal communication;
• Read a PLC-generated log and determine the alarm time recorded in it.
• Completion time: 30 minutes.

Known Conditions

• IP address of the industrial-control device or virtual machine.
• The device supports Modbus on port 502.
• The PLC exposes these registers and coils: ** Status registers 0x0000–0x0009 for monitoring. ** Control registers 0x000A–0x0014 for control. ** Status coils 0x0000–0x0009 for monitoring. ** Control coils 0x000A–0x0014 for control. ** Status registers 0x0100–0x0163 for the alarm log.
• The control-coil address for the alarm-log enable switch is 0x000D

Completion criterion

After finding the alarm time, use it as the flag in the formatyyyy-mm-dd hh:mm:ss

Solution

This challenge builds on the preceding one. First enable logging by setting coil 13 to true. After fuzzing several registers, error values appeared at 256[+100], so read that address:

[18:25:10] [256] 25
[18:25:12] [257] 13
[18:25:16] [258] 84 T
[18:25:19] [259] 224
[18:25:23] [260] 92 /

[18:25:26] [261] 115 s
[18:25:29] [262] 119 w
[18:25:32] [263] 105 i
[18:25:34] [264] 116 t
[18:25:37] [265] 99 c
[18:25:39] [266] 104 h
[18:25:41] [267] 32 space
[18:25:44] [268] 49 1
[18:25:46] [269] 51 3
[18:25:50] [263] 105 i
[18:25:56] [270] 49 1
[18:25:59] [271] 32 space
[18:26:02] [272] 116 t
[18:26:06] [273] 114 r
[18:26:08] [274] 105 i
[18:26:10] [275] 112 p
[18:26:13] [276] 32 space
[18:26:15] [277] 111 o
[18:26:18] [278] 102 f
[18:26:20] [279] 102 f
[18:26:23] [280] 46 .
[18:26:26] [281] 0
[18:26:28] [282] 76 L
[18:26:33] [283] 0
[18:26:37] [284] 0
[18:26:39] [285] 0

Analysis of the preceding data shows190d54e05cPossibly a timestamp.

After splitting and reordering for endianness:‭5CE0540D‬, then convert to decimal ‭1558205453‬, converted to a Unix timestamp:

Submit flag: 2019-5-19 2:50:53

There was a third industrial-control challenge, but we ran out of time to calculate the checksum and did not obtain its flag, so it is omitted here.

0x04 Conclusion

S7 has no public official specification or standardized public terminology. My knowledge is limited, and this introductory article combines online material with my own understanding. Corrections are welcome. Industrial-control security also depends heavily on access to real, simulated, or emulated equipment. This article is only an introductory reference, and I hope it helps.

0x05 References

Siemens S7Comm Communication Protocol https://laucyun.com/3aa43ada8cfbd7eca51304b0c305b523.html#6-8

Siemens SIMATIC Step 7 Programmer's Handbook http://www.plcdev.com/book/export/html/373

S7 Communication (S7comm) https://wiki.wireshark.org/S7comm

wireshark dissector plugin sources http://gmiru.com/resources/s7proto/constants.txt

PI service names https://laucyun.com/static/upload/file/2018/01/PI_service_names.txt

Industrial Control System Security: Modbus Study Notes https://www.freebuf.com/articles/ics-articles/148637.html

Modbus TCP Traffic Analysis http://www.vanimpe.eu/2015/12/07/introduction-to-modbus-tcp-traffic/

0x06 Appendix I: Error-Code Meanings

0x07 Appendix II: PI Server Names

0x08 Modbus Abbreviations

0x07 Appendix III: Industrial-Control Captures and Modbus Resources

Industrial-control captures:

Link:https://pan.baidu.com/s/1lkr4bsoCJTACzVwzgHcgdQ Password: tp1u

Modbus resources: Link:https://pan.baidu.com/s/1Au0HBlGNHGN0JIzl5Iwf8g Password: gp3b