Hacking garage door remote controllers

On December 4, 2014, in GNU/Linux, Hacks, News, Programming, Security, by Vegard Haugland

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.

Background

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.

Gear

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

Software

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.

Gqrx

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

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

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
           |-TEST-PINS----DEBUG-PINS------|
           |                              |
      ------                              |
      | 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.

pulse

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.

animation

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.

rfcat

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.

#!/usr/bin/python2.7

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.RFxmit(packet)
try:
    d = RfCat()
    d.setFreq(FREQ) 
    d.setMdmModulation(MOD_ASK_OOK)
    d.makePktFLEN(PKTLEN) 
    d.setMdmDRate(DRATE) 
    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:

Tagged with:
 

Monitoring your CrashPlan home backup instance

On April 15, 2014, in GNU/Linux, Hacks, News, Programming, by Vegard Haugland

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.

2014-04-15-215100_1366x768_scrot

The above screenshot shows the command line options of logparser.py. 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.

2014-04-15-215132_1366x768_scrot

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).

2014-04-15-215143_1366x768_scrot

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
Tagged with:
 

Reverse Engineering an Unknown Savegame File Format

On September 24, 2012, in Games, Hacks, News, Programming, by Vegard Haugland

Lately, I’ve spent a few hours playing FTL: Faster than Light – the spaceship simulation, real-time, roguelike-like game. One of the most challenging aspects of this game is that when you’re dead, you’re *really* dead. There is no way to continue playing, so you have to start over. Considering this game is quite difficult to finish in the first place (actually, I haven’t even finished it yet), I started looking for ways to tip the odds in my favor.

In-game screenshot of FTL showing the spaceship type “Kestrel”.

FTL allows you to save your game using a single save-slot. I suspected that this had to be written to a file somewhere, and after doing some digging I found the savegame file called “continue.sav”. The contents of this file is binary encoded in little-endian. So, in order to understand which bytes to alter in order to make the game easier, I had to reverse engineer the file format. Reverse engineering can be quite rewarding. Sort of like mentally climbing a mountain. While you’re working at it, it’s tedious and it can drive you crazy. However, when you finally make it, it is usually worth the effort!

In order to edit a binary file, you cannot use a regular text editor, as these programs parse the bytes in the binary file as ASCII. This will make the contents look like gibberish, and altering any of the contents will probably result in crashing FTL once you try to load the modified savegame.

Instead, you need a hex editor, which allows you to see and modify the binary file at byte level. Once you get a hex editor, you can fire it up and load the savegame. At first, you probably won’t make any sense out what you are seeing. To make it easier for yourself, make a copy of the savegame. Then return to the game, modify a variable and save the game again. Then, by comparing the two savegames, you should easily spot any differences.

Using this method, I quickly managed to map one third of the data in the binary file. To show an example, I have highlighted some of the byte values in the image below. The first 4 bytes contains the current ship integrity level. Second is the fuel value, followed by the number of available missiles. Finally we find the the number of droids and the amount of available scrap.

Here we are see bytes in the savegame encoded in little-endian. Each value consists of 32 bits (or 4 bytes).

Once you have all this information, you can either manipulate the values directly in the hex editor, or you can create a savegame editor. The first is definately easiest, as you need to spend more time decoding the file format in order to make a savegame editor. Especially if the size of the savegame changes based on the content, which is the case with the FTL savegames. As an example, text strings are stored dynamically, meaning that each string in the savegame is preceded by 4 bytes telling the length of the string. Because of this, you need to decode every byte before you reach the correct offset where you can modify the ship integrity.

ftlsg – an FTL savegame editor. Currenty, you are limited to changing the basic (read: important) attributes. (note: the values shown in this screenshot differs from the hex dump screenshot)

When you have finished decoding all the bytes preceding the offsets you want to modify, you need to apply your programming skills and create code that parses the binary file, that allows you to make modifications and that allows you to save the modified savegame. I started on one such project, written in C, which I am currently hosting on GitHub. Check it out at: http://github.com/v3gard/ftlsg.

The savegame editor is currently limited to changing the 5 basic attributes; ship integrity, fuel, missiles, droids and scrap. However, as I have mapped out a rather large portion of the binary file, I plan on adding support for changing more attributes in future versions.

If you feel like giving reverse engineering a try, I can highly recommend getting started with the FTL savegames. Mapping out the attributes listed above is not too difficult, and it is always fun learning something new!

Tagged with:
 

