Industrial Control with Modbus
by Malvineous
With recent news articles about network attacks on power grids and other infrastructure, one may be forgiven for wondering how exactly a circuit breaker can be controlled over the Internet, and how one would even begin to look for such vulnerabilities.
To help provide some answers, this article hopes to be an overview of the Modbus protocol and how it is used to control such industrial devices. Some tips are also provided at the end for anyone wishing to find inexpensive Modbus devices they can use to further their understanding of how one can control real-world devices via simple computer programs. There are many such devices available, from temperature sensors to electricity meters to relay control boards that can switch power on and off to other devices.
But first, to put everything into context, a little history.
What is RS-232?
Many readers will be familiar with RS-232, the standard specifying the electrical signals used for the serial ports found on so many computers over the last few decades. Before USB, and even for quite some time afterwards, these ports were used for connecting peripherals such as dial-up modems. They are still commonly used for configuring industrial devices and as a fallback for some commercial Ethernet-connected devices, so they can still be accessed when the network is unavailable.
One limitation of RS-232 is that it is a point-to-point connection, allowing communication between only two devices. Electrically, this is because the transmitters at each end of the connection are active at all times, even when no data is being sent. This means that should two transmitters be connected to the same wire, they will work about as well as listening to two people shouting at the same time - neither can be heard clearly, if at all, each drowning out the other.
A side effect of this is that RS-232 must be full-duplex, allowing data to flow in both directions at the same time, because each end of the connection needs a dedicated wire to transmit on. So for RS-232, separate wires for transmitting and receiving are required.
What is RS-485?
To address some of the limitations in RS-232, RS-485 was created. Like RS-232, all devices must still select a common baud rate to operate at, although RS-485 can go all the way up to 10 Mbps. RS-485 also requires that the transmitters be switched off when no data is being sent, allowing multiple transmitters to share the same wire. As a consequence, all receivers need to listen on the same wire as well, making RS-485 half-duplex. Although this is a small drawback, it is greatly outweighed by the benefits of being able to connect many devices to the same wire run. (There are also some schemes that run two RS-485 buses in parallel to achieve a kind of full-duplex, so it's not really that much of a drawback anyway.)
This may appear to be a bit like a rudimentary Ethernet network, for those readers who remember the days of 10 Mbps thin Ethernet (10Base2) with its coax cables, allowing multiple computers to be connected to a single cable run. In fact, RS-485 shares a number of similarities with thin Ethernet, but in some regards offers more flexibility.
While thin Ethernet required both ends of the cable to have terminating resistors installed in order to operate, with RS-485 these are only needed for high speed operation. At lower speeds the terminators can be omitted, and a reduced speed also allows the maximum length of the cable run to be far longer - over ten times longer than Ethernet's 100 meter/300 foot maximum. (As a side note, the early parallel SCSI interface used many RS-485 lines in parallel to make up the 50-pin SCSI bus. This is also why sometimes these old SCSI buses would appear to work on short cable runs even when the termination wasn't set up properly.)
Unlike Ethernet, RS-485 only deals with getting bytes from one device to all the others. It does not have MAC addresses, collision detection, a concept of data packets, or any of the other features of Ethernet. With RS-485, all this must be done in software by a higher level protocol, just as it did with RS-232. All you get from the RS-485 interface is a stream of bytes, and it's up to you to decide what these bytes should represent, and indeed if they are even correct, since significant noise on the line can corrupt the data.
This means when using RS-485, you must define the set of rules used by all devices on the bus. If two devices transmit at the same time, the result will be garbled, so you need to come up with some protocol to prevent this from happening in the first place.
What is Modbus?
With RS-232, ascribing meaning to the bytes traveling over the wire was often done with higher level protocols such as SLIP and PPP. With RS-485, a very common protocol that does the same is Modbus. Originating in 1979, Modbus is an early protocol and is very simple by today's standards. However, with that simplicity comes robustness, and many modem industrial devices still use Modbus for control today. Modbus is also effectively an open standard, while many of the competing (and often superior) standards such as BACnet cannot be obtained without payment, preventing them from fully replacing Modbus.
To prevent collisions on the wire, Modbus works in a master-slave arrangement. There is only one master device on the RS-485 bus, and it requests data from up to 247 slave devices (although practically speaking, RS-485 maxes out at around 32 devices per bus). After the master initiates a request from one of the slave devices, that slave is allowed to transmit its response. This arrangement ensures only one device is ever transmitting at a time, avoiding collisions. A CRC code in each message guards against any corruption from noise on the line.
Conceptually, Modbus devices are based on numbered registers, each of which can hold a numeric value. The Modbus master sends messages such as "read register X" or "write X to register Y," with the device returning an appropriate response. For an electricity meter, one register may contain the current mains voltage, while a different register may contain the current rate of power consumption in watts. Since the registers are addressed only by numbers, it is crucial to have a register map for the device you are working with, so that you can find out which register contains the information you are seeking, and which registers must be written in order to trigger the action you need.
There are 65,536 possible registers in each category, and there are three categories. The first category is called "coils," so named as they were originally used to turn the coils in relays on and off in order to control devices like heaters and air conditioning compressors. These registers are only a single bit wide so are not commonly used now, with the other two categories being preferred as each of those registers is 16 bits wide. Sadly, there is no standard about the endianness of each register value (endianness is the direction of the bits within a byte - do they come in as 12345678 with the 1 first, or 87654321 with the 1 last), so some devices will supply their 16-bit register value in little endian order and others in big endian, and again the register map must be consulted to discover which order a particular device uses.
Often two registers will be combined to store a 32-bit or 64-bit value (either as an integer or a floating point), however, like the endian issue , here care must also be taken to discover in which order the two registers are combined. Generally speaking, registers are mapped directly into the memory of the microcontroller on the device, so little endian values in each register should mean registers are combined in little endian order to read any 32- or 64-bit values. However, it is unfortunate that sometimes devices are encountered that combine registers together in one endian order, but return each register value within as a different endian order, which certainly creates a headache for the programmer!
How Do I Speak Modbus?
There are many cheap USB-to-RS-485 adapters available from the usual places, costing as little as a dollar including postage from China. These devices appear as standard USB serial ports, so they don't need any additional drivers to operate, appearing as /dev/ttyUSB0, COM1:, or similar depending on your OS.
In the network connected world, there are many Modbus gateways that can provide an interface between the RS-485 bus and a TCP/IP network. Typically, these will listen on TCP port 502 and, once connected, the bytes sent and received over the TCP connection are identical to those sent over the RS-485 bus. For this reason, most Modbus utilities will let you specify either a serial port or an IP address when using them for communication.
There are a huge number of devices that speak Modbus, however, as many of them are industrial, they tend to be on the expensive side. Searching for [ (rs485,modbus) -usb ] on eBay or similar will give you an idea of what is available (this will match anything containing "rs485" or "modbus," but ignore anything containing "usb" so that all the USB-to-RS-485 adapters don't clutter the search results). You will find things like humidity sensors and relay boards, however, bear in mind that this is less likely to show industrial devices such as variable-frequency motor drives as those are assumed to have Modbus or equivalent interfaces, so this isn't usually highlighted and you need to go digging in the specs to find out.
Before purchasing any Modbus device, make sure it either comes with a register map or that you can find one online, as without this it will be very difficult to figure out which register values mean what.
How Do I Use Modbus?
As Modbus is a relatively non-descriptive protocol (i.e., there is no hint what a register might be for unless you consult documents that are not part of the protocol), there are limited utilities available for working with it. There are programs specific to certain devices, like Network UPS Tools (NUT) that can only speak to specific models of backup power supply via Modbus, and there are general programs like mbpoll that are mainly useful to perform raw reads and writes on Modbus devices to confirm you are reading the register map correctly.
To actually do anything useful with your device, you will likely have to write your own program to provide an interface between the Modbus registers and the system you want to connect the device to. For example, I have written a program that queries an electricity meter connected to my computers, and if the power drops below a certain threshold, it means the monitors on all the PCs have gone into sleep mode, implying that everyone must have left the room. The program then writes to a couple of registers on a relay board which shuts off power to the sound system and the lights. The data is also logged to a time-series database, which is useful for displaying dashboards. In my case I am displaying the temperature and humidity in different rooms read from Modbus sensors located in each one, as well as the predicted cost of my next electricity bill based on my power use so far in the current billing period.
While this is far from any form of industrial control, it has at least allowed me to put my "play" devices to some use now that I have learned a great deal from them.
How Do I Hack a Power Grid?
While Modbus is one of the protocols used in SCADA systems, there are a number of others such as PROFIBUS and BACnet. BACnet in particular provides much more information about what each data point means and controls, but it is still far from self explanatory. In short, it means that remotely exploring SCADA infrastructure is not an easy task, and will likely start with an unrelated compromise in order to gain access to schematics, network architecture, and other documentation. Without this, figuring out how a network of Modbus devices are arranged, what they do, and the implications of sending them control messages would be exceedingly difficult to discover.
The remote network would also almost certainly need to be compromised, as most organizations are now at least aware that these devices have no support for any kind of security. They are typically placed on an isolated VLAN, not even accessible from the rest of the corporate network. Gaining access to this restricted VLAN is likely to be quite difficult, involving the compromise of an accessible device that has access to the restricted VLAN, such as a reporting interface or a PC used for managing the SCADA systems.
It would appear that some of the recent attacks making headlines were able to get malware onto the PCs controlling the SCADA systems, making the accomplishment even more impressive as this suggests that the attackers had no access to the target network. How they managed to figure out what IP addresses things were listening on, what protocols to use, which registers to write to and the correct values to write is amazing if all they had to work with was a simulated environment built around stolen schematics. Apparently, the attack on Ukraine's power grid was foiled because at the last moment the commands were sent to the wrong IP address, so maybe a device was replaced or moved at some point and the attackers were working off older documents? Or perhaps forgetting to update the documentation isn't always bad...