Correct use of grep during recursive search

Whenever I need to search through multiple files after a specific term, I usually turn to GNU grep. If I happen to be on a Windows computer, I normally install Cygwin that allows  me to use the same tool. If all else fails, or I am unable to install Cygwin for some reason, I turn to the the built-in Windows command line tools find and findstr for emergencies.

Grep is a great tool. It’s easy to learn, and it has multiple additional functionaltity (like regular expression search patterns) for finding that particular needle in the haystack you are looking for .

In its simplest form, you normally run:

grep "search term" *

This will search through all files in the current folder and report where instances of “search term” are found.

If you however need to search through the current folder (which also happens to contain multiple subfolders), and you want to do a recursive search through all the subfolders, you would on a Linux system normally write the following:

grep -r "search term" *

And you will then get the desired response. Grep will recurse through the current directory and all subdirectories for instances of “search term”.

I got really surprised the other day when I had to do a recursive search on files with a specific suffix, like *.txt. Beforehand, I knew to a certain degree what the result would be, but grep was unable to find what I was looking for! Let me illustrate by example:

For this test we will use a random set of text files found on the internet. For my own amusement, I used the ufo archives from, located at Feel free to try out for yourself.

Now, if we want to find out which files that contain a specific search term, in the current directory and all subdirectories, the intuitive approach would be to run the following command:

grep -r "The lecture was then essentially" *.ufo

Don’t you agree? However, grep will not provide the desired response if you run this command!

Instead, it will search through all files in the *current* directory!

In order to search through all the subdirectories as well, you need to use the following command:

grep -r "The lecture was then essentially" * --include=*.ufo

This will give the desired output. Note that the file search pattern has been modified from “*.ufo” to “*”.

I haven’t confirmed my theory on this yet, but my  assumption is that “*.ufo” is interpreted by the shell first and then passed on to grep. Grep would then think (since the shell interpreted your input first hand) you would only be interested in the files listed in the current directory.

Now that you know better, you won’t make the mistake I did (and probably have done several times earlier without knowing better!). Happy searching!

Hacking garage door remote controllers

Since I bought my house a year ago, which has a built-in garage with a radio controlled garage door opener, I have played with the idea that some day I will learn the basics of radio and replicate the signal from my garage door key fob and open the garage door from a command line.

This article explains step by step how I managed to figure that out. I have attempted to keep it strictly to the point and without involving too much detail. Interested readers are instead referred to the sources where I have found the information myself. Impatient readers can skip the next section, background, without losing context.


Let me be frank. Before this project, I knew basically nothing about the technical aspects of radio. The topic always fascinated me, but never enough to actually start studying or examining how it works. It was first when I saw a YouTube video featuring a talk by the creator of rfcat which was held at the DEF CON ® 20 conference in 2012 that I became dedicated to learning the basics.

There are a few guides available online about these type of projects already (i.e. hacking fixed key remotes), but I couldn’t find one detailed enough for my scenario and simple enough for someone with my limited background in radio t0 understand. Before starting this project, my knowledge of radio was fairly limited to knowing how I could operate the radio in my car, that radio operates over different frequencies in the spectrum (radio broadcast, WLAN, RC etc) and that the data can be modulated in different ways (AM/FM) . I had no practical knowledge whatsoever and barely knew what pulse code modulation (ASK/OOK) was.

However, that didn’t stop me from learning how it could be done, and I combined the information I found online with additional support from two individuals on the #rfcat IRC channel on Freenode,  AndrewMac and samy^^,  who pretty much taught me everything I needed to know. AndrewMac had written an article on the topic a few years back, and samy^^ demonstrated a neat trick to me on how to decode wave patterns, which I will show you later on.


The gear I used to accomplish this project is listed below. All but the proprietary key fob can easily be ordered online.

  • Software Defined Radio (SDR) that you can buy off Deal Extreme for $20
  • TI CC1111 radio transceiver development kit, flashed with rfcat firmware (which allows it to operate in lower frequency ranges)
  • GoodFET JTAG adapter (you need this to flash the firmware on the TI CC1111)
  • Proprietary key fob that you want to replicate


