Running Traffic over SSH easy peasy

Last week I was stuck in a hotel located in the middle of a forest with crappy GPRS signal so my mobile internet wasn’t any good. On top of this the ‘free’ wifi at the hotel provided only web traffic connectivity ( ports 80 and 443). Sure, a smart guy would run a VPN over port 443 and would be on his way. Unfortunately I’m not that guy. I struggled getting some remote ssh server listening on port 80 and in the end managed to do my thing.

Reading Hacker news today I stumbled upon a cool piece of softare: sshuttle. Acording to the developer, it allows you to seamlessly run traffic over ssh in a VPN kinda way, but without the vpn hassle. All you need is a working ssh connection and sudo rights on your machine. Traffic gets somehow redirected via ipfw or iptables to the ‘tunnel’ and out it goes to the remote ssh endpoint. I just tested this with a couple of remove ssh servers and it works pretty good. Ah yes, and it’s open source so you can inspect the code for funny stuff..

Bash and Template Files

Last week I had to migrate my dns server and to do stuff properly I also added a couple of slave DNS servers just to make sure. Problem: ~15 domain names that need to be added to a fresh bind installation. The zone files didn’t change too much so that was fine, sed helped me out with the replacing of old IPs. But what about the bind configuration ? I had to add add the following declaration for all the 15 domains and on each of the slave dns server the “slave” equivalent:

zone "" {
        type master;
        file "/etc/bind/zones/";

I was in the mood for automation but I wanted something light and quick to setup. Obvious answer: bash.

I created a “template” file where and I replaced the domain name with a place holder:

zone \"$domain\" {
        type master;
        file \"/etc/bind/zones/$domain/zone.db\";

I then wrote a small bash loop that walks the array of domains and feeds them one by one to the template file. The end result was a nice config file with all of the domain names.

for i in `find * -prune -type d`; do
eval "echo \"$(cat db.zones.tmpl)\""

The essence here is that the eval function forces bash to do parsing and variable replacement once more on the argument.


I’m going to start a series of blog posts about linux apps that I can’t live without. After a fresh system install these are the first installed.

The more and more I use Linux the more I find myself stuck into some console. While the default terminal app shipped with Gnome is just fine for small jobs it gets annoying when I accidentally close it and or when it’s not on the right desktop. Alt-tab-ing all the time is painful.

This is where the geek in me comes in. Remember the times of Quake and the “console”, when you pressed the ’tilda’ key (~) and a nice console dropped down from the top of the screen allowing you to type game commands ? Well that nifty little concept  made its way to the modern desktop!

Enter Yakuake or “A drop-down terminal emulator based on KDE Konsole technology” as the About menu says. I install it even if I use gnome and although it ads some tens of megs of libraries and breaks the “pure gnome install”. It’s so damn worth it! Pressing a magic key (default F12) instantly pops out the Yakuake window. Do your thing in the console and press the magic key again and the console disappears making way for your other apps. It’s simply brilliant. Yakuake has support for multiple terminal tabs so you can have multiple sessions opened. Using short cut keys you can quickly change the tabs. I consider that Yakuake improves my productivity just as much as the ‘screen’ utility, even tough it has nothing to do with ‘screen’ 🙂

Yakuake is not the only app that offers this type of functionality. Tilda is another ‘quake console clone’ and it’s based on GTK instead of QT.

Another alternative is ‘guake’, a younger app that aims at the same goal: quake style terminal emulator. It is also GTK based , hence the ‘g’, and it feels more snappy than tilda. With a bit of customizing it comes close to yakuake but I find it a bit unpolished.

Personally I find Yakuake faster and more friendly but it’s all about habits. Give them all a chance!

If you are using a Mac and want the same thing take a look at Visor ( Quake3 anyone? ). It is roughly the same thing.

The same thing goes for you Windoes Powershell lovers out there. You can have the amazing Powershell in a quake console:

Nice pic goes here.

Hardware Keylogger Detection


Keyloggers are nifty things used to grab keyboard input for later analysis and use.

The most common type of keylogger is the software keylogger as it is just some program that records key presses. Running it usually requires administrator privileges and this limits the attack surface as one must first gain this type of privileges.

Hardware keyloggers on the other hand are just small devices that sit between the keyboard and PC and listen and record all the keystrokes.

This article refers to the KeyDaemon USB, a hardware keylogger produced by the Polish company KeeLog. Official website

The device is pretty small: on one end there’s an USB A plug (this goes to the PC) and on the other end there’s an USB A receptacle (here the keyboard is plugged). The plastic casing contains a microcontroller that listens in to the USB traffic. A 2GB storage module is also embedded in the small casing and is used to store the sniffed key presses.

The default mode is the “record mode” where the device silently records data. When a magic 3-key combination is pressed ( KBS is the default) the keylogger goes into “playback mode” and it makes visible the embedded flash storage. The keyboard is disabled and in place a flash storage device is detected by the operating system. Inside the flash disk there are two important files: log.txt which contains all the key presses captured by the keylogger and config.txt, which contains configuration settings for the device. By editing config.txt one can change the magic key combination (more on this later).

The keylogger is transparent and does not change the USB vendor ID or product ID. One can not tell that the device is plugged in just by looking at the USB device enumeration ( lsusb for example). This makes the detection of the device quite difficult at first sight.


The initial approach was to see if the current drain on the USB port was higher with the keylogger in place, but this turned out to be too impractical as it’s hard to do an accurate measurement. The OS support for this is also limited and I felt that this was a dead end.

Next I wanted to see how the keylogger handled unexpected flows of commands. The ioctl interface in linux permits changing the leds on the keyboard from user space. This nifty python script makes your keyboard flash the leds like a Las Vegas Casino billboard:

import fcntl
import os
import time

SCR_LED  = 0x01
NUM_LED  = 0x02
CAP_LED  = 0x04

console_fd ='/dev/console', os.O_NOCTTY)

