Category: HackRF

HackRF Sweep Spectrum Analyzer for Windows

A few weeks ago the HackRF drivers and firmware were updated and one new feature added was hackrf_sweep. This new feature allows us to scan across the spectrum at up to 8 GHz per second, which means that a full 0 – 6 GHz scan can complete in under a second.

Previously only Linux software such as QSpectrumAnalyzer was compatible with hackrf_sweep, but now over on GitHub user pavsa has released a new Windows based Spectrum Analzyer which is compatible with hackrf_sweep.

We gave the software a test and it ran flawlessly with our HackRF. The features include:

  • Optimized for only one purpose – to use HackRF as a spectrum analyzer
  • All changes in settings restart hackrf_sweep automatically
  • Easy retuning
  • hackrf_sweep integrated as a shared library
  • Peak display
  • High resolution waterfall plot

Remember that to run the software you will need to have updated your HackRF to the latest firmware. The spectrum analyzer software is also Java based, so you’ll need to have the Java JRE for Windows x64 installed.

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 RTL-SDR.com 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.

Universal Radio Hacker - 01: Record a signal

Scanning the Spectrum at 8GHz per Second with the new HackRF Update

Recently Mike Ossmann, creator of the HackRF released version 2017.02.1 of the libhackrf, hackrf-tools and firmware on the HackRF Git. The update was developed together with the help of Dominic Spill. The full release text is pasted below:

To upgrade to this release, you must update libhackrf and hackrf-tools on your host computer. You must also update firmware on your HackRF. It is important to update both the host code and firmware for this release to work properly. If you only update one or the other, you may experience unpredictable behavior.

Major changes in this release include:

Sweep mode: A new firmware function enables wideband spectrum monitoring by rapidly retuning the radio without requiring individual tuning requests from the host computer. The new hackrf_sweep utility demonstrates this function, allowing you to collect spectrum measurements at a sweep rate of 8 GHz per second. Thanks to Mike Walters, author of inspectrum, for getting this feature working!

Hardware synchronization: It is now possible to wire the expansion headers of two or more HackRF Ones together so that they start sampling at the same time. This is advantageous during phase coherent operation with clock synchronized HackRFs. See the -H option of hackrf_transfer. Thank you, Mike Davis!

A new utility, hackrf_debug, replaces three older debug utilities, hackrf_si5351c, hackrf_max2837, and hackrf_rffc5071.

Power consumption has been reduced by turning off some microcontroller features we weren’t using.

There have been many more enhancements and bug fixes. For a full list of changes, see the git log.

Special thanks to Dominic Spill who has taken over much of the software development effort and has helped with nearly every improvement since the previous release!

One of the most interesting updates is the upgrade to hackrf_sweep. The new firmware allows you to make huge wideband scans of the entire 0 – 6 GHz range of the HackRF in under one second (8 GHz/s). In comparison the Airspy is currently capable of scanning at about 1 GHz/s (although the Airspy author has mentioned that a sweep mode could also easily be added on the Airspy).

To update the drivers and flash the new firmware in Linux:

  1. Download the new release tar at https://github.com/mossmann/hackrf/releases/tag/v2017.02.1
     
  2. Extract the tar.xz file into a folder.
     
  3. Build and install the host tools using the instructions
    at https://github.com/mossmann/hackrf/tree/master/host
     
  4. Flash the new firmware with hackrf_spiflash -w firmware-bin/hackrf_one_usb.bin (or the bin file for the Jawbreaker if you have that version of the HackRF)
     
  5. Disconnect then reconnect the HackRF.

To install Mike Ossmanns fork of QSpectrumAnalyzer which supports the new hackrf_sweep:

  1. sudo apt-get install python3-pip python3-pyqt4 python3-numpy
     
  2. git clone https://github.com/mossmann/qspectrumanalyzer
     
  3. sudo pip3 install ./qspectrumanalyzer
     
  4. This gets installed to ~/.local/bin

To generate a wideband waterfall image sweep with hackrf_sweep and Kyle Keen’s heatmap.py software:

  1. git clone https://github.com/keenerd/rtl-sdr-misc. Take note of heatmap.py inside rtl-sdr-misc/heatmap.
     
  2. Scan from 1 MHz – 3 GHz, with a bin size of 100k, LNA gain of 32 and VGA gain of 8: ./hackrf_sweep -f1:3000 -w100000 -l32 -g8 > output_data.csv
     
  3. Generate the heatmap (can take some time to complete if you have a large data file from a long scan): python heatmap.py output_data.csv heatmap_image.png