Teensy 2.0 USB Development Board

On February 20, 2012, in Programming, by Vegard Haugland

Last week I received my shining new Teensy 2.0 USB Development Board. During the weekend, I decided to spend some time getting to learn how to program it.

My Teensy 2.0 USB "Keyboard"

The Teensy is a complete USB-based microcontroller development system, capable of implementing several types of projects. The microcontroller on the Teensy 2.0 is an Atmel Mega32U4. All the programming is done via the USB port. There is also a project called Teensyduino, which allows you to write code for your Teensy board using the Arduino IDE.

The guys who produce the Teensy board have already made available easy to use libraries, that lets you implement a lot of functionality with little code. I decided to try out their USB Keyboard library, and make a small program that allowed me to make a programmable “keyboard”. These libraries are written in pure C, and can be compiled with gcc.

The small project I did allowed my to enter some text into any given application on my OS (which the Teensy was connected to), based on the state of a register in the micro-controller.  In order to see the state of the register, I hooked it up to a small blue LED, as seen in the image on the right. You can also see two buttons there. The top-most button flicks the LED on and off (i.e. sets the register to 0x00 or 0xFF, respectively), and the bottom button transmits some hard-coded text into the OS.

Screendump from my laptop while trying out the Teensy board

The buttons are powered by the +5V VCC pin on the Teensy and connected to ground via a 1K Ohm pull-down resistor. When the top button is pressed, a signal is sent to the D2 pin, and when the bottom button is pressed, a signal is sent to the D3 pin. The LED received power from the  B1 pin, which is set when the D3 pin receives power.

When my program is compiled and uploaded to the Teensy, the OS kernel thinks that a USB keyboard is connected to the USB port and parses all input as keyboard events. So, when I press the button button, the text “The light is now off” is sent to the OS. If I first press the top button which switches on the LED, I can re-press the bottom button, and the text “The light is now on” is sent instead.

I wonder what I might be able to accomplish  if I issued the command to open up a terminal and enter some code…:-)

 

Why you should stay away from Thrust::VPS

On February 19, 2012, in News, Ramblings, by Vegard Haugland
Thrust::VPS

Thrust::VPS - Damn, that's crappy VPS!

I’ve been a customer with Thrust::VPS (aka Damn::VPS) for well over a year. Despite several minor issues I’ve had with them during this period, I continued my customer relationship with them due to their low prices and high bandwidth cap of 1TB each month. During the last couple of weeks however, I started experiencing a lot of problems on my VPS (Virtual Private Server). When I contacted their tech support to resolve these issues, the answers I received were vague and, in my honest opinion, very unprofessional. In fact, the customer treatment I received from them was appalling to be frank, and it ended up with me terminating the contract I had with them, and signing a contract with Linode instead. Here’s why.

Continue reading »

 

Downloading FLV streams using rtmpdump

On October 16, 2011, in Hacks, News, by Vegard Haugland

Many TV channels allow you to stream their shows from a flash plugin on their website. How cool wouldn’t it be if you were able to download these streams to a file on your computer, or even show the streams in your favorite movie player, like mplayer? Let me tell you one thing. This is indeed possible.

How?

In order for the flash plugin to show the streams on your computer, they need to be freely available on the interwebz. If we use a protocol analyser like Wireshark to dig into the information sent between the flash plugin that runs in your browser, and the server that provides the video streams, we often see that it is transmitted using the Real Time Messaging Protocol (RTMP). If you happen to use a GNU/Linux based operating system, you’re in luck. There exists a toolkit called ‘rtmpdump’ that allows you to interact with a server offering RTMP streams. All you need to display these streams on your computer, are a few parameters that are exchanged between the aforementioned flash plugin and the RTMP server.

Example? Pretty please!?!

I will now show you an example of how this is done by grabbing an episode of the Norwegian TV show “Robinson-ekspedisjonen” that runs on TV3. This is the Norwegian version of Survivor. These episodes are freely available on http://tv3play.no if you want to display them in your browser. If you are like me, and you’d like a local copy on your computer, follow these steps:

1. Navigate to the URL where the first episode of Season 11 is located (http://www.tv3play.no/play/252950/)

2. Fire up a terminal and enter the following command (and yes, regular expressions are awesome!):

ngrep -W byline | grep -Pio '(swfUrl\.{2}M\K.*?(?=\.{2}tc))|(pageUrl\.{2}"\K.*(?=\.{3}))|(tcUrl\.{3 }\K.*?(?=\.{2}))|(resetting \K.*?(?=\.{3}))'

3. Start the show in your browser. A commercial should now appear (that you should really watch in return of downloading the stream ;-)), and wait for the output that appears in the terminal. It should be something like:

