Using modbus-cli to Read and Write Modbus registers in LabShock
In the previous post — “Using modbus-cli to Read and Write Modbus Coils in LabShock” — I showed something simple:
We were able to read and write Modbus coils… with no authentication.
In this part, I continued the experiment inside LabShock (OilSpring Air lab), but instead of coils, I focused on actual process values—and also writing directly to registers.
The Setup (Operator View)
From the OpenPLC monitoring dashboard, everything looks clean:
You just see:
That’s the operator view.
Reading via Modbus (What We Did)
After installing modbus-cli, I ran:
modbus read 192.168.2.10 %MW10 20
Quick breakdown:
So we dump:
What We Got
From the output:
One command → raw memory view.
Making Sense of %QW, %IW, %MW
%QW10 → Output
What the PLC sends (e.g., pump speed)
%IW10 → Input
What the PLC reads (sensor values)
%MW10 → Memory
Internal storage used by the program
Why We Saw Those Values
Even though the dashboard shows %QW and %IW, we read %MW.
That’s because PLC logic often copies values internally:
%QW10 → %MW10
%IW10 → %MW20
So:
We didn’t read outputs or inputs directly—we read their copies.
Writing to a Register (New Part)
Now the important part.
We didn’t just read—we also wrote to memory.
modbus write 192.168.2.10 %MW10 60
Breaking It Down
Recommended by LinkedIn
So:
Write value 60 into memory address %MW10
What Happens After Writing
If you check:
You will see the value change.
To confirm from CLI:
modbus read 192.168.2.10 %MW10 1
This reads only one value.
You should now see:
Why This Is Important
This is not just reading anymore.
This is:
Direct modification of PLC data
Depending on the logic, this could:
Operator vs What We Did
What This Proves
This reinforces the same point as Part 1:
Modbus is not secure by design.
We were able to:
All of this:
Why This Matters
1. Read = Recon
You can map the system just by reading.
2. Write = Impact
You can influence the system by writing.
3. No Barriers
If you can reach the PLC:
You can interact with it.
What Defenders Should Take From This
Final Thought
Part 1 showed we can control coils. Part 2 shows we can read and modify process values.
When a protocol lets you read and write critical data with no authentication, that’s not a misconfiguration — that’s the design.
And once you see that layer, you’re no longer looking at the system like an operator… you’re seeing it like an attacker.
This analysis perfectly highlights the critical fragility of OT systems. The real danger isn't just the exposure of protocols like Modbus, but the perceptual misalignment: while the operator's screen displays normalcy, the network is already telling a completely different story. This 'invisibility' of the attack is the perfect breeding ground for what I call the 'arsonist firefighter' paradox. If those managing the defense also control the visibility of the traffic, they can easily conceal a threat until it becomes profitable to reveal it. The security of critical infrastructures cannot rely on blind faith in what appears on a dashboard; it must be built on independent monitoring and the total integrity of the software chain of command.
Agree with Zakhar, Great write up... Thanks for sharing.
Thanks for sharing your knowledge
Welldone Sulaiman Alhasawi
Many thanks Sulaiman Alhasawi for using Labshock and documenting the process! This is exactly what real OT Security should look like in practice. This is the mission behind Labshock: make OT Security testable, not only documented