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

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

Introduction

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.

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:

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

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
    • Device identity and topology
    • Cyclic Real-Time I/O
  • DCE/RPC over UDP port 34964
    • Application Relationship
  • AR and IOCR configuration
    • Process data and state

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.

Phase Two: DCE/RPC and Application-Relation Traffic

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, and AlarmCRBlockReq. The observed DCE/RPC interface UUID was 4a823108-a078-11d0-b21a-00a0241a673b.

Phase Three: Cyclic Real-Time Framing

The third phase examined cyclic Real-Time traffic over PROFINET EtherType 0x8892. A separate traffic generator was built to examine frame structure, field placement, timing, and controlled payload changes.

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

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?