Today, let’s discuss Modbus. Here’s what we’ll cover:
1. Terminology Explanation
2. Background
3. Protocol Principles
4. Transmission Methods
5. Differences Between Modbus RTU and Modbus ASCII
6. Modbus TCP and Its Considerations
7. Function Code Roles
8. Security Analysis of Modbus Protocol
1. Terminology Explanation
Checksum
The checksum is usually the last digit of a group of numbers, derived from the preceding numbers through certain calculations, used to verify the correctness of that data group. When inputting code as data into a computer or other devices, input errors can easily occur. To reduce such errors, coding experts have invented various checksum and error detection methods and established checksums based on these methods. Common checks include: Sum Check, XOR Check, LRC Check, CRC Check, etc.
Discrete Input
Mainly used to read the data of a single bit, such as the status of IO;
Coil
Switch output signal, mainly used to write a single bit of data, forming a paired operation with discrete quantities;
Input Register
Mainly used to read 16 bits, which is two bytes of data;
Holding Register
Mainly used to write 16 bits of data;
PLC
A Programmable Logic Controller (PLC) is a type of programmable memory used to store programs and execute logic operations, sequential control, timing, counting, and arithmetic operations for user-directed instructions, controlling various types of machinery or production processes through digital or analog input/output.
Serial Communication
With the application of computer systems and the development of microcomputer networks, communication functions have become increasingly important. The communication referred to here involves the exchange of information between computers and the outside world. Thus, communication includes information exchange between computers and external devices, as well as 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 transfer, making it particularly suitable for long-distance transmission. For devices that are not far from the computer, such as human-machine exchange devices and external devices with serial storage like terminals, printers, logic analyzers, disks, etc., serial data exchange is also quite common. In real-time control and management, communication between CPUs in a hierarchical distributed control system is generally serial. Therefore, serial interfaces are commonly used in microcomputer application systems. Many peripherals and computers communicate serially; this serial communication refers to the information transfer method between peripherals and interface circuits, while the CPU and interface still operate in parallel.
Serial Port
The 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 common communication protocol for instrumentation devices; many GPIB-compatible devices also have RS-232 ports. Additionally, the serial communication protocol can be used to acquire data from remote collection devices.
The concept of serial communication is very simple: the serial port sends and receives bytes bit by bit. Although it is slower than parallel communication, which sends data by bytes, the serial port can send data on one line while receiving data on another. It is simple and capable of long-distance communication. For example, when IEEE488 defines parallel communication conditions, it 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; however, for serial ports, the length can reach up to 1200 meters.
Typically, serial ports are used for transmitting ASCII characters. Communication is accomplished using three lines: ground, transmit, and receive. Since serial communication is asynchronous, the port can send data on one line while receiving data on another. Other lines are used for handshaking but are not mandatory. The most important parameters of serial communication are baud rate, data bits, stop bits, and parity. For two communicating ports, these parameters must match:
a. Baud Rate: This is a parameter that measures communication speed. It indicates the number of bits transmitted per second. For example, 300 baud means sending 300 bits per second. When we refer to the clock cycle, we mean the baud rate. For example, if the protocol requires a baud rate of 4800, then the clock is 4800Hz. This means that the sampling rate on the data line for serial communication is 4800Hz. Typically, telephone lines have baud rates of 14400, 28800, and 36600. Baud rates can be much higher than these values, but baud rate is inversely proportional to distance. High baud rates are often used for communication between instruments placed very close together, a typical example being GPIB device communication.
b. Data Bits: This is a parameter that measures the actual data bits in communication. When a computer sends a message 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 code), then each data packet uses 7 bits of data. Each packet refers to a byte, including start/stop bits, data bits, and parity bits. Since the actual data bits depend on the selected 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 desynchronization between two devices during communication. Therefore, stop bits not only indicate the end of transmission but also provide the 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 also becomes slower.
d. Parity Bit: A simple error detection method in serial communication. There are four types of parity: even, odd, high, and low. Of course, it’s also possible to have no parity bit. For even and odd parity cases, the serial port sets a parity bit (the bit following the data bits) to ensure that the transmitted data has an even or odd number of logical high bits. For example, if the data is 011, then for even parity, the parity bit would be 0, ensuring the number of logical high bits is even. For odd parity, the parity bit would be 1, resulting in three logical high bits. High and low bits do not actually check the data; they simply set the logical high or low for checking. This allows the receiving device to know the state of a bit and provides an opportunity to determine whether noise has interfered with communication or whether the transmitted and received data are unsynchronized.
2. Background
As early as 1971, Modicon first introduced the Modbus protocol, giving birth to Modbus RTU and Modbus ASCII. Later, Schneider Electric acquired Modicon and launched the Modbus TCP protocol in 1997. In 2004, the National Standards Committee of China officially recognized Modbus as 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 controllers can communicate with other devices over a network. The Modbus protocol is characterized by being standard, open, supporting multiple electrical interfaces, having a simple and compact data frame format, high data transmission volume, and good real-time performance. It has been widely used in industrial control systems and has become a universal industrial standard. A thorough analysis of the Modbus protocol’s implementation principles and its 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 communication protocol standard in the industrial field and is a widely used connection method between industrial electronic devices.
3. Protocol Principles
Modbus uses a simple Master and Slave 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, in usage, the monitoring system (HMI) serves as the Master, while PLCs, electric meters, and instruments serve as Slaves. The HMI system continuously polls various relays and registers for the latest values and then processes them for display and various logical calculations and control adjustments.
In this, the function code segment and data segment together are 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 for exception message response packets. The values 1-127 are function code numbers, with 65-72 and 100-110 being user-defined codes.
4. Transmission Methods
The Modbus protocol is an application layer message transmission protocol, including three types of messages: ASCII, RTU, and TCP. The protocol itself does not define the physical layer but only defines the message structure that controllers can recognize and use, regardless of the network through which they communicate.
When using the Modbus protocol for serial transmission, either RTU or ASCII mode can be selected, and it specifies message, data structure, command, and response methods, requiring data verification. The ASCII mode uses LRC verification, while the RTU mode uses a 16-bit CRC verification. When transmitted over Ethernet, TCP is used, and this mode does not use verification because the TCP protocol is a reliable, connection-oriented protocol.
5. 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. Among them, ASCII stands for American Standard Code for Information Interchange; 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 initialize the transmission, and the slave device responds according to 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 can include both unicast and broadcast modes.
In broadcast mode, the Modbus master device can send requests to multiple slave devices simultaneously (device address 0 is used for broadcast mode), and slave devices do not respond to broadcast requests.
In unicast mode, the master device sends requests to a specific slave device (each Modbus slave device has a unique address), and the request message frame includes 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 feedback 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). The allowed character set for transmission includes hexadecimal 0-9 and A-F; the slaves in the network monitor the transmission path for the English colon (“:”). If detected, they decode the message frame and check if the address matches their own. If it does, they receive 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 decomposed into ASCII characters “A” and “F” for sending, doubling the number of characters transmitted compared to RTU. The benefit of ASCII mode is that it allows a maximum time interval of 1 second between two characters without causing communication failure. This mode uses Longitudinal Redundancy Check (LRC) for error checking. When the controller is set to communicate over the Modbus network in RTU mode, each 8-bit byte in the message includes two 4-bit hexadecimal characters, and this mode does not have 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 instance, the hexadecimal number 0xAF is sent directly as hexadecimal 0xAF (binary: 10101111), resulting in a transmission density that is twice that of ASCII mode. RTU mode uses Cyclic Redundancy Check (CRC), and the specific format is shown in the following figure:
6. Modbus TCP and Its Considerations
6.1 Master and Slave, Server and Client
In the Modbus protocol, the master sends a Modbus request, and the slave returns a response based on the request content. In the Modbus protocol, the master is always the active party, while the slave is always the passive party.
In network applications, there are clients and servers. The client (e.g., a browser) sends requests to the server, which then returns content (e.g., HTML text) to the client.
In Modbus TCP, the master acts as the client, while the slave acts as the server. Do not assume that the server is more important; the master is also important, so the master is the server.
6.2 Can There Be Multiple Masters?
From the previous analysis, since the master is the client, Modbus TCP supports multiple masters. In a local area network, multiple masters and slaves can exist. The connection capacity of the slave (the number of connected masters) is determined by the maximum TCP connection count of uIP.
6.3 Brief Overview of Modbus TCP Protocol
Modbus TCP and Modbus RTU are essentially the same, but there are some differences:
The TCP mode was developed to ensure that Modbus data can be smoothly transmitted over Ethernet, using TCP port 502. The protocol’s physical layer, data link layer, network layer, and transport layer are all based on TCP protocol, with Modbus protocol modified and encapsulated only at the application layer. The receiving end unpacks the TCP data packet, retrieves the original Modbus frame, parses it according to Modbus protocol specifications, and then repackages the returned data packet into the TCP protocol to send back to the sender. Unlike the data format transmitted over serial links, TCP mode removes additional addresses and checks, adding a message header instead, as shown in the figure below.
In Modbus TCP, there is an MBAP header, which includes the following parts:
6.4 Relationship Between Modbus TCP and TCP IP
Modbus TCP can be understood as an application layer protocol that operates over TCP. Since it is based on TCP, a complete MODBUS TCP message must include TCP headers, IP headers, and Ethernet headers.
7. Function Code Roles
The client that initiates the Modbus transaction creates the Modbus application data unit. The function code (in the PDU) indicates to the server which operation will be executed.
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 a message is sent from the client to the server, the function code field determines which operation the server will perform.
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 the discrete item and register addresses, the number of items being processed, and the actual number of data bytes in the field.
In some requests, the data field may not exist, in which case the server does not need any additional information. The function code alone indicates the operation.
There are different types of function codes:
Function codes are mainly divided into valid function codes, exception function codes, and error function codes. If a correctly received Modbus ADU does not contain errors related to the requested Modbus function, the response data from the server to the client will contain the same function code as the request. If errors related to the requested Modbus function occur, the response data will contain an exception code and an error code.
For example, the client can read the on/off status of a set of discrete outputs or inputs, or the user can read/write a set of register data contents. When the server responds to the client, it uses the function code field to indicate a normal (no error) 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.
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 logical 1, and adding the exception code followed by the error code to notify the client of the reason for the exception.
Valid Function Codes
There are over twenty valid function codes, but in general usage, the eight most common are 1, 2, 3, 4, 5, 6, 15, and 16, along with two special uses, 20 and 21, which are General Reference Registers that most Modbus devices do not provide. The main types of control data on a PLC include the following four types. These eight function codes are used to process this control data, detailed as follows:
Four Types of Control Data:
DI: Digital Input (discrete input), one address one data bit, the user can only read its status and cannot 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. On a PLC, it is referred to as Input relay, input coil, etc.
DO: Digital Output (discrete output), one address one data bit, the user can set, reset, and read status. Represented by one bit as On/Off, used to output control signals to activate or stop motors, alarms, lights, etc. On a PLC, it is referred to as Output relay, Output coil, etc.
AI: Analog Input (input register), one address 16-bit data, the user can only read and cannot modify, represented as a 16-bit integer value to record control signal numerical inputs, such as temperature, flow, material quantity, speed, rotational speed, valve opening degree, liquid level, weight, etc. On a PLC, it is referred to as Input register.
AO: Analog Output (holding register), one address 16-bit data, the user can write and read back, represented as a 16-bit integer value to output control signal numerical settings, such as temperature, flow, speed, rotational speed, valve opening degree, feed quantity, etc. On a PLC, it is referred to as Output register, Holding register.
8. 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 speaking, security issues in protocols can be divided into two types: one is security problems caused by the design and description of the protocol itself; the other is security problems caused by incorrect implementations of the protocol. The Modbus protocol has issues in both aspects.
8.1 Inherent Issues of Modbus Protocol
The vast majority of industrial control protocols were designed with a focus on functionality, improving efficiency, and enhancing reliability, without considering security issues. The Modbus protocol is no exception, despite having become a de facto industrial standard. From the previous principle analysis, it is evident that its inherent security issues include: lack of authentication, authorization, encryption, and function code misuse.
(1) Lack of Authentication
The purpose of authentication is to ensure that the received information comes from legitimate users; unauthenticated users sending control commands to devices will not be executed. In the Modbus communication process, there are no relevant definitions regarding authentication, allowing an attacker to establish a Modbus communication session simply by finding a valid address and using function codes, disrupting the entire or part of the control process.
(2) Lack of Authorization
Authorization ensures that different privileged operations must be performed by authenticated users with different permissions, significantly reducing the probability of misoperations and internal attacks. Currently, the Modbus protocol lacks a role-based access control mechanism and does not classify users or define user permissions, allowing any user to execute any function.
(3) Lack of Encryption
Encryption ensures that information exchanged between parties during communication is not illegally obtained by third parties. In the Modbus communication process, addresses and commands are transmitted in plaintext, making it easy for attackers to capture and analyze the data, providing convenience for attacks.
(4) Function Code Misuse
Function codes are a crucial component of the Modbus protocol, with almost all communications containing function codes. Currently, function code misuse is a major factor leading to abnormalities in Modbus networks. For instance, illegal message lengths, short-cycle useless commands, incorrect message lengths, and delayed acknowledgment of exception 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 implementing specific industrial control systems often lack security knowledge or do not realize security issues. This leads to various security vulnerabilities in systems using the Modbus protocol.
(1) Design Security Issues
Developers of Modbus systems focus primarily on functional implementation issues, with security often receiving little attention during the design phase. Design security refers to fully considering security during the design phase, addressing 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 the buffer during data filling, leading to overflow data overwriting legitimate data. This is one of the most common and dangerous vulnerabilities in software development, potentially causing system crashes or being exploited by attackers to take control of the system.
Many Modbus system developers lack security development knowledge, leading to numerous buffer overflow vulnerabilities that could result in severe consequences if exploited by malicious actors.
(3) Modbus TCP Security Issues
Currently, the Modbus protocol can be implemented on general computers and general operating systems, running over TCP/IP to meet development needs. Thus, the inherent security issues of the TCP/IP protocol inevitably impact the security of industrial control networks. Common attack methods in IP internet, such as unauthorized data acquisition, man-in-the-middle attacks, denial of service, IP spoofing, and viruses, can all affect the security of Modbus systems.
8.3 Security Recommendations
Currently, the security measures taken by Modbus systems are generally insufficient. Here, we reference industry research on information security and combine it with the security issues of industrial control systems to propose some security recommendations that can effectively reduce the threats faced by industrial control systems.
(1) Start from the Source
Vulnerabilities in industrial control networks largely stem from issues during implementation. If security measures are integrated throughout the lifecycle of the Modbus system—from requirement design, development, internal testing to deployment—through secure design, secure coding, and secure testing, it can significantly eliminate security vulnerabilities and reduce the overall security risks of the Modbus system.
(2) Anomaly Behavior Detection
Anomaly behavior represents potential threats, regardless of whether an attacker is present. Therefore, developing dedicated anomaly behavior detection devices for Modbus systems can greatly enhance the security of industrial control networks. For Modbus systems, it is essential to analyze various operational behaviors and describe them using a six-tuple model based on “subject, location, time, access method, operation, object”; then analyze whether the behavior is anomalous; and ultimately decide on measures such as recording or alerting.
(3) Security Audits
Security auditing of Modbus involves deep decoding and analysis of protocol data, recording key information such as the time, location, operator, and operation behavior to achieve security audit log recording and auditing functions for the Modbus system, thus providing traceability for security events after they occur.
(4) Use of Network Security Devices
Using intrusion prevention and firewall network security devices. Firewalls are serial devices that, when configured, only allow specific addresses to access the server and prohibit 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 abnormal operations and various penetration attacks from both internal and external sources, providing protection for the internal network.
Source: This article is reproduced from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact us to delete it promptly. Thank you!
Scan to Follow
WeChat ID｜13615417996
Follow the QR code on the left to get
[Siemens Data Collection]