DEV Community: 404Saint

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

404Saint — Mon, 21 Sep 2026 15:46:59 +0000

By RUGERO Tesla (@404Saint).

S7comm is one of those protocols that looks simple until you start following the conversation all the way down. At first, there is just a TCP connection to port 102, then TPKT appears, then COTP, then Siemens-specific connection parameters, then the S7comm session has its own negotiation, then a memory address becomes meaningful, then a single function code can turn a packet from a read request into a write operation. That was exactly what I wanted to investigate.

After working through Modbus TCP, EtherNet/IP, DNP3, BACnet, OPC UA, IEC 104, IEC 61850, and PROFINET, S7comm felt like the right protocol to finish this part of the research with. The earlier projects taught me to establish the architecture before touching the wire, but this time, I wanted to stay on the wire.

The laboratory target was a Snap7 server exposing a Siemens S7-style communication interface on TCP/102. I built the research client myself, constructed the protocol messages, captured the exchanges, and then started deliberately deviating from the expected conversation, and that ended up being the most interesting.

The Stack Before the First S7 Packet

Before looking at an S7comm packet, there is a small stack that needs to be understood.

┌──────────────────────────────┐
│          S7comm              │
├──────────────────────────────┤
│           COTP               │
├──────────────────────────────┤
│        TPKT / RFC 1006       │
├──────────────────────────────┤
│            TCP               │
├──────────────────────────────┤
│            IP                │
├──────────────────────────────┤
│         Ethernet             │
└──────────────────────────────┘

The TCP endpoint is normally port 102.

TPKT provides the ISO-on-TCP framing. COTP provides the transport session semantics above it. S7comm then uses that established channel for Siemens-specific application services. That matters during research because an apparently simple S7comm exchange can actually contain several different state machines. I started with the COTP connection because it was the lowest S7-specific piece I could directly control.

Establishing the Session

The first experiment constructed a COTP Connection Request manually.

The target was:

127.0.0.1:102

The destination TSAP represented the lab configuration's Rack 0, Slot 2:

Dst-TSAP: 0x0102
Src-TSAP: 0x0100

The client transmitted:

03 00 00 16
11 E0
00 00 00 01
00 C2 02 01 02
C1 02 01 00
C0 01 09

The response came back as a COTP Connection Confirm. The important part was seeing the layers line up in an actual capture rather than simply accepting what a high-level S7 library told me was happening.

Figure 1. Captured S7comm session establishment showing the TPKT/COTP connection sequence between the research client and Snap7 target.

The TPKT header reported a 22-byte frame.

The COTP TPDU changed from: 0xE0 for the Connection Request to: 0xD0 for the Connection Confirm. The reference fields were also visible directly in the exchange.

One detail that caught my attention was the TPDU size parameter: C0 01 09. This indicates a COTP TPDU size of 512 bytes. That number is easy to confuse with the S7 PDU size negotiated later. They are different parts of the communication model.

I also tested unusual destination TSAP values. A destination TSAP of 0x01FF was accepted by the Snap7 target. In the lab's Siemens-style interpretation, that corresponds to Rack 7, Slot 31.

Another unusual value, 0x0F02, was also accepted. That result is useful, but only within the boundaries of the experiment. The Snap7 server accepting those values does not establish that a physical Siemens PLC would accept the same combinations. At this point, the transport session existed and the actual S7 conversation had barely started.

Teaching the PLC How We Want to Talk

Once the COTP session was established, the next step was S7comm PDU negotiation. This was where the protocol started becoming much more interesting. The Setup Communication exchange negotiated a maximum S7 PDU size of: 480 bytes. The session also reported one parallel calling job and one parallel called job.

The negotiated value was visible directly in the response rather than being inferred from the later packets.

Figure 2. S7comm Setup Communication followed by a ReadVar request targeting DB3.

The next request used the ReadVar service:

ROSCTR: 0x01
Function: 0x04

The variable specification identified an S7-Any pointer.

The target was:

Area:      DB
Area ID:   0x84
DB number: 3
Offset:    0
Count:     16

The server returned an Ack-Data PDU with: Return code: 0xFF and 16 bytes of data.

The lab DB3 contents were:

01 01 01 01 01 01 01 01
01 01 01 01 01 01 01 01

This was the first point where the protocol stopped looking like an abstract collection of headers, because now I had a memory model. I could specify an area, a DB number, an offset, and a length. The PLC-style target would interpret those fields and return the corresponding data and that made the next question fairly obvious.

What happens when the operation changes from reading memory to modifying it?

Reading Was Only the Beginning

The S7comm WriteVar service uses function: 0x05

For the first write experiment, I targeted DB3 at offset zero and supplied 16 bytes of 0xFF, and the request was accepted. The response returned: 0xFF for the write item.

The Snap7 server confirmed the operation:

Write request, Area : DB3, Start : 0, Size : 16 --> OK

In this laboratory configuration, there was no additional authentication step protecting that memory write. That is an important observation, but it needs to be scoped correctly. This demonstrates unauthenticated memory modification against the Snap7 target used in the lab. It does not establish that a particular physical Siemens PLC would accept the same request under the same conditions.

Figure 3. Wire-level validation of the WriteVar experiments, including the successful DB3 write and subsequent boundary-testing request.

I then moved the write far outside the DB boundary. DB3 was 1024 bytes. The next request targeted offset: 65000 and the server rejected it.

The response returned: 0x05 and the server reported:

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

This was a useful contrast. The same service that allowed a valid write also enforced the memory boundary when the requested address was outside the configured DB. So the experiment wasn't simply “send WriteVar and everything works.” There was an actual implementation boundary and that becomes important later.

Trying the Control Plane

The next experiment moved away from ordinary memory access.

S7comm UserData uses: ROSCTR: 0x07 among other functions. I constructed a CPU control request intended to exercise the PLC STOP control path and the request was transmitted to the Snap7 server. There was no successful response. Instead, the connection was dropped. The important result here is what the experiment did not prove. The packet was successfully constructed and transmitted but the Snap7 demo server did not implement the requested CPU control function.

That means the experiment demonstrated the structure and transmission of the control-plane request, along with the emulator's implementation boundary. It did not demonstrate that a physical Siemens PLC would enter STOP as a result. That is easy to lose when packet-level research gets compressed into a headline.

Asking the PLC About Itself

After reading and writing memory, I moved into S7 diagnostics. S7comm UserData provides access to System Status List information, commonly referred to as SZL data.

The first query used:

SZL ID: 0x0011
Index: 0x0000

The Snap7 target returned the request successfully.

The response exposed module identification information:

6ES7 315-2EH14-0AB0
6ES7 315-2EH14-0AB0
Boot Loader

Figure 4. SZL UserData exchanges used to enumerate module-identification information from the simulated S7 target.

This is where diagnostic enumeration becomes interesting from a security perspective. A protocol does not need to provide an obvious “enumerate device” command to expose useful information. If diagnostic services can return module identifiers, firmware information, hardware details, or other system metadata, those services become part of the information-disclosure surface.

I tested another SZL identifier: 0x0111 but this time the target did not provide the requested object. The response indicated that the object was unavailable, matching the Snap7 server's own NOT AVAILABLE result.

Again, the implementation boundary matters. The absence of a response for this identifier does not tell us what every Siemens CPU would do. It tells us what this implementation did when presented with the request.

What Happens When We Ignore the Conversation's Rules?

This was the point where the research became much more interesting.

By now, the expected session flow was familiar:

TCP
  ↓
COTP CR / CC
  ↓
Setup Communication
  ↓
S7comm services

So I decided to remove one of those steps. Instead of establishing COTP, negotiating the S7 PDU parameters, and then issuing a ReadVar request, I established the COTP session and immediately sent the S7comm read. No Setup Communication, and the Snap7 server responded. The ReadVar operation returned live DB3 data.

Figure 5. Phase 5 capture showing the state-manipulation and held-open session experiments against the Snap7 target.

That was one of the most interesting findings in the entire project. The expected protocol sequence existed conceptually, but the implementation did not enforce it for this read operation.

The packet capture made the sequence very clear:

COTP connection
      ↓
ReadVar
      ↓
Setup Communication

The S7comm service arrived before the negotiation that was supposed to precede it. At this point, I stopped asking what the protocol was supposed to do and started asking what the implementation would actually tolerate.

The write experiment was different

I repeated the same idea with WriteVar. This time the server processed the request but returned: 0x05 for the write item. The subsequent fully negotiated read showed that DB3.0 remained unchanged. So there was no pre-Setup write bypass demonstrated here.

The results were asymmetric:

Operation	Before Setup Communication
ReadVar	Accepted
WriteVar	Reached service, rejected with `0x05`
CPU control	Not implemented by Snap7 target

That is useful than simply calling the implementation “vulnerable.” The state enforcement was incomplete for the tested read path, while the write path did not produce a successful modification.

Holding the Connections Open

The last experiment looked at resource handling. I created 50 sessions, completed the expected negotiation, then sent a ReadVar request with a TPKT length deliberately larger than the actual payload. Each socket was kept open for approximately 15 seconds. All 50 connection attempts were established and held. The server remained available after the sockets were released.

Connections attempted: 50
Successfully held open: 50
Failed before hold: 0

Total wall time: 15.01s
Server liveness: UP

That result does not demonstrate a denial of service. It demonstrates that the tested server tolerated the controlled connection load and malformed-length condition for the duration of the experiment without becoming unavailable. But that is still useful. Connection handling, timeout behavior, parser robustness, and state management are all part of the attack surface of an industrial protocol implementation.

And real Siemens products have historically had security advisories involving port 102, including connection exhaustion and other protocol-handling issues. Siemens has also published advisories for vulnerabilities affecting S7 communication over TCP/102. The lesson from the lab is therefore: Protocol state and resource handling deserve to be tested independently of application-level functionality.

The Emulator Boundary

This was probably the most important discipline in the whole project. A protocol emulator is incredibly useful. It gives me something I can repeatedly connect to, instrument, reset, and abuse without worrying about damaging production equipment. But it also creates a boundary around the evidence.

The experiments demonstrated that the Snap7 implementation:

accepted the tested unauthenticated WriteVar request against DB3
enforced the configured DB boundary for an out-of-range write
returned SZL 0x0011 identification data
processed a ReadVar request before Setup Communication
rejected the tested pre-Setup WriteVar operation
did not implement the tested CPU control request
remained available after the controlled 50-session experiment

But they did not demonstrate:

that a physical Siemens PLC would accept the same unauthenticated write
that a physical PLC would enter STOP from the constructed control request
that 50 held-open sessions constitute a denial-of-service condition
that every S7-300, S7-400, S7-1200, or S7-1500 behaves this way
that the tested Snap7 state-machine behavior represents Siemens' implementation

Keeping that boundary intact makes the research stronger. It is very easy to turn a packet capture into a claim about an entire product family, but I would rather have a smaller claim that I can actually defend.

From S7comm to S7CommPlus

Classic S7comm also provides a useful reference point for understanding why Siemens introduced additional security mechanisms into newer generations.

Modern S7-1200 and S7-1500 systems include configurable access protection and newer secure communication mechanisms. Siemens documentation describes protection levels that can restrict reading, writing, and CPU state changes, depending on the configured access level.

Siemens has also documented TLS-based secure PG/HMI communication in newer firmware and TIA Portal environments. For example, its S7-1500 communication documentation lists TLS 1.2 and TLS 1.3 support for newer firmware versions. The security model has therefore moved considerably beyond the classic S7comm environment. The protocol stack itself is still relevant, though.

TCP/102, TPKT, and COTP remain important pieces of the communication path. What changes is what happens above that foundation: session establishment, authentication, integrity protection, confidentiality, authorization, and the handling of protected operations. That atters because securing the application layer does not make the lower layers irrelevant. An attacker still needs to understand how the device establishes communication before they can meaningfully investigate what is protected above it.

There is also no single timeless “S7CommPlus” behavior that can be applied to every modern Siemens CPU. Protocol generations, firmware versions, configuration, and enabled communication paths matter. Siemens itself has documented the transition toward TLS-protected communication and has issued security advisories involving legacy communication mechanisms. One advisory, for example, describes weaknesses in legacy key protection and notes the introduction of individual device passwords and TLS-protected PG/PC and HMI communication in newer TIA Portal and CPU versions.

That makes the contrast more useful than simply saying that S7comm is “old” and S7CommPlus is “secure.” The interesting question is what security properties were added, where they were added, and which communication paths still depend on legacy mechanisms.

Security Characteristics

Area	Observation
Transport	S7comm laboratory communication used TCP/102 with TPKT and COTP
Session establishment	COTP CR/CC exchange exposed TSAP and reference parameters
PDU negotiation	Setup Communication negotiated a 480-byte S7 PDU
Memory access	ReadVar successfully accessed DB3 in the Snap7 lab
Memory modification	WriteVar successfully modified DB3 without authentication in the tested configuration
Bounds enforcement	Out-of-range DB3 write was rejected with `0x05`
Diagnostics	SZL `0x0011` returned module identification data
State enforcement	Snap7 accepted ReadVar before Setup Communication
Write state handling	Pre-Setup WriteVar did not successfully modify memory
CPU control	Tested UserData control request was not implemented by Snap7
Resource handling	50 held-open test sessions did not make the Snap7 target unavailable
Modern security contrast	Newer Siemens platforms provide configurable access protection and secure communication mechanisms

This result is a much clearer picture than I had when I started. S7comm is not simply “TCP port 102.” It is a layered conversation with its own transport setup, session negotiation, memory model, diagnostic services, and state assumptions. And once those assumptions become visible on the wire, they become testable.

Closing the Loop

The most satisfying part of this research was not finding one magic packet. It was watching the protocol reveal itself one layer at a time. First, a COTP connection, then a negotiated PDU, then a memory read, then a write, then diagnostics, then deliberately breaking the expected order and watching the implementation decide what it would tolerate.

After IEC 104, IEC 61850, and PROFINET, S7comm felt like the natural place to finally cross the boundary I had been preparing for throughout the series.

Research Repository

The complete laboratory, research notes, scripts, packet captures, and screenshots are available in the industrial-protocol-labs repository:

https://github.com/404saint/industrial-protocol-labs/tree/main/s7comm-research

The experiments were performed against a local Snap7-based laboratory target. They should not be interpreted as evidence of identical behavior on physical Siemens PLCs.

Reproducing PROFINET in the Lab: Discovery, AR Establishment, and Cyclic RT Boundaries

404Saint — Sat, 12 Sep 2026 03:29:25 +0000

By RUGERO Tesla (@404Saint).

I approached this research with the same general workflow I have used for the other industrial protocols in my lab. Start with the architecture, identify a usable implementation, reproduce the visible protocol behavior, inspect the traffic, and then move toward security-relevant experiments. PROFINET made that process more complicated than I expected.

The first challenge was getting the laboratory into a useful state. I spent a considerable amount of time working through Linux namespaces, virtual interfaces, routing, and the behavior of the available open-source implementation. Once the environment was working, the next challenge appeared: some parts of PROFINET were easy to observe, while other parts depended on controller/device behavior that the available stack did not fully expose. That changed the shape of the research.

I could still examine discovery, application-relation traffic, cyclic Real-Time framing, and crafted Layer 2 inputs. I simply had to be more careful about what each experiment actually established.

The goal of this project became straightforward:

Build a reproducible PROFINET laboratory, examine its observable protocol surfaces, and document the point where packet construction, implementation output, and verified endpoint behavior stop answering the same question.

Laboratory Scope

The laboratory used Linux network namespaces to isolate the controller and device sides of the experiment. The main implementation was p-net, supported by custom Python and Scapy-based harnesses, packet captures, and Wireshark/TShark analysis.

The work followed five phases:

DCP and LLDP discovery
DCE/RPC application-relation traffic
Cyclic Real-Time frame analysis
Layer 2 traffic generation, netload, and malformed inputs
A specification-driven review of PROFINET security mechanisms

