Introduction
This and the following two posts should serve as a step-by-step guide through the whole process of analyzing a radio frequency black box, demodulate and understand the data transfered and finally modulate our own data in order to e.g. perform a brute force attacks.
The information provided and the results are immensely inspired by Michael Ossmann and the workshops he has given at our location. Visit him and his great tool HackRF at https://greatscottgadgets.com/hackrf/ !
It should be noted that the information in this post are no rocket science and similar stuff has been already done e.g. here: https://funoverip.net/2014/11/reverse-engineer-a-verisure-wireless-alarm-part-1-radio-communications/
This post is also intended to serve as a full disclosure for the alarm system in scope (Olympia Wireless Alarm System: Protect 9061), which has been found to be easily attackable. The complete advisory will be added with one of the next two posts. The timeline for the vendor contact is as follows:
18 Sep 2014: First try of vendor contact
09 Oct 2014: Second try: direct contact to product owner
30 Dec 2014: Notification of public release
20 Apr 2015: Public Release
Starting Point
The first step in analysis, when dealing with a new device/technology, is to use it the way it was intended, to get an idea what it does, what parts/functions of it might communicate via RF and which communication might be the most interesting one.
The next step is to figure out, at which frequency the device is communicating. There are different ways to get this information:
- Have a look at the package (or simply ask a salesman in the shop).
- Visit the vendors/suppliers/sellers homepage and look for details of the device.
- If manufactured in the US, there might be an FCC id on it: https://fcc.io/ (is a wrapper for the search of https://apps.fcc.gov/ ). For China (CMIIT IDs) use http://www.srrc.org.cn/WP_Search.aspx. Look for documents like test reports, there might be most probably some information regarding the frequency(ies) used.
- If nothing helps, go to a “quiet” place (like the basement, where maybe less other signals are interfering) and cycle through the frequency range while using the device. Ideally start with the ISM Band frequencies (e.g. 433,05 – 434,79 MHz for EU, or 902 – 928 MHz for US devices): http://de.wikipedia.org/wiki/ISM-Band
In this case, the frequency could be gathered from the handbook of the product site on the vendors homepage: http://www.olympia-vertrieb.de/de/produkte/sicherheit/drahtlose-alarmanlagen/protect-9061.html
Capturing communication
After having identified an interesting communication (in this case maybe the unlock command 😉 ), and gathered the relevant frequency (868 MHz), we are almost ready to capture some communication. The only thing left is a HackRF, connected to a gnuradio workflow suitable for our needs. At this point, the following flowgraph should be suitable:
As can be seen, we also write in a file for further analysis and replay attack (I recommend to include a short description of what we are capturing, the center frequency and the sample rate within the filename, as these parameters are important for analysis and replay, and might be forgotten: e.g. unlockSignal_freq868M_sampRate2M.dump ). When starting the flowgraph and sending a unlock signal, we see something like this (note the activated “peak hold” option in the FFT output):
NOTE!!! The output from the FFT and Waterfall Sink might be missing your signals, as (most probably) some peaks are stripped as a trade off for a nice overview. So either send it multiple times to be sure to notice it (for the most loud and long signals, this should be no problem), or have a closer look in the captured file, as this file is unstripped.
Next, we could open the file for analysis and see what we got, or we first simply try to replay the captured file without any further investigation and have a look, whether or not we are able to unlock the alarm system with it 🙂
Simple Replay
To replay the captured file, the following flow graph can be used:
And voila: After sending the captured file, the alarm system is deactivated. And also, after trying it a second and third time : )
That’s it for today, so stay tuned for the next part coming approximately next week, where we are going to get some data out of the signals and have a closer look at the bits and bytes.
Regards,
Frank