The guide assumes that the reader is using a Linux based operating system. If not, there are other alternative applications you can use (e.g. sdrsharp instead of gqrx), and you can probably, with a little effort, apply the remaining steps to suit your environment. If you’re running on a Linux based OS,  you need three different applications to finish this project.


From the official README, Gqrx is an (experimental) software defined radio application implemented using GNU Radio and the Qt GUI toolkit.  It works on Linux and Mac OSX. We will use this application to identify the signal from the key fob and make a recording of it.


rfcat, similar to GNU cat, is aiming to be a standard utility to read or write the contents on the radio frequency spectrum.  The main goals of the project are to reduce the time for security researchers to create needed tools for analyzing unknown (rf based) targets, to aid in reverse-engineering of hardware, and to satiate the developer’s rf lust. We will use this tool to replay the data we will decode from the key fob.


Audacity is a free (both as in free beer and freedom), easy-to-use, multi-track audio editor and recorder for Windows, Mac OS X, GNU/Linux and other operating systems. In addition to playing audio, you can also use audacity to analyze wave patterns (e.g. transform a wave into a bit stream), which we will do later in this guide.

Flashing the CC1111EMK with custom firmware

As mentioned on the CC1111EMK product specification from Texas Instruments, it is designed to operate in the 868 MHz and 915 MHz frequency bands. The CC1111 SoC is however capable of operating in the following ranges, given that it has been flashed with the correct firmware:

  • 300 – 348MHz
  • 391 – 464MHz
  • 782 – 928MHz

For additional details on the capabilities of the CC1111 chip, check out this information from the rfcat developers.

To flash the CC1111 with custom firmware, you also need a JTAG adapter like a GoodFET.

Flashing CC1111 with GoodFET
Flashing the CC1111EMK. You only need to plug in the GoodFET to the USB socket as it will deliver power to the CC1111 SoC.

Once you have all the gear, connect the JTAG adapter to the CC1111 debug pins as per the rfcat documentation and as shown in the above image (I only had male-female connectors, so I had to use a breadboard in between).

EMK Dongle Details
           | 2 4 6 8 10   2 4 6 8 10      |
           | 1 3 5 7 9    1 3 5 7 9
           |                              |
      ------                              |
      | USB                               |
      ------                              |
           | Don's Dongle (EMK)           |

              GoodFET              EMK
                PIN             DEBUG PIN

                 1 <----- DD -----> 4
                 2 <----- VCC ----> 2
                 5 <----- RST ----> 7
                 7 <----- DC -----> 3
                 9 <----- GND ----> 1

Once you have the connectors terminated, follow the remaining instructions in the rfcat documentation:

  • Install sdcc
  • Install make
  • Make sure both are in the path
  • cd into the “rfcat/firmware/” directory
  • “make testgoodfet” will read info from your dongle using the GoodFET. You should see something like this:
    SmartRF not found for this chip.
    Ident CC1111/r1103/ps0x0400
    Freq         0.000 MHz
    RSSI 00
  • “make backupdongle” will read the current firmware from your dongle to the file …/bins/original-dongle-hex.backup.
    (“make restoredongle”) to revert to the original firmware.
  • “make clean installRfCatDonsDongle” will clean, build, and install the RfCat (appFHSSNIC.c) firmware for a cc1111emk.

Once you have finished flashing the CC1111EMK, we continue by capturing the signal from the proprietary key fob.

Capturing the signal

Capturing the signal requires that you can listen to the rf spectrum in gqrx, so you need to connect your SDR to a USB socket and ensure you have the correct drivers installed. After that, you can activate the SDR from the power button in gqrx, and it will look something like the below screenshot (which has nothing to do with this project).  The screenshot below displays two strong wide FM radio signals, where one is operating on the 98.200 MHz frequency.

gqrx screenshot

To make a recording of the signal from your key fob, you need to know which frequency it is operating on. Most of these garage door key fobs operate somewhere around 433 MHz (mine was set to 433.92 MHz, and it was even printed on the remote).  Once you have discovered the frequency, try to squelch the background noise as much as possible to get a clean signal. This is done by adjusting the squelch parameter, as shown in the below screenshot. As my SDR’s antenna was quite close to the keyfob, -60 dBFS turned out great.

gqrx squelch dBFS

Once you have made a recording, you can look at the result in Audacity.

