We kindly were provided with access to a DeltaV system used for training.

Therefore we were able to change a few things without fearing to break anything important.

This system consisted of three DeltaV controllers, two Operator-System instances So in general there were three types of systems involved:

The first change here, was to replace the network switch with a network hub, so we could capture the entire network traffic. (By the way …​ if you happen to still have a working Hub, don’t give that away. It turns out it’s really hard to get you hands on hubs these days)

With this we let the system run and did a pretty long network capture.

This 29MB WireShark capture was what we started working with.

As WireShark didn’t have a DeltaV disector, we had to trace it down ourselves.

When looking at the capture, we very quickly filtered out the usual network protocols and the Windows communication and found a lot of binary UDP traffic running on port 18507.

Special with all of these was that they all started with a payload of 0xFACE.

Here it appeared that UDP packets are sent with some sort of payload, which are obviously responded to by packets with a fixed and very small size (64 bytes).

So we are assuming these short messages, that seem to partially repeat some of the information of the first packet (but not all), are probably acknowledge packets.

From looking at the nature of the traffic and knowing the IP addresses of the DeltaV controllers (PLC) and the Operator Systems (Controll-Software), we could see that this communication is probably subscription based as we could see a lot of the Controller sending packets to the OS, which the OS then acknowleges in regular intervals.

When filtering only the UDP packets on port 18507 we could scroll though the byte representation, we could quickly identify some things.

In order to prove any assumption we made, we used little programs that used Pcap4J to programmatically check assumptions.

As mentioned before, it appeared obvious that for almost identical packets the first two short values were very similar too, which led us to the assumption that these are type and `sub-type'. So we wrote a little program, that scanned all the packets and counted how many types we had. This was a very large number. Also did we output some additional information about packets on the console …​ one of these pieces of information was the length of the packet.

When outputting a sorted list of the type values (maybe it’s strange, but I like data sorted) it seemed quite obvious, that for a larger presumed type value, also the length of the packet was larger. Especially when comparing the difference of these values also showed that of a type had a value that is larger than another packet, that also the length was exactly this number of bytes larger.

So in the end it turned out that the first short value is not the type, but a packet length-related value. It even turned out that the number encoded here was constantly 2 bytes short the number of bytes after the 3 constant bytes of 0x800400, ending leaving two bytes at the end.

These two bytes seemed to be extremely jumpy. Here we could see that for every packet this value seemed to change quite dramatically, even if the payload was almost identical. We did see values repeated, but couldn’t see any correlation between the content of the colliding packets. So in the end we assume this is some sort of checksum value.

With this assumption, we now think that the first short value is the payload-length value.

Knowing the first short value no longer is the type, upgraded the second short value to being a new candidate for being a full type.

Scanning the communication, it pretty quickly became obvious that here most communication packets have a value of 0x0002 and some have 0x0006. Only when starting a new OS instance while capturing, made some others pop up: 0x0003 and 0x0004.

So we are assuming the 0x0003 and 0x0004 packets are related to establishing a connection. Also we could see the node initiating a connection sends a 0x0003 packet, which is then replied to by a 0x0004 packet.

Then most information is sent via 0x0002 packets. However every now and then there comes a pair of 0x0006 packets, who’s length seems to prevent being used to transfer any data. We are therefore assuming these packets are used for syncing.

As mentioned before we did a lot of automatically splitting up PCAPNG files into separate ones depending on different conditions, because this allowed to browse through similar packets using simple human pattern recognition for decoding.

Pretty soon after starting to splitting up the streams, so the communication between two nodes was separated into one separate file, we did notice what we assumed to be a connection-id and a mesasage-counter instantly following the type.

However when doing the statistical counting and listing of these values, we noticed that after the message-id 0xFF came the 0x00, as we would have expected, but the assumed connection-id was also incremented by one. So it turned out that the similarity of the first byte were not due to a connection-id, but rather the counter of just having the same first byte. After the type byte seems to come a message-id counter. It seems as if this initialized to some random value during the connection establishment and is then incremented with every message.

However our little check did reveal, that this id is identical for a packet following a 0x0006 packet. Therefore we are assuming the 0x0006 packets are used to sync the connection between two nodes.

The short value (or a byte value following a 0x00 byte), after this message id seems to be constant for every message sent from ine node to another, but we think to have seen one node use different values for communicating with different nodes. Also it seems that all Controllers seem to have values from 0x0000 to 0x0009 and OSes seem to have values from 0x000A to 0x000F. We are assuming this is some sort of sender-id value.

The following 3 bytes were quite a mystery to us. We could see that it seems to be an ever increasing number stored here, however the increment was not linear. However when interpreting these 3 bytes as a number and filtering only packets initiated by the controller to one particular OS, filtering out Ack messages by accident, we did notice a certain pattern. When correlating that to the capture file, we could see that the pattern correlated to the pattern in the communication. We were told, that the OS is configured to update the values once a second and could see that pattern in the capture. Here was when we noticed that the numeric value in the 3 bytes followed this pattern. In the end it turns out that if we interpret this 3 byte number where the first 14 bits encoding seconds and the following 10 bits the sub-second part, the values in the timestamp matched the timestamps of the pacet capture.

We have to admit that we were a little surprised about this. Currently we are assuming that this timestamp is used for tracking transmission times. 4 bytes would allow quite a time-range, but would come at a cost of one additional byte per packet, that wouldn’t be needed for simple run-time checking. Two bytes however only would allow to encode only about 63 seconds, which is probably too little when thinking about packet-losses and re-transmissions. So in the end we assume these 3 bytes are a simple timestamp.

As mentioned before, the following byte is usually 0x80 except for the first packet every party exchanges with the other side. In this case the value is 0x00. So we’ll just keep that in mind an not worry about interpreting a meaning into this. The last two bytes of the wrapper packet header are simply constantly 0x8000 in every packet. Here too, we’ll just live with knowing that and not wondering what it could mean.

After having decoded what we think is the wrapper-protocol packet structure, we knew decoding the internal protocol would be a bigger challenge.

Therefore the test-setup was changed a little.

The number of controllers and operator-systems were reduced to one each. The OS was changed to display only one single value of the controller. A simulator was introduced, which was connected to the controller and communicated to this via ProfiNet protocol. This simulator allowed us to provide values to the controller via the backend ProfiNet connection.

With this setup we started working on the payload decoding.

The first two bytes of the payload seem again to relate to a type as similar packets usually had identical values here.

Especially we did a lot of separate captures for all sorts of different operations. During this we managed to reverse engineer the connection on the wrapper-protocol layer as well how the communication looks inside the internal protocol.