We’ve uploaded an 0-6 GHz example waterfall scan image over about 30 minutes which is available at filedropper.com/op4. The png file is 90 MB. A sample of the sweep from 400 – 600 MHz is shown below. Trunking, various telemetry and DVB-T signals are visible.

hackrf_sweep 400 - 620 MHz sample
hackrf_sweep 400 – 620 MHz sample

Some GIF examples of QSpectrumAnalyzer running the new hackrf_sweep in order from 1) 0 – 6 GHz scan, 2) 0 – 3 GHz scan, 3) 0 – 1 GHz scan, 4) 500 – 640 MHz scan, 5) 2.4 GHz WiFi Band are shown below.

Continue reading

Removing that Center Frequency DC Spike in Gnuradio the Easy Way

Recently RTL-SDR.com reader ghostop14 wrote in to us and wanted to share his GNU Radio block and tutorial that shows how to get rid of the DC spike in GNU Radio. The DC spike is the annoying spike in the middle of the spectrum that appears no matter where you tune and shows up with almost all SDRs, such as the HackRF used by ghostop14. Software programs like SDRsharp and HDSDR have algorithms in place to filter and remove the DC spike, but until now there was no block that existed for GNU Radio.

If you’re looking for the quick solution, the CorrectIQ GNU Radio block by ghostop14 is available at https://github.com/ghostop14/gr-correctiq.git. But if you want an interesting read on how ghostop14 figured out how to create the block, then he’s done a nice writeup which is available here (pdf). Some excerpts:

It’s your first time with gnuradio and you love your hackrf. You’ve played with receiver software like SDRSharp and audio piping to decode your favorite signal of choice, and now you’re ready to dig deeper and learn more about SDR. Everyone’s talked about gnuradio, so you install it and fire up your first flowgraph. You drop in an osmocom source block and set the device to hackrf, set your sample rate, frequency, and gain then connect it to a frequency sink and hit the button to generate your flowgraph. The ease with which you just built a receiver and the excitement about the possibilities is overwhelming… you can’t wait to hit play.

Then it happens. Right in the middle of your first flowgraph is this huge signal spike that you know is not the signal you want to receive, and as you change the frequency it follows you. What?!? So your first thought is you did something wrong. After all you’re new to gnuradio and you’re sure you’re making a newbie mistake. First you make sure there really isn’t a signal there. You go back to SDRSharp and there’s no spike. Then you swap out your hackrf for your airspy and rtl-sdr dongle, feed that into gnuradio, and there’s still no spike. What’s going on? Why is my favorite SDR that I want to use doing this? What you’ve stumbled on is an artifact of the way SDR radios do IQ sampling. Your first attempts at searching on the problem reveal that it’s called a DC spike and it’s going to appear in the raw IQ data and there’s nothing you can do to stop it. So you go back to your favorite search engine because you can’t be the first person to want to get rid of it and you find that folks say that you have 3 options: 1.) ignore it (yeah not happening. It’s huge and right in the middle of my spectrum!) 2.) Offset tune away from it on your center frequency (which means every flowgraph I make or download I’m going to have to custom change to actually get a clean center frequency signal to make them work. There has to be a better way!), or 3.) filter it out.

(cntd…)

I finally had a few hours to look into the problem further and spent the time to search and understand what was happening, and the math behind fixing it. Then researched how others were doing the same thing in their code. Turns out the solution is simple. Since the data represents an alternating RF signal, over time the signal average in a clean signal should be zero (I know I’m oversimplifying it). When there’s the IQ DC spike, that average isn’t zero. So the solution is to calculate a weighted average over ongoing samples and simply subtract it from each future sample. It doesn’t affect the overall quality of the filtered signal, but as long as the spike is on the center frequency, this approach very efficiently gets rid of it. And that was what I was hoping to accomplish.

The CorrectIQ block which gets rid of the DC spike in GNU Radio.
The CorrectIQ block which gets rid of the DC spike in GNU Radio.

Hak5 at Shmoocon 2017: Shock Collar Radio Roulette, GNU Radio, Sniffing IR (Terrahertz) Signals and More!

Over on YouTube the popular Hak5 channel has uploaded a video with several SDR related topics mentioned during Shmoocon 2017 conference.

