Communication With the CO2 Laser Machine

The purpose of this project is to automate the communication process with the machine while ensuring remote access.

Port Scanning

Port scanning using Nmap and Netcat revealed no open TCP ports, but an active UDP port (50200) was detected. This confirms the presence of a service on that port. However, initial attempts to send files to the machine via this port were unsuccessful.

Analysis via Wireshark

Network analysis with Wireshark confirmed that the machine communicates via UDP but does not have an active listening service by default. It only responds to specific requests from RDWorks or LightBurn software, suggesting a proprietary application-layer protocol. The lower network layers function correctly, as shown by successful ping and discovery test responses.

Exploring the Payload Content

After sending the file with the “tesst.rd” extension, its content was observed in hexadecimal format a common representation for binary data. A Python script was used to perform the conversion and verify the content’s integrity. The result showed that the data matched the sent file, except for two missing character pairs

The analysis of the added headers, conducted across multiple files, revealed that the overwritten bit pairs varied from one file to another without a recurring pattern. This variability suggests random data alteration during transmission.

Problem Investigation

The two overwritten characters are located at the beginning of the payload. Several possible causes were considered:

1. A character reading or conversion error during the transformation process
2. A proxy or firewall on the machine modifying traffic for security reasons
3. A dependency on the specific software solutions used

Hypothesis

Hypothesis 1:

A reverse approach was used to verify the origin of the data corruption. The captured hexadecimal data was reconverted into a “tesst.rd” file and then compared with the original file. Since the contents were identical, this rules out data transformation as the cause of the character loss.

Hypotheses 2 and 3:

Due to a lack of documentation and restricted access to network configurations, confirming the presence of a proxy or firewall remains difficult. However, software dependency appears to be a more plausible cause, as certain libraries or conversion tools may unintentionally alter data during processing.

Reconstruction of the UDP Payload

The approach is based on sending data in the form of UDP packets to a target machine while establishing bidirectional communication. A Python script was developed to:

1. Convert a file into hexadecimal format
2. Associate the data with predefined sequences generated from all possible combinations of 4 hexadecimal characters (0–9, A–F), i.e., 16⁴ = 65,536 combinations
3. Send the UDP packets
4. Wait for a response confirming successful transmission

1. Creation and Configuration of UDP Sockets

Two UDP sockets were set up:

1. One socket for sending data to the target IP address and port
2. One local socket for receiving responses from the remote device

2. File-to-Hexadecimal Conversion

The source file is read and converted into a hexadecimal string, which is then prepared for merging with the test sequences.

3. Combining Data and Formatting

The file’s hexadecimal data is concatenated with the generated test sequence combinations. The entire structure is then transformed into binary format (bytes) before transmission.

4. Sending and Receiving Data

Data transmission is performed in a separate thread, while a second thread listens for a response. Once a specific response is received (e.g., 0xc6, indicating successful transmission), the sending process is stopped.

5. Thread Management

The use of separate threads allows for concurrent sending and receiving, ensuring smooth, non-blocking communication.

This setup allows files to be sent to the laser machine by following the same steps as usual.

Remote access is enabled through an Ethernet connection between the Raspberry Pi and the machine, along with a bridge configuration that assigns the Raspberry Pi’s Ethernet interface the same IP address as its WLAN network. This eliminates the need to reconfigure the interface each time.