How I Learned to Research Industrial Protocols

By RUGERO Tesla (@404saint).

Nine industrial protocols later, the protocol research series is over. When I started it, I thought I was going to learn industrial protocols, and that was true, but it turned out to be only part of what I was doing because I was also learning how to research them.

My first attempt looked very different from my last one. I built larger labs than I needed, chased details without knowing why I was looking for them, and sometimes treated the protocol itself as the scope of the research, but that changed over time.

I started asking better questions, building smaller experiments, writing my own harnesses, capturing traffic, and using the packets themselves as evidence. The research became less about trying to understand everything a protocol could possibly do and more about answering specific questions about how it actually behaved.

This article is about that change.

Why I ended up in ICS/OT

I did not start in cybersecurity with a clear plan to work in industrial security. I honestly started because hacking looked interesting. At the time, most of what I knew about hacking came from the usual places. Movies, pop culture, CTFs, and the general idea that cybersecurity was about finding a way into something. But learning the actual field changed that picture quickly.

Real systems were more complicated than the movies made them look. Security was not just about typing a few commands and suddenly having access to a machine. There were networks, applications, authentication, configurations, operating systems, people, and a lot of other things between an idea and a successful attack. That complexity did not bother me at all, in fact, I eventually found industrial systems even more complex. What really bothered me was the type of work I was trying to become good at.

I realized that I enjoyed building systems and then breaking them much more than I enjoyed constantly trying to find the next bug. I learned better when I could create a controlled environment, understand how its components worked together, change something, observe the result, and then try to break my own assumptions. That was also how I had been learning cybersecurity in the first place. So I started looking for a part of the field where that way of thinking made sense and that eventually led me to ICS/OT.

My first real step was not a protocol research project

Before I had a protocol research methodology, I had Modbus Exposure Analyzer. When i started, the idea was simple. I wanted to build a tool that could identify exposed Modbus services and help analyze what they exposed. At first, I thought I could test it against systems I found on shodan, but that idea did not last very long. I quickly learned that industrial systems are not ordinary Internet services that should be treated as convenient targets for experimentation. If I wanted to test my tool safely, I needed something I controlled. So I built a local Modbus environment and tested the tool there. That small decision ended up influencing almost everything that came afterward.

If I wanted to understand an industrial protocol, I could build an environment around it. If I wanted to test something, I could reproduce it locally. If I wanted to capture traffic, I could generate the traffic myself. The first article I published about that work was also my first time publishing on dev.to. I did not have a publishing strategy at the time. I mostly wanted to put the work somewhere other people could see it and try it. I did not know it yet, but I had started building the foundation for the rest of the project.

I built much more lab than I needed

When I decided to properly study industrial protocols, I started with a roadmap. The plan was to learn protocols first, then PLC architecture and runtimes, then control logic, firmware analysis, firmware extraction, reverse engineering, and whatever came after that. The protocol part sounded straightforward, but oh boy was i wrong!!

I started building zero-cost laboratories with OpenPLC, FUXA, Docker, virtual machines, GNS3 and different protocol implementations. The environments became more complicated because I thought a better research environment needed to look more like an actual industrial environment. To be honest, there was value in that. I learned how the components fit together. I learned about the relationships between controllers, HMIs, engineering systems and networks. I started understanding the difference between a protocol in isolation and a protocol operating as part of a larger system. But I also started discovering a problem. Sometimes the laboratory was becoming more complicated than the question I was trying to answer. And at the beginning, I did not even have a clear question.

The rabbit holes

My early research was often driven by curiosity rather than a defined research goal. Modbus is probably the clearest example. I initially wanted to examine the function codes. That sounds reasonable until you realize how easily that turns into an endless checklist.

What about this function? What about that one? What happens with this exception? What happens with another implementation? What happens with malformed input? What happens when the device is in another state? There is always another question. The protocol itself becomes the scope, and there is no obvious point where you are finished. But guess what? DNP3 changed that for me.