One fun event talked about in the video was the Shmoocon wireless village SDR contest by Russell Handorf which involved wireless dog shock collars. These are collars usually placed on dogs, that emit a mild electric shock when a button on a wireless remote is pressed. This can help train the dog into better behaviors. Contestants were able to first make recordings of the wireless signals made by the shock collars. Then each contestant strapped a wireless shock collar to their leg and the goal was then to reverse engineer and understand the protocol as quickly as possible, then use that knowledge and a HackRF to shock the other contestants.

Another part of the video discuss GNU Radio reverse engineering with representatives from bastille.net who are wireless IoT security researchers. The video then goes on to interview Micheal Ossmann (creator if the HackRF) who talks a bit about his work in building an infrared (IR) software defined radio. Micheal explains how infrared is essentially just radio at terrahertz frequencies and that many SDR concepts can be applied by using a photodiode sensor. He mentions that there are several IR systems used these days, such as the common remote control, toys, and high bandwidth wireless IR headphones used in car entertainment systems and conferences. The hardware Micheal has created is called “Gladiolus” and is still in development.

Shmoocon 2017: Sniffing IR Signals and More! - Hak5 2120

Running a 1G Mobile Phone Network with a HackRF

First generation (1G) mobile phone technology was brought out in the 80’s and was an unsecured analogue system. These days 1G technology is completely phased out in favor of digital standards like 2G (GSM), 3G and 4G LTE and so those old 1G handsets are now useless. However, at Shmoocon 2017 presenter Brandon Creighton delivered a talk where he showed how to use a TX capable SDR like a USRP or HackRF to create your own home 1G system that allows those old brick phones to be useful once again.

The actual video of the conference talk won’t be available online until about half way through the year but the blurb read:

AMPS, the first widely deployed cellular network in the US, was old enough that it had been designed by pre-breakup Bell, yet robust enough to survive for decades in service. Unlike LTE or even GSM, it was also a protocol simple enough to be described in a fairly short specification; if you wanted to you could listen to calls with a TV tuner (or modified phone).

This is a talk on the design and implementation of gr-amps, a set of GNU Radio blocks that can turn a TX-capable software-defined radio into a base station for AMPS devices–including that brick phone in your basement. No background in SDR is necessary to follow along (but it doesn’t hurt).

Expect detours into near-forgotten phreaker history: the weaknesses that enabled phone cloning, the efforts of wireless carriers and the US government to fight exploitation, and more.

The GNU Radio code to run your own AMPS (1G) system is available on GitHub.  It has been tested on a USRP and HackRF.

lethalweaponcellphone

[Also seen on Hackaday]

Combining the Bandwidth of two HackRF’s

RTL-SDR.com reader Syed Ghazanfar Ali Shah Bukhari from the Frequency Allocation Board in Pakistan recently emailed us to let us know a trick he's found which lets you combine the bandwidths of two HackRF software defined radios in GNU Radio. Syed's program is based on Oliver's flowgraph that we posted previously, which was used to combine the bandwidth of two RTL-SDR dongles.

Syed also sent us the GRC file to share which we've uploaded here.

He writes:

I have used grc flow graph of Oliver as mentioned in the link :-
https://www.rtl-sdr.com/combining-the-bandwidth-of-two-rtl-sdr-dongles-in-gnu-radio and modified it to be used with 2 HackRF Ones. I also shifted the two bandwidths inward by 1 MHz instead of 0.2 MHz to make a smooth continuation for a 38 MHz spectrum. Unfortunately one of my HackRF Ones has its RF Amp burnt up so I adjusted its IF and BB gain to have same noise floor as that of other HackRF One. It's really awesome. I am sending you the diagram and grc file. The attached image is showing complete GSM900 downlink spectrum (38 MHz) in my area with active 2G and 3G signals.

September 2018 Update:

An rtl-sdr user with nick JAAP had some query pertaining to calculation of center frequency of each HackRF. The values I used were a bit erroneous. If you the previous flow graph I sent you, the center frequencies for both HackRFs are same in the SDR source box. That should be different for both with a 20 MHz difference between the two. Some spectrums started repeating themselves on those values. I have improved the flowgraph using variables and equations to remove the logical bug. I have added a slider for bandwidth cropping that can be used for test pupose only to understand the concept behind the frequency shifting and cropping of spectrum of both HackRFs. I have attached the new grc file and the image. Gain values can be adjusted as per user requirement and sensitivity of your own SDRs. I am working on grc which will show a spectrum using 5 rtl-sdrs and two hackRFs thus combining BWs to give a span of 50 plus MHz.

Update GRC File available here.

Multi HackRF Spectrum
Multi HackRF Spectrum
Multi HackRF GRC flowgraph
Multi HackRF GRC flowgraph