The first four phases involved direct laboratory experimentation. The final phase connected those observations to PROFINET’s historical Security Class model and newer secure application mechanisms.

The Protocol Surfaces

Before working with the captures, I needed a practical model of how the main protocol components fit together.

Controller / Engineering System
              |
              | DCP and LLDP
              v
     Device identity and topology
              |
              | DCE/RPC
              v
     Application Relationship
              |
              | AR and IOCR configuration
              v
       Cyclic Real-Time I/O
              |
              v
       Process data and state

DCP provides Layer 2 discovery and configuration functions. LLDP contributes neighboring-device and topology information. DCE/RPC over UDP port 34964 carries acyclic application-relation traffic, including structures associated with AR and IOCR configuration. Cyclic Real-Time communication uses PROFINET’s EtherType, 0x8892, and carries process data directly over Ethernet.

These components are connected. Discovery identifies a device, but discovery alone does not create a cyclic I/O relationship. AR-related traffic has meaning within the context of a controller/device relationship. A cyclic RT frame can have a recognizable layout, but its acceptance still depends on endpoint state and implementation behavior. That relationship between architecture and packet meaning guided the rest of the research.

Evidence and Interpretation

I kept three forms of evidence separate throughout the experiments.

✔ The packet captures established things such as EtherTypes, MAC addresses, UDP ports, DCE/RPC fields, frame IDs, payload lengths, timing, and whether responses appeared.

✔ Application output added information about discovery results, parsed structures, reported state, and local transmission behavior.

✔ Security conclusions were then drawn from those observations, with care around what remained unverified. For example, a captured crafted frame proves that the frame reached the capture point. It does not tell me whether the target accepted it, rejected it, ignored it, or processed it in some other way.

That sounds obvious, but it becomes easy to lose track of when a script reports a successful send and the capture looks exactly like the frame that was intended.

Phase One: DCP and LLDP Discovery

The first phase established the identity and Layer 2 visibility of the device under test. The p-net device was placed in a separate namespace and queried from the controller side using DCP Identify traffic. The response exposed the station name, vendor and device identifiers, and active IP configuration.

The device reported:

Station name: rt-labs-dev
Vendor ID:    0x0493
Device ID:    0x0002
IP address:   192.168.1.20
Subnet mask:  255.255.255.0
Gateway:      192.168.1.1

The DCP traffic used EtherType 0x8892. The station-name information appeared under the Name of Station option, using option 0x02 and suboption 0x02. The result was useful immediately. I could identify the device and retrieve its configuration without relying on an IP-based management service.

Figure 1. DCP discovery audit showing the station name, vendor and device identifiers, and active IP configuration reported by the laboratory device.

Testing a station-name update

After discovery, I tried changing the station name to: tesla-pnet-node. The device continued reporting: rt-labs-dev. The update did not take effect. The behavior was consistent with runtime write protection, although the unchanged station name alone did not reveal the exact reason for the failure. This was a useful early reminder that a request and its intended effect are separate things. The request could be generated and transmitted successfully while the configuration remained unchanged.

LLDP topology information

LLDP provided another view of the same Layer 2 environment.

The captured information included:

Chassis ID:
P-Net Sample Application  12345 Abcdefghijk    007                  3 V  0  2  0

Port ID:
port-001.rt-labs-dev

System Name:
p-net IO-Device

TTL:
20 seconds

The LLDP frames used EtherType 0x88CC and the standard LLDP multicast destination: 01:80:c2:00:00:0e. The TTL represented the validity lifetime of the advertised information. I treated it as an information lifetime rather than assuming it described the transmission interval.

Figure 2. LLDP topology information observed from the laboratory device, including chassis identity, port identity, system name, and advertisement lifetime.

Security relevance

The discovery phase exposed several useful protocol surfaces:

Station-name identity
Vendor and device identifiers
IP configuration
Layer 2 device visibility
Neighbor and port information
Configuration-related operations

An actor with suitable Layer 2 access could use these mechanisms to learn about devices and their network context. The experiment did not establish a vulnerability by itself, but it showed how much information is available before any higher-level communication relationship is created.

Phase Two: DCE/RPC and Application-Relation Traffic

DCP discovery identifies a device. It does not establish the communication relationship required for cyclic I/O.

The second phase moved into DCE/RPC traffic over UDP port 34964. The custom harness constructed a connect request containing structures associated with:

ARBlockReq
IOCRBlockReq
AlarmCRBlockReq

The request used this ARUUID:

08019a8a-9f6f-4bb1-ad46-0da8698a5bc5

The observed DCE/RPC interface UUID was:

4a823108-a078-11d0-b21a-00a0241a673b

The packet capture showed a controller-to-device request followed by a device-to-controller response.

The capture independently established:

DCE/RPC version 4
Request packet type 0x00
Response packet type 0x02
Interface UUID
Opnum 122
Response association with the original request

The response contained:

dcerpc.request_in: 1

That field associated the response with the first request in the capture.

Figure 3. DCE/RPC request and response observed during the application-relation experiment over UDP port 34964.

I also captured the broader exchange to examine the surrounding traffic and the sequence reported by the implementation.

Figure 4. Expanded view of the DCE/RPC application-relation exchange and associated traffic observed during the laboratory handshake.

AR-related structures and state progression

The application output provided additional context for the AR-related blocks and reported a state sequence resembling:

IDLE
  → CONNECT
  → PARAM
  → CONFIG
  → APPL-READY
  → RUN

I treated this as implementation and test behavior. It helped explain what the application believed was happening during the exchange, but I did not present it as a universal wire-level state machine for every PROFINET implementation. TShark exposed the DCE/RPC fields, but it did not independently decode every individual PROFINET block field in the request and response. The block-level interpretation therefore came from the combined evidence of the harness, implementation output, and packet structure. That combination was enough to make the exchange useful for research, while still leaving some endpoint-side questions open.

Security relevance

The experiment exposed several questions relevant to application-relation security:

How are ARUUID values validated?
How does an implementation bind an AR to a device and controller?
How are duplicate or conflicting relationships handled?
What prevents replay or injection of relationship-management traffic?
How does the implementation behave when relationship resources are exhausted?
Which parts of the exchange receive authentication or integrity protection?

The ARUUID identified a communication relationship. It did not function as a credential. The observed exchange also did not demonstrate mutual cryptographic authentication at the DCE/RPC layer. Questions around injection, hijacking, replay, and resource exhaustion would require additional endpoint-side experiments and implementation-specific evidence.

Phase Three: Cyclic Real-Time Framing

The third phase examined cyclic Real-Time traffic over PROFINET EtherType 0x8892.

At this point, the available p-net configuration became a limiting factor. It did not produce a usable cyclic RT stream for the experiment I wanted to perform. Rather than leave the wire format unexplored, I built a separate traffic generator to examine frame structure, field placement, timing, and controlled payload changes.

The generator was deliberately limited in scope. It could construct and transmit candidate RT frames, but it did not establish an AR, negotiate IOCRs, maintain a process image, or demonstrate receiver-side acceptance.

Observed frame layout

The generated frames were 60 bytes long and followed this layout:

Ethernet destination       6 bytes
Ethernet source            6 bytes
EtherType                  2 bytes
Frame ID                   2 bytes
IO/application data       40 bytes
Cycle Counter              2 bytes
DataStatus                 1 byte
TransferStatus             1 byte

The capture contained:

Frame count:       515
Frame length:      60 bytes
EtherType:         0x8892
Frame ID:          0x8000
Application data:  40 bytes
Cycle Counter:     0x0000
DataStatus:        0x35
TransferStatus:    0x00

The relative PROFINET RT payload layout was:

Offset 0–1:   Frame ID
Offset 2–41:  IO/application data
Offset 42–43: Cycle Counter
Offset 44:    DataStatus
Offset 45:    TransferStatus

One representative frame contained:

Offset 14:  80 00
Offset 16:  01 59
Offset 18:  01 02 03 04
Offset 56:  00 00
Offset 58:  35
Offset 59:  00

Correcting the cycle-counter interpretation

One of the more useful moments in this phase came from checking the changing values against the actual field offsets. The sequential values initially looked like possible cycle-counter values. When I checked their position in the frame, they were inside the application-data region. The actual cycle-counter field remained: 00 00. The changing values belonged to application data.

This was a good example of why protocol analysis needs more than a changing byte sequence. Field position, length, surrounding structure, and protocol semantics all have to agree before a value can be assigned a meaning.

Controlled payload insertion

The generator inserted: FF 00 AA 55 into the application-data region. The special frames began at capture frame 346. The sequence appeared at absolute offsets 18 through 21, placing it inside application data rather than inside the cycle counter or status fields. The cycle counter remained unchanged. DataStatus and TransferStatus also remained unchanged.

Figure 5. Cyclic PROFINET RT analysis showing the observed frame structure, application-data changes, cycle-counter position, and status fields.

No PROFINET diagnostics or alarms appeared in the capture. All 515 packets used the same EtherType and Frame ID.

Timing observations

The experiment did not produce the expected 144-millisecond silence. The maximum observed packet gap was approximately: 33.972 ms. Around the controlled payload event, a normal interval of approximately 32 milliseconds was divided into shorter intervals surrounding the inserted frame. The capture therefore showed a timing change around the event, rather than a complete communication silence.

I used a watchdog model of: 32 ms × 3 = 96 ms as a laboratory assumption for discussing possible timeout behavior. That value was not treated as a universal PROFINET threshold, and the experiment did not demonstrate a watchdog transition.

Security relevance

The experiment demonstrated that a host with Layer 2 access can construct candidate PROFINET RT frames and place controlled values inside the application-data region. It did not establish that a real controller or device accepted those frames, modified its process image, triggered a diagnostic, or changed state.

The cycle counter and status fields provide continuity and communication-state information, but they do not provide cryptographic authentication. A capable Layer 2 actor can construct plausible field values. Whether an endpoint accepts those values depends on the implementation and the communication state surrounding the frame. PROFIsafe was outside the scope of this experiment.

Phase Four: Layer 2 Traffic, Netload, and Malformed Inputs

The fourth phase used an independent Scapy-based harness to generate three categories of Layer 2 traffic:

A netload-oriented burst
DCP-like station-name packets
Malformed RT-like frames

The goal was to observe the traffic-generation path and inspect the resulting captures. I also wanted to see whether the target produced any visible response, diagnostic, or recovery behavior.

Netload-oriented burst

The harness targeted approximately 15,000 packets per second. The actual measured transmission rate was approximately: 4,014.46 packets per second. The experiment transmitted 500 frames and recorded no kernel or interface drops. The resulting burst lasted approximately: 108.536 ms

The capture showed 499 packet intervals:

Minimum: 159.979 µs
Maximum: 1.708031 ms
Mean:    217.507 µs
Median:  205.040 µs

The intended rate was therefore not reproduced. The result told me more about the behavior of the traffic-generation path than about how a PROFINET endpoint would handle a genuine Class III load. That limitation was useful to record because the harness output alone could have made the experiment look more successful than the measurements supported.

DCP-like station-name packets

The harness transmitted three crafted station-name packets from a rogue source MAC address:

aa:bb:cc:dd:ee:ff

The packets claimed the station name:

rt-labs-dev

The payload included:

03 01 00 01 00 01 00 08 02 02 00 0b
72 74 2d 6c 61 62 73 2d 64 65 76

I refer to these as DCP-like station-name packets because they did not include the conventional DCP frame identifier FE FD. Calling them valid DCP Identify Responses would have gone beyond what the packet structure supported. The capture showed all three transmitted frames, but no subsequent response appeared.

Malformed RT-like frames

The harness also transmitted five frames using:

Frame ID: 0x00FF
Payload:  10 bytes

The frames appeared in the capture. No target-side diagnostic, rejection, recovery action, or state change was observed.

The complete capture contained:

500 netload-oriented frames
3 DCP-like station-name frames
5 malformed RT-like frames

All captured traffic used EtherType 0x8892. No IP, ARP, UDP, TCP, ICMP, or LLDP traffic appeared in the capture.

Figure 6. Phase 4 traffic audit showing the captured Layer 2 burst, DCP-like station-name packets, and malformed RT-like frames.

Security relevance

The phase demonstrated that crafted Layer 2 traffic could be generated and captured in the isolated laboratory. The captures did not reveal how the target parsed, rejected, ignored, or processed each frame. The harness labels described the intended test stages, while the PCAP established what was transmitted and visible at the capture point. That left the endpoint-side outcome unresolved.

Phase Five: Historical Security Classes and Newer Secure Mechanisms

The final phase connected the laboratory observations to PROFINET’s published security architecture.

The research question was:

How does the security architecture defined by PROFINET specifications address the discovery, application-relation, cyclic RT, and Layer 2 attack surfaces observed experimentally, and how has that architecture evolved from the historical Security Class 1/2/3 model toward newer secure application mechanisms?

The comparison covered:

DCP and LLDP discovery
DCE/RPC and application relations
Cyclic RT traffic
Layer 2 injection and malformed traffic
Netload robustness
Historical Security Classes 1, 2, and 3
Newer secure application mechanisms
Secure provisioning and device identity

Historical Security Classes

The historical model described three broad security classes:

Security Class 1: robustness
Security Class 2: integrity and authenticity
Security Class 3: confidentiality

This model provided a useful way to discuss increasing security requirements. It should, however, be kept separate from newer PROFINET security terminology.

Newer security architecture

Published PROFINET specification material describes newer mechanisms and architectural changes, including:

Secure-capable successors for protocols without secure variants
SXP over Layer 2
SXP over Layer 3
Secure provisioning
IDevID and certificate-based device identity
Secure SXP over TCP
Security-related GSDML application classes
SecureAccess
SecureRealtime
Updated robustness terminology

The newer architecture addresses particular communication and application requirements through more specific mechanisms.

The experimental observations can be mapped to those directions:

Observed surface	Experimental concern	Related security direction
DCP and LLDP	Device identity and topology exposure	Discovery hardening and controlled access
DCE/RPC and AR	Relationship establishment and trust	Secure-capable successors and authenticated mechanisms
Cyclic RT	Injection and freshness concerns	SecureRealtime-related protection
Layer 2 traffic	Injection, malformed input, and netload	Robustness requirements, segmentation, and access control
Device identity	Trust in device descriptions	IDevID, certificates, and secure provisioning
Historical security classes	Robustness, integrity, authenticity, and confidentiality	Newer security profiles and application classes

This phase remained specification-driven. The newer mechanisms were not implemented or validated in the laboratory.

What the Laboratory Established

The research established a reproducible environment for examining several PROFINET protocol surfaces.

The experiments demonstrated:

DCP discovery and device identity enumeration
Station-name and IP configuration visibility
LLDP chassis, port, and system information
DCE/RPC request and response behavior over UDP/34964
AR-related application output and reported state progression
Cyclic RT frame structure
Actual cycle-counter and DataStatus positions
Controlled application-data changes in generated RT frames
Transmission of crafted Layer 2 traffic
Measured behavior of the traffic-generation path
A specification-driven comparison with historical and newer security mechanisms

What Remained Outside the Laboratory’s Reach

Several questions required a more complete controller/device environment or a different implementation.

The experiments did not establish:

Universal PROFINET behavior across vendors
Complete controller/device interoperability
Endpoint acceptance of every crafted frame
Process-image modification
Target-side diagnostics or recovery
Successful Class III netload reproduction
Cryptographic protection of every observed legacy exchange
PROFIsafe behavior
Production-equivalent resilience
The behavior of a complete commercial PROFINET controller/device pair

These limits define the boundary of the results. They do not erase the discovery, packet analysis, implementation work, or corrections made during the research.

Conclusion

This study established a reproducible laboratory for examining PROFINET discovery, application-relation traffic, cyclic RT framing, and selected Layer 2 inputs.

