Network aware laser cutter security

posted in: Laser cutting | 4

My Chinese laser cutter has a feature which allows it to be connected to a cabled LAN, but I’m always concerned about attaching random hardware to my home network as sometimes Internet connected devices have a “phone home” feature where they connect to a central server and send back log data, or possibly do other things which you’d rather they didn’t.

So although my workshop PC is around 5m from my laser cutter, I initially opted to use a USB extension cable to connect the PC to the laser cutter.

Unfortunately I found that using a long USB cable was problematic as the laser cutter kept disconnecting from the PC, and I’d have to unplug and reconnect the cable, almost every time I sent a job to the cutter.


As my workshop PC is not actually connected to the Internet, I decided it was safe to make a Ethernet crossover cable and connect the PC directly to the laser cutter via cat 5 cable. The cable worked well, and the connection does not drop out, and the cutter control software seems to work in exactly the same way as when communicating via USB.

As I was still curious about whether the cutter had a “phone home” feature, I decided to install WireShark on the PC and monitor the LAN traffic.


The control unit in the laser cutter is a RUIDA RDC6442G ( )

On the control panel, you set the IP address of the laser cutter and also enter the address of a gateway, so I entered the IP of the workshop PC as the gateway IP, and then fired up Wireshark


I was pleased to see, that the laser cutter does not appear to communicate over the LAN at all, unless sent data from the control program (RDWorks) in the PC. I left the machine for several hours and not a single packet was detected.

This does not completely rule out that the laser cutter may attempt to communicate after an extended period e.g. every 24 hours, but at least it does not start trying to contact the Internet immediately

The control program RDWorks doesnt seem to access the Internet either, which is also very good news.


The main reason for monitoring the data was for network security reasons, but I had a quick look at the data protocol.

When RDWorks communicates with the cutter it uses UDP, sending to port 50200 on the cutter, and the cutter sends back UDP data to port 40200


The format seems to be proprietary binary, with RDWorks sending a command packet.

e.g. This seems to be the initial packet that is always sent by RDWorks


to which the RDC6442G  responds with


and then sends a reply packet e.g.



Another example is RDWorks sends


to which the RDC6442G  responds with


and then sends



When I sent drew a 10mm x 10mm square in RDWorks and sent this to the laser cutter, by pressing the start button, this appears to be the data for this cut (but at lest 5 commands were sent to the cutter before this data was sent, and RDWorks sent a further 411 bytes in the next command



I don’t think there is any point in further investigation of the actual protocol itself as RDWorks is free and although is Windows only, it appears to run OK under Wine on Linux.


Overall, although I would not connect the laser cutter to my internal LAN because of the safety implications of any computer on the LAN sending the command to start the laser cutter running, I think that from a network security standpoint it seems relatively safe.

If absolute network security is required a cheap wifi / wired router running OpenWRT or DDWRT could by placed between the laser cutter and the rest of the network to limit traffic to just UDP and ports and 40200 50200 and limit which IP addresses the laser cutter is allowed to communicate with.

Or just use a dedicated PC with no other network connections, like I do.


4 Responses

  1. Jason Dorie

    You might find this helpful: The posts detail the message format of the laser files, which appear to be largely identical to data sent over the network or through the USB cable. I’ve written software already to read the generated .RD files and reorganize the cut data for faster raster scanning.

  2. Roger Clark

    Thanks for the link

    Do you know if the data format is the same for all RUIDA controllers, as I don’t think mine is the same model number as in that post

  3. Jason Dorie

    I can’t say for certain, but mine is an RDC6442G, which is pretty current, using RDWorks V8, and the information for V6 on his site is accurate for my hardware. I’ve managed to figure out a bunch of additional messages that he doesn’t have on his site, including tiling info, parameter bank settings, origin and limits, and vertical / horizontal relative cuts and moves. Once you have the descrambler and the high-bit == message start info, a good bit of the rest is not terribly hard to figure out.

  4. Roger Clark


    When I get time I’ll try running Wireshark again and capture some traffic and see it makes sense when descrambled