I started defining what I actually wanted to investigate before trying to investigate everything the protocol could possibly contain. That did not make the research complete and I don't think any of these projects should be described that way, but it gave the research boundaries. Instead of asking, "How much of DNP3 can I learn?", I could ask, "What do I want to establish about DNP3?" I stopped trying to finish protocols, and i started trying to answer questions about them.

The laboratory got smaller

This was probably the biggest methodological change in the entire series. I quickly realized that I did not always need a complete industrial environment to answer a protocol question. If I wanted to understand a particular exchange, I needed to generate that exchange. If I wanted to understand a request, I needed to send the request. If I wanted to understand the response, I needed to capture it. That meant I could often work with a local implementation of the protocol, write a small harness around it, generate the interaction I wanted, capture the traffic, and inspect the result with Wireshark or tshark.

The laboratory became much smaller and the research became more focused.

My workflow started looking more like this:

Research question → local implementation → harness → packet capture → packet analysis → interpretation

That was enough for a surprising number of the questions I wanted to answer. I did not need to recreate an entire power station to study a particular IEC 104 exchange, and I did not need to build a complete factory to investigate a protocol mechanism because a result from a software-defined laboratory either. I just needed a controlled implementation, a way to interact with it, and evidence of what happened. That realization also changed how I thought about the purpose of a lab. A good laboratory does not have to look impressive. It has to give you control over the experiment. I had confused a realistic environment with a useful research environment, but they are not always the same thing.

The wire became evidence

This was another change that happened gradually.

Early on, packet captures were not always treated with the discipline I would use today. Sometimes I captured traffic because it was useful to have. Sometimes I relied more heavily on what the implementation or documentation told me. As the series progressed, that changed and I started treating the packet capture as evidence.

If I said something happened on the wire, I wanted to be able to look at the traffic. If I described a request and response, I wanted to see them. If I claimed that a particular field changed, I wanted the capture to support it. And that did not make the research perfect, but it sure made the boundary between what I observed and what I believed much clearer, and it also made the research more reproducible.

Someone else could build a similar environment, generate the same interaction, capture the traffic and see whether the same thing happened. That became more important to me than making the laboratory look realistic.

The implementations became part of the experiment

Another thing changed along the way.

I stopped thinking of protocol implementations only as software I needed in order to run a lab. They became experimental subjects. Open-source implementations and local stacks gave me something I could interact with safely. Sometimes I used high-level libraries. Other times I wanted to get closer to the protocol and construct interactions myself.

The point was not to pretend that one implementation represented every device in the field. It was to understand what I could establish from a controlled implementation. That difference became increasingly important as the research became more serious because result from a software-defined laboratory is a result from that laboratory. It does not automatically become a claim about every vendor implementation or every production system. Once I understood that boundary, I did not need to make the laboratory larger to make the research more valuable. I only needed to make the experiment clearer.

Nine protocols, one changing method

The protocols kept changing.

✔ Modbus TCP.

✔ EtherNet/IP and CIP.

✔ DNP3.

✔ BACnet/IP.

✔ OPC UA.

✔ IEC 60870-5-104.

✔ IEC 61850.

✔ PROFINET.

✔ S7comm.

They have different architectures, transports, message structures, security mechanisms and assumptions. But as the series progressed, the questions underneath the individual protocols became more consistent.

⟶ How does communication start?

⟶ What does a legitimate exchange look like?

⟶ Where is trust assumed?

⟶ What does authentication actually protect?

⟶ What remains exposed when security mechanisms are missing?

⟶ What can an observer learn from the traffic?

⟶ What can an attacker influence?

⟶ What happens when an implementation behaves differently from what I expected?

⟶ What evidence can I establish in the laboratory?

And perhaps most importantly:

⟶ What am I actually trying to prove?

The last question helped me avoid a lot of rabbit holes. It also changed how I approached each new protocol. I was no longer starting from zero every time. I had a method that had been shaped by the previous investigation.

The methodology was part of the research