The available open-source implementation supported meaningful wire-level analysis, but it did not expose enough controller/device behavior to verify every intended endpoint-side effect. The separate cyclic RT generator made frame construction, field placement, and timing measurable, but it could not substitute for a functioning PROFINET IO-Device relationship.

The most valuable part of the process was learning to recognize that boundary while the experiments were still in progress. A generated frame can look correct in a capture. A script can report a successful transmission. An implementation can print a state transition. Those observations become much more useful when I know exactly which part of the protocol they represent and which questions they leave unanswered.

The research therefore ended with a clearer understanding of both PROFINET and the laboratory itself. I could reproduce discovery behavior, inspect application-relation traffic, analyze cyclic RT fields, generate controlled Layer 2 inputs, and compare those surfaces with the protocol’s security architecture. I could also identify where further claims would require a more complete endpoint implementation. That is, to me, a meaningful result for protocol security research.

The protocol remains the subject. The implementation is the instrument. Sometimes the instrument exposes a complete interaction. Sometimes it gives only a partial view. The researcher’s job is to understand what the instrument can establish, preserve the evidence, and avoid turning an intended experiment into a claim that the laboratory never demonstrated.

Key Takeaways

DCP and LLDP expose useful device identity and topology information at Layer 2.
DCP discovery does not establish the application relationship required for cyclic I/O.
DCE/RPC traffic over UDP/34964 provides an observable surface for examining AR-related communication.
An ARUUID identifies a communication relationship but is not a credential.
Cyclic RT frame construction does not prove endpoint acceptance or process-image modification.
Changing values inside a frame does not make those values the cycle counter. Field offsets and protocol semantics must agree.
The observed RT cycle counter remained 0x0000, while changing values were located inside application data.
The netload experiment measured the limits of the traffic-generation path rather than reproducing a complete Class III resilience test.
DCP-like and malformed frames were captured, but target-side processing was not established.
Historical Security Classes 1, 2, and 3 should be separated from newer PROFINET security terminology.
Packet captures, application output, and specification material answer different parts of the research question.
A completed protocol study does not need to produce an exploit in every phase.
Understanding what the laboratory can and cannot prove is part of the research result.

Reproduce the Research

The complete laboratory setup, research notes, custom scripts, packet captures, and supporting material are available in the repository below. If you want to go beyond the observations in this article, the repository is the place to start reproducing the experiments yourself.

Repository: https://github.com/404saint/industrial-protocol-labs/tree/main/profinet-research

IEC 61850 Security Research: From SCL and MMS to GOOSE, Sampled Values, and the Process Bus

404Saint — Tue, 01 Sep 2026 11:55:08 +0000

By RUGERO Tesla (@404Saint).

IEC 61850 is another one of those protocols that becomes more interesting the deeper you go.

At first glance, it looks like another industrial protocol to dissect: identify the transport, decode the messages, enumerate the data model, and look for places where authentication or authorization is missing and that description turns out to be inadequate.

IEC 61850 is an ecosystem of communication models rather than a single protocol. MMS operates over the station bus and provides a comparatively conventional client/server interface. GOOSE and Sampled Values operate directly over Ethernet and introduce an entirely different set of assumptions around multicast, timing, state, sequencing, and data integrity. That difference became the central theme of this research.

I spent several days building an isolated IEC 61850 laboratory around libIEC61850, examining SCL configuration, MMS sessions, control operations, GOOSE, Sampled Values, and process-bus behavior. The work combined packet captures, custom Python tooling, native library examples, malformed-input testing, and direct observation of the simulated IEDs. There was also an unexpected historical component.

During the research, Parker McCauley pointed me toward Bruce Muschlitz, a former UCA conformance-testing participant, with a simple instruction:

Ask Bruce about the UCA decision dart board.

That conversation eventually led to an older 9-2LE Sampled Value capture, a legacy Excel visualization tool, and several observations about how real conformance testing used to be performed. So this article is both a protocol-security study and a record of how the investigation evolved.

1. Establishing the IEC 61850 Architecture

Before touching packets, I wanted a clear model of what I was actually testing.

The laboratory was divided conceptually into three communication areas:

                    IEC 61850 Laboratory
                           │
          ┌────────────────┼────────────────┐
          │                │                │
          ▼                ▼                ▼
       SCL /          Station Bus       Process Bus
   Configuration          │                │
                          │          ┌─────┴─────┐
                          │          │           │
                         MMS       GOOSE         SV
                          │          │           │
                       TCP/102    Ethernet     Ethernet

The difference matters because MMS and the process-bus protocols do not provide the same security boundaries. MMS uses ISO-on-TCP and exposes an application-layer model containing logical devices, logical nodes, data objects, and control points. GOOSE and Sampled Values are much closer to the wire. They are Layer 2 Ethernet protocols identified by EtherTypes rather than TCP or UDP ports.

That immediately creates different questions for a security researcher.

For MMS:

What can a client discover?
Can it establish a session anonymously?
What objects are exposed?
Which operations require authorization?
Are control operations protected?

For GOOSE and SV:

Who is allowed to publish?
How is publisher state represented?
How are sequence numbers interpreted?
What happens when frames originate from an unexpected source?
Can subscribers distinguish legitimate traffic from manipulated traffic?

The architecture primer established these questions before the experiments began.

2. SCL: The Configuration Is Part of the Attack Surface

The first formal phase examined the SCL configuration rather than immediately attacking the network protocols. IEC 61850 systems rely heavily on configuration describing IED capabilities, logical nodes, communication parameters, datasets, and relationships between devices.

That means some of the information required to understand the operational system may exist before a single application-layer packet is exchanged.

Figure 1. SCL configuration analysis from the laboratory. The configuration provided the structural baseline used for subsequent MMS and process-bus experiments.

This was important for the rest of the research because the later experiments were not performed against an abstract IEC 61850 endpoint. They were performed against a specific configured data model. The configuration therefore became the reference against which observed behavior could be interpreted.

3. MMS: Finding the Station-Bus Attack Surface

The next phase moved into MMS. The laboratory IED exposed MMS through ISO-on-TCP on port 102. Once a connection could be established, the interesting question was no longer whether TCP/102 was reachable. It was what the server was willing to disclose and execute after the connection. The first step was enumeration.

A custom Python harness was used to inspect the MMS information model and map the exposed hierarchy.

MMS
 │
 ├── Logical Devices
 │      │
 │      └── Logical Nodes
 │              │
 │              └── Data Objects
 │                      │
 │                      └── Data Attributes
 │
 └── Control Objects

Figure 2. MMS data-model enumeration performed against the laboratory IED.

The important observation was that the server exposed a meaningful operational model after session establishment. This matters because IEC 61850 does not merely expose registers in the way a simple legacy industrial protocol might. The client is interacting with a structured information model. Once that model is known, the next question becomes much more interesting: Which parts of that model can actually be manipulated?

4. MMS Control: Discovery Became Manipulation

The third phase focused on control operations. The initial attempt to write directly to a control value did not behave as a naive writable register would. The server rejected the operation because of its data-typing and control semantics. That failure was useful.

It demonstrated that a failed raw write does not necessarily mean the underlying control point is protected. IEC 61850 provides higher-level control services through the ACSI model, and the correct operation path produced a very different result.

The laboratory demonstrated that a properly constructed control operation could alter the simulated control state without an authentication mechanism being enforced by the tested configuration.

Figure 3. Laboratory observation of MMS control operations against the simulated IED.

This became one of the more important distinctions in the research:

A protocol implementation can correctly enforce its application semantics while still providing insufficient security authorization.

The server knew that the request had to be structured correctly. It did not necessarily know whether the requester should have been allowed to perform it. That is central to industrial protocol security.

5. Leaving TCP Behind: The Process Bus

At this point the research became considerably more interesting. MMS had given me a structured client/server interaction model but GOOSE and Sampled Values did not.

Both operate directly over Ethernet.

Ethernet
   │
   ├── 0x88B8 → GOOSE
   │
   └── 0x88BA → Sampled Values

The laboratory used Linux network namespaces and a virtual Ethernet bridge to create an isolated process-bus environment.

The basic topology was:

              br-processbus
              /            \
             /              \
        ns-ied1            ns-sub1
          │                   │
      veth-ied1           veth-sub1

The IED and subscriber could therefore exchange Layer 2 traffic without involving the physical network. That gave me a controlled environment for examining the actual Ethernet frames.

Figure 4. Process-bus traffic observed inside the isolated laboratory bridge.

This was also where the security model changed. There was no TCP session to authenticate. There was no client/server connection in the conventional sense. A subscriber observes Ethernet frames and interprets them according to the protocol semantics. That makes source identity, state numbers, sequence numbers, timing, and cryptographic protection much more important.

6. GOOSE State Is More Than Payload

GOOSE frames contain state and sequencing information that allows subscribers to reason about publisher behavior.

Among the fields examined were:

stNum
sqNum
TAL

stNum represents the state number while sqNum tracks sequencing within a state.

The Time Allowed to Live value provides another important piece of information about the expected timing behavior of a message. These fields are not merely metadata. They influence how a subscriber interprets the stream. That means manipulating them can potentially affect the subscriber's view of system state even when the underlying payload appears structurally valid. The research therefore moved from passive dissection into controlled anomaly injection.

7. GOOSE and SV Injection

The fifth phase tested how the process-bus environment reacted to deliberately manipulated traffic.

The experiments included:

unauthorized source MAC addresses;
extreme stNum values;
sequence-number manipulation;
quality-field manipulation;
Sampled Value frequency anomalies.

Figure 5. Controlled GOOSE state-number manipulation using an unauthorized source.

The purpose was not to demonstrate a production attack. The laboratory was used to determine how the simulated protocol participants interpreted abnormal frames. A structurally valid frame can therefore become interesting from a security perspective even when the Ethernet frame itself is perfectly ordinary.

7.1 Quality Metadata

One experiment modified the quality information associated with the transmitted measurement.

Figure 6. Controlled quality-field manipulation during process-bus testing.

This illustrates an important property of industrial telemetry: The numerical value is only part of the information being transmitted. A measurement may be accompanied by metadata describing its quality or validity. An attacker who changes the metadata does not necessarily need to modify the numerical value itself to influence how downstream systems interpret the measurement. That creates a useful difference between: Value integrity + Metadata integrity. They both matter.

7.2 Sampled Value Frequency

The same principle appeared in Sampled Values. Sampled Value streams are time-dependent. Their usefulness depends not only on the numbers being transmitted, but also on the temporal characteristics of the stream.

One controlled experiment introduced a frequency mismatch into the SV traffic.

Figure 7. Controlled Sampled Value frequency anomaly observed during the process-bus experiment.

This became particularly interesting later, when I began studying the historical 9-2LE material provided by Bruce Muschlitz.

8. The Unexpected Detour: A Conversation With UCA History

The IEC 61850 research took an unexpected turn before the formal security work was finished. Parker McCauley had commented on one of my research updates and, after seeing IEC 61850 in the list, told me, "Good luck on IEC 61850." When I replied that I was diving into GOOSE and MMS and would bring PCAPs, he suggested I contact Bruce Muschlitz and ask about the UCA decision dart board. And I did.

Bruce explained that he had worked in UCA conformance testing and that one of his major contributions involved the initial accreditation of testers. One detail immediately caught my attention. A significant part of that accreditation process involved manually inspecting PCAP logs to verify that testers were generating the correct stimulus and correctly interpreting the device-under-test response. There was no sophisticated automated pipeline doing the work for them.

And Bruce had built an Excel-based tool to visualize Sampled Value data because raw packet streams were not particularly useful for understanding waveform behavior.

He eventually sent me two historical artifacts:

Template_SV_viewer_rev4p0.xlsm
Sample240.pcap

That changed the direction of one part of the research.

9. Reconstructing a Legacy 9-2LE Sampled Value Analysis Workflow

The Excel tool was designed specifically around the fixed dataset structure of IEC 61850-9-2LE. Rather than simply opening the spreadsheet and treating it as a black box, I decided to reproduce the relevant analysis path in Python.

The pipeline became:

Sample240.pcap
      │
      ▼
Ethernet
      │
      ▼
VLAN detection
      │
      ▼
EtherType 0x88BA
      │
      ▼
ASN.1 / BER
      │
      ▼
SV ASDU
      │
      ▼
0x87 seqData
      │
      ▼
9-2LE fixed dataset
      │
      ├── Ia
      ├── Ib
      ├── Ic
      ├── In
      ├── Va
      ├── Vb
      ├── Vc
      └── Vn

For the 9-2LE capture, the fixed dataset made the parsing problem unusually deterministic.

Each of the eight measurement channels occupies eight bytes:

4 bytes → measurement
4 bytes → quality

giving:

8 channels × 8 bytes = 64 bytes

The parser extracted the values, tracked smpCnt, and reconstructed the signals as time-series data. The result was much easier to understand than a terminal full of integer values. The three-phase relationships became visible. The frequency, the neutral channel became visible, and anomalies that would be easy to miss in a packet table became obvious when represented as waveforms.

10. Why Bruce Used Excel

There was an amusing practical lesson here.

My first instinct was essentially:

Why Excel?

Python, Scapy, Matplotlib and a few lines of code were enough to build a native analysis pipeline. Bruce's answer was much more practical. Many engineering workstations used for conformance testing were heavily restricted. Installing a new application could be difficult. Excel, however, was already there. That meant an Excel macro could be deployed to systems where installing a dedicated analysis application was not realistic.

Bruce himself admitted that Python would have been preferable if there had been a free choice. That was a useful reminder that engineering tooling is often constrained by the environment in which it has to operate, not by what would be technically elegant.

11. What the Historical Capture Revealed

The supplied Sample240.pcap became the baseline for the independent parser. The capture contained a 9-2LE Sampled Value stream with the fixed dataset structure described above.

The reconstructed measurements showed recognizable three-phase behavior and allowed the current and voltage channels to be viewed as continuous signals rather than isolated packet fields.

That difference is important because, Wireshark is excellent at telling you that a field contains a value.

It is much less useful for answering questions such as:

Is this waveform periodic?

Are the phases behaving consistently?

Is the frequency correct?

Is the neutral channel behaving as expected?

Did the signal suddenly become noise?

Bruce had made the same observation from a conformance-testing perspective. One of the common anomalies he encountered was simply bad input data: a source that was producing noise when it should have been producing a meaningful signal.

Another was using the wrong input frequency, such as 50 Hz where 60 Hz was expected. Those are not necessarily protocol parsing errors, they are measurement-integrity problems, and packet inspection alone can make them surprisingly difficult to see.

12. One Important Correction to the 9-2LE Parser

Bruce also caught an important limitation in my initial parser design. I had been treating the 0x87 tag as though it represented a universally fixed 64-byte payload. That is only appropriate when the 9-2LE fixed dataset is already known. It does not generalize to newer IEC 61869-9 implementations where dataset contents are declared through configuration.

He also pointed out that a frame may contain multiple 0x87 TLVs, particularly at higher sampling rates. That matters because a parser that simply searches for the first 0x87 tag and consumes 64 bytes is not a general IEC 61850 Sampled Value parser. It is a 9-2LE-specific parser. That difference is now explicit in the research. This is exactly the sort of implementation boundary that is easy to miss when working only from a single capture.

13. The Dataset Design Question

The historical discussion also exposed an interesting design trade-off. Bruce described an earlier idea involving a fixed dataset intended to make merging units and subscribers effectively plug-and-play.

The concept was attractive:

Merging Unit
     │
     │ fixed dataset
     ▼
Any compatible subscriber

The subscriber would already know what each position represented. The eventual direction taken by IEC 61869-9 instead required more reliance on dataset configuration, including information available through SCL. That saves bits on the wire but moves some complexity into configuration and interpretation.

It is a classic engineering trade-off:

Simpler wire format
        vs.
More flexible configuration

Neither choice is inherently a security vulnerability, but every additional layer of configuration and interpretation creates another boundary that security researchers and conformance testers need to understand.

14. What the Research Actually Demonstrated

After several days in the laboratory, the IEC 61850 attack surface looked considerably different from when I started. The research demonstrated that the protocol stack has several distinct security boundaries.

MMS

The laboratory showed:

session establishment without native identity authentication in the tested configuration;
structured information-model enumeration;
exposed control objects;
successful control execution without an enforced authentication boundary;
correct rejection of malformed or semantically invalid operations in some cases.

GOOSE

The experiments examined:

Layer 2 multicast delivery;
publisher state;
sequence tracking;
Time Allowed to Live;
unauthorized source behavior;
manipulated state numbers;
manipulated quality metadata.

Sampled Values

The research examined:

Layer 2 transmission;
ASN.1 BER structure;
fixed 9-2LE dataset parsing;
sample-counter continuity;
waveform reconstruction;
phase relationships;
frequency behavior;
quality metadata.

The most important conclusion is not that IEC 61850 is "insecure." That would be an unnecessarily broad claim. The more useful conclusion is that different parts of the IEC 61850 ecosystem rely on very different trust assumptions, and those assumptions need to be examined independently.

15. Protocol Integrity Is Not Measurement Integrity

One of the strongest lessons from the research was the need to separate two concepts.

Protocol integrity

EtherType
VLAN
ASN.1 / BER structure
ASDU structure
Dataset length
Sequence fields
Quality fields

Measurement integrity

Waveform continuity
Amplitude
Frequency
Phase relationship
Channel consistency
Neutral behavior

A frame can be perfectly valid from a protocol perspective while carrying a measurement that makes no physical sense. The inverse is also true. An unusual waveform does not automatically mean that the packet was maliciously modified. Equipment faults, bad configuration, synchronization problems, sensor problems, and capture artifacts can all produce unusual telemetry.

That became one of the central principles of this research:

A valid packet is not necessarily a trustworthy measurement.

16. What I Did Not Claim

There is a temptation in protocol-security research to turn every interesting observation into a vulnerability claim. I deliberately avoided doing that here. The laboratory used simulated IEC 61850 components and controlled packet injection. The GOOSE and SV manipulation experiments demonstrate how the tested environment responded to abnormal traffic. They do not establish that every commercial IED or merging unit will behave the same way. Likewise, the MMS observations apply to the specific libIEC61850 configuration used in the laboratory. The historical Sample240.pcap establishes a useful analytical baseline, but it does not represent every legitimate 9-2LE waveform. The research therefore treats implementation behavior, protocol behavior, and physical-system behavior as separate layers.

17. Why the PCAPs Matter

The PCAP files are not included merely because packet captures look impressive in a research repository. They are the evidence behind the observations.

For each major phase, the repository contains the corresponding capture alongside the analysis script and screenshots. That makes it possible to move through the research in the same direction I did. The screenshots provide a quick visual record, the PCAPs provide the raw evidence, the scripts provide the experimental mechanism, and the notes explain what the evidence means.

18. A Few Lessons From the Laboratory

The most useful lessons from this research were not individual packet fields.

Start with the architecture

Jumping directly into packets makes complex protocols harder to understand. The SCL model, communication planes, logical nodes, datasets, and service relationships provide the context required to interpret the packets correctly.

Treat different communication planes differently

MMS, GOOSE, and Sampled Values are not simply three encodings of the same protocol. They operate under different transport and trust assumptions.

Capture everything

A terminal output can tell you that something happened, but a PCAP can show exactly what happened on the wire.

Visualize telemetry

For Sampled Values in particular, numerical output is not enough, awaveform can reveal a problem that is almost invisible in a packet table.

Separate implementation behavior from specification behavior

A laboratory implementation can accept something that the specification does not intend, or reject something that a researcher expected to work. Both observations are valuable, but they should not be confused.

Preserve the ugly parts of the research

Some of the most useful observations came from things that initially did not work. The MMS connection problems, virtual-interface behavior, parser assumptions, and 9-2LE-specific limitations all became useful once they were understood. A reproducible research record should document those boundaries instead of pretending the experiment was perfectly linear.

19. Final Findings

The IEC 61850 laboratory produced several concrete observations:

SCL provides valuable structural context for interpreting the operational attack surface.
The tested MMS configuration allowed session establishment without an authentication boundary.
The exposed MMS information model could be enumerated and used to identify operational control objects.
Properly structured control operations could alter simulated control state without authentication being enforced by the tested configuration.
GOOSE operates directly over Layer 2 Ethernet, creating a fundamentally different security model from MMS.
GOOSE state and sequencing fields provide important context for subscriber behavior and therefore deserve security monitoring.
Controlled manipulation of GOOSE state and quality information demonstrated the relevance of metadata integrity, not just payload integrity.
Sampled Value analysis benefits substantially from waveform reconstruction rather than packet-level inspection alone.
9-2LE's fixed dataset makes lightweight parsing practical, but that assumption must not be generalized to newer IEC 61850 Sampled Value implementations.
Protocol validity and measurement plausibility are separate security properties.
Historical conformance-testing practice reinforces the value of PCAP inspection and visualization when validating industrial communication behavior.
The observations are specific to the laboratory implementation and configuration and should not be generalized to all IEC 61850 deployments.

20. Closing

IEC 61850 turned out to be exactly as difficult as I was warned. Not because the packets are impossible to decode, but because there is much more to the system than the packets. MMS introduces a structured application model. GOOSE introduces Layer 2 event communication and state tracking. Sampled Values introduce continuous telemetry where the meaning of a packet depends partly on what the signal looks like over time. SCL ties much of that behavior back to configuration, and security has to account for all of it.

The most useful result of the research was therefore not a list of malformed frames or unauthenticated operations. It was a better model of where trust actually exists. And perhaps the most unexpected part was discovering that the same discipline used in modern packet-level security research was already being applied years ago by engineers manually inspecting PCAPs for conformance.

Repository

The complete laboratory, research notes, scripts, PCAP captures, and supporting screenshots are available in the accompanying repository.

The laboratory was conducted entirely against locally controlled IEC 61850 simulation infrastructure. No production substations, IEDs, merging units, or operational power systems were targeted.

Acknowledgment

This research was partially informed by historical technical guidance from Bruce Muschlitz, formerly involved in UCA conformance-testing work.

Bruce provided the historical Template_SV_viewer_rev4p0.xlsm tool and Sample240.pcap capture, along with technical context concerning 9-2LE Sampled Values, merging-unit testing, waveform visualization, dataset design, and conformance-test PCAP analysis. The Python parser and visualization workflow used in this research were independently implemented from the supplied material. I am grateful for the opportunity to learn from that history.

IEC 60870-5-104 Security: From APCI State Activation to IEC 62351

404Saint — Tue, 25 Aug 2026 13:01:44 +0000

By RUGERO Tesla (@404Saint).

A packet-level security study of IEC 60870-5-104, combining protocol architecture, raw APCI/ASDU experimentation, implementation boundary testing, and a controlled comparison against IEC 62351 security mechanisms.

IEC 60870-5-104 is one of those protocols where understanding the security problem requires going below the usual “port 2404 is exposed” discussion.

A TCP connection is only the beginning. Before an ASDU is exchanged, the protocol establishes its own link state through APCI control frames. Once data transfer is active, numbered I-frames carry telemetry and commands, while S- and U-frames maintain the session and its state. That structure makes the protocol interesting to study from the wire level.

For this research, I built an isolated IEC 60870-5-104 laboratory around lib60870-C, wrote raw Python protocol harnesses rather than relying exclusively on a high-level IEC 104 client, captured the resulting traffic with Wireshark, and then compared the cleartext behavior against a separate TLS/mTLS security laboratory. The objective was not simply to demonstrate that IEC 104 is “insecure.” It was to determine where the security boundary actually exists at each layer, what the implementation enforces, what it does not enforce, and what changes when security extensions are introduced.

The complete research artifacts, including notes, scripts, PCAPs, and screenshots, are available in the iec104-research directory.

1. Starting With the Protocol: IEC 104 Before Security

IEC 60870-5-104 extends the IEC 60870-5 telecontrol family over TCP/IP. The protocol architecture separates the TCP transport from the IEC 104 application protocol and its APCI framing. (SIST E-Commerce)

At the wire level, an IEC 104 APDU begins with:

+--------+--------+-------------------------------+
|  0x68  | Length |       APCI / ASDU             |
+--------+--------+-------------------------------+

The APCI contains four control octets.

Those control fields determine whether the frame is an:

I-format frame : application information and ASDU payload
S-format frame : receive acknowledgements
U-format frame : link control such as STARTDT, STOPDT, and TESTFR

The distinction matters because a TCP socket does not automatically mean that IEC 104 application data can be exchanged. The IEC 104 state machine has to be activated first.

2. Phase 1 : APCI State Activation

The first research phase focused exclusively on the link state.

The laboratory target was: 127.0.0.1:2404 lib60870-C / cs104_server_no_threads. After establishing TCP connectivity, the session remained in the stopped state.I then transmitted the raw U-format activation frame: 68 04 07 00 00 00, which represents: STARTDT ACT. The server responded: 68 04 0B 00 00 00, or: STARTDT CON. The important observation was not the bytes themselves. It was what wasn't present. There was no identity negotiation, credential exchange, cryptographic challenge, or authentication step between TCP establishment and link activation.

The transition was effectively:

TCP Connected
      │
      ▼
   STOPPED
      │
      │ STARTDT ACT
      ▼
 STARTDT CON
      │
      ▼
DATA TRANSFER ACTIVE

The base IEC 104 protocol therefore provides the state transition mechanism, but not an authentication boundary.

The research notes document the complete U-format control set and additional state behavior, including TESTFR and STOPDT.

Figure 1. Wire-level observation of the IEC 104 link activation sequence during Phase 1.

This became the baseline for the rest of the investigation:

If link activation itself is unauthenticated, what can a client do once the channel reaches the data-transfer state?

3. Phase 2 : Moving From Link State to the ASDU Address Space

Once the link was active, the research moved into the ASDU layer. IEC 104 uses Information Object Addresses (IOAs) together with Common Addresses (CAs) to identify application data. The test harness therefore moved from U-format control frames to I-format ASDUs.

Several Type IDs were particularly relevant:

Type ID	ASDU	Purpose
`11`	`M_ME_NB_1`	Measured value, scaled
`45`	`C_SC_NA_1`	Single command
`100`	`C_IC_NA_1`	General Interrogation

One of the first things visible in the capture was that the server was not simply responding to individual requests. It was also producing cyclic telemetry.

For example:

RX | Type 11 | CA 1 | IOA 110 | 0xcc0300
RX | Type 11 | CA 1 | IOA 110 | 0xcd0300
RX | Type 11 | CA 1 | IOA 110 | 0xce0300

The payload changed monotonically, providing a simple observable representation of a live counter. The capture also demonstrated why IEC 104 research cannot be implemented as a simplistic send() → recv() exchange. Multiple APDUs can exist inside the TCP byte stream.

A client therefore needs to maintain an application-level stream parser capable of separating:

TCP Stream
    │
    ├── APDU
    ├── APDU
    ├── APDU
    └── APDU

Rather than assuming one socket read corresponds to one IEC 104 frame.

Figure 2. Captured ASDU traffic during telemetry and Information Object Address enumeration.

An invalid Common Address was also tested. The laboratory server did not terminate the connection when presented with CA: 9999. Instead, the request produced an IEC 104 response while the transport sequence continued. This was an implementation behavior worth recording because protocol error handling is often just as important as the normal path.

4. Phase 3 : What Happens When the State Machine Is Abused?

The third phase deliberately moved away from normal protocol operation.

Three areas were tested:

I-frames before STARTDT
I-frames after STOPDT
Manipulation of N(S) and N(R) sequence values

The first result was actually reassuring. An I-format frame sent before link activation caused the server to close the connection. Likewise, after: STOPDT ACT STOPDT CON attempting to send another I-frame resulted in connection termination rather than continued command processing. So the state machine itself was not completely permissive.

The implementation distinguished between:

STOPPED
    │
    └── I-frame → rejected

STARTED
    │
    └── I-frame → processed

The sequence-number behavior was more interesting. IEC 104 uses N(S) and N(R) to provide ordered transfer and acknowledgement. The standard specifies sequential progression of these counters. (iTeh Standards)

In the laboratory, however, the server accepted experimentally supplied forward jumps such as N(S) = 5000 and N(S) = 32767 without immediately resetting the connection. That does not mean that every IEC 104 implementation will behave this way. It means that this particular lib60870-C configuration demonstrated tolerance that deserved investigation.

The protocol defines sequence semantics. The implementation determines how strictly those semantics are enforced.

Direct Control Execution

The more consequential observation in Phase 3 involved Type ID 45, C_SC_NA_1. A direct Single Command was transmitted toward: IOA: 5001 with the laboratory actuator configured to represent a breaker-like control point.

The command was accepted without a preceding Select operation.

Client
  │
  │ Type 45 / IOA 5001
  │ Direct Execute
  ▼
RTU
  │
  └── State changed

This demonstrated that the tested configuration did not enforce Select-Before-Operate as a mandatory prerequisite for that control point.

That finding is configuration and implementation-specific, but its security implication inside the laboratory is straightforward: network reachability plus knowledge of the addressing scheme was sufficient to reach a control function.

Figure 3. Phase 3 testing of APCI state enforcement, sequence handling, and direct control execution.

5. Phase 4 : Testing the Parser Boundary

After understanding the normal protocol and control paths, I moved down toward malformed input. The objective was to determine how the implementation behaved when the bytes no longer represented well-formed IEC 104 traffic. Several boundary conditions were tested.

Invalid start octet

Instead of: 68, the frame began with: 99 . The connection was closed.

Exaggerated length

A frame advertised a much larger payload than the bytes actually transmitted: 68 FF ... The server waited for additional stream data until the socket timeout rather than processing an incomplete APDU.

Unsupported Type ID

A Type ID of: 255 was supplied. The server remained operational and continued transmitting valid telemetry.

Truncated ASDU

An incomplete application payload was supplied. Again, the process remained stable.

Illegal U-format direction

A client-originated confirmation frame such as STARTDT CON was tested where an activation request was expected. The server did not treat it as a valid state transition.

These tests produced an important distinction between security failure and parser robustness.The target did not crash during the malformed-input testing. That is a positive implementation property.

At the same time, some invalid inputs were silently discarded rather than producing explicit diagnostic responses.

Figure 4. Malformed APCI and ASDU boundary testing against the laboratory implementation.

The resulting picture was therefore more nuanced than simply calling the stack “vulnerable.” The implementation showed reasonable structural resilience while simultaneously exposing security weaknesses elsewhere.

6. The Security Boundary Was Not at APCI

After four phases, the architecture of the problem became much clearer. The IEC 104 link state machine provided protocol state. It did not provide identity. The ASDU layer provided application semantics. It did not automatically provide authorization. The sequence counters provided ordering. They did not provide cryptographic authenticity. And the parser correctly rejected a number of malformed structures. It still could not distinguish a legitimate master from an unauthorized one based on the base protocol alone. That distinction is critical in OT security.A protocol can be perfectly capable of answering:

“Is this frame structurally valid?”

without being capable of answering:

“Is this station authorized to send this command?”

7. Phase 5 : Introducing IEC 62351

The final research phase changed the security model rather than continuing to attack the cleartext implementation. A separate Python laboratory was created around a TLS-wrapped IEC 104 environment.

The cleartext baseline used: TCP/2404 while the secure environment used: TCP/19999 with mutual TLS. IEC 62351-3 provides security profiles for TCP/IP-based power-system protocols, including IEC 60870-5-104. IEC 62351-5 specifically addresses security for IEC 60870-5 and derived protocols. (IEC 61850)

The important conceptual change was:

CLEAR
------------------------------------------------

