Elite Dangerous is a fantastic game. Made by Frontier Developments, the game is (in my honest opinion), one of the best space ship simulators available on the market for consumers. Especially if you truly immerse yourself into the game by using additional hardware, such as flight controllers (I have a Thrustmaster Warthog) or VR headsets like Oculus Rift. If the latter is too expensive (or you feel it is too much of a strain on the eyes to use for longer periods of time), it is possible to further enhance the gameplay using head tracking devices.
One such head tracking device is the EDTracker. It is recognized by the operating system as a joystick, so it can be used for several different games and applications. Check out the demo video below!
EDTracker consists of both hardware and software. The hardware can be bought ready to use, or you can buy the parts and assemble it yourself. Self-assembly is much cheaper, but it requires that you have a soldering iron and some basic skills in electronics (as in know how to read a drawing, use a multi meter, how to solder/desolder, etc.). If you choose to assemble it yourself, the parts cost around £19 GBP included shipping to Norway, not including solder and wires.
Here’s a photo of the parts I received. It includes an Arduino clone called Pro Micro (ATMega 32U4 chip), a prototyping board, a tactile switch and most importantly, the MPU-9250 chip which provides gyro, accelerometer and compass.
For wires, I just stripped some CAT 5e cable.
The Pro Micro controller is now soldered on the protoboard in addition to the tactile switch with wiring. Brown wire is GND, blue is button input, orange is VCC (for powering the MPU-9250). The remaining wires are for data. My build deviates somewhat from the drawing, as I have mounted the microcontroller “upside down” that I have mounted the microcontroller upside down, for easier access
Adding the MPU-9250.
Final assembly complete with direct exposure to the circuit board for extra Nerdy™ look.
Finally, I downloaded the EDTracker GUI for uploading the software to the controller. After I finished calibration, I made a short test available on Youtube demonstrating that it works. I’ll probably use this a lot in Elite Dangerous from now on 🙂
To solve an IPTV/IGMP issue I had a while back, a friend gifted me a Routerboard 433 UAH. Personally, I love this thing! It provides a really snappy experience, and managed with ease to handle all my network traffic. In addition, the system was neatly managed as it was powered by MikroTik RouterOS.
Up until a few weeks ago, I had no issues with this. I had then been a proud owner of this for about two years (and it was probably a couple of years old when I got it). Then all of a sudden, it started rebooting. I didn’t think much of it at first, as it happened perhaps once per day – but after a few days it happened more often until it finally ended in an infinite boot cycle. Upon opening the chassis and manually inspecting the circuit board, I found that the capacitors had busted.
Apparently, this is a known issue with Routerboard.. Cheap capacitors or a bad batch?
Here’s an overview picture of how my board looked like before any work was done.
Here is a more detailed picture of how one of the capacitors had burst.
4 of 5 capacitors, rated 6.3V at 560 µF needed replacement. Luckily these are easily found at eBay, and arrived at my place 12 days after I ordered some new for $3.
Once the new capacitors arrived, I fired up my trusty soldering iron – and went to work removing the broken ones.
Desoldering and removing the old capacitors was not as easily as I initially thought. The solder used on the board from the factory was probably industrial rated and thus required a higher temperature than what my soldering iron managed (max 405ºC). For this reason, I removed all the broken capacitors with wire cutters and drilled holes where the old solder was, using my Dremel 300.
“Desoldering” complete. Ready for new capacitors.
New capacitors in place. Looking good!
All the broken capacitors are now replaced and soldered tight.
Fully assembled and ready for testing.
The device now booted as normal and was fully working as before. Instead of throwing the old board and buying a new one (1.999 NOK if bought in Norway, about $230) – I fixed the device for $3 in parts and about an hours work of desoldering/drilling/soldering.
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
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:
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).
Once you have the connectors terminated, follow the remaining instructions in the rfcat documentation:
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.
Freq 0.000 MHz
“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.
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.
Once you have made a recording, you can look at the result 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.
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:
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.
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:
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.
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:
I 04/12/14 03:00AM [Standard] Scanning for files to back up
I 04/12/14 03:01AM [Standard] Scanning for files completed in < 1 minute: 36,575 files (201.70GB) found
I 04/12/14 05:10PM [Standard] Starting backup to CrashPlan Central: 68 files (50.70KB) to back up
I 04/12/14 05:10PM [Standard] Completed backup to CrashPlan Central in < 1 minute: 68 files (50.70KB) backed up, 12.90KB encrypted and sent @ 48 bps
I 04/12/14 05:48PM [Standard] Starting backup to CrashPlan Central: 7 files (2KB) to back up
I 04/12/14 05:48PM [Standard] Completed backup to CrashPlan Central in < 1 minute: 7 files (2KB) backed up, 1.70KB encrypted and sent @ 112 bps
I 04/13/14 03:00AM [Standard] Scanning for files to back up
I 04/13/14 03:01AM [Standard] Scanning for files completed in < 1 minute: 36,649 files (201.70GB) found
I 04/13/14 03:01AM [Standard] Starting backup to CrashPlan Central: 2 files (1KB) to back up
I 04/13/14 03:01AM [Standard] Completed backup to CrashPlan Central in < 1 minute: 2 files (1KB) backed up, 1KB encrypted and sent @ 32 bps
I 04/13/14 09:14PM [Standard] Starting backup to CrashPlan Central: 57 files (771.70MB) to back up
I 04/13/14 09:30PM [Standard] Completed backup to CrashPlan Central in 15 minutes: 57 files (771.70MB) backed up, 743.60MB encrypted and sent @ 7.3Mbps
I 04/13/14 10:26PM [Standard] Starting backup to CrashPlan Central: 12 files (15.70MB) to back up
I 04/13/14 10:26PM [Standard] Completed backup to CrashPlan Central in < 1 minute: 12 files (15.70MB) backed up, 14.30MB encrypted and sent @ 3.6Mbps (Effective rate: 8.2Mbps)
I 04/14/14 03:00AM [Standard] Scanning for files to back up
I 04/14/14 03:00AM [Standard] Scanning for files completed in < 1 minute: 36,718 files (202.50GB) found
I 04/15/14 03:00AM [Standard] Scanning for files to back up
I 04/15/14 03:00AM [Standard] Scanning for files completed in < 1 minute: 36,718 files (202.50GB) found
In brief, there are three important data types we need to parse:
When the backup (or scan) job started
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 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.
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
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.
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.
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.
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!
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.
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:
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:
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:
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.