all_on = SCR_LED | NUM_LED | CAP_LED
all_off = 0

while 1:
	fcntl.ioctl(console_fd, KDSETLED, all_on)
	fcntl.ioctl(console_fd, KDSETLED, all_off)

Unfortunately the keylogger had no trouble in handling this type of data.

The next step was to see how the device handles traffic sent from the PC to the keyboard and not the other way around. One would expect that a properly designed keylogger would also take into consideration the direction of the traffic flow. As you will see this is not the case…

The USB keyboard uses the HID protocol to send and receive data to and from the PC. The basic data packet (or report) has 8 bytes. The first byte contains keycodes for the modifier keys (ALT, SHIFT, CTRL), the second byte is reserved for OEM and the remaining 6 bytes are used to send the keycodes for the pressed keys. So one can simultaneous press the modifier keys and 6 other keys.

Using libusb I wrote a very small application that sends the magic 3-key combination out to the keyboard. I didn’t think that this would work as I was expecting a propper design but to my surprise the device flash storage opened like a Christmas present from the first run. One interesting detail is that the keylogger needs to “warm up” since it was first plugged in. Sending the magic key combination immediately after plugging it in does not open the flash storage.

The next logical step was to further extend the app to brute force all the 3-key combinations. If no data can be written to the device then the flash storage has just popped up and a keylogger has been detected.

The device does not take into account the order in which the magic keys are pressed so KBS is also KSB or BKS. Also due to the fact that one can press a key only once a key combination of AAA for example would be invalid. This makes the number of key combinations very small and the brute force takes less than 1 second! While the code needs some polishing and some bugfixes (the USB handle is not cleanly released and this makes the keyboard unusable after execution – it needs to be replugged) it clearly proves that hardware keyloggers can be detected. This is a design flaw it will take a while until it will be fixed.

The PS2 variant of the keylogger has the same flaw and can be detected in the same manner : send all 3 key combinations out the ps2 port and the device will be detected at some point.

My proof-of-concept code uses a small library written by Paul J Stoffregen and Robin Coon of

Given the fact that this device is so weak (less than 1s to detect) a script or service could be executed at boot time. Maybe companies that write security software could use this to implement a hardware keylogger detection function.

Other devices use a passphrase instead of a key combination. This is harder to brute force and as stated above it all depends on the way the keyloger snoops the traffic. If it does take into account the source of the traffic then the above method is useless and the keylogger is still invisible.

Tar file with the code : keelogdetect.tar
Source code available via SVN :

Parsing XML data using bash and standard Unix tools

