Inside S7comm: From ISO-on-TCP to PLC Memory

Description and use

S7comm protocol analysis on a Snap7 server uncovered unauthenticated memory writes, boundary enforcement, lack of CPU control implementation, and diagnostic enumeration of module IDs.

Problem

Investigate the low‑level behavior of the Siemens S7comm protocol, including session establishment, memory read/write, control commands, and diagnostic enumeration, to understand its security implications and implementation boundaries.

Outcome

The study revealed that the Snap7 emulator accepts unauthenticated memory writes, enforces memory boundaries, does not implement CPU control commands, and exposes module identifiers via SZL queries. It also clarified the layered protocol stack and negotiated parameters, providing a foundation for security assessment of real Siemens PLCs.

Workflow

• 1. Construct and send a COTP Connection Request to 127.0.0.1:102 with appropriate TSAP values.
• 2. Capture and verify the COTP Connection Confirm, noting TPDU size and reference fields.
• 3. Perform S7comm Setup Communication to negotiate maximum S7 PDU size and job counts.
• 4. Send a ReadVar request targeting DB3, offset 0, count 16 and capture the Ack‑Data PDU.
• 5. Send a WriteVar request to DB3, offset 0, size 16 with 0xFF bytes and verify success.
• 6. Attempt an out‑of‑range WriteVar to DB3, offset 65000, size 4 and observe the Out of range error.
• 7. Send a CPU control request (ROSCTR 0x07) to trigger STOP; note connection drop and lack of implementation.
• 8. Query SZL data (ID 0x0011, Index 0x0000) to retrieve module identification strings.
• 9. Document all packet captures and responses for analysis.

Evidence

The Snap7 server confirmed the operation: Write request, Area : DB3, Start : 0, Size : 16 --> OK

Source

Write request, Area : DB3, Start : 65000, Size : 4 --> Out of range

Source

The Snap7 target returned the request successfully. The response exposed module identification information: 6ES7 315-2EH14-0AB0 6ES7 315-2EH14-0AB0 Boot Loader

Source