1.http://flvplayer.viastream.viasat.tv/play/swf/player110516.s.wf?rnd=1318382997
2.rtmp://mtgfs.fplive.net/mtg
3.flash/norway/tv3/robinson2011/robinsonekspedisjonen_sd_1101-flash_500

4. Here follows a short description of the above output.

1. This is the URL of the flash plugin that runs in your browser. Since we are parsing raw network data, an extra “.” has been added in between the “swf” extension. This can safely be removed. The corresponding switch in rtmpdump is “-W”
2. This is the location where you access streams on the RTMP server. The corresponding switch in rtmpdump is “-r”.
3. Finally, this is the path to the TV show on the RTMP server. The corresponding switch in rtmpdump is “–playpath”.

5. We can now feed these variables to rtmpdump, and do whatever we want with the captured stream. Here are two examples:

Download:

rtmpdump -r "rtmp://mtgfs.fplive.net/mtg" --swfVfy --swfUrl "http://flvplayer.viastream.viasat.tv/play/swf/player110516.swf?rnd=1318382997" --playpath "flash/norway/tv3/robinson2011/robinsonekspedisjonen_sd_1101-flash_500" -o output.flv

Show in mplayer:

rtmpdump -r "rtmp://mtgfs.fplive.net:1935/mtg" -W "http://flvplayer.viastream.viasat.tv/play/swf/player110516.swf?rnd=1318382997" --playpath "flash/norway/tv3/dagens_mann/sesong_1/dagens_mann_101-flash_500" -live | mplayer -

6. Side note. If you want to watch/download the stream in higher quality, replace “flash_500″ with “flash_900″ in the playpath.

Is this legal?

The way I see it, we are not doing anything illegal here, as the video streams are made available from the publisher.

Sure, they are hidden such that “Average Joe” will have difficulties downloading them. Also, we do perform a neat hack when we extract the required variables from the network packet stream using a regular expression, but we still need to watch the commercial (or at least wait for it to finish) in order to get these variables.

As long as I (or you) keep the downloaded streams for yourself, and don’t distribute them directly, you are operating within any legal boundaries, at least if you live in Norway.

Tagged with:
 

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./\=s1.next()/, 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()’.

Tagged with:
 

Configure sendmail as an MTA relay on Slackware

On February 22, 2011, in GNU/Linux, by Vegard Haugland

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/sendmail.cf, 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/sendmail-slackware.mc“. That was indeed the correct file, and I simply added “define(`SMART_HOST’, `smtp.online.no’)“. To see the entire configuration file, expand the spoiler below.

Spoiler Inside: modified sendmail-slackware.mc SelectShow

Once that was done, I had to compile the configuration file with “m4 /usr/share/sendmail/cf/cf/my-sendmail.slackware.mc > /etc/mail/sendmail.cf“, 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!

Tagged with:
 

Getting cmus to cooperate with conky

On January 26, 2011, in GNU/Linux, by Vegard Haugland

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 ];
then
echo "cmus is not installed."
exit
fi

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" ];
then
echo "Nothing"
else
echo "$ARTIST - $TITLE"
fi

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.

Tagged with:
 

Identifying skimming equipment

On September 11, 2010, in Security, by Vegard Haugland

Skimming

Illustration of someone attaching skimming equipment to an ATM. Image courtesy of BBC News.

Almost every week I make notice of articles in the national newspapers that someone has become victim of ATM fraud, or skimming. Usually, the article describes where the event took place and issues a warning that you should contact your bank if you suspect that you have been victim to such crimes.

One thing that bothers me about this, is that neither the media or even the banks here in Norway publish any information about how one can detect skimming equipment, so you can avoid having your VISA card scanned (or your pin code video taped) in the first place.

By doing some research, I found out that a bank in Australia (!) has published information on how to spot if an ATM has been modified, with images of how it looks like both with and without the skimming equipment attached. My first impression is that the material is both informative and easy to follow.

Once you read through the PDF, you should be more fit to avoid being victim of card skimming in the future! :-)

In addition, I would recommend that you examine the ATM every time before you use it. If anything seems out of the ordinary, see if you are able to move any loose panels around. You do not have anything to loose, except your money.

Tagged with: