Reverse Engineering the Unitronics PCOM Protocol for Forensic Analysis

TLDR: The Unitronics Vision series PLC, a common target for the CyberAv3ngers, lacks standard logging, making incident response nearly impossible without specialized tools. This research introduces PCOMClient, a new tool that enables researchers to bypass authentication, extract project files, and parse the device's internal signature log. By reverse engineering the proprietary PCOM protocol, we can now pull critical forensic artifacts like connection strings and timestamps directly from embedded devices.

Industrial Control Systems (ICS) are often treated as black boxes by security researchers. When an incident occurs, the standard playbook—pulling logs from a SIEM or analyzing Windows Event Logs—fails because the target is an embedded device with no operating system to speak of. The recent targeting of Unitronics Vision series PLCs by the CyberAv3ngers group highlighted this gap. These devices are ubiquitous in water and wastewater infrastructure, yet they offer almost no visibility into their own compromise.

The PCOM Protocol: A Proprietary Hurdle

Unitronics devices communicate using a proprietary protocol called PCOM. Because there is no public documentation or RFC for this protocol, interacting with these devices requires reverse engineering the binary communication between the Engineering Workstation (EWS) and the PLC.

The protocol supports two primary modes: ASCII and Binary. The ASCII mode is relatively straightforward, but the Binary mode is where the heavy lifting happens. To perform a memory read or write, you must construct a binary packet that includes a specific magic header, an opcode, and a CRC.

The lack of encryption and authentication in older firmware versions of these devices is a massive oversight. For versions prior to v9.00, the PCOM protocol essentially operates without any access control. If you have network access to the device, you have total control. You can download new logic, modify existing processes, or, as we discovered, extract forensic evidence.

Bypassing Authentication with CVE-2024-38434

During our research, we identified a way to bypass the "Upload Password" mechanism, which is tracked as CVE-2024-38434. The device uses an upload password to prevent unauthorized users from reading the project file stored in memory. However, the implementation is flawed. By sending a specific opcode (0x42), we can trigger a reset of the upload password mechanism.

Once the password is reset, the device accepts any password, effectively nullifying the protection. This allows us to perform a full project upload, which is the equivalent of dumping the device's brain. The project file itself is an Access database saved as an encrypted ZIP. Once we extract the project, we gain access to the logic, assets, and metadata that were running on the PLC at the time of the attack.

Extracting the Signature Log

The most valuable artifact we discovered is the "Signature Log." This is an internal structure that acts as a flight recorder for the PLC. It tracks every significant event, including project downloads, uploads, and state changes.

To extract this log, we developed a multi-step process:

1. Use opcode 0x16 to find the resource table address.
2. Read the resource table memory to locate the signature table index.
3. Request the signature table address using that index.
4. Read and parse the signature table, which is Zlib-compressed.

The resulting log provides a clear timeline of the attacker's activity. We can see the exact time the attacker connected, the project name they used, and the specific operations they performed. This is the kind of data that turns a "we think we were hacked" scenario into a concrete incident report.

Practical Application for Pentesters

If you are conducting a penetration test on an OT network, do not assume the PLC is a dead end. If you encounter a Unitronics device, check the firmware version. If it is outdated, you have a direct path to full device control. Even on patched systems, the ability to extract the project file and signature log is a game-changer for post-exploitation analysis.

The PCOMClient tool we released provides a framework for these operations. It handles the PCOM encapsulation, allowing you to bridge serial or TCP connections to the device. You can use it to perform arbitrary memory reads and writes, which is essential for both offensive testing and forensic data collection.

Securing the Perimeter

Defending these devices starts with basic hygiene that is often ignored in OT environments. First, ensure these devices are never directly exposed to the internet. Use Shodan to verify if your organization has any exposed PCOM ports. If you find one, it is already a liability.

Second, update the firmware to the latest version to mitigate the authentication bypass. Finally, implement strict network segmentation. A PLC should only communicate with its designated EWS, and that communication should be monitored for anomalous PCOM opcodes.

The industry needs to move away from the "security through obscurity" model that proprietary protocols like PCOM rely on. As researchers, we need to continue building these forensic tools to force transparency on embedded devices. If you have access to a Unitronics device, use the tool, dump the logs, and help us map out the remaining undocumented opcodes. The more we understand these protocols, the harder it becomes for attackers to hide their tracks.