Looking back, I don't think the biggest result of this series is that I learned nine industrial protocols. It's that I learned how to investigate them. The methodology changed because the research kept challenging it. I tried different laboratory designs and different implementations. I moved between high-level libraries and lower-level interactions, wrote harnesses, captured packets, parsed them with tshark, and compared what I expected with what actually crossed the wire. I became more deliberate about evidence and learned to define research goals before allowing myself to explore every possible direction.

None of that was part of some perfect methodology I had from the beginning. The methodology grew alongside the research. In that sense, the series was an experiment in two things at the same time. I was studying industrial protocols, but I was also figuring out how I needed to study them.

Making the work accessible

There is another reason I kept using software-defined laboratories... I wanted the work to be accessible. You should not need expensive industrial hardware just to start learning how an industrial protocol works. You should not need to buy a large training environment before you can inspect a packet. And you should not need to spend thousands of dollars before you can begin experimenting with OT security.

That does not mean a software-defined lab can reproduce every property of a production industrial system, because it cannot. But for many protocol-level questions, a controlled local implementation is enough to learn something real, reproduce it, and share the evidence. That was part of the point of the project. If I could learn something without spending money, I wanted to document it so somebody else could learn it too. The main investment was time.

The research grew beyond the repository

The technical work was changing, but the way I shared it changed too. I started on dev.to. And eventually I expanded to HackerNoon because I wanted the work to reach more people. When the editorial process became too slow for the pace at which I wanted to publish, I started putting the work on my own website.

At first, the website mostly pointed somewhere else, but eventually, I built my own Markdown rendering system and made the website the home of the articles. I also started sharing the research progress on LinkedIn again. That led to conversations with industrial professionals and researchers, and eventually to people with much more field experience than I had giving me feedback on the work. Publishing the research publicly meant that the methodology was no longer something I was developing in isolation. People could question it, they could add context, and they could point out things I had missed.

What I would change

There is plenty I would do differently if I started the series today.

I would define the research question earlier, capture evidence earlier, avoid building infrastructure that the research question does not require, and be more careful about separating what I observed in a laboratory from what I could reasonably say about production systems.

And I would probably spend much less time trying to understand everything, but I would not erase the early versions of the work. They are part of how I learned what needed to change. And the goal was never to produce nine perfect protocol investigations, but to keep getting better at the investigation.

The portfolio

One of the reasons I documented all of this was simple.

I wanted the work itself to speak for me. I am not finishing this series with a collection of certificates. I am finishing it with repositories, code, laboratories, packet captures, notes, articles and a methodology that someone can actually inspect. That is important to me because a portfolio can become a CV. Someone can look at the work and see how I approach an unfamiliar system. They can see how I build a laboratory, how I investigate a protocol, and how I write code, capture evidence, document findings and communicate what I learned. That is more useful to me than simply saying that I studied something.

If you want to go deeper

This article is a retrospective, so there is a lot that I had to leave out.

If you want to see how the methodology actually changed, I would encourage you to go through the research itself. Read the protocol articles, look through the notes, inspect the code, and explore the research repository. The individual projects contain much more technical detail than I could fit into this retrospective, and some of the differences between the early and later work are much easier to see there.

The repository is also where the research process is most visible. You can see the laboratories, the scripts, the protocol implementations, the packet analysis and the experiments behind the articles. I don't expect every part of the series to be perfect, and that was never the point. I just want the work to be open enough that you can examine it yourself, reproduce parts of it, disagree with something, or take something useful from it.

The articles tell the story, the repository shows the work, and if you're interested in ICS/OT security, I hope you find something there worth building on.

The series is over

S7comm was the final protocol in this series.

When I started with Modbus, I was trying to understand what the protocol could do. By the time I reached S7comm, I was more interested in asking a smaller and more useful question:

What exactly do I want to establish, and what evidence do I need to establish it?

That change is probably important to me than the number of protocols I completed. The protocols were the subject of the research while the methodology became one of its results. And perhaps, this is where I leave the protocol series. There is more to learn, and there is another series coming. I am not going to explain it yet. You'll see it when it starts. For now, the protocol work is done, and I'm just getting started!