The scanner performs detection in two stages.

1. TCP connection

The scanner attempts to establish a TCP connection to:

If the connection cannot be established, the target is treated as not responding to Modbus/TCP.

However, an open TCP/502 port by itself is not considered sufficient evidence of Modbus.

2. Modbus application-layer probe

After connecting, the scanner sends a Modbus request using libmodbus.

The primary probe is:

This generates a Modbus Function Code:

The request asks the target for one input register starting at address 0.

If the target returns a valid Modbus response, the scanner considers the service detected.

Modbus/TCP Packet Structure

A Modbus/TCP packet consists of:

The MBAP header is specific to Modbus/TCP.

Primary Detection Packet

The scanner's first probe uses Function Code 0x04.

A representative request is:

Breaking this down:

Transaction Identifier

Identifies the transaction.

The value can vary because the transaction identifier is normally managed by the Modbus client library.

Protocol Identifier

A value of 0 identifies Modbus.

Length

Specifies the number of bytes following the length field.

Unit Identifier

Identifies the target Modbus unit.

Function Code

Function Code 0x04 means:

Starting Address

The scanner starts at register address 0.

Quantity

The scanner requests one register.

Expected Response

A successful response to the request contains Function Code 0x04 and the requested register data.

A representative response could look like:

Breaking it down:

The important part for detection is that the target successfully processes the Modbus request and returns a valid Modbus application-layer response.

The actual register value is device-dependent.

Why Port 502 Alone Is Not Enough

Simply checking:

does not necessarily prove that the service is Modbus.

Port numbers are conventions. A different application can listen on TCP/502, and a Modbus device may also behave differently depending on its configuration.

The scanner therefore uses:

This makes application-layer detection more meaningful than a simple port scan.

Fallback Detection

Some devices may not respond to the initial 0x04 request because of their register configuration or supported function codes.

The scanner therefore attempts a second request if the first one fails:

This uses Function Code:

A representative request is:

Breakdown:

The scanner considers the target detected when either Modbus operation receives a successful response.

Detection Flow

Implementation

The scanner uses libmodbus to construct and parse Modbus/TCP packets rather than manually constructing protocol frames.

The primary operation is:

If this fails:

The connection is then closed and the libmodbus context is freed.

This keeps the protocol handling inside the Modbus library while the scanner handles:

• Target enumeration
• Threading
• Connection management
• Detection
• Progress tracking
• Result logging

Timeouts

The scanner uses short connection and response timeouts:

This prevents a single unreachable or unresponsive host from blocking a worker for an excessive amount of time.

Industrial networks can contain devices with relatively slow responses, so timeout values may need to be adjusted depending on the environment.

Multithreading

Targets are divided between multiple worker threads.

For example:

Each worker independently attempts Modbus/TCP detection.

This allows multiple hosts to be tested concurrently rather than waiting for each target sequentially.

Important Detection Considerations

A positive result means that the target successfully responded to a Modbus request understood by the scanner.

It does not necessarily identify:

• Device manufacturer
• Device model
• Firmware version
• PLC program
• Register contents
• Whether the device is vulnerable

Those are separate fingerprinting or assessment tasks.

The scanner is primarily a Modbus/TCP service detection tool.

Limitations

The detection method is intentionally conservative.

A device may be Modbus-capable but fail detection if:

• TCP/502 is filtered
• A firewall blocks the request
• The device requires a different Unit ID
• The requested function code is unsupported
• The device does not expose the requested address
• The device is temporarily unavailable
• Network latency exceeds the configured timeout

Therefore:

It means the scanner could not obtain a successful response using the probes it attempted.

Build

Install the required dependencies and compile with:

Or directly:

Run:

Example:

Summary

The scanner detects Modbus/TCP services by performing actual protocol interaction rather than relying exclusively on TCP port detection.

The detection process is:

The key principle is simple:

Detect the protocol, not just the port.