I’ve been interested for the crypto world for a few months now and I’ve acquired a ming rig, otherwise I wouldn’t feel complete 🙂

For all of you that have a mining rig, you’re probably familiarised with those tiny usb devices that you stick in a usb port to monitor your computer and reset it in case it hangs/freezes.


This is known as a usb watchdog and the way it works is very simple:


  1. Connect this device to a USB port. The usb watchdog has 4 pins: 2 that should be connected to the power switch and another 2 for the reset button. Use jumper wires to make the connection.
  2. When the watchdog gets powered on, it will wait for x amount of time for you to tell him “Hey, I’m still a alive! Wait for x more seconds and if you don’t get back from me again then please reset the computer”.
  3. Repeat the previous step indefinitely

Those messages are sent by a specific software. If for some reason your computer crashes,  then the watchdog won’t receive another message from the software. If a message is not sent within those x seconds, the usb watchdog will know that something isn’t right and it will issue a hardware reset simulating the physical push of the reset button.


This usb watchdogs are shipped with dedicated software, which in my case is pretty useless because it was made for Windows computers and my mining rig is linux based. I could try to use wine but I don’t feel like killing flies with bazookas.


The windows software seemed pretty basic how hard could it be to reverse engineer the protocol?


Couldn’t be easier:

The first thing was to find some software that could inspect the connection and check what was being passed back and fourth. The first link provided by google was all I needed. I’m talking about this one.

Using a Serial port sniffer it was pretty obvious to understand the patterns.  First let’s check the serial port settings:

  • Baud rate: 9600
  • Parity bits: None
  • Stop bits: 1

This is enough for you to start sending messages to the usb watchdog.

The protocol:

The only thing that you need to know now is the protocol. The sniffer will give you a good picture of it.
First of all, whenever you open the watchdog software, you can see that it sends a packet (0x80) which then get an answer from the watchdog (0x81). I’m not entirely sure of how data is encoded but it’s pretty clear that whenever the software connects, it presents you with a message containing the firmware version. I would say that this is probably encoded here in this byte.

Then you can see a sequence of bytes (0x10) that are being sent at a rate of 1/s. The timeout value was set to 160 seconds. If I set the timeout value to 10 seconds, the application will start sending 0x01.

So, if 1 equals to 10 seconds, 160 seconds should be equal to 16. What is the hexadecimal representation of 16? You guessed it: 0x10 🙂

If click on the reset button, a 0xff is sent and the relays are triggered.

As far as I know, there are only these three operations available:

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


The script


If you were expecting something fancy, you’ll be disappointed, but the sources are available here: https://github.com/zatarra/usb-watchdog 🙂
Basic functionality is implemented but you might want to extend it. You can test your video cards, test an internet endpoint, or you could even remote restart your mining rig.  Use your imagination! 😀


Warning: Do not set the heartbeat interval to a very low value, such as a minute. If you do that and your computer crashes,  you will have one minute to complete the boot process and load this script. If your computer fails to do that it will get stuck in an infinite loop which sucks if your mining rig is in a remote location.


Check my repository for the latest version of this script.


If you find this useful, buy me a beer: 😀

bitcoin: 3Mj3v5hrx5qQhwzzWPMGwkJ8DRMCywhZFy
bitcoin cash: 1KDbjLM9DdsCyfDMSYHdm52r5R3BRP2dfS
ethereum: 0xfF7167e9ea8A4d882dd9161FC5F1560B9031A6c6
litecoin: MERSbMVM9NmQoDhr5ktswpaumWk8dGbyUu
ripple: rN1sXzZUBej2wiZSjgKtAgNRTUoFhUdt36 


A couple of guys asked me to create a simple python script to allow the iClass cards to be read and extract their UID to control a few other devices. I thought of sharing with you since there are a few other people asking for the same on the Internet.

from smartcard.CardType import AnyCardType
from smartcard.CardRequest import CardRequest
from smartcard.util import toHexString, toBytes
from smartcard.CardMonitoring import CardMonitor, CardObserver
from smartcard.util import *
import urllib2
import time
class printobserver( CardObserver ):
    """A simple card observer that is notified
    when cards are inserted/removed from the system and
    prints its uids. The code is not pretty but it works!
    def update( self, observable, (addedcards, removedcards) ):
        apdu = [0xff, 0xca, 0, 0, 0]
        for card in addedcards:
            cardtype = AnyCardType()
            cardrequest = CardRequest( timeout=1, cardType=cardtype )
            cardservice = cardrequest.waitforcard()
            response, sw1, sw2 = cardservice.connection.transmit(apdu)
            tagid = toHexString(response).replace(' ','')
            print tagid
            #urllib2.urlopen("http://your_web_servers_waiting_for_card_data/?uid=%s" % tagid, None, 3)
          except Exception as e:
            print "Exception detected: %s" % e
print "Card Monitor started..."
cardmonitor = CardMonitor()
cardobserver = printobserver()
cardmonitor.addObserver( cardobserver )
while True:

It was tested using an Omnikey 5321 v2 USB reader and it was working perfectly. I know that I’m doing two calls to the device (the first one detects it and the second one requests the UID) and this could probably be done in a single pass. If you know how to do it, please step forward 🙂

PS: It was also shared on github: https://gist.github.com/zatarra/75df47c8bd5a8d913cb4