TCP
 │
 IEC 104
 │
 APCI
 │
 ASDU
 │
 Control


SECURED
------------------------------------------------

TCP
 │
 TLS / Authentication
 │
 IEC 104
 │
 APCI
 │
 ASDU
 │
 Control

Instead of trying to make APCI itself become an authentication mechanism, security is introduced around the communication channel and, where applicable, through application-layer security mechanisms. The newer IEC 60870-5-7 technical specification describes the security extensions that apply IEC 62351 mechanisms to IEC 60870-5-101 and IEC 60870-5-104.

8. Mutual TLS Changes the First Question

In the cleartext laboratory, the first meaningful exchange was:

TCP connection
      ↓
STARTDT ACT
      ↓
STARTDT CON

In the secure laboratory, a client first had to satisfy the TLS authentication boundary.
An unauthenticated client attempting to establish the secure channel received:

[SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED]
tlsv13 alert certificate required

That is a fundamentally different failure point. The unauthorized client does not reach IEC 104 link activation. It fails before the application protocol becomes usable. With a valid certificate, the secure channel was established using: TLS_AES_256_GCM_SHA384 and IEC 104 traffic subsequently operated inside that encrypted channel.

Figure 5. Secure laboratory client validating certificate-based authentication and the protected IEC 104 channel.

Figure 6. Secure laboratory server enforcing the TLS authentication boundary.

This also changed what passive packet capture could reveal. In the cleartext laboratory, the PCAP contains the actual IEC 104 structures.

A packet analyst can see:

STARTDT
Type ID
CA
IOA
Command values
Telemetry

Inside TLS, the network observer sees the transport conversation and TLS records rather than the IEC 104 application payload.

9. Encryption Alone Does Not Solve Authorization

This is where the final phase becomes more interesting. Encryption protects the channel. It does not automatically decide whether an authenticated station should be allowed to operate a particular control point. The secure laboratory therefore added an authorization layer.

The test client authenticated as: CN=scada-master and attempted to operate: IOA: 5001. The request reached the secure server, where the laboratory authorization logic evaluated the role mapping.

The result was:

Authenticated Session Established
        │
        ▼
Control Request: IOA 5001
        │
        ▼
Authorization Check
        │
        ├── Not permitted
        ▼
Access Denied

The server produced: 68 04 47 00 00 00 and the laboratory logged the operation as an RBAC violation. This produced an important contrast with Phase 3.

Cleartext laboratory

Reach port 2404
      ↓
STARTDT
      ↓
Send Type 45
      ↓
Control executed

Secured laboratory

Establish TLS
      ↓
Authenticate client
      ↓
Evaluate authorization
      ↓
Control request rejected

The two mechanisms therefore address different problems. Authentication asks who is communicating and Authorization asks what that identity is allowed to do.

IEC 62351-8 defines the role-based access-control component of the IEC 62351 security family, while IEC 62351-5 provides security mechanisms specifically for IEC 60870-5-derived protocols. (IEC Webstore)

10. Putting the Research Together

The six research notes can therefore be reduced to a fairly simple security model.

Layer	Research Question	Laboratory Observation
TCP	Can the endpoint be reached?	TCP/2404 accepted connections
APCI	Can the link be activated?	`STARTDT ACT/CON` without identity verification
ASDU	What application data exists?	Telemetry and IOA structures observable
Control	Can commands be issued?	Direct Type 45 execution observed
State	Does the implementation enforce protocol state?	Yes, for several tested transitions
Parser	Does malformed input crash the process?	No crashes observed
Security extension	Can communication be authenticated and protected?	mTLS blocked unauthenticated clients
Authorization	Can authenticated identities be restricted?	Laboratory RBAC rejected unauthorized control

This is the part of the research I found most useful. The cleartext implementation was not simply “bad.” It had a functioning protocol state machine. It handled several malformed inputs safely. It maintained sequence counters. It processed telemetry correctly. The problem was that protocol correctness and security authorization are different properties.

11. What the Packet Captures Added

The PCAPs were important because the conclusions were not based solely on application output. They provide a second layer of evidence alongside the Python harness output.

For example, Phase 1 can be reduced to actual bytes:

68 04 07 00 00 00
68 04 0B 00 00 00

While Phase 3 exposes the I-frame containing the tested command. Phase 5 then provides the contrast: the IEC 104 application payload is no longer directly visible to a passive observer because the communication is encapsulated inside TLS. That progression from raw APCI bytes to encrypted application traffic is really what the entire research series is about.

12. Building the Laboratory

The cleartext target was built from lib60870-C.

The basic environment was:

git clone https://github.com/mz-automation/lib60870.git
cd lib60870/c
mkdir build && cd build
cmake ..
make

The server used for the experiments was: cs104_server_no_threads

A second build layout was also used during the laboratory work:

cd ~/Desktop/iec104-lab/build
cmake ../lib60870/lib60870-C
make
./examples/cs104_server_no_threads/cs104_server_no_threads

Packet capture was performed directly against the loopback interface.

For the cleartext target:

wireshark -k -i lo -f "tcp port 2404"

and for the secure laboratory:

wireshark -k -i lo -f "tcp port 19999"

The captures were then retained as phase-specific PCAPNG artifacts.

The secure laboratory also generated its own local CA and server/client certificates, allowing the entire authentication experiment to remain inside the controlled research environment.

13. What I Would Take Away From This Research

There are several conclusions I would carry into an actual IEC 104 security assessment.

1. Start before the ASDU

Jumping directly into Type IDs and IOAs misses the protocol state machine. STARTDT, STOPDT, TESTFR, and the I/S/U distinction establish the context in which application traffic becomes meaningful.

2. Separate protocol behavior from implementation behavior

The standard defines the protocol semantics. The implementation decides how strictly those semantics are enforced. The sequence-counter observations and malformed-frame behavior are good examples.

3. Treat addressing as security-relevant

Once the Common Address and IOA structure becomes known, the application layer becomes considerably easier to reason about. Telemetry enumeration is therefore not merely an informational exercise.

4. Do not confuse encryption with authorization

TLS prevents passive observers from reading the IEC 104 payload and, with mutual authentication, establishes a cryptographic identity boundary. It does not by itself determine whether an authenticated station should be allowed to operate a particular breaker.

5. Test the whole path

The useful security boundary was not found in a single packet.

It emerged across:

TCP
 ↓
APCI
 ↓
ASDU
 ↓
IOA
 ↓
Control Function
 ↓
Authentication
 ↓
Authorization

That is why I structured the research as a sequence rather than a single packet-dissection exercise.

Conclusion

IEC 60870-5-104 is straightforward to understand once its layers are separated. TCP provides the transport. APCI provides framing, sequencing, acknowledgements, and link-state control. ASDUs provide telemetry and control semantics. But none of those layers, in the baseline laboratory implementation, established the cryptographic identity or authorization boundary required for secure operation.

That became visible from the first experiment. From there, the research progressed through telemetry enumeration, IOA discovery, direct command execution, sequence manipulation, malformed-frame testing, and finally the introduction of TLS and authorization controls. The result is not a claim that every IEC 104 implementation behaves exactly like the laboratory target. It is a demonstration of how to interrogate the protocol and its implementation systematically.

Start with the architecture. Move to the wire. Validate the state machine. Map the application layer. Test the boundaries. Then introduce the security controls and repeat the same observations. That helped in distinguishing that IEC 104 uses TCP/2404 and actually understanding where the protocol's security boundary begins and where it doesn't.

Research Artifacts

The complete laboratory is available in the industrial-protocol-labs repository.

The IEC 104 research directory contains:

iec104-research/
├── certificates/
├── notes/
├── pcaps/
├── screenshots/
└── scripts/

The research notes cover the architecture primer, four cleartext protocol/security investigations, the secure-extension contrast, and the complete laboratory reproduction procedure. All experiments were performed against isolated laboratory systems under my control. The observations above describe the tested lib60870-C configuration and the accompanying research environment; they should not be interpreted as universal behavior of all IEC 60870-5-104 implementations.

IEC 104 Before the Wire: Understanding Its Architecture, Framing, and Security Boundaries

404Saint — Thu, 20 Aug 2026 15:57:00 +0000

By RUGERO Tesla (@404Saint).

IEC 60870-5-104 (IEC 104) is the TCP/IP-based member of the IEC 60870-5 telecontrol family. It was designed to carry SCADA telemetry and control information across packet-switched networks, particularly within electrical power systems.

Before getting into raw packets, it is worth understanding how IEC 104 is structured, how its communication state is maintained, and where its security boundaries actually exist.

This is the map before we meet the protocol on the wire.

Protocol Stack

IEC 104 operates over TCP, commonly using port 2404.

Two protocol components are particularly important:

APCI : Application Protocol Control Information
ASDU : Application Service Data Unit

The APCI handles framing, sequencing, acknowledgments, and connection control.

The ASDU carries the actual telecontrol information.

+-------------------------------------------------------------+
| ASDU                                                        |
| Type ID | VSQ | COT | CA | IOA | Information Objects       |
+-------------------------------------------------------------+
| APCI                                                        |
| 0x68 | Length | Control 1 | Control 2 | Control 3 | Ctrl 4 |
+-------------------------------------------------------------+
| TCP / IP                                                    |
+-------------------------------------------------------------+

Every APDU begins with the 0x68 start byte, followed by a length field and four control bytes. The length represents the bytes following the length field, including the four control bytes and, when present, the ASDU. That fixed structure is the starting point for understanding IEC 104 traffic.

I, S, and U Formats

IEC 104 defines three APDU formats.

I-Format:

→ I-format frames carry application information and therefore contain an ASDU.

They also carry two sequence numbers:

N(S) : send sequence number
N(R) : receive sequence number

These allow communicating stations to maintain ordered transmission and acknowledgment state.

S-Format:

→ S-format frames are supervisory frames.

They do not carry an ASDU. Their purpose is to communicate receive acknowledgments independently of application data.

U-Format:

→ U-format frames handle connection-control functions.

Three important functions are:

STARTDT    Start data transfer
STOPDT     Stop data transfer
TESTFR     Test the communication relationship

This creates an important distinction: A TCP connection is not the same thing as an active IEC 104 data-transfer session.

The TCP connection establishes transport connectivity. IEC 104 then manages its own application-level communication state.

Inside the ASDU

When an I-format frame carries application data, the ASDU defines what that data means.

A simplified ASDU looks like this:

+-------------------------------+
| Type Identification            |
+-------------------------------+
| Variable Structure Qualifier   |
+-------------------------------+
| Cause of Transmission          |
+-------------------------------+
| Common Address                 |
+-------------------------------+
| Information Object             |
|   IOA + Information Elements   |
+-------------------------------+

✔ Type Identification

The Type ID determines the information type being transmitted.

Examples include:

M_SP_NA_1    Single-point information
C_SC_NA_1    Single command

✔ Variable Structure Qualifier

The VSQ indicates how many information objects are present and whether their addressing follows a sequential structure.

✔ Cause of Transmission

The COT provides context for why the ASDU is being transmitted.

Depending on the message, it can indicate events such as spontaneous transmission, interrogation responses, activation, activation confirmation, or termination.

✔ Common Address and IOA

The Common Address (CA) identifies the logical station or ASDU address.

The Information Object Address (IOA) identifies the individual information object within that address space.

Common Address
      |
      +---- IOA 1
      +---- IOA 2
      +---- IOA 3
      +---- IOA 4

Together, these fields provide the addressing model through which IEC 104 identifies telemetry and control points.

Where the Security Boundary Actually Sits

The base IEC 104 protocol does not itself provide the cryptographic security properties associated with modern secure application protocols.

That includes mechanisms such as:

cryptographic peer authentication
confidentiality
cryptographic integrity protection

Historically, this placed significant responsibility on the surrounding network architecture.

             Network Security Boundary

      +---------------------------------------+
      |                                       |
      |       IEC 104 Environment             |
      |                                       |
      | Master <==== TCP/2404 ====> RTU       |
      |                                       |
      +---------------------------------------+
                    ^
                    |
             Firewall / ACL /
             Segmentation

But there is an important qualification here.

IEC 104 is not limited to its unsecured base protocol.

The IEC 62351 family defines security mechanisms for power-system communication. IEC 62351-3:2023 specifies TLS-based profiles for TCP/IP protocols, including confidentiality, integrity protection, and message-level authentication.

For protocols based on IEC 60870-5, IEC 62351-5:2023 defines an application-profile security mechanism for securing their operation.

The IEC 60870 family then defines the protocol-specific integration in IEC TS 60870-5-7:2025, which explicitly covers security extensions for IEC 60870-5-101 and IEC 60870-5-104. It describes the message formats and adaptations required to apply IEC 62351 and allows a receiver to verify that an APDU originated from an authorized user and was not modified in transit.

So the correct security question is:

What security profile does the deployed implementation support, and is it actually enabled and correctly configured?

Where the Attack Surface Begins

The protocol architecture raises several questions worth investigating.

☐ Session State

STARTDT and STOPDT control the IEC 104 data-transfer state. That makes session-state handling an obvious area for testing. How does an implementation react to unexpected state-control messages? Does it ignore them, reject them, or terminate the connection?

☐ Sequence State

I-format communication depends on synchronized N(S) and N(R) values. That raises questions around duplicate, stale, replayed, or otherwise unexpected sequence information. Again, the interesting part is the implementation's response.

☐ Application Commands

The ASDU structure provides another research surface. If an unauthorized system can reach an IEC 104 endpoint, can it construct a syntactically valid command? Can valid Common Addresses and IOAs be identified? And what controls exist between receiving a command and actually executing it? These are implementation questions.

The protocol specification tells us where to look but the lab tells us what actually happens.

Security Characteristics

Characteristic	Security Relevance
TCP/2404	Network reachability exposes the protocol endpoint
Stateful I/S/U communication	Session behavior becomes an attack surface
Sequence numbers	Unexpected sequence state warrants investigation
Structured ASDUs	Application messages follow defined semantics
CA / IOA addressing	Target identification becomes important
Base IEC 104	No native cryptographic security in the core protocol
IEC 62351 extensions	Security mechanisms can be applied to IEC 104 deployments

The last two rows are deliberately separated. A security assessment of IEC 104 should distinguish between the base protocol and the security mechanisms implemented around it.

From Architecture to Packets

The basic model is now clear:

TCP
 |
 +-- APCI
 |    |
 |    +-- I-Format
 |    +-- S-Format
 |    +-- U-Format
 |
 +-- ASDU
      |
      +-- Type ID
      +-- VSQ
      +-- COT
      +-- Common Address
      +-- IOA
      +-- Information

That gives us the vocabulary needed for the next phase. The specification tells us what the fields and state machines are supposed to mean. The next step is to find out what they actually look like on the wire.

Next: IEC 104 packet-level analysis: raw frame construction, state transitions, PCAP dissection, and implementation behavior.

I Started With One OPC UA `GetEndpoints` Request. Then I Found Anonymous Writes.

404Saint — Tue, 11 Aug 2026 15:54:11 +0000

By RUGERO Tesla (@404Saint).

[*] Target Server: opc.tcp://127.0.0.1:4840
[*] Sending unauthenticated GetEndpointsRequest...
[+] Received 5 exposed endpoints.

Five endpoints from a single unauthenticated GetEndpointsRequest. That was the starting point for this OPC UA laboratory. The response advertised four cryptographically protected configurations and one endpoint using:

SecurityMode:   None
SecurityPolicy: None

The server was therefore not enforcing a single security posture at the discovery layer. A client could select the unprotected endpoint even though Sign and SignAndEncrypt configurations were available.

Endpoint discovery showing the five configurations advertised by the laboratory server.

That observation alone was not treated as a downgrade vulnerability. No active downgrade attack was performed. The finding was simpler: an unencrypted endpoint was explicitly available for client selection.

The next step was to use it.

From `GetEndpoints` to `ActivateSession`