Parsing XML can be a tedious and unpleasant job if you insist on using just standard Unix tools like sed, awk, cut, grep and so on. One might say that it’s better to use python/perl/ruby/other language that ships with a full blown XML parser and use the standard Unix utilites for what they were meant for, plain old text files and not pesky XML. The problem with those nice programming languages is that they take away the one liners. You need to import stuff, have variables, flow control and so on.

A nice tool that makes one’s life easier when it comes to XML is XML2. It can convert a normal xml file to a more line oriented file format. The standard debian distribution has this neat tool in the repos so you are one apt-get away from using it.


One simple example. Take this XML file:

<fruit name="apple" type="royal gala" quantity="2" price="1"/>
<fruit name="orange" type="tasty" quantity="4" price="1.5"/>
<fruit name="banana" type="green" quantity="3" price="1"/>

We run xml2 against it:

cosu@roadwarrior:/tmp$ xml2 < fruits.xml
/xml/fruits/fruit/@type=royal gala

And now we extract all the fruit names:

cosu@roadwarrior:/tmp$ xml2 < fruits.xml |grep name |cut -d"=" -f2

There you go! A fruit salad! Of course for more complicated stuff use other tools 🙂


Joining pdf files

Combining multiple pdfs into a single file can be handy for putting together one big final report or for submitting a single print job instead of multiple smaller ones. Joining pdfs in a Debian based Linux distribution can be easily done by using the pdfjoin utility. It is provided by the pdfjam package. One only needs to

sudo aptitude install pdfjam

Then all that needs to be done is cd-ing into the folder containing the large number of pdfs and running:

pdfjoin *.pdf –outfile out.pdf

There you go, instant pdf!

Choosing random entries from a group

In the past two weeks we had a lottery-type thing on (Romanian Guitarist Community). Proguitar, the official importer of Fender products in Romania, wanted to give-away a custom made Fender Stratocaster electric guitar. To register, the community users had to fill out a form and choose from a series of custom options for the guitar.

As organizers we had to pick out the lucky winner of the raffle. Usually this is done by someone who is impartial. Due to the fact that we had about 1600 entries and that we are geeks we wanted to do something that geeks would do. Therefore we ditched the “extract the name of the lucky winner from a bowl”. The geek version of this is described in RFC2777 – Publicly Verifiable Nomcom Random Selection

In short RFC2777 describes a simple publicly verifiable algorithm to pick out a set of entries from a group as random as possible. The keywords here are public – anyone can see how the entries are picked – and as random as possible. To have random values a thing called information entropy is needed. To get that initial random value full of juicy entropy we used, as suggested in the RFC, the results from three international lotteries. This initial random value was slightly modified for each “extracted” entry and then transformed into a MD5 hash. Due to the nature of a hash when slightly modifying the original the resulting hash differs heavily from the original hash.

Below you can find a naive python implementation that can be freely used for any purpose. Just make sure you fill in the entropySource with a good initial random value.

import md5                                                 

if __name__ == '__main__':

    entropySource = ""

    numberOfEntries = 1655
    numberOfWinners = 10  

    numbers = map( lambda x: x + 1, range( numberOfEntries ) )

    i = 0
    entries = numberOfEntries
    print "index \t hex value of MD5 \t div \t selected"
    while ( i < numberOfWinners ) :                     
        md5hash =                             
        md5hash.update( chr( i ) + entropySource + chr( i ) )
        val = int( md5hash.hexdigest(), 16 )                 
        modulo = val % entries                               
        print str( i + 1 ) + "\t" + md5hash.hexdigest() + "\t" + str( entries ) + "\t" + str( numbers[modulo] )
        del numbers[modulo]                                                                                    
        i += 1                                                                                                 
        entries -= 1                        

Great success!

(that’s what Borat would say)

Today I’ve received wonderful news! I have been accepted to the System And Network Engineering Master at the University of Amsterdam! Starting from the end of August I’ll be relocating to Amsterdam for one year of full geek experience (hopefully!). I can not thank enough my girlfriend on being such a great support and motivator.Without her nothing could have happened.  Also my teachers (esp prof. Rughinis and prof. Tapus) at the Faculty of Automatic Control and Computer Science at University POLITEHNICA of Bucharest have been great mentors and supporters of my admission.

This could be a good time to add this blog to your RSS reader as starting from September I’ll be posting regularly on both geek related stuff and the lifestyle of an international student in the Netherlands.