Category: Security

Reverse Engineering Linear DX Wireless Door Locks

Employees at the network data security company Duo recently had their interest piqued when they discovered that their office’s keycard based door system had a wireless remote which was used by reception to unlock and lock the door. The device was a DX model magnetic lock created by Linear.

After noting down the FCC ID printed on the device, they determined that the operating frequency was 315 MHz. They discovered from the documentation that each wireless DX device is encoded with a unique code that is precoded at the factory. Only remotes with the correct code programmed in can open the door.

The first attack they tried was a simple replay attack. They used a HackRF to record the signal, and then play it back again. This worked perfectly first time.

Next they decided to take this further and reverse engineer the protocol and see if a brute force attack could be applied. By doing some logic analysis on the circuit, they were able to figure out how to iterate over the entire key space. It turns out that the lock can be brute forced in at most 14.5 hours, or 7.25 hours on average.

The Linear DX Wireless Door Lock
The Linear DX Wireless Door Lock

Reverse Engineering Signals with the Universal Radio Hacker Software

Thanks to reader M Kizan who notified us about a Python based digital signal reverse engineering software program called ‘Universal Radio Hacker’ which is developed by Johannes Pohl. The software supports hardware interfaces for SDRs such as the RTL-SDR and HackRF and can be run on Windows, MacOS and Linux.

The Universal Radio Hacker is a software for investigating unknown wireless protocols. Features include

  • hardware interfaces for common Software Defined Radios
  • easy demodulation of signals
  • assigning participants to keep overview of your data
  • customizable decodings to crack even sophisticated
  • encodings like CC1101 data whitening
  • assign labels to reveal the logic of the protocol
  • fuzzing component to find security leaks
  • modulation support to inject the data back into the system

Inspectrum and Waveconverter are two similar programs for analyzing digital signals, however Universal Radio Hacker seems to be the most advanced.

Johannes has also uploaded four tutorial videos to YouTube which show the software in action. In the videos he uses Universal Radio Hacker to reverse engineer a wirelessly controlled power socket, and then in the last video he uses the software to transmit the reverse engineered signals via a HackRF.

Reverse Engineering Honeywell 345 MHz Home Automation Sensors with an RTL-SDR

OpenHAB is an open source home automation software program which is designed to interface and manage all the various sensors and systems in an automated house. One problem however, is that many wireless sensors and actuators utilize a proprietary communications protocol that is not supported by OpenHAB.

In his home, Dan Englender had several Honeywell 5800 series 345 MHz wireless security door sensors, all of which interface using a proprietary protocol that is not yet implemented in OpenHAB. In order to get around this, Dan decided to reverse engineer the protocol and implement a decoder into OpenHAB himself. 

Dan’s four part write up covers the RF capture & demodulation, protocol reverse engineering and implementation into OpenHAB. First he looked up the frequency and bandwidth of the signal via the FCC filing information on Then he captured some packets from a door sensor using his RTL-SDR and GNU Radio, and then wrote a short Python program to decode the protocol and transmit the door open/closed information to OpenHAB. In the future he hopes to optimize the decoder so that it can comfortably run on a Raspberry Pi as the GNU Radio script uses quite a bit of computing power.

The final project is called decode345 and the code is available over on his GitHub.

Honeywell 345 MHz Door Sensor
Honeywell 345 MHz Door Sensor
Custom Door Sensor Status in OpenHAB
Custom Door Sensor Status in OpenHAB
[Also seen on Hackaday]


Camp++ YouTube Talk: GSM Signal Sniffing for Everyone with GR-GSM and Multi-RTL

Over on YouTube the channel Budapest Hackerspace has recently uploaded a talk by Piotr Krysik which was given during the August 2016 Camp++ 0x7e0 information security conference. The talk is titled: “GSM signal sniffing for everyone with gr-gsm and Multi-RTL by Piotr Krysik” and talks about using the gr-gsm software and RTL-SDR dongles to sniff the GSM mobile phone network. Also, a tool developed by Piotr called multi-rtl which allows the proper synchronization of multiple RTL-SDR dongles in order to cover the large gap between the GSM uplink and downlink frequencies is discussed.

The talk explains a bit about how GSM works, and then goes on to talk about the gr-gsm and multi-rtl software. The talk blurb reads:

Gr-gsm is a set of tools for receiving GSM transmissions, which works with any software radio hardware capable of receiving GSM signal. Together with widely available RTL2832 based TV dongles, that are popularly used as low cost software radio receivers (known as RTL-SDR), it enables everyone to receive and study protocols used in GSM’s mobile radio interface.

Ability to receive signals spread over wide frequency range exceeding single RTL-SDR receiver’s bandwidth (~2.4MHz) was available exclusively for the owners of more capable and more expensive SDR devices. With introduction of Multi-RTL project by the author of the talk, this limit was overcome through synchronization of multiple RTL-SDR receivers in time domain, that doesn’t require complicated hardware modifications. With Muli-RTL it is possible to receive for example uplink and downlink of GSM900 transmissions, that are separated by 45MHz.

Speaker will present origins of both of the projects, together with description of their inner workings, examples of applications and plans for the future.

The talk slides can be downloaded here.