OPC UA establishes application sessions through a defined sequence:

OpenSecureChannel
        ↓
CreateSession
        ↓
ActivateSession

Using the SecurityPolicy=None endpoint, an anonymous identity token was supplied during ActivateSession.

The server accepted the session:

[+] SecureChannel established
[+] Session activation succeeded

SecureChannel State: OPEN (SecurityPolicy#None)
Session State:       ACTIVE
Authentication Type: Anonymous

Successful anonymous session establishment over the SecurityPolicy=None endpoint.

At this point the scope of the test changed. Endpoint discovery had established insecure exposure. Session establishment demonstrated that the exposed endpoint was actually usable without an authenticated identity. The address space was the next layer.

Walking the Address Space

OPC UA does not present an industrial control environment as a flat register table.

Its application model is an address space containing Objects, Variables, Methods, Properties, References, and associated metadata.

A recursive traversal was therefore used to enumerate the Object graph and inspect the variables reachable through the anonymous session.

The crawler followed child references and collected:

Browse Name
NodeId
Node Class
AccessLevel
UserAccessLevel
Current Value
Read Result

Relative browse-path resolution was also tested against the standard Server object:

0:Objects
 └── 0:Server
      └── 0:ServerStatus
           └── 0:CurrentTime

which resolved to:

ns=0;i=2258

The traversal itself was not the interesting finding.

Most of the address space did not provide unrestricted access. Several nodes rejected reads or returned authorization-related errors.

That distinction became important when evaluating write permissions.

AccessLevel Wasn't the Final Verdict

The audit did not classify a variable as writable solely because an attribute suggested that it was. Readable variables were tested with actual WriteRequest operations.

The mutations were deliberately small and reversible:

Boolean
False → True

integer
0 → 1

Double
0.0 → 1.0

Int64
0 → 1

example bytestring
b'test123' → b'test123_probe'

Each successful mutation was immediately restored to its original value.

The result was unambiguous:

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Boolean!
Value changed: False -> True

[CRITICAL VULNERABILITY] Write ACCEPTED on tag integer!
Value changed: 0 -> 1

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Double!
Value changed: 0.0 -> 1.0

[CRITICAL VULNERABILITY] Write ACCEPTED on tag Int64!
Value changed: 0 -> 1

[CRITICAL VULNERABILITY] Write ACCEPTED on tag example bytestring!
Value changed: b'test123' -> b'test123_probe'

Recursive address-space enumeration and access-level inspection from the anonymous session.

Successful write mutations against five tested variables. Every mutation was reverted after verification.

This is stronger evidence than simply reporting an exposed AccessLevel.

The server received the write request, accepted it, value changed and the original value was then restored. The finding is therefore specific to effective write authorization: the anonymous session was able to modify the tested variables without presenting an authenticated user identity.

The Security Boundaries Were Not Universally Broken

The write finding made it important to test the other security controls rather than assume that everything was misconfigured.

The endpoint configuration exposed SecurityPolicy=None, but protected configurations were also available:

SignAndEncrypt     Aes128_Sha256_RsaOaep
Sign               Aes128_Sha256_RsaOaep
SignAndEncrypt     Basic256Sha256
Sign               Basic256Sha256

An independent X.509 certificate was then generated for the certificate validation test.

It was deliberately unrelated to the earlier test certificate:

Subject:
CN=independent-untrusted-client

Issuer:
CN=independent-untrusted-client

Self-Signed:
True

Application URI:
urn:freeopcua:client:independent-test

The protected connection attempt used:

Basic256Sha256
SignAndEncrypt

The server rejected the certificate:

BadCertificateUriInvalid

Independent self-signed certificate rejected during the protected OPC UA handshake.

Invalid username/password authentication was also rejected with:

BadUserAccessDenied

The resulting security picture was therefore more nuanced than a simple “OPC UA authentication is broken” conclusion.

Security Boundary	Result
`SecurityPolicy=None` advertised	Insecure exposure
Anonymous session	Accepted
Address-space traversal	Extensive visibility
Tested anonymous writes	Accepted
Invalid credentials	Rejected
Independent X.509 certificate	Rejected
Protected endpoints	Available

The significant finding was the combination of an anonymously accessible session and effective write permissions on the tested variables.

Seeing the Protocol Instead of Just the API

The packet captures were an important part of the investigation.

For example, the username authentication test produced an ActivateSessionRequest containing a UserNameIdentityToken:

UserName: admin
Password: ...
EncryptionAlgorithm:
    http://www.w3.org/2001/04/xmlenc#rsa-oaep

The client reported BadUserAccessDenied, but the PCAP showed how the identity token was actually represented on the wire. That distinction matters in protocol research. A high-level library can tell you that an operation succeeded or failed but a packet capture can show the actual message, security mode, token type, request structure, and server response.

The laboratory therefore combined both:

Python harness
      +
OPC UA server
      +
Wireshark / PCAP
      +
manual protocol inspection

rather than treating the client library as the protocol itself.

The Research Repository

The complete laboratory is available in the repository:

industrial-protocol-labs / opcua-research

It contains the phase-by-phase notes, Python research harnesses, packet captures, screenshots, logs, and reproduction instructions.

opcua-research/
├── captures/
├── logs/
├── notes/
├── screenshots/
└── scripts/

The detailed notes cover:

OPC UA architecture and security model
Endpoint discovery
SecureChannel and session establishment
Address-space traversal
Access-level auditing
Effective write authorization
X.509 trust-boundary testing
Laboratory reproduction

The interesting part of this research was not any individual API call. It was following the protocol far enough to determine what an apparently ordinary anonymous session could actually do.

GetEndpoints was only the first request.

Building BACnet from Raw Packets: Objects, Priority Arrays, BBMDs, and Event Services

404Saint — Tue, 04 Aug 2026 15:41:40 +0000

By RUGERO Tesla (@404saint)

Industrial communication protocols reveal their design philosophy through the way they represent operational state.

Modbus exposes memory through coils and registers.

EtherNet/IP builds on the Common Industrial Protocol (CIP), organizing devices into object classes and explicit messaging services.

BACnet approaches automation from an entirely different direction. Rather than treating field devices as collections of registers, it models an automation system as a distributed object database in which sensors, actuators, schedules, alarms, and configuration elements are represented as standardized objects with well-defined properties.

That architectural decision fundamentally changes how clients interact with a BACnet device. Reading process information no longer involves polling register offsets; instead, application services operate directly against object instances and individual properties. Command execution is governed by priority arbitration, network communication depends on the BACnet Virtual Link Layer (BVLL), and many state changes are distributed through event-driven notifications rather than continuous polling.

This article documents a packet-level analysis of those mechanisms using an isolated BACnet/IP laboratory built around the open-source bacnet-stack implementation. Instead of relying on high-level BACnet libraries, each experiment manually constructed BVLL, NPDU, and APDU structures in Python to observe how the target implementation processed protocol requests under controlled conditions.

The research was divided into four phases:

Object Model & Property Engine
Priority Array Arbitration
Routing, BBMD & Subnet Traversal
Change-of-Value (COV), Event Services & BACnet/SC

Research Environment

The target consisted of a locally compiled bacnet-stack server exposing a virtual BACnet/IP device over UDP port 47808 (0xBAC0). All experiments were executed from a separate Python research harness that manually assembled protocol frames before transmitting them to the server.

Unlike production assessments, the objective was not vulnerability discovery. Instead, the laboratory provided an instrumented environment for observing protocol behavior, validating packet construction, and documenting implementation responses to both expected and unusual requests.

Phase 1 — Inspecting the BACnet Object Database

BACnet devices organize operational state into standardized objects. Every physical or logical component of the automation system is represented as an object containing a collection of named properties.

Rather than beginning with write operations, the first phase focused on understanding the controller's exposed object model.

The initial experiment queried the Object_List property of the Device object. The response returned 76 object instances, including standard BACnet object classes such as Analog Inputs, Analog Outputs, Binary Inputs, Binary Outputs, and several vendor-defined object types.

Subsequent experiments exercised additional application services including:

ReadProperty
ReadPropertyMultiple
CreateObject
DeleteObject
Extended property identifiers

One observation recorded during testing was that the target accepted an unauthenticated CreateObject request while rejecting unsupported property identifiers and protected deletion attempts using standard BACnet Error-PDUs. The implementation remained stable throughout the assessment and returned protocol-compliant error responses instead of terminating the connection.

Figure 1. Phase 1 research harness demonstrating object enumeration, multi-property inspection, dynamic object creation, invalid property handling, and protected object deletion against the laboratory BACnet/IP target.

The experiments established the structure of the target's internal object database before moving to command execution behavior.

Phase 2 — Understanding Priority Array Arbitration

One of BACnet's most distinctive features is the Priority Array.

Unlike protocols where writing a value immediately replaces the previous state, commandable BACnet objects maintain sixteen independent priority slots. The object's effective value is determined by the highest-priority non-NULL entry within the array.

To examine this behavior, the research harness issued successive WriteProperty requests targeting different priority levels before reading back the resulting Priority Array.

The experiments included:

Writing at Schedule priority (Slot 16)
Writing at Manual Life Safety (Slot 1)
Writing at Manual Operator (Slot 8)
Relinquishing control using NULL
Dumping the complete Priority Array

The server acknowledged each write request with a SimpleACK, while subsequent reads demonstrated how the implementation stored and evaluated priority values.

During testing, one implementation-specific observation stood out. Although a write targeted Priority Slot 8, the value later appeared in Slot 12 when the Priority Array was retrieved. Because this behavior was observed only within the laboratory implementation, no broader conclusions were drawn regarding BACnet itself. The result is simply documented as an implementation observation requiring additional investigation.

Figure 2. Priority Array assessment showing writes across multiple priority levels, NULL relinquishment, and the resulting Priority_Array returned by the laboratory target.

Beyond illustrating BACnet's arbitration model, the experiments highlighted how command execution depends on protocol semantics rather than simply accepting the most recent write.

Phase 3 — Routing, BBMDs, and Network Infrastructure

BACnet/IP extends beyond application services by introducing the BACnet Virtual Link Layer (BVLL).

BVLL enables communication across routed IP networks through Broadcast Management Devices (BBMDs), Foreign Device Registration, and BACnet network-layer routing services.

Three infrastructure mechanisms were examined:

Foreign Device Registration
Who-Is-Router-To-Network
Global Who-Is broadcasts

The target acknowledged a Register-Foreign-Device request using a successful BVLL Result response, indicating acceptance of the registration message at the protocol layer.

Router discovery requests produced no I-Am-Router-To-Network responses during the observation period, and global broadcast discovery did not identify additional BACnet devices within the laboratory environment.

These observations are consistent with the isolated topology used during testing and should not be interpreted as representative of production BACnet deployments.

Figure 3. BBMD and network infrastructure assessment demonstrating Foreign Device Registration, router discovery, and broadcast-based topology observations.

This phase reinforced the distinction between BACnet's application layer and the additional networking infrastructure required to operate across routed environments.

Phase 4 — Event Services, COV, and BACnet/SC

The final phase examined BACnet's event-driven communication model.

Unlike protocols that depend exclusively on polling, BACnet allows clients to subscribe for Change of Value (COV) notifications. Once subscribed, the server can transmit state updates whenever monitored values change.

The research harness manually constructed a SubscribeCOV request targeting an Analog Input object.

The target acknowledged the subscription using a SimpleACK before transmitting an Unconfirmed COV Notification, confirming that the subscription had been accepted and event delivery was operational.

The second experiment focused on the Event_Enable property.

Rather than issuing a write operation in isolation, the property was read, modified, and read again to verify that the server stored the updated Bit String exactly as transmitted. This confirmed successful property modification within the laboratory implementation.

The final experiment probed TCP port 47809, the standard transport used by BACnet Secure Connect (BACnet/SC), by attempting a WebSocket handshake. The connection was refused, indicating that the laboratory server exposed only traditional BACnet/IP services during testing.

Figure 4. Event-service analysis demonstrating SubscribeCOV acknowledgement, Event_Enable verification before and after modification, and BACnet/SC transport probing.

Together, these experiments completed the examination of BACnet's application services, event mechanisms, and secure transport transition.

Key Observations

Across the four research phases, several implementation characteristics were consistently observed:

The target exposed its object database through standard property services.
Priority arbitration followed BACnet's multi-slot command model rather than simple overwrite semantics.
Foreign Device Registration requests were acknowledged at the BVLL layer.
Router discovery and global broadcast enumeration produced no observable responses within the isolated laboratory.
SubscribeCOV successfully generated event notifications.
Event_Enable property modifications were reflected in subsequent reads.
No BACnet/SC listener was present on the expected secure transport port.

None of these observations should be generalized beyond the laboratory implementation. They describe the behavior recorded during controlled testing and serve as a foundation for understanding BACnet's protocol mechanics rather than evaluating commercial products.

Repository

The complete research repository contains:

Protocol architecture primer
Four packet-level research phases
Laboratory reproduction guide
Python research harnesses
Network diagrams
Terminal captures
Detailed implementation observations

GitHub: https://github.com/404saint/industrial-protocol-labs/tree/main/bacnet-research

Closing Remarks

BACnet is often introduced as "the building automation protocol," but that description overlooks much of what makes it technically interesting. Its object-oriented data model, priority-based command arbitration, network-layer routing infrastructure, and event-driven services distinguish it from many traditional industrial protocols.

Constructing protocol frames manually made those design decisions significantly clearer than interacting through abstraction libraries alone. More importantly, documenting the observed behavior, whether expected or implementation-specific, provides a reproducible reference for engineers and security researchers studying BACnet at the packet level.

Disclaimer: All experiments described in this article were conducted within an isolated laboratory environment using controlled BACnet/IP implementations. The work is intended solely for protocol education, interoperability research, and defensive security analysis. Do not perform similar testing against systems without explicit authorization.

Hands-On DNP3 Protocol Analysis: State Machines, Transport Mechanics, and Secure Authentication (SA v5)

404Saint — Sun, 02 Aug 2026 14:58:13 +0000

By RUGERO Tesla (@404saint)

In my previous article, Beyond Cyclic Polling: Objects, Classes, and Outstation State in DNP3, we explored how DNP3 (IEEE 1815) organizes information through object groups, event classes, and Internal Indications (IIN). That discussion focused on the protocol's architecture and how an outstation exposes operational state to a SCADA master.

Understanding the specification, however, is only half of the story.

The more interesting question is what happens inside an implementation when frames begin arriving on the wire. How does an outstation process malformed transport fragments? What state transitions occur when control commands arrive out of sequence? How are administrative function codes handled internally? What actually changes when Secure Authentication (SA v5) is introduced?

To answer those questions, I built an isolated DNP3 research laboratory entirely in Python. Rather than relying on vendor implementations or third-party protocol libraries, I implemented custom outstation targets, protocol parsers, and master-side test harnesses to observe protocol behavior from the raw socket layer upward. This made it possible to inspect state transitions, reproduce protocol edge cases, and verify implementation behavior under controlled conditions.

The repository contains:

A custom DNP3 outstation implementation
A Secure Authentication (SA v5) enabled outstation
Individual master-side test suites for each research phase
Packet captures for every experiment
Detailed technical notes documenting protocol behavior and implementation observations

You can explore the complete project here:

GitHub Repository

https://github.com/404saint/industrial-protocol-labs/tree/main/dnp3-research

This article summarizes five phases of that research:

Reconnaissance and protocol fingerprinting
Control execution and Select-Before-Operate validation
Administrative state transitions
Transport-layer behavior and unsolicited messaging
Secure Authentication (SA v5)

Phase 1 — Reconnaissance & Internal Indication Analysis

Before attempting any control operations, it is useful to understand what information a DNP3 endpoint exposes during normal communication.

Unlike many industrial protocols that require several exchanges before meaningful information becomes available, a standard Class 0 Integrity Read (FC 0x01) immediately returns an Application Layer response containing the Internal Indications (IIN) field.

Those two bytes provide a surprisingly useful snapshot of the outstation's operational state.

Depending on the implementation, the response may reveal whether:

the device has recently restarted,
time synchronization is required,
event buffers contain pending data,
hardware faults have been detected,
unsupported function codes were received,
parameter validation has failed.

Because the IIN field is part of normal protocol behavior, it represents one of the earliest opportunities to understand how an outstation is currently operating.

The first phase of the lab simply performs a baseline integrity poll and parses those response flags.

Figure 1. recon_enum.py issuing a Class 0 Integrity Read and decoding the returned Internal Indications.

On the opposite side of the connection, the custom outstation processes the incoming FT3 frame, builds the Application Layer response, and returns the corresponding IIN values.

Figure 2. The custom outstation parsing the request and constructing the response APDU.

One observation from this phase is the persistence of the Device Restart indication (IIN1.7). Following initialization, this flag remains asserted until the master acknowledges the restart condition. Although simple, this mechanism allows supervisory systems to distinguish between continuous operation and a recently restarted device without relying on external monitoring.

This phase also establishes an important baseline for later experiments. Once administrative commands, transport anomalies, and authentication mechanisms are introduced, changes in the IIN field become an effective way to observe how internal state evolves throughout the protocol.

Phase 2 — Control Execution & Select-Before-Operate Validation

One of DNP3's defining characteristics is its emphasis on deterministic control execution.

Rather than immediately actuating field devices whenever a command arrives, IEEE 1815 defines a Select-Before-Operate (SBO) workflow for Control Relay Output Blocks (CROB). The design intentionally separates validation from execution, reducing the likelihood of accidental operations caused by communication errors or malformed traffic.

Under the SBO model, a control operation normally follows two stages:

Select (FC 0x03) : The master requests control of a specific output point. The outstation validates the request and temporarily reserves that point.
Operate (FC 0x04) : If the reservation remains valid, the outstation executes the requested operation and clears the reservation state.

The protocol also defines Direct Operate (FC 0x05), which bypasses the reservation phase entirely and requests immediate execution.

To understand how the implementation enforced these different execution paths, I evaluated two scenarios:

issuing a Direct Operate request without a preceding Select, and
transmitting an Operate request against an unarmed point.

The master-side test suite executed both cases sequentially.

Figure 3. control_attacks.py exercising multiple CROB execution paths.

The first experiment demonstrated that Direct Operate followed its intended execution path. Because FC 0x05 explicitly bypasses the reservation stage, the simulated outstation accepted the request and executed the control action immediately.

The second experiment intentionally violated the SBO state machine.

An Operate request (FC 0x04) was transmitted without a matching active Select. Rather than executing the command, the outstation rejected the request because no reservation existed for the specified control point.

The internal logs clearly illustrate that transition.

Figure 4. The outstation detecting an invalid Operate sequence and rejecting the request.

Although these experiments were performed against a custom implementation, they demonstrate why protocol state machines matter just as much as packet syntax. A correctly implemented DNP3 endpoint does more than decode bytes... it continuously tracks execution context, validates command ordering, and determines whether a requested action is currently valid.

That distinction becomes even more important when administrative function codes begin modifying the outstation's runtime state.

Phase 3 — Administrative State Transitions

Control commands are only one part of the DNP3 application layer.

IEEE 1815 also defines a collection of administrative function codes that influence the lifecycle of an outstation itself. Rather than manipulating individual field points, these commands affect the runtime environment responsible for processing telemetry, maintaining event history, and coordinating system time.

Among the most significant administrative functions are:

Function Code	Purpose
`0x0D`	Cold Restart
`0x0E`	Warm Restart
`0x12`	Stop Application
`0x18`	Write Time

Unlike CROB operations, these requests alter the state of the outstation rather than the state of an individual control point.

To observe these transitions, I executed each function sequentially against the simulated outstation while monitoring both protocol responses and internal application state.

Figure 5. system_attacks.py exercising administrative function codes against the baseline outstation.

Several interesting behaviors emerged during testing.

Time Synchronization

The Write Time function (FC 0x18) updates the outstation's internal clock. In the lab, submitting a new timestamp immediately modified the runtime clock and cleared the Need Time indication (IIN1.4), demonstrating how time synchronization directly affects protocol state.

Although expected behavior, it reinforces how closely event sequencing depends on accurate clocks in industrial systems.

Warm Restart

Issuing a Warm Restart (FC 0x0E) temporarily interrupted application processing while preserving much of the runtime context.

The response included a restart delay object, allowing the master to estimate when normal communications could safely resume.

Stop Application

The most interesting behavior occurred after issuing Stop Application (FC 0x12).

Rather than terminating the network connection, the transport and link layers continued accepting frames while the application layer stopped processing operational requests.

Subsequent read operations were therefore rejected, not because the TCP session had failed, but because the application itself had transitioned into a halted state.

That distinction is subtle but important.

From a network perspective, the device still appeared reachable.

From an application perspective, however, it was no longer servicing requests.

The outstation logs clearly illustrate these transitions.

Figure 6. Runtime state changes following administrative commands, including clock updates, application halt, and restart processing.

This phase reinforced an important implementation detail: protocol availability is not determined solely by socket state. Internal application state can significantly alter how an endpoint responds, even while lower protocol layers continue operating normally.

Phase 4 — Transport Reassembly & Unsolicited Messaging

The DNP3 Transport Pseudo-Layer is often overlooked because it consists of only a single control byte.

Despite its simplicity, that byte is responsible for coordinating fragmentation and reassembly across every multi-frame Application Protocol Data Unit (APDU).

Bit Position

7      6      5 4 3 2 1 0
+------+------+
| FIR  | FIN  | Sequence |
+------+------+

The transport header contains three pieces of information:

FIR (First Fragment) : Indicates the beginning of an APDU stream.
FIN (Final Fragment) : Marks the final fragment in the stream.
Sequence Number : A six-bit counter used to order fragments.

Most DNP3 communications fit within a single frame, making fragmentation relatively uncommon during normal operation.

Nevertheless, any implementation supporting larger payloads must correctly maintain fragment state, sequence tracking, and timeout behavior.

To evaluate that logic, I intentionally exercised several edge cases.

Reassembly State Validation

The first experiment transmitted a frame marked as the final fragment without ever establishing an active fragment stream.

From the parser's perspective, this meant receiving the end of a conversation that had never started.

The master-side test suite generated the malformed transport header and transmitted it directly to the outstation.

Figure 7. transport_attacks.py generating malformed transport sequences and unsolicited response traffic.

Rather than attempting to process the payload, the parser detected the invalid state transition and rejected the frame.

The corresponding runtime logs clearly show the parser identifying the missing fragment context before terminating reassembly.

Figure 8. The transport engine detecting an invalid fragment sequence during APDU reassembly.

The second experiment intentionally opened a fragmented stream without completing it.

Instead of immediately raising an error, the parser allocated reassembly state and advanced the expected sequence counter.

This illustrates another important implementation consideration.

Transport parsers do more than decode individual packets. They maintain state across multiple frames. Any robust implementation must therefore handle incomplete streams, unexpected sequence numbers, retransmissions, and timeout cleanup without exhausting internal resources.

Unsolicited Response Processing

The final experiment in this phase focused on Unsolicited Responses (FC 0x82).

Unlike conventional request-response communication, unsolicited messages allow an outstation to report significant events without waiting for the master to poll.

Typical uses include:

binary input changes,
analog threshold crossings,
event notifications,
alarm conditions.

Within the laboratory, I generated a synthetic unsolicited response carrying an Analog Input object (Group 30 Variation 1) to observe how the implementation processed an event arriving outside the normal polling cycle.

Because the frame matched the expected protocol format, the simulated receiver accepted the message and updated its internal state accordingly.

The purpose of this experiment was not to demonstrate a universal weakness in DNP3 deployments, but to study how unsolicited messaging is integrated into protocol processing and why implementations must validate message origin, sequencing, and where supported, authentication before committing unsolicited event data.

5. DNP3 Secure Authentication (SA v5) Verification

One of the most significant limitations of legacy DNP3 is the absence of built-in authentication for critical control operations. Any device capable of reaching an outstation can potentially issue administrative or control function codes unless additional security controls are deployed.

To address this, IEEE 1815-2012 introduced DNP3 Secure Authentication Version 5 (SA v5), later aligned with IEC 62351-5. Rather than encrypting protocol traffic, SA v5 protects sensitive operations through a challenge-response mechanism that verifies message authenticity and integrity before control commands are executed.

To better understand this workflow, I implemented a dedicated Secure Authentication outstation (outstation-sa.py) alongside a companion master test harness (master_test_runner.py). Together they reproduce the complete authentication state machine, allowing each stage of the protocol exchange to be observed in isolation.

The master-side test harness executing the complete Secure Authentication validation suite, including challenge negotiation, HMAC verification, session establishment, and authenticated control execution.

Walking Through the Authentication Workflow

The authentication sequence follows a well-defined state machine.

Baseline Read (FC 0x01)

Standard telemetry reads continue to operate normally. Since these requests are considered non-critical, they do not require cryptographic validation and are processed without additional authentication overhead.

Challenge Negotiation (FC 0x20, Object 120 Variation 1)

Before executing a protected operation, the master initiates the authentication process. The outstation responds with a challenge containing a nonce, sequence information, and additional parameters required to construct a valid authentication response.

Challenge Verification (FC 0x20, Object 120 Variation 2)

Using the pre-shared session key, the master computes an HMAC over the challenge data and submits the resulting authentication payload. The outstation independently performs the same calculation and compares the received digest against its own result.

Authenticated Session Establishment

If verification succeeds, the outstation marks the communication session as authenticated and returns its current Secure Authentication status (Object Group 120). Subsequent protected operations are now permitted within the authenticated session.

Protected Control Execution

With authentication complete, privileged operations, such as Select-Before-Operate (FC 0x03) are processed normally. Requests that would otherwise require authorization can now proceed under the active authenticated session.

The Secure Authentication outstation validating Group 120 authentication objects, updating session state, and authorizing protected control operations after successful HMAC verification.

Engineering Observations

Building this Secure Authentication implementation reinforced an important distinction that is often overlooked: Secure Authentication is not encryption.

Application payloads remain visible on the wire, making DNP3 traffic fully inspectable by monitoring platforms and industrial intrusion detection systems. Instead, SA v5 protects the integrity and authenticity of critical operations by ensuring that protected commands originate from an authenticated master and have not been modified or replayed in transit.

Across the five phases of this research, several observations consistently emerged:

DNP3 is fundamentally a stateful protocol. Correct behavior depends not only on packet contents, but also on transport state, control sequencing, and session context.
Administrative function codes deserve the same operational scrutiny as relay control commands, as they directly influence device availability and operational visibility.
Transport-layer correctness is just as important as application-layer validation. Robust fragment handling and sequence tracking are essential for reliable implementations.
Secure Authentication significantly strengthens DNP3 by introducing integrity verification and replay protection for sensitive operations, while remaining compatible with existing protocol deployments.

Perhaps the biggest lesson from this project was methodological.

Reading the specification explains what the protocol is designed to do. Packet captures show what happened on the network. Building an implementation exposes the internal decisions that connect those two perspectives.

That shift,, from interacting with industrial protocols to implementing them, has fundamentally changed how I approach protocol research. Understanding parser behavior, state machines, and implementation details provides insights that are difficult to obtain through passive observation alone.

The complete research laboratory, including the custom outstation implementations, master-side tooling, packet captures, screenshots, and detailed technical notes, is available in the accompanying GitHub repository.

As with every project in this series, all experiments were performed in an isolated laboratory environment for protocol research, defensive engineering, and implementation analysis. No testing was conducted against production industrial systems.

Beyond Cyclic Polling: Objects, Classes, and Outstation State in DNP3

404Saint — Tue, 28 Jul 2026 16:56:40 +0000

By RUGERO Tesla (@404saint)

If you approach DNP3 (Distributed Network Protocol 3) from a background in Modbus/TCP or EtherNet/IP (CIP), your mental model of industrial communications will immediately break.

In Modbus or CIP, state management is largely cyclic and stateless at the application layer. A Master polls a slave’s memory registers (e.g., Read Holding Registers 0x03), receives a snapshot of current values, and repeats the process on a fixed timer loop. If the network link drops for 10 seconds, every intermediate state change during that window is permanently lost.

DNP3 was explicitly engineered for wide-area networks (WANs) such as electrical distribution grids and water systems, where telemetry channels like serial radios, cellular and high-latency links are prone to latency, low bandwidth, and intermittent dropouts.

To survive these harsh environments, DNP3 flips the operational model from cyclic polling to event-driven, buffered telemetry.

Here is a deep dive into how DNP3 abstracts memory, categorizes events, and maintains state integrity before we jump into packet-level dissections.

1. Data Abstraction: Groups, Variations, and Objects

In Modbus, you read raw memory addresses (00001, 40001). You are responsible for knowing whether a given offset contains a bit, a 16-bit integer, or a split 32-bit float.

DNP3 abstracts raw memory into Objects, identified by Group and Variation:

Group: Defines the data type or container (e.g., Group 1 = Binary Input, Group 30 = Analog Input, Group 50 = Time and Date).
Variation: Defines the specific byte structure, resolution, and inclusion of flag/timestamp metadata for that data type.

For example, if an Outstation needs to transmit an Analog Input:

Group 30, Variation 1: 32-bit Analog Input with Flag.
Group 30, Variation 2: 16-bit Analog Input with Flag.
Group 30, Variation 5: Single-precision Floating Point with Flag.

DNP3 Data Hierarchy Structure — Group, Variation, and Point Index mapping.

By allowing the Master station to explicitly request specific Variations (or allowing the Outstation to select them dynamically), DNP3 optimizes bandwidth usage over constrained mediums. You don't waste 32 bits on the wire if a 16-bit integer or a single change flag is all that changed.

2. Event Classes and the Internal State Machine

To prevent constant high-frequency polling across limited radio links, DNP3 separates data into Static Data and Event Data, divided across four internal classes:

Class 0 (Static Data): Represents the current real-time snapshot of points on the Outstation. Requesting Class 0 is the equivalent of a full system state readout (Integrity Poll).
Class 1 (High Priority Events): Critical alarm triggers, trip signals, or high-urgency state transitions.
Class 2 (Medium Priority Events): Standard operational status changes.
Class 3 (Low Priority Events): Analog deadband breaches, minor diagnostic changes, or slow-moving trend data.

The Buffer Mechanism

When a physical field value changes (e.g., a breaker trips), the Outstation:

Detects the state transition.
Formats the change into an Event Object (e.g., Group 2 for Binary Input Event), appending a microsecond-resolution timestamp.
Appends the Event Object into its local Class 1/2/3 Event Buffer.
Updates its internal Class 0 snapshot value.

Architectural flow showing field state transitions updating Class 0 snapshot vs. pushing timestamped Event Objects into Class 1/2/3 buffers for Master polls.

When the Master polls for Class 1, 2, or 3 Events (an Event Poll), the Outstation empties its event buffer over the wire. The Master doesn't just learn what the value is right now, it receives the chronological history of every single state transition that occurred since the last poll.

3. Unsolicited Responses: Breaking Master-Slave Hierarchy

In standard Master-Slave/Client-Server OT architectures, an Outstation never speaks unless spoken to. If a critical transformer overheats right after a poll completes, the Master won't know until the next polling interval.

DNP3 solves this via Unsolicited Responses:

An Outstation is configured with threshold conditions (e.g., any Class 1 Event occurring).
As soon as the event enters the Class 1 buffer, the Outstation spontaneously initiates an Application-Layer response to the Master without waiting for a request.
The Master accepts the event data and returns an Application-Level Confirmation (ACK).

This fundamentally shifts the latency model: bandwidth usage remains near zero during quiescent operation, but response time for critical alarms becomes near-instantaneous.

4. Reliability and Integrity: IIN Bytes & Confirmation Loops

Because DNP3 operates over unreliable networks, packet delivery guarantees are handled natively at the Application Layer, rather than relying solely on TCP or lower layers.

Internal Indications (IIN)

Every single Application Layer response from a DNP3 Outstation includes a 2-byte header known as the Internal Indications (IIN) flags. These bits act as continuous system diagnostics returned to the Master in every message.

Caption: Bit-level mapping for Octet 1 (IIN1.0–IIN1.7) and Octet 2 (IIN2.0–IIN2.7).

Key Bit Flags Highlighted:

IIN1.0: All Stations Message Received
IIN1.4: Device Restart
IIN1.5: Device Trouble
IIN1.7: Event Buffer Overflow (CRITICAL: Last state/events lost)
IIN2.1: Class 1 Data Available
IIN2.2: Class 2 Data Available
IIN2.3: Class 3 Data Available

If a communications link drops for hours and the Outstation's memory buffer completely fills up, it sets the IIN1.7 (Event Buffer Overflow) bit. When the connection is re-established, the Master reads this bit and immediately knows that time-series continuity was broken, triggering an automatic Class 0 Integrity Poll to re-baseline the system state.

The Application Confirmation Loop

To guarantee zero event loss:

Master polls Class 1 Events.
Outstation transmits Events 1 through 5 in an Application Response (FIN=1, CON=1).
Outstation retains Events 1 through 5 in its local buffer.
Master receives the response, parses the events, and transmits an Application Confirm (CONFIRM).
Only upon receiving the explicit Confirm header does the Outstation purge Events 1 through 5 from its memory buffer.

If the network connection drops before step 4, the Outstation retains the events and re-transmits them on the next successful session.

Summary & Next Steps

DNP3 trades the simplicity of cyclic register-reading for an event-driven, timestamped state machine designed for high-latency, degraded environments. Understanding these core concepts: Object Groups/Variations, Event Classes, Unsolicited Responses, and IIN state flags is critical before analyzing traffic on the wire.

In Part 2, we will fire up an active DNP3 Master/Outstation pair in the lab, trigger simulated field alarms, and inspect raw Wireshark PCAPs to dissect the exact byte-level layout of Application Layer headers, Object Requests, and IIN response flags.

Why Advanced Industrial Protocols Give Raw Sockets the "Silent Treatment"

404Saint — Mon, 13 Jul 2026 22:28:35 +0000

By RUGERO Tesla (@404saint)

When I first ditched high-level libraries like pyModbus to build my own socket-based protocol toolkit, my goal was simple. I just wanted to see the protocols actually talk on the wire.
Using libraries is easy. They abstract away the complexity, but they also blind you to the wire-level mechanisms. If you want to master Operational Technology (OT) security, you have to understand the bytes.

Building a raw Modbus toolkit worked. But when I tried to take that same mentality and apply it to advanced protocols like EtherNet/IP and DNP3, reality hit hard. Treating EtherNet/IP like Modbus almost broke me.

Here is the truth about what happens when you abandon abstractions, and why the wire level is a brutal teacher.

1. The Anatomy of a "Silent Timeout"

With basic protocols, formatting is relatively flat. But advanced industrial protocols are nested nightmares. When you are manually crafting binary streams using Python's struct module, perfection isn't an option, it’s the baseline.

Being off by even a single byte doesn't just trigger an elegant error message. It causes a complete system breakdown:

The PLC refuses to respond.
Your script hangs and hits a generic timeout.
The network gives you total silence.

When you're twisting a raw socket script trying to debug a timeout, the script itself gives you zero useful feedback. To actually find out where the alignment broke, I found myself digging through containerized Docker logs just to see what the simulated PLC environment was choking on.

2. The Trap of Library Assumptions

The frustration doesn't start with raw sockets, it starts when you make assumptions about high-level libraries without knowing how they work under the hood.
If you guess how a library is handling a protocol format and you are one byte off, you enter a loop of endless guessing. You burn two hours trying to tweak the library inputs, only to realize the abstraction layer won't let you bend the packet the way you need to.

The ironic part? You realize the only solution left is to craft the entire payload manually from scratch. But when you step up to an advanced protocol like EtherNet/IP, that manual path becomes an uphill battle against complex session registrations and CIP (Common Industrial Protocol) routing headers.

3. Why Automated Tools Fail in the Field

Relying solely on automated tools or commercial scanners is a massive liability in OT security.
The engineers who write automated tools build them on assumptions about what a "standard" industrial environment looks like. But in the real world, every industrial environment is shifted a little bit.
When a tool encounters a non-standard environment, one of two things happens:

The industrial device gives the tool the silent treatment.
The automated tool panics and returns a confident wrong answer.

The Takeaway:

Meeting Protocols on the Wire.

This is exactly why manually wrestling with raw sockets even when it drives you crazy is invaluable.When you meet these protocols directly on the wire, your perspective changes. When you are the one parsing the raw binary data streams, network anomalies become immediately obvious. You stop guessing what a flashing link light or a timed-out script means because you know exactly which byte in the header failed to align.

Abstractions are great for speed, but deep security research requires you to look at the raw bytes,even when they give you the silent treatment.

Abandoning Abstractions: Manually Crafting EtherNet/IP Packets Almost Broke Me

404Saint — Mon, 29 Jun 2026 21:13:20 +0000

By RUGERO Tesla (@404Saint).

There is a persistent illusion in Industrial Control Systems (ICS) security research: that high-level libraries, abstraction frameworks, or protocol tooling give you a real understanding of Operational Technology (OT) behavior.

They don’t.

They hide the architecture.

Determined to understand what actually happens when a Programmable Logic Controller (PLC) receives a control-plane command, I built an EtherNet/IP and Common Industrial Protocol (CIP) sandbox from scratch. No Scapy. No protocol wrappers. Just raw sockets, a Linux loopback interface, a cpppo simulator, and a passive monitoring tool (enip_monitor.py) capturing traffic in real time.

It looked clean on paper. Then I reached the application layer.

And things stopped behaving like theory.

The Reality of the “Industrial Abstraction Layer”

If you come from Modbus or traditional IT networking, you’re used to linear memory spaces—fixed registers, predictable offsets, and flat addressing.

EtherNet/IP and CIP discard that model entirely.

Instead, they introduce a structured object system wrapped inside multiple encapsulation layers:


+-----------------------------------------------------------+
| EtherNet/IP Encapsulation Header (24 bytes)               |
| → Session control, commands (0x0065, 0x006F)              |
+-----------------------------------------------------------+
| Common Packet Format (CPF)                                |
| → Routing, addressing, and transport segmentation         |
+-----------------------------------------------------------+
| CIP Application Layer                                     |
| → Service codes (0x4C, 0x4D, 0x10, etc.)                  |
+-----------------------------------------------------------+

To communicate with a PLC at the wire level, your code must:

Establish a session using RegisterSession (0x0065)
Wrap all subsequent requests in SendRRData (0x006F)
Encode routing information inside CPF structures
Construct symbolic or logical paths for the CIP Message Router
Ensure strict byte alignment across nested payload layers

A single mistake in any layer breaks everything silently.

The Wall: Fragmentation and State Confusion

Basic tag reads (0x4C) and writes (0x4D) against my test dataset (SAINT_DATA) worked as expected.

Then I moved into fragmented transfers using:

0x52 (Read Fragmented)
0x53 (Write Fragmented)

This is where things stopped being predictable.

I was manually tracking offsets, element counts, and buffer boundaries across multiple frames. The client appeared to execute correctly:


[+] Attribute Write Resolved: write_frag.elements
[+] Attribute Write Resolved: write_frag.offset
[+] Attribute Write Resolved: write_frag.data
[+] Attribute Write Resolved: service

But nothing changed on the wire.

No values. No errors. No feedback.

Just silent failure.

At this level, there is no stack trace. If a single byte in the CPF or path encoding is wrong, the CIP Message Router doesn’t explain itself—it simply drops the inner execution.

The Breakthrough: Observing the Wire Directly

The turning point came from running enip_monitor.py alongside my client scripts, capturing loopback traffic in real time.

Instead of trusting the client’s internal state logs, I started trusting the packet stream.

Then I triggered a deliberate failure by querying a non-existent tag (NON_EXISTENT_TAG).

The monitor immediately exposed the actual system behavior:


[!] SESSION REGISTRATION DETECTED | Handle: 0xe946f379 | Status: 0
[+] INDUSTRIAL MONITORING ALERT
Source IP   : 127.0.0.1
Session     : 0xf6d8e0cf
CIP Service : Unconnected Send (Router)
Target      : NON_EXISTENT_TAG

The PLC responded with a clear General Status Code 0x05 (Path Destination Unknown).

That moment mattered.

It confirmed the mismatch between what the client believed it sent and what the wire actually carried. Once I aligned the fragmentation offsets correctly, the payload began committing cleanly.

The system was never broken. The assumptions were.

Core Takeaway

This project proved something simple but important:

Abstraction layers do not guarantee understanding. They often remove it.

EtherNet/IP and CIP are optimized for speed, interoperability, and extensibility. In doing so, they expose a deeply structured but highly implicit execution model where correctness depends entirely on precise packet construction.

From a security perspective, this matters because:

The protocol trusts correctly formatted packets by default
Symbolic and object-level structures are externally observable
Error states leak structural information about internal routing logic
Enumeration and interaction require no authentication in many legacy configurations

Defending these systems requires working at the wire level:

Building packet-aware detection logic (e.g., Suricata/Snort rules)
Monitoring encapsulation and CIP service behavior directly
Enforcing strict network segmentation and device mode control
Deploying CIP Security where supported

Closing Thought

If you want to understand OT systems properly, don’t start with tooling.

Start with bytes.

Raw sockets are frustrating, slow, and unforgiving but they expose what every abstraction layer tries to hide.

Repository

All scripts, validation flows, and 13 supporting technical notes are documented here:

👉 https://github.com/404saint/industrial-protocol-labs/

Disclaimer

This research was conducted in a controlled, isolated laboratory environment for educational and defensive security purposes only. All protocol interaction, traffic generation, and packet analysis were performed against a local simulation stack and loopback interface.

This work is intended to support industrial cybersecurity understanding, detection engineering, and protocol analysis. It is not intended for use against production systems or any environment without explicit authorization and appropriate safety controls.

Always ensure compliance with applicable laws, operational safety requirements, and organizational policies when working with industrial control systems.

The Reality of Raw Sockets: When Your Packet Trace Lies and the PLC Stays Silent

404Saint — Tue, 23 Jun 2026 15:20:44 +0000

By RUGERO Tesla (@404Saint).

We see a lot of clean "wins" on tech blogs. People post beautifully formatted walk-throughs where every exploit chain connects on the first try, every payload returns a root shell, and the terminal looks like a movie script.

This isn't one of those posts.

This is the raw, unedited chronology of what happens when you spend hours fighting industrial protocols, getting brick-walled by application layers, and chasing down silent network failures at 2:00 AM.

1. The Trap of Protocol Assumptions (DNP3 vs. Modbus)

The cycle started yesterday. Fresh off building a custom toolkit for Modbus TCP which is a beautifully simple, stateless, and completely predictable protocol, I figured I would easily pivot the framework to handle DNP3.

I expected a similar flow. I was entirely wrong.

Five hours of continuous, grueling socket programming later, I was staring at a wall. DNP3 isn’t just a protocol; it’s an intricate architectural ecosystem. It requires dealing with complex outstation internal states, multi-layered packet fragmentations, and strict link-layer confirmations. Treating DNP3 like Modbus isn't just a minor mistake; it’s a fundamental misunderstanding of the wire.

Realizing I was fighting a losing battle without deep-diving into the complete specification first, I made a tactical decision: I parked DNP3 for a dedicated project later, stepped back, and redirected my raw Python socket architecture toward EtherNet/IP (ENIP) and the Common Industrial Protocol (CIP).

2. The Illusions of the Network Layer (The TCP ACK Trap)

By late tonight, the initial EtherNet/IP encapsulation code was ready. I fired off the initial Phase 1 registration packets (0x0065) against my local lab target running an OpenPLC instance. The handshakes were flawless, and the session handles were rotating cleanly in hexadecimal. The transport layer felt bulletproof.

Figure 1: Successful ENIP session registration (0x0065) yielding an active handle.

Then came Phase 2: Attempting a Symbolic Segment Tag Read (0x4C) over an unconnected data path (SendRRData, 0x006F). I hit enter on the execution script and watched tcpdump on my secondary monitor.

Figure 2: The network illusion— captured a flawless TCP transport-layer handshake followed by absolute application-layer silence.

On the network level, it looked like a total success:

The script pushed the raw custom ENIP payload to port 44818.
The target container immediately shot back a TCP . ACK.

But on my main terminal, everything just froze.

[*] Phase 02: Building and delivering Vendor class 0x64 read requests...
[-] Wire execution crashed. Context: timed out

Five seconds of total silence, followed by a socket timeout exception. This is the ultimate illusion of network testing. The host OS kernel swallowed the packet and acknowledged it at the transport layer, but the actual PLC application layer went completely dark. No TCP Reset (RST). No CIP error frames. Just an empty void.

3. Demolishing the Target (Inside the OpenPLC Logs)

I spent the next hour questioning my own code. When you're crafting raw binary payloads via Python’s struct.pack(), a single misaligned byte, a broken word size, or an incorrect item count in the Common Packet Format (CPF) wrapper will cause an industrial parser to drop the ball.

I tore the script apart, rebuilt the hexadecimal mapping from scratch, and even stripped out the proprietary Rockwell tag-read service down to a completely generic, standard CIP Identity Object discovery path (Class 0x01, Instance 0x01, Service 0x0E).

# Re-aligning the CPF wrapper and Encapsulation Header
rr_data_packet = struct.pack(
    '<HHII8sI IHHHHHH',
    0x006F, 24, handle, 0, b'SAINT404', 0,  # Encap Header
    0, 0, 2, 0x0000, 0, 0x00B2, 8          # CPF Data
) + cip_data

I ran it again. Same result. Another 5-second hang.

At this point, you have to stop assuming your tool is broken and start looking at the target's internal state. I dropped out of my code editor and pulled the live stdout logs from the target runtime container:

docker logs openplc-lab

There, buried in the container timestamps, was the exact smoking gun:

2026-06-23T14:05:56.165168622Z ENIP: Received unsupported EtherNet/IP Type
2026-06-23T14:05:56.165170130Z Server: Error writing response: -1

The realization was incredibly clarifying. The script wasn't broken. The packet wasn't misaligned. OpenPLC’s lightweight, modular EtherNet/IP listener simply does not support Rockwell-style proprietary symbolic tag reading or standard unconnected explicit message routing (UCMM).

Instead of cleanly replying over the wire with a standard CIP protocol error frame (like a normal PLC would), OpenPLC’s backend code hit an unhandled exception path, threw an internal error (-1), and dropped the socket completely without writing a single byte back to my network interface.

4. Upgrading the Arsenal

In offensive security and asset fingerprinting, a silent application-layer drop is incredibly valuable telemetry. It tells you exactly who and what is on the other side of the wire.

A real, production-grade Allen-Bradley controller or a high-fidelity simulator will return either tag data or a structured CIP error frame (Path Segment Error).
An OpenPLC instance will choke internally, log an unhandled error, and leave the client script hanging until a timeout.

The ultimate lesson? Hobbyist software teaches you about hobbyist bugs. Fighting with a stripped-down implementation only maps out its internal software limitations rather than showing you how real-world OT systems respond to packet manipulation.

To truly reverse-engineer industrial connection managers, Forward_Open loops, and complex CIP state machines, you need a target that acts like the real thing.

Tomorrow, the lightweight containers are getting parked. We are upgrading the lab environment to high-fidelity target harnesses.