Signal in Audacity

We are only interested in the data between 2.75ms and 3.35 ms. The pattern after 3.35 ms is simply noise from the transmitter. As we can see from the recording, there are 8 data groups (or “packets”). The next step now is to further analyse these blocks and ultimately decode it.

Decoding the signal

Decoding the signal can be done in several ways. My first attempt was to use the rtl_433 application which allowed me to make a data dump of the signal (as interpreted by rtl_433), as shown from the output below. However, I had no way of verifying whether it was correct or not except for the fact that 8 packets were sent.

signal_start = 123439928, signal_end = 123606725
signal_len = 166797,  pulses = 88
iteration 1. t: 557    min: 362 (51)    max: 753 (37)    delta 9850
iteration 2. t: 562    min: 365 (52)    max: 759 (36)    delta 45
iteration 3. t: 562    min: 365 (52)    max: 759 (36)    delta 0
pulse coding: Short pulse length 365 - Long pulse length 759

short distance: 219, long distance: 604, packet distance: 9208

p_limit: 562

[00] {11} 1a 80 : 00011010 10000000 
[01] {11} d1 40 : 11010001 01000000 
[02] {11} 1a 80 : 00011010 10000000 
[03] {11} d1 40 : 11010001 01000000 
[04] {11} 1a 80 : 00011010 10000000 
[05] {11} d1 40 : 11010001 01000000 
[06] {11} 1a 80 : 00011010 10000000 
[07] {11} d1 40 : 11010001 01000000

As we can see from the output, rtl_433 reports that

  • The keyfob sends 8 packets, of which 2 are unique (i.e. 2 alternating packets, sent four times)
  • Packet 1 consists of the bitstream 00011010 10000000 (0x1a, 0x80)
  • Packet 2 consists of the bitstream 11010001 01000000 (0xd1, 0x40)

I suspected that the decoded bitstream was incorrect, as the last part of all the eight packets (alternating between 10000000 and 01000000)  didn’t resemble the waveform previously displayed.

The image below shows the first of eight packets that are transmitted from the key fob. As seen, there are two types of pulses that are sent – short and long. The packet starts with three short pulses, followed by two long etc. If we compare this with the output of rtl_433, the first eight bits (00011010) matches the pattern where short pulses are interpreted as 0 and long pulses as 1 – but the second byte (10000000) is way off.


This might have happened due to incorrect configuration parameters in rtl_433 when I made a dump of the data. If you look closely, you’ll notice that the packet doesn’t even contain 16 pulses, which would be required to decode the data to two bytes with this method, but merely twelve!

At this point, I started asking more experienced people on IRC for input on how to decode the 12 pulses, and I eventually got in contact with samy^^ on the #rfcat channel on Freenode, who suggested not to count each pulse as a bit, but consider each pulse, which lasts ~4ms, as 4 bits! This is essentially the same as setting the baud rate to 1000 Bd.

Since Audacity has the possibility to highlight data down to 1 ms, this made the process a whole lot easier. I have made a GIF below to illustrate this. Note that I no longer count short pulses as 0 and long pulses as 1, but every 1 ms as either 0 or 1, depending on whether the carrier (i.e. when the amplitude is high) is present or not.


Using this trick, the following 6 bytes can be extracted from this waveform:

  • 00010001
  • 00010111
  • 01110001
  • 01110011
  • 01110001
  • 00110000

After I had used this method to decode the first packet, I repeated the process for the second packet. Since the whole bit stream consisted of sending packets 1 and 2 repeatedly 4 times, we are now done with the decoding stage and can continue with replaying the data.

Replaying the signal

For replaying the signal, we use the rfcat library which is available here. The library is written in Python, and it is quite simple to get started using it. The official documentation (i.e. the README file which is part of the project) is quite good, but fails to mention signal strength and how you disable sending the default preamble.

To use rfcat, you can either use the rfcat script, which is basically a wrapper to either Python or IPython (whichever is available) that imports all the libraries you need – or you can create a script yourself in case you need to do something a bit more advanced. The below screenshot shows the “welcome” screen when you fire up the rfcat script.