CNxROOT Two Posts: How to Build an RTL-SDR Server with OpenWRT, Creating a GSM BaseStation with OpenBTS and a USRP

Recently security researcher cnxroot wrote in to let us know about two of his posts that may be of interest to readers. The posts are written in Chinese, so please use Google Translate to read them in English – it translates okay to some extent.

The first post shows us how to run the RTL-SDR on an OpenWRT capable router server. OpenWRT is a Linux firmware/OS that can be installed on several compatible router devices which extends the usefulness and features of the router. Since it is running Linux the RTL-SDR drivers can be installed onto it, and then rtl_tcp can be run, providing a remote RTL-SDR.

The second post is a bit more advanced. It is about creating a pseudo GSM base station with a USRP SDR and intercepting IoT devices which connect over GSM/GPRS. The post shows how to set up OpenBTS which can be used to create a base station.

RTL-SDR running on an internet router with OpenWRT.
RTL-SDR running on an internet router with OpenWRT.

Reverse Engineering Traffic Lights with an RTL-SDR Part 2

Back in September 2015 we made a post about how Bastian Bloessl was able to use his RTL-SDR dongle to reverse engineer and decode the signals coming from portable wirelessly synchronized traffic lights which are commonly set up around road construction zones.

Recently Bastian noticed that a new set of wireless traffic lights had been set up at his University, so he got to work on trying to reverse engineer those. He found that these new lights use the same frequency band, but work using a different modulation and frame format scheme.

The reverse engineered wireless traffic lights.
The reverse engineered wireless traffic lights.

To reverse engineer these new lights he made a recording of the signals in GQRX and then opened them up in Inspectrum, which is a very nice tool for helping to reverse engineer digital signals. Thanks to Inspectrum he was easily able to extract the preamble and decode the data in GNU Radio.

Bastian has also uploaded a video that shows him reverse engineering the binary frame format in the Vim text editor which may be useful for those wishing to understand how it’s done.

Once the frame format was reverse engineered, he was able to use the program he created last year which allows him to view the status of the lights remotely in real time.

Identifying Transmitters with CTCSS Fingerprinting

Oona Räisänen is a RF hacker and enthusiast who has in the past brought us posts about decoding burger pagers in restaurants, decoding wireless bus signs and FM-RDS with SDR’s like the RTL-SDR. This time she has written an interesting post that shows how she can “fingerprint” radio transmitters by analysing their CTCSS transmissions. CTCSS is short for “Continuous Tone-Coded Squelch System” and is a low frequency tone added on to some transmissions used in handheld radio systems shared by several distinct groups. The CTCSS tone prevents users of a shared system from having to listen to other users talking if they are not part of the same group with the same CTCSS tone frequency. CTCSS provides no means for actually individually identifying a radio.

Oona wanted to see if she could fingerprint and thus identify individual radios by their CTCSS tone by looking at identifying features such as small variances in CTCSS tone power and frequency. The idea is that each radio will have minute differences in the exact tone and power produced by the CTCSS circuitry, due to differences in the crystal oscillators and component tolerances. Oona used an RTL-SDR to record CTCSS data from a conversation on a local handheld radio network. Then by plotting the frequency vs power data on a heatmap graph she was able to find 8 different clusters of points, which potentially identifies 8 individual handheld radios.

Frequency vs power heatmap identifying 8 different radios.
Frequency vs power heatmap identifying 8 different radios.

With the individual radios identifiable by their cluster centers, each cluster can be assigned a name. Now each subsequent transmission can be compared to each cluster center, and assigned to the closest matching cluster, thus matching a new unknown transmission with a known radio. This makes it easier for someone listening in with no context to follow a conversation. 

Assign names to each radio.
Assign names to each radio/cluster center.

Building your own Rogue GSM Basestation with a BladeRF

Over on his blog author Simone Margaritelli has added a tutorial that shows how to set up a bladeRF to act as a GSM basestation (cell tower). Having your own GSM basestation allows you to create your own private and free GSM network, or for more malicious illegal users it can allow you to create a system for intercepting peoples calls and data. Simone stresses that it is well known that GSM security is broken (and is probably broken by design), and now it is about time that these flaws were fixed.

In his tutorial he uses a single bladeRF x40 and a Raspberry Pi 3 as the processing hardware. The bladeRF is a $420 transmit and receive capable software defined radio with a tuning range of 300 MHz – 3.8 GHz and 12-bit ADC. He also uses a battery pack which makes the whole thing portable. The software used is Yate and YateBTS which is open source GSM basestation software. Installation as shown in the tutorial is as simple as doing a git clone, running a few compilation lines and doing some simple text configuration. Once set up mobile phones will automatically connect to the basestation due to the design of GSM.

Once setup you can go further and create your own private GSM network, or make the whole thing act as a “man-in-the-middle” proxy to a legitimate GSM USB dongle, which would allow you to sniff the traffic on anyone who unknowingly connects to your basestation. This is similar to how a “Stingray” operates, which is a IMSI-catcher device used by law enforcement to intercept and track GSM communications. More information on using the bladeRF as an IMSI catcher with YateBTS can be found in this white paper.

bladeRF x40, Raspberry Pi 3 and a battery pack. Running a GSM basestation.
bladeRF x40, Raspberry Pi 3 and a battery pack. Running a GSM basestation.