My interest in the world of cryptocurrency has been growing over the last several months. In order to address this interest, I have finally obtained a crypto mining rig.

Those of you who are familiar with mining rigs have been exposed to USB watchdogs. These are small devices that are connected to a USB port with the goal of monitoring your computer and restarting it in the case that your system freezes.

The operation of a USB watchdog is simple:

1. Insert the device into a free USB port. There are four pins that need to be connected. Use jumper wires to connect two of the pins to the reset button with the other two pins attached to the power switch.

1. Once you power on the device, it waits for a pre-determined period of time to receive a message indicating the computer is still functioning properly. If that message is not received in the designated time frame, the computer will be reset.

1. Step 2 is repeated indefinitely.

Specialized software is responsible for sending messages to the watchdog. If your computer crashes or freezes, the software will not be able to relay the message. If the time interval is exceeded before receiving a message, the watchdog is alerted that there is a problem with the system. It then initiates a hardware reset that is the equivalent of pushing the computer’s reset button.

USB watchdogs come with this dedicated software, though in my case the program was essentially useless. It was designed to be used on a Windows machine and I use a Linux computer for my mining rig. This posed a problem that needed to be addressed.

Taking a look at the Windows software, it seemed fairly simple so I decided to try to reverse engineer the application.

It was easy to do:

First, I needed a program that could be used to monitor the connection and the data which was being passed to the watchdog. A quick Google search directed me to a valuable tool,  com port monitoring.

Employing a serial port sniffer made it easy to decipher the necessary patterns. You need to verify the serial port settings which should be:

• Baud rate: 9600

• Parity bits: None

• Stop bits: 1

That’s all you need to begin transmitting messages to the USB watchdog.

The protocol:

The next aspect to consider is the protocol in use. Here again, the sniffer lets you conduct this investigation.

The first thing to notice is that when the watchdog software is started, it sends a packet (0x80) to which the watchdog device replies with (0x81). Despite not knowing the exact manner in which the data is encoded, it is fairly obvious that this initial connection message contains the firmware version.

I then discovered that a sequence of bytes (0x10) was being sent at the rate of one per second. This was with a timeout value of 160 seconds. Changing the timeout value to ten seconds caused the program to send a different byte (0x01).

Some deduction indicated that if a byte value of one equals ten seconds, 160 seconds should be represented by a 16. And 16 is represented in hexadecimal notation with 0x10.

When the reset button is pressed, the relays are triggered and a byte of 0xff is sent.

To my knowledge, the only operations available are these three:

• Send a heartbeat message containing the current timeout value.
• Check firmware version.
• Reset.

The script

The completed script is rather basic. The source code is available for you to use at https://github.com/zatarra/usb-watchdog.

There is definitely room to extend the script’s functionality in a number of ways only limited by your imagination. Some suggestions are to remotely start a mining rig or test video your system’s video cards.

Warning: Setting the heartbeat interval too low can backfire on you. If you set it to one minute, that is the amount of time you have to react if your computer crashes. You will need to boot the machine and start the script within that time frame. Failure to do that will put your computer into an infinite loop which can be very troublesome...