Introduction
Today, let’s discuss Modbus, starting with the main content of today:
01 Terminology Interpretation
02 Background
03 Protocol Principles
04 Transmission Methods
05 Differences Between Modbus RTU and Modbus ASCII
06 Modbus TCP and Its Considerations
07 Function Code Roles
08 Security Analysis of Modbus Protocol
01 Terminology Interpretation
Checksum: A checksum is typically the last digit of a group of numbers, derived from the preceding numbers through a certain calculation, used to verify the correctness of the data group. Errors can easily occur when inputting data as code into computers or other devices, so coding experts have invented various checksum methods to reduce such input errors, establishing checksums based on these methods.Common checksums include: Sum, XOR, LRC, CRC…
Discrete Input: Mainly used to read data of a single bit, such as the status of an I/O;
Coil: Switch output signal, mainly used to write a single bit of data, performing bitwise operations with discrete inputs;
Input Register: Mainly used to read 16 bits, or two bytes of data;
Holding Register: Mainly used to write 16 bits of data;
PLC: Programmable Logic Controller, a type of programmable memory used for storing programs internally and executing logical operations, sequential control, timing, counting, and arithmetic operations directed towards user instructions, controlling various types of machinery or production processes through digital or analog inputs/outputs.
Serial Communication: With the application of computer systems and the development of microcomputer networks, communication functionality has become increasingly important. Communication here refers to the exchange of information between computers and the outside world. Therefore, communication includes not only between computers and external devices but also between computers themselves. Since serial communication transmits information one bit at a time over a single transmission line, it requires fewer transmission lines and can utilize existing telephone networks for information transmission, making it particularly suitable for long-distance transmission. For devices like terminals, printers, logic analyzers, and disks that are not far from the computer, serial data exchange is also common. In real-time control and management, communication between CPUs in a hierarchical distributed control system is generally serial. Thus, serial interfaces are commonly used in microcomputer application systems. Many peripherals and computers communicate in a serial manner, where this serial method refers to the information transmission method between peripherals and interface circuits, while the CPU and interface still operate in parallel.
Serial Port: A serial port is a very common device communication protocol on computers, not to be confused with the Universal Serial Bus (USB). Most computers contain two RS232-based serial ports. The serial port is also a universal communication protocol for instrumentation and equipment; many GPIB-compatible devices also have RS-232 ports. Additionally, serial communication protocols can be used to obtain data from remote collection devices.
The concept of serial communication is straightforward; serial ports send and receive bytes bit by bit. Although slower than parallel communication, which sends by byte, serial ports can send data on one line while receiving on another. It is simple and capable of achieving long-distance communication. For example, while IEEE488 specifies that the total length of device lines must not exceed 20 meters and the length between any two devices must not exceed 2 meters, serial communication can reach lengths of up to 1200 meters.
Typically, serial ports are used for the transmission of ASCII characters. Communication is completed using three lines: ground, transmit, and receive. Since serial communication is asynchronous, the port can send data on one line while receiving on another. Other lines are used for handshaking but are not mandatory. The most critical parameters of serial communication are baud rate, data bits, stop bits, and parity. For two ports communicating, these parameters must match:
a. Baud Rate: This is a parameter that measures communication speed, indicating the number of bits transmitted per second. For example, 300 baud means sending 300 bits per second. When we refer to clock cycles, we mean baud rate. For instance, if a protocol requires 4800 baud, the clock is 4800Hz, meaning the sampling rate of serial communication on the data line is 4800Hz. Typically, baud rates for telephone lines are 14400, 28800, and 36600. Baud rates can be much higher, but they are inversely proportional to distance. High baud rates are often used for communication between closely placed instruments, a typical example being GPIB device communication. b. Data Bits: This parameter measures the actual data bits in communication. When a computer sends a packet, the actual data will not be 8 bits; standard values are 5, 7, and 8 bits. How this is set depends on the information you want to transmit. For example, standard ASCII code is 0–127 (7 bits). Extended ASCII code is 0–255 (8 bits). If the data uses simple text (standard ASCII), each data packet uses 7 data bits. Each packet refers to a byte, including start/stop bits, data bits, and parity bits. Since actual data bits depend on the chosen communication protocol, the term “packet” refers to any communication situation. c. Stop Bits: Used to indicate the last bit of a single packet. Typical values are 1, 1.5, and 2 bits. Since data is timed on the transmission line and each device has its own clock, there may be slight asynchrony between two devices during communication. Thus, stop bits not only indicate the end of transmission but also provide an opportunity for the computer to correct clock synchronization. The more stop bits used, the greater the tolerance for clock synchronization discrepancies, but the data transmission rate is also slower. d. Parity Bit: A simple error checking method in serial communication. There are four error checking methods: even, odd, high, and low. Of course, no parity bit can also be an option. For even and odd parity, the serial port sets a parity bit (one bit after the data bits) to ensure that the number of logical high bits transmitted is even or odd. For example, if the data is 011, then for even parity, the parity bit is 0, ensuring an even number of logical high bits. If it is odd parity, the parity bit is 1, resulting in three logical high bits. High and low bits do not truly check the data but simply set a logical high or low for checking. This allows the receiving device to know the state of a bit, providing an opportunity to determine whether noise has interfered with communication or whether the transmitted and received data are out of sync.
02 Background
In 1971, Modicon first launched the Modbus protocol, which gave birth to Modbus RTU and Modbus ASCII. Later, Schneider Electric acquired Modicon and introduced the Modbus TCP protocol in 1997. In 2004, the National Standards Committee of China officially made Modbus a national standard, marking the beginning of Modbus’s contribution to industrial communication in China.
Through this protocol, controllers can communicate with each other and with other devices via the network. The Modbus protocol is characterized by its standardization, openness, support for various electrical interfaces, simple and compact data frame format, large data transmission volume, and good real-time performance, making it widely used in industrial control systems and becoming a general industrial standard. An in-depth analysis of the Modbus protocol’s implementation principles and security is of significant practical importance for enhancing the security of industrial control systems. Modbus RTU and Modbus ASCII are primarily used in serial communication, while Modbus TCP is commonly used in Ethernet communication. Today, Modbus has become the standard communication protocol in the industrial field and is a commonly used connection method between industrial electronic devices.
03 Protocol Principles
Modbus uses a simple Master and Slave protocol (client/server protocol) for communication. The client acts as the master and sends requests to the server; upon receiving the request, the server (slave) analyzes it and responds. The communication frame used is called the Application Data Unit (ADU), which includes the communication address segment, function code segment, data segment, and checksum segment, as shown in the figure below:
Generally, monitoring systems (HMI) serve as the Master, while PLCs, electric meters, and instruments serve as Slaves. The HMI system continuously polls various relays and registers from the Slave to obtain the latest values, which are then displayed and processed for various logical calculations and control adjustments.
The combination of the function code segment and the data segment is referred to as the Protocol Data Unit (PDU). The function code segment occupies one byte, with a value range of 1-255, where 128-255 are reserved values for exception message response packets. The range of 1-127 is for function code numbers, with 65-72 and 100-110 reserved for user-defined codes.
04 Transmission Methods
The Modbus protocol is an application layer message transmission protocol that includes three message types: ASCII, RTU, and TCP. The protocol itself does not define the physical layer; it only defines the message structure that controllers can recognize and use, regardless of the network used for communication.
When using the Modbus protocol for serial transmission, either RTU or ASCII mode can be selected, with specified message, data structure, command, and response modes requiring data verification. The ASCII mode uses LRC for verification, while the RTU mode uses 16-bit CRC verification. When transmitted over Ethernet, TCP is used, and this mode does not use verification since the TCP protocol is a reliable, connection-oriented protocol.
05 Differences Between Modbus RTU and Modbus ASCII
Modbus is an application layer protocol that defines data units (ADU) independent of the underlying network, allowing communication over Ethernet (TCP/IP) or serial links (RS232, RS485, etc.) (Ethernet ADU and serial ADU are slightly different). On serial links, the Modbus protocol has two transmission modes—ASCII mode and RTU mode. ASCII stands for American Standard Code for Information Interchange, while RTU stands for Remote Terminal Unit.
First, let’s look at how Modbus works.
Modbus adopts a master-slave communication mode, where only the master device can initiate the transmission, and the slave device responds based on the master’s request. Typical master devices include field instruments and display panels, while typical slave devices are programmable logic controllers (PLCs).
In master-slave communication over serial links, a Modbus master device can connect to one or N (up to 247) slave devices. Communication between master and slave devices includes unicast and broadcast modes.
In broadcast mode, the Modbus master device can simultaneously send requests to multiple slave devices (address 0 is used for broadcast mode), with slave devices not responding to broadcast requests.
In unicast mode, the master device sends a request to a specific slave device (each Modbus slave device has a unique address), and the request message frame contains function codes and data, such as function code “01” used to read the status of discrete coils. Upon receiving the request, the slave device responds and sends the message back to the master device.
In communication between master and slave devices, either ASCII mode or RTU mode can be used.In ASCII (American Standard Code for Information Interchange) transmission mode, the message frame starts with an English colon (“:”, ASCII 3A Hex) and ends with a carriage return and line feed (CRLF, ASCII 0D and 0A Hex), allowing for hexadecimal characters 0-9 and A-F; the slave devices on the network monitor the transmission path for the English colon (“:”). If present, they decode the message frame to check whether the address in the message matches their own address, and if so, they accept the data; if not, they ignore it.
In ASCII mode, each 8-bit byte is split into two ASCII characters for transmission; for example, the hexadecimal number 0xAF is split into ASCII characters “A” and “F” for transmission, doubling the number of characters sent compared to RTU. The advantage of ASCII mode is that it allows for a gap of up to 1 second between characters without causing communication failure. This mode uses Longitudinal Redundancy Check (LRC) for error checking.
When the controller is set to communicate on the Modbus network in RTU mode, each 8-bit byte contains two 4-bit hexadecimal characters, and this mode has no start and end markers. Its advantage is that it can transmit more data at the same baud rate.
In RTU (Remote Terminal Unit) mode, each byte can transmit two hexadecimal characters; for example, the hexadecimal number 0xAF is sent directly as hexadecimal 0xAF (binary: 10101111), thus its transmission density is twice that of ASCII mode. RTU mode uses Cyclic Redundancy Check (CRC), and the summary of RTU mode is as follows:
The specific format is shown in the figure below:
06 Modbus TCP and Its Considerations
6.1 Host and Slave, Server and Client
[In the Modbus protocol]
The host sends a Modbus request, and the slave responds based on the request content. In the Modbus protocol, the host is always the active party, while the slave is always the passive party.
[In network applications]
In network applications, there are clients and servers; the client (e.g., a browser) sends requests to the server, and the server returns content (e.g., HTML text) to the client.
[In Modbus TCP]
The host is the client, while the slave is the server. Do not think that the server is more important; the host is also important, so the host is the server.
6.2 Can There Be Multiple Hosts?
From the previous analysis, since the host is the client, Modbus TCP supports multiple hosts, allowing for multiple hosts and slaves within a local area network. The connection capacity of the slave (number of hosts it can connect to) is determined by the maximum number of TCP connections of uIP.
6.3 Brief Overview of Modbus TCP Protocol
Modbus TCP is fundamentally similar to Modbus RTU, but there are some differences.
a. The slave address becomes less important and is often ignored. In a sense, the slave address is replaced by the IP address.
b. CRC checking becomes less important and can even be ignored. Since TCP packets already include checks, Modbus TCP simply cancels CRC checking to avoid redundancy.
The TCP mode was developed to facilitate the smooth transmission of Modbus data over Ethernet, using TCP port 502. This protocol’s physical layer, data link layer, network layer, and transport layer are all based on TCP protocol; only at the application layer is the Modbus protocol modified and encapsulated. The receiving side unpacks the TCP packet to retrieve the original Modbus frame, which is then parsed according to Modbus protocol specifications, and the returned data packet is repackaged into TCP protocol for return to the sender. Unlike the data format transmitted over serial links, TCP mode eliminates additional addresses and checks, adding a message header; its specific format is shown in the figure below.
Modbus TCP includes an MBAP header, which consists of the following parts:
| Field | Length | Description | Client | Server |
|---|---|---|---|---|
| Transmission Flags | 2 bytes | Sequence number during MODBUS request and response transmission | Generated by the client | Copied by the server upon response |
| Protocol Flags | 2 bytes | Modbus protocol defaults to 0 | Generated by the client | Copied by the server upon response |
| Length | 2 bytes | Length of the remaining part | Generated by the client | Generated by the server upon response |
| Unit Flags | 1 byte | Slave flag (slave address) | Generated by the client | Copied by the server upon response |
[Note]
[1] Transmission flags can be understood as sequence numbers to prevent MODBUS TCP communication misalignment; for example, a later response arriving at the host before an earlier one.
[2] The unit flag can be understood as the slave address, which is no longer important.
6.4 Relationship Between Modbus TCP and TCP IP
Modbus TCP can be understood as an application layer protocol that occurs over TCP; since it is a TCP protocol, a complete MODBUS TCP message must include TCP headers, IP headers, and Ethernet headers.
07 Function Code Roles
The client that initiates Modbus transaction processing creates a Modbus application data unit. The function code (in the PDU) indicates to the server what operation will be performed.
The function code field of the Modbus data unit is encoded in one byte. The valid range is decimal 1-255 (128-255 are reserved for exception responses). When sending a message from the client to the server, the function code field indicates which operation will be executed by the server.
The data field of the message sent from the client to the server includes additional information that the server uses to perform the operation defined by the function code. This field also includes discrete item and register addresses, the number of items being processed, and the actual number of data bytes in the field.
In certain requests, the data field may be absent, in which case the server does not require any additional information. The function code merely indicates the operation.
Types of Function Codes
Function codes are mainly divided into valid function codes, exception function codes, and error function codes. If no errors related to the requested Modbus function occur in a correctly received Modbus ADU, the response data from the server to the client will contain the normal function code from the request.If errors occur related to the requested Modbus function, the response data will contain an exception code and an error code.
For example, the client can read the on/off status of a group of discrete outputs or inputs, or the user can read/write a group of register data contents. When the server responds to the client, it uses the function code field to indicate a normal (error-free) response or the occurrence of some error (known as an exception response). For a normal response, the server only responds with the original function code, as shown in the figure below:
For an exception response, the server returns a code equivalent to that of the client, setting the most significant bit of the original function code to logic 1 and adding the exception code plus error code to notify the client of the reason for the exception. As shown in the figure below:
Valid Function Codes
There are over twenty valid function codes, but generally, eight of them are most commonly used: 1, 2, 3, 4, 5, 6, 15, and 16, along with two special uses, 20 and 21, for General Reference Register, which most Modbus devices do not provide. The primary control data types on PLCs include the following four types. These eight function codes handle these control data, detailed as follows:
Control Data Types:
DI: Digital Input (discrete input), one address one data bit, users can only read its status, not modify it. Represented by one bit as On/Off, used to record the status of control signal inputs, such as switches, contact points, motor operation, limit switches… etc. Referred to on PLC as Input relay, input coil, etc.
DO: Digital Output (coil output), one address one data bit, users can set, reset, and read back status. Represented by one bit as On/Off, used to output control signals to activate or stop motors, alarms, lights… etc. Referred to on PLC as Output relay, Output coil, etc.
AI: Analog Input (input register), one address 16-bit data, users can only read, not modify, represented as a 16 bits integer value used to record the numerical input of control signals, such as temperature, flow, material quantity, speed, rotational speed, valve opening, liquid level, weight… etc. Referred to on PLC as Input register.
AO: Analog Output (holding register), one address 16-bit data, users can write and read back, represented as a 16 bits integer value used to output the numerical value of control signals, such as temperature, flow, speed, rotational speed, valve opening, feed quantity… etc. set values. Referred to on PLC as Output register, Holding register.
08 Security Analysis of Modbus Protocol
The Modbus protocol is a typical industrial control network protocol, and studying its security is of great significance for enhancing the security of industrial control networks. Generally, security issues with protocols can be divided into two types: those arising from the design and description of the protocol itself, and those arising from incorrect implementations of the protocol. The Modbus protocol also faces both types of issues.
8.1 Inherent Issues of Modbus Protocol
Most industrial control protocols were initially designed with a focus on functionality, efficiency, and reliability, without considering security issues. The Modbus protocol is no exception, even though it has become a de facto industrial standard. From the previous principle analysis, its inherent security issues are: lack of authentication, authorization, encryption, and function code abuse.
(1) Lack of Authentication
The purpose of authentication is to ensure that the received information comes from legitimate users; unverified users sending control commands to devices will not be executed. During Modbus protocol communication, there are no definitions related to authentication, and an attacker only needs to find a legitimate address to establish a Modbus communication session using function codes, thus disrupting the entire or part of the control process.
(2) Lack of Authorization
Authorization ensures that different privileged operations are performed by authenticated users with different permissions, greatly reducing the chances of operational errors and internal attacks. Currently, the Modbus protocol lacks a role-based access control mechanism, does not categorize users, and does not define user permissions, allowing any user to execute any function.
(3) Lack of Encryption
Encryption ensures that the information exchanged between both parties during communication is not illegally accessed by third parties. The Modbus protocol transmits addresses and commands in plaintext, making it easy for attackers to capture and analyze data, providing convenience for attackers.
(4) Function Code Abuse
Function codes are a crucial component of the Modbus protocol, and almost all communications contain function codes. Currently, function code abuse is a major factor leading to anomalies in Modbus networks. For example, illegal message lengths, short cycles of useless commands, incorrect message lengths, and delayed response codes can all lead to denial-of-service attacks.
8.2 Issues Arising from Protocol Implementation
Although the Modbus protocol has been widely applied, developers often lack security knowledge or awareness of security issues when implementing specific industrial control systems. This leads to various security vulnerabilities within systems using the Modbus protocol.
(1) Design Security Issues
Developers of Modbus systems mainly focus on functional implementation, with security issues rarely considered during design. Design security refers to adequately considering security during design to address various anomalies and illegal operations that may occur in Modbus systems. For example, if a node is maliciously controlled and sends illegal data during communication, it is necessary to consider how to discern and handle such data.
(2) Buffer Overflow Vulnerabilities
Buffer overflow occurs when data exceeds the capacity of a buffer, causing overflow data to overwrite legitimate data. This is one of the most common and dangerous vulnerabilities in software development, potentially leading to system crashes or being exploited by attackers to control the system. Most Modbus system developers lack secure development knowledge, leading to numerous buffer overflow vulnerabilities, which, if exploited by malicious actors, can result in severe consequences.
(3) Modbus TCP Security Issues
Currently, the Modbus protocol can be implemented on general computers and operating systems, operating over TCP/IP to meet development needs. Consequently, the inherent security issues of the TCP/IP protocol inevitably affect the security of industrial control networks. Common attack methods in the IP Internet, such as unauthorized data acquisition, man-in-the-middle attacks, denial of service, IP spoofing, and viruses, can all impact the security of Modbus systems.
8.3 Security Recommendations
Currently, the security measures taken by Modbus systems are generally inadequate. Here are some security recommendations based on information security industry research and the specific security issues of industrial control systems, which can effectively reduce the threats faced by industrial control systems.
(1) Start from the Source
Vulnerabilities in industrial control networks largely stem from issues arising during implementation. By controlling from the source, including security measures throughout the entire lifecycle of Modbus system design, development, internal testing, and deployment—integrating secure design, secure coding, and security testing techniques—can significantly eliminate security vulnerabilities and reduce the overall security risk of the Modbus system.
(2) Anomaly Behavior Detection
Anomalous behavior represents potential threats, regardless of whether an attacker is present. Therefore, developing dedicated anomaly detection devices for Modbus systems can greatly enhance the security of industrial control networks. For Modbus systems, first analyze the various operational behaviors, describing them in a six-tuple model based on “subject, location, time, access method, operation, object”; subsequently analyze whether these behaviors are anomalous; and finally decide on measures such as logging or alerting.
(3) Security Auditing
Security auditing of Modbus involves in-depth decoding and analysis of protocol data, recording key information such as the time, location, operator, and operational behavior, implementing security audit log recording and auditing functions for Modbus systems, thereby providing the capability to trace back security events after they occur.
(4) Use of Network Security Devices
Employ intrusion prevention and firewall devices for network security. Firewalls serve as serial devices that, through settings, only allow specific addresses to access the server while prohibiting external addresses from accessing the Modbus server, effectively preventing external intrusions; intrusion prevention devices can analyze the specific operational content of the Modbus protocol, effectively detecting and blocking anomalous operations and various penetration attack behaviors from both internal and external sources, providing protection for the internal network.
What Others Are Watching
[Video] How German Engineers Create PLC Cabinets?
[Video] How Are German WITRON Electrical Cabinets Produced?
[Video] What Is the Working Environment of German Engineers Like?
[Video] Why Is PROFINET Better Than PROFIBUS?