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 


This is going to be a quick one.

Remember ZSUN Wifi Card reader? It seems that there’s a new device that does the same thing. In fact it does look like a clone:




I just bought one of these from a Chinese supplier. It costed $7.5 USD and it does exactly the same. Using NMAP to scan for open ports I get the same results. So it was not surprising when I got access to it using the very same password “zsun1188”.

Screen Shot 2016-04-21 at 20.40.08


In order for you to flash the existing firmware you need to edit /etc/producttype and replace the A50 for SD100.  The rest of the process should be pretty straight forward.


Enjoy your dirt cheap new router 🙂

Here in my company we regularly need to check for expired certificates or just to have a proactive management checking which certificates are close to their expiry dates and issue new ones to avoid service disruption.

For that reason I’ve created a simple bash script which can be used in conjunction with nagios to check for expiring certicates.

#       Check certificates inside a java keystore
TIMEOUT="timeout -k 10s 5s "
ARGS=`getopt -o "p:k:t:" -l "password:,keystore:,threshold:" -n "$0" -- "$@"`
function usage {
        echo "Usage: $0 --keystore <keystore> [--password <password>] [--threshold <number of days until expiry>]"
function start {
        CURRENT=`date +%s`
        THRESHOLD=$(($CURRENT + ($THRESHOLD_IN_DAYS*24*60*60)))
        if [ $THRESHOLD -le $CURRENT ]; then
                echo "[ERROR] Invalid date."
                exit 1
        echo "Looking for certificates inside the keystore $(basename $KEYSTORE) expiring in $THRESHOLD_IN_DAYS day(s)..."
        $KEYTOOL -list -v -keystore "$KEYSTORE"  $PASSWORD 2>&1 > /dev/null
        if [ $? -gt 0 ]; then echo "Error opening the keystore."; exit 1; fi
        $KEYTOOL -list -v -keystore "$KEYSTORE"  $PASSWORD | grep Alias | awk '{print $3}' | while read ALIAS
                #Iterate through all the certificate alias
                EXPIRACY=`$KEYTOOL -list -v -keystore "$KEYSTORE"  $PASSWORD -alias $ALIAS | grep Valid`
                UNTIL=`$KEYTOOL -list -v -keystore "$KEYSTORE"  $PASSWORD -alias $ALIAS | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'`
                UNTIL_SECONDS=`date -d "$UNTIL" +%s`
                REMAINING_DAYS=$(( ($UNTIL_SECONDS -  $(date +%s)) / 60 / 60 / 24 ))
                if [ $THRESHOLD -le $UNTIL_SECONDS ]; then
                        echo "[OK]      Certificate $ALIAS expires in '$UNTIL' ($REMAINING_DAYS day(s) remaining)."
                        echo "[WARNING] Certificate $ALIAS expires in '$UNTIL' ($REMAINING_DAYS day(s) remaining)."
        echo "Finished..."
        exit $RET
eval set -- "$ARGS"
while true
        case "$1" in
                        if [ -n "$2" ]; then PASSWORD=" -storepass $2"; else echo "Invalid password"; exit 1; fi
                        shift 2;;
                        if [ ! -f "$2" ]; then echo "Keystore not found: $1"; exit 1; else KEYSTORE=$2; fi
                        shift 2;;
                        if [ -n "$2" ] && [[ $2 =~ ^[0-9]+$ ]]; then THRESHOLD_IN_DAYS=$2; else echo "Invalid threshold"; exit 1; fi
                        shift 2;;
if [ -n "$KEYSTORE" ]

All you have to do is call it like this:

./checkCertificate --keystore [YOUR_KEYSTORE_FILE] --password [YOUR_PASSWORD] --threshold [THRESHOLD_IN_DAYS]

The threshold indicates how many days are left until the expiry date is reached. I’m sure that there are several other ways of doing it but this is my own 🙂

In case you’ve tried to upgrade your XBMC application using the official repositories from “team-xbmc” you may have already noticed that the rar support was disabled. This means that you won’t be able to play movies or open subtitles without extracting it first.

You have two options to fix this issue:

a) You compile the source code and enable the non free features.

b) You use a precompiled version made by someone else.

Fortunately there are good news for those who want option b.  A guy named Nathan runs a repository where you can download XBMC with these features enabled. Just add his repository to your sources list and you are ready to go.

sudo add-apt-repository ppa:nathan-renniewaldock

apt-get install xbmc


You can also manually check out his repository here.

Have fun! 🙂

After several months offline I decided to implement the needed changes in order to make it work again with my current ISP.  If this is the first time you see this, I have implemented an online version of  this project.