Two interesting methods that are not mentioned in the welcome screen, are:

  • d.setMdmSyncMode(0) – By default a preamble or sync word is sent before the user data. The keyfob used in this guide did not make use of a preamble, so we disable it.
  • d.setMaxPower() – By default the CC1111EMK with rfcat firmware transmits the signal with low power. If you run this method, it will set the power to the maximum which would make your signal travel longer.

Finally, the following code is my end result which allowed me to open my garage door from a CC1111EMK using rfcat and rfcat firmware.


import time
import sys 
from rflib import *

FREQ = 433920000 # Set my frequency to the gate remote
PKTLEN = 6       # Set my packet length to 6 as I am sending
                 # 6 bytes in each packet
DRATE = 1000     # baud rate of 1000 means that a 1ms pulse
                 # can be counted as a bit

packet_1 = [ 
            '00010001', '00010111', '01110001',
            '01110011', '01110001', '00110000'
packet_2 = [ 
            '00010001', '00100100', '01100111',
            '01001010', '00001111', '00011110'
data_hex_1 = [ chr(int(x, 2)) for x in packet_1]
data_hex_2 = [ chr(int(x, 2)) for x in packet_2]

def send_data(d, data, repeat=4):
    # PCM'ify the packets
    for i in range(0,repeat):
        for packet in data:
    d = RfCat()
    d.setMdmSyncMode(0) # disable syncword and preamble as this is not used
                        # by the remote.
    #d.setMaxPower()    #imma chargin' mah lazer 
    send_data(d, ["".join(data_hex_1), "".join(data_hex_2)])

except Exception, e:
    sys.exit("Error %s" % str(e))
    # TODO implement software reset in case of USB timeout

If you are interested in more information regarding RF signals and use of rfcat, I recommend reading:

Monitoring your CrashPlan home backup instance

I take a lot of pictures and little is more important to me than making sure that all my photos are kept in safe storage. For this purpose, I use the online backup service from CrashPlan. With the CrashPlan backup client being written in Java, it is supported on many platforms, including GNU/Linux, and it even allows you to configure your CrashPlan server via SSH.

CrashPlan is a great “bang for buck”, costing only as little as $4/month (if you buy a 4 year subscription) and top you have unlimited online storage. What is the catch you ask? Well, if you ask me the main catch is that with the “Home” edition (for $4/month), you are not able to access its API. This is important to me as I use Nagios to monitor all my servers and also important services that I need to know is up and running 24/7.

Using Nagios to monitor CrashPlan
Using Nagios to monitor CrashPlan

I figured out a way to accomplish this as the CrashPlan server application produces a history log of whatever it is doing, called “history.log.0”. This file typically looks something like this:

history.log.0 sample: click to open SelectShow

In brief, there are three important data types we need to parse:

  1. The timestamp
  2. When the backup (or scan) job started
  3. When the backup (or scan) job completed

If you are used to parsing text and recognizing patterns, you can easily write some regular expressions to extract the types of text that this log contains. I wrote a small application in Python (crashplan-log-parser) that does exactly this, and allows you to print the latest job that finished, statistics and also the number of hours passed since the last job was completed.


The above screenshot shows the command line options of The below screenshot however, shows the statistics command in use. Of a total of 110 jobs (found in the log file), 76 are scan jobs and 34 are backup jobs. The last backup was completed this morning 03:00 AM Norwegian time.


Finally, for integration in Nagios, the following command is also available. This prints the number of hours since the last backup or scan job was completed (integer value).


With this information, one could easily write a Nagios monitor script for polling this e.g. once per 30 minutes. e.g.

Nagios passive check script: for monitoring CrashPlan Home SelectShow

Replacing a vertical list of characters with a sequence of numbers in VIM

During my spare time, I try to learn C. Often I find myself having to create arrays, and fill these with data manually. Since I hate, and let me emphasize, hate, doing repetitive tasks, I wanted to show you guys how to create an array with 6 elements as simple as possible.

Consider the following; you want to create an array of strings with 6 elements, where each element can hold a maximum of 25 characters. Hence, you type the following:

#include <stdio.h>

int main(int argc, char argv[])
char my_array[6][26];

strcpy(my_array[0], "Something");
strcpy(my_array[1], "Something else");
strcpy(my_array[2], "Something different");
// etcetera

return 1;

Now, that wasn’t very tiresome, but what if you had to enter 10 elements, or even 50? Typing strcpy(my_array[x], “blahblah”); that many times can even make the most patient person go nuts. If you’re a VIM user, this process can however be simplified quite a bit.

First, start VIM. Next, type ‘strcpy(my_array[x], “”‘);’, and yank this line by pressing ‘yy’. Now, to repeat this process 5 times, simply type “5p”. You should now have 6 lines containing:

strcpy(my_array[x], "");
strcpy(my_array[x], "");
strcpy(my_array[x], "");
strcpy(my_array[x], "");
strcpy(my_array[x], "");
strcpy(my_array[x], "");

The final step is now to replace all the x characters with a sequence of numbers, ranging from 0 to 5. By using the Nexus plugin, located here, you can do this with one neat command.

With the plugin installed, replace the first occurance of ‘x’ with 0. Then, enter Visual Block Mode (C v), and select the remaining x characters. Now, enter the command: :’< ,'>s/\%V./\, and all the x characteres is replaced with a sequence of numbers, ranging from 1 to 5. You should now have:

strcpy(my_array[0], "");
strcpy(my_array[1], "");
strcpy(my_array[2], "");
strcpy(my_array[3], "");
strcpy(my_array[4], "");
strcpy(my_array[5], "");

Neat, huh? If you want to perform the task again, you will see that s1 continues from where it stopped in the above example. To reset the s1 variable, run ‘:call s1.reset()’.

Configure sendmail as an MTA relay on Slackware

My landlord recently changed to a different ISP that blocks all outgoing requests on port 25, except towards their own SMTP-server. After getting my hands dirty by plowing throgh the sendmail documentation, located here, I figured out that it wasn’t very difficult to configure sendmail to relay all outgoing e-mails towards this server, thus solving the entire problem.

If you want all outgoing mail to go to a central relay site, define SMART_HOST.

I started by checking the sendmail configuration file, /etc/mail/, that strictly specified “DO NOT EDIT THIS FILE!  Only edit the source .mc file.“. Following this advice, I had to figure out where this .mc file was located.

I did a quick search for all files containing sendmail and cf on my local system, and discovered “/usr/share/sendmail/cf/cf/“. That was indeed the correct file, and I simply added “define(`SMART_HOST’, `’)“. To see the entire configuration file, expand the spoiler below.

Spoiler Inside: modified SelectShow

Once that was done, I had to compile the configuration file with “m4 /usr/share/sendmail/cf/cf/ > /etc/mail/“, and restart inetd and sendmail by running /etc/rc.d/rc.inetd restart && /etc/rc.d/rc.sendmail restart.

Problem solved, and I’m receiving my emails again!

Getting cmus to cooperate with conky

Screenshot of My Current Desktop

cmus is a small, fast and powerful console music player for Linux and *BSD. If you also happen to use conky, the light-weight system monitor, grabbing data from cmus and rendering it in conky is a piece of cake!

cmus comes with an application called cmus-remote that allows you to control the music player from a remote location. We’re now gonna use this app to grab the metadata and make it accessible to conky.

Since conky doesn’t have a plugin for accessing cmus directly, we need to write a simple shell script:

if [ ! -x /usr/bin/cmus-remote ];
echo "cmus is not installed."

ARTIST=$( cmus-remote -Q 2>/dev/null | grep artist | cut -d " " -f 3- )
TITLE=$( cmus-remote -Q 2>/dev/null | grep title | cut -d " " -f 3- )

if [ -z "$ARTIST" ];
echo "Nothing"
echo "$ARTIST - $TITLE"

If you have a song currently being played in cmus, you can run the script shown above in your favorite terminal, and something like “Scar Symmetry – Trapezoid” will be returned.

To get the information displayed in your conky bar, you can add the following somewhere in your .conkyrc:

${execi 2 /path/to/script}

To see an example of how a rendered bar looks like, check out the screenshot of my current desktop. I’m using the i3 window manager, and the output from conky is rendered using a combination of i3-wsbar and dzen2.

My .conkyrc is available here, and you can download the cmus-conky-script here.

Using Dropbox on Slackware

This guide will show you how to install Droxbox on a system that doesn’t have Nautilus installed. This is especially useful to people who use Slackware, because GNOME is not installed by default. You still need a file manager though, so in this example, we’ll use Thunar.

In order to get Dropbox to work, we have to trick Dropbox into thinking that Nautilus is already installed. The easiest way to accomplish this, is by creating a script in /usr/bin called nautilus, which basically is a link to Thunar. To get started, download a precompiled binary from I used a binary compiled for Fedora 10 called nautilus-dropbox-0.6.1-1.fc10.i386.rpm.

$ wget

What we now are going to do is to run rpm2tgz on this package so that we can explode the package using explodepkg. We do so because we want to create a slackware-package, where we also include our little workaround. First, log in as root.

$ su -
$ mkdir /tmp/dropbox
$ mv nautilus-dropbox-0.6.1-1.fc10.i386.rpm /tmp/dropbox
$ rpm2tgz nautilus-dropbox-0.6.1-1.fc10.i386.rpm
$ explodepkg nautilus-dropbox-0.6.1-1.fc10.i386.tgz

Now, go to /tmp/dropbox/usr/bin, fire up your favorite text-editor and write the following:

thunar $@
exit 0

When you’re done, save the file as “nautilus”. Now, go back to /tmp/dropbox, create a folder called install, touch a file called “slack-desc” and run makepkg to create a slackware-package.

$ mkdir install
$ touch install/slack-desc
$ makepkg dropbox-0.6.1-i386-1vh.tgz

The only thing that has to be done now, is to install the package.

$ installpkg dropbox-0.6.1-i386-1vh.tgz

Special keys stops working while using VMware

Has it occured to you that when you’re using VMware Workstation or Server that CTRL, ALT and SHIFT stops working? When this first started happening to me, I just restarted X to fix the problem. As you probably know, this is not a good solution

If you however try executing setxkbmap once this problem occurs, you should gain control over the keys again. This did at least work for me 🙂

New kernel resulted in massive audio problems

Today I upgraded my current kernel (2.6.24) to the newest, 2.6.25 and also made some minor changes to the config-file. I added some new options, and removed a few I thought was unnecessary.

After the new kernel compiled successfully, I moved the image to /boot and configured lilo. Then, I did a quick reboot and everything worked fine, or so I thought.

I compiled the kernel while I was attending a rather boring lecture at school, and I didn’t have the opportunity to check how the whole system worked until I got home. When I finally got home, I had to relax a bit so I put on some music. To my surprise, Audacious returned an error saying it couldn’t access the sound-device. I then checked the rights on every file related to sound in /dev, and everything seemed to be in order. Then, I tried reconfiguring ALSA by running alsa-conf, but neither that seemed to do the trick.

My last resort before googling for an answer was checking the audio-tab under preferences in Audacious. Making sure that “Current output plug-in” was set to ALSA 1.3.5, I clicked the button “Output Plugin Preferences” and noticed that the current audio-device was set to “default”. I tried switching to one of the other fields in the combobox (Intel ICH6: xxx), and guess what. Audacious finally worked again.

Since I now was able to play audio without problems, I settled for using this workaround – at least until I tried playing a movie through MPlayer. When I attemped to watch a movie, I got the error-message “X11 error: BadAccess (attempt to access private resource denied)” slammed in my face. I also tried running gmplayer – which refused to start and returned the error-message “Fatal Error! – [ws] shared memory extension error.”. Now I realized that something was very wrong. Using my wits, I determined that the issue had to be with the newly compiled kernel. I ran a “make menuconfig” and tried to locate any misconfigurations.. ..although without results.

I was now out of ideas and went on to the last resort and googled the error-message outputted by gmplayer along with “kernel”. A few minutes and 4 webpages later, I found the solution to the problem.

While I was configuring the new kernel, I had disabled “System V IPC” (CONFIG_SYSVIPC), which is located under “General Setup”. I remember reading the help-message before I disabled this option and it didn’t look very important. It stated that some programs, like “dosemu” wouldn’t work unless this was turned on. Since I don’t use dosemu, but dosbox instead, I thought I wouldn’t be needing it and therefore left it out.

However, I was very wrong and from now on,  I will always compile my new kernels where I’ll include CONFIG_SYSVIPC. And yes, when the new kernel was compiled yet again, I booted it and everything worked like it used to.