You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat.
–Albert Einstein, when asked to describe radio
Testing RTUs and PLCs is often painful work. Straight-up fuzzing them is not a good idea unless you’re a bit like Batman and have multiple levels of fallback plan. Testing two Project Basecamp systems has prodded me into a lot of ingenuity both restoring devices and developing foolproof test plans.
Serial ports aren’t something that I particularly enjoy messing with. Who wants to deal with baud rates, proprietary protocols, and hardware taps when I can play with a real live Ethernet port and just use Wireshark or tcpdump instead? Unfortunately, serial ports are sometimes the only way to recover a device that has been badly broken by your oddball ftp request or a replay attack gone awry.
Enter socat, a beautiful sockets-savvy version of netcat, which lets us build a serial cable from New York to Los Angeles (and beyond). Coupled with VMWare (or any virtualization product that allows virtual-serial-ports-as-sockets-or-pipes), you can do pretty cute serial-port-over-tcp configurations that are transparent to the applications which actually use them.
To do this setup, you’ll need a serial port server, some computer that acts as an always-on host to decapsulate TCP traffic. I use an Ubuntu Linux box. That server doesn’t have any serial ports of its own, so I use a crummy USB-to-Serial adapter that works under Linux.