Just check the link on the top of this website ( http://www.davidgouveia.net/android-ksoap2-stub-generator/ ). All you need to do is input the url of the wsdl that you want to generate the stub.

Have fun 🙂


Today I’m going to show you a very small script that allows you to convert any video (as long as it is supported by mplayer) to a GIF.

Required tools:

* mplayer

* convert


mplayer is popular media player available for multiple operating systems that support a wide range of video formats. The convert tool is an utility that lets you convert between multiple image formats among other definitions.  Since the mplayer takes screenshots using jpeg format, we need to use the convert tool to do the convertion to aGIF format.


Copy the following code, save it to a file and change its permissions (chmod a+x) and you are ready to roll 🙂



shopt -s nocaseglob
if [ ! -d "$TMPDIR" ]
        mkdir $TMPDIR
\rm $TMPDIR/* &> /dev/null
if [ $# -lt 3 ]
        echo -e "Usage: $0    []\nExample:\n$0 00:15:11 10 myvideo.avi 320:240"
        exit 1
if [ -n "$4" ]
echo "Generating screenshots. Please be patitent..."
mplayer -ao null -ss $1 -endpos $2 $3 -vo jpeg:outdir=$TMPDIR/ -vf $SCALE &amp;&gt; /dev/null
if [ -f $TMPDIR/00000001.jpg ]
        echo "Finished generating frames. Assembling the animated GIF..."
        convert -delay 5 $TMPDIR/*.jpg $TMPDIR/output.gif
        echo "Done! Please check the $TMPDIR/output.gif"
        exit 0
        echo -e "Oops\! Something went wrong and the frames were not generated. Check your parameters\!"
        exit 1

Just try it and let me know 😉

As a sysadmin, I should always search and check for errors on every machine that I manage. Unfortunately one of them has an Adaptec 5405 which I forgot to monitor using nagios and just like Murphy’s Law says – “Anything that can go wrong will go wrong” – something went wrong and I have lost information. Not a really big problem because I have backups of everything but it could have been avoided if I had monitored the status of the Adaptec just the way I do with software raid arrays (/proc/mdstat rules!).

So I developed another simple script using Perl (again 😛 ) to check the status of all the available arrays.

#!/usr/bin/perl -w
use strict;
use warnings;
my $adaptec_tool = "/usr/src/cmdline/arcconf";
my $dump = `$adaptec_tool getconfig 1 ld`;
my @raids = ();
while ($dump =~ /Logical device name.*?:.*?([a-z0-9]+).*?raid level.*?:.*?([0-9]+).*?status of logical device.*?:.*?([a-z0-9]+)/gsi) {
        push @raids, {"name" => $1, "raidlevel" => $2, "status" => $3};
foreach my $raid (@raids)
        if ( $$raid{status} ne "Optimal" )
                print "Critical: Raid not Optimal! (Array Name: $$raid{name}, Level: $$raid{raidlevel}, Status: $$raid{status})\n";
print "OK: All arrays in optimal shape\n";
exit (0);

You just need to download the “Adaptec Storage Manager” to connect to the RAID card and read the status. You can use this link to do it.

This is probably a common problem among all the people trying to get audio over HDMI under Linux using an EN210 graphics card (or similar).

Even though the HDMI may appear in your available cards listed in proc (/proc/asound/cards) you will probably see that you cannot find it using the aplay utility. Just check it running the command “aplay -l”. The HDMI device isn’t listed here isn’t it?

The reason for this issue is related to the ALSA driver version 1.0.21 (or older) which is quite buggy for these graphics cards.

You can check which version you are using by executing the following command:

cat /proc/asound/version

If you get a version older than 1.0.21 then you need to upgrade it. You can check your favourite distribution’s repository for an update or you can try to compile it from source code.

If you can’t find an update, check this page: http://ubuntuforums.org/showthread.php?t=1681577

It might help you 😉

If you are running the latest version of Ubuntu and tried to mount a NTFS filesystem you probably already know that you can’t and maybe you have even seen an error like “mount exited with exit code 21″.

This seems to be due to a bug in libfuse2 and/or fuse-utils package. To fix this temporarily you can downgrade both packages to a prior version. libfuse2 and fuse-utils version 2.8.1-1.1ubuntu2.2 seem to be OK but 2.8.1-1.1ubuntu3.2 is useless.

Just download both packages and install them:



Don’t forget that these are 32bit packages. If you are using 64bit OS then download the needed packages.

sudo dpkg -i libfuse2_2.8.1-1.1ubuntu2.2_i386.deb
sudo dpkg -i fuse-utils_2.8.1-1.1ubuntu2.2_i386.deb

Problem solved 🙂