Last week we made a post about the HackRF Portapack, and gave some examples of it in action. Recently the furtek Havoc firmware for the portapack was updated, and it now supports SSTV transmission. Over on Twitter, Giorgio Campiotti @giorgiofox has uploaded a video showing an example transmission in action.
In the video the HackRF with Portapack transmits a test SSTV image to an Elecraft K3 ham radio, which is linked to a PC. SSTV decoding software on the PC turns the data back into an image.
SSTV stands for ‘Slow Scan TV’, and is a method used by hams to send images over radio. Typically this activity occurs on HF frequencies. Sometimes the ISS transmits SSTV images down to earth as well to commemorate special events.
The PortaPack is an addon created by Jared Boone for the HackRF software defined radio. It costs $200 USD at the sharebrained store and together with a USB battery pack it allows you to go completely portable with your HackRF. The HackRF is a multi-purpose SDR which can both receive and transmit anything (as long as you program it in) from 1 MHz to 6 GHz.
Since we last posted about the PortaPack many new features have been added, and the firmware has matured significantly. Now the official PortaPack firmware allows you to receive and demodulate SSB, AM, NFM, WFM and display up to an 18 MHz wide waterfall. You can also decode marine AIS, the automobile tyre pressure monitoring system (TPMS) and utility ITRON ERT meters.
There is also a popular fork of the official PortaPack firmware called portapack-havoc, which is created by a dev who goes by the handle ‘furrtek’. This firmware is a bit more risky in terms of the trouble it can get you into as it enables several new features including:
Close call – See if anyone is transmitting near to you
A CW generator
a GPS and various other jammers
an LCR transmitter – the wireless protocol used in France for programming traffic related signage
a microphone transmitter
a pocsag receiver and transmitter – receive and send to pagers
a PWM RSSI output – useful for crude automatic direction finding
an RDS transmitter – transmit radio station text data to compatible broadcast FM radios
a soundboard – play a stored bank of wav sounds on a frequency
an SSTV tranmitter – transmit slow scan TV signals
an OOK transmitter – control on-off-keying devices such as doorbells.
Below we’ve created a YouTube playlist showing several videos that show the portapack in action.
PortaPack H1 Firmware 20160222
And below we show a tweet from @furrtek showing off the recently added SSTV transmit feature, and a tweet from @giorgiofox showing off the microphone transmit feature.
Over on YouTube a video titled “Hunting Rogue WiFi Devices using the HackRF SDR” has been uploaded. The talk is given by Mike Davis at the OWASP (Open Web Application Security Project) Cape Town. The talk’s abstract reads:
Rogue WiFi Access Points are a serious security risk for today’s connected society. Devices such as the Hak5 Pineapple, ESP8266-based ‘throwies’, or someone with the right WiFi card and software can be used to intercept users’ traffic and grab all of their credentials. Finding these rogue devices is a very difficult thing to achieve without specialised equipment. In this talk Mike will discuss the work he has been doing over the past year, to use the HackRF SDR as a RF Direction-finding device, with the goal of hunting down various malicious RF devices, including car remote jammers.
The talk starts off with the basics, explaining what the problems with WiFi devices are, what the HackRF and SDR is, and then goes on to explain some direction finding methods that Mike has been using.
Hunting rogue WiFi devices using the HackRF SDR - Part 1 of 2
Hunting rogue WiFi devices using the HackRF SDR - Part 2 of 2
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.
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.
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 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.
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:
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)
Disconnect then reconnect the HackRF.
To install Mike Ossmanns fork of QSpectrumAnalyzer which supports the new hackrf_sweep:
To generate a wideband waterfall image sweep with hackrf_sweep and Kyle Keen’s heatmap.py software:
git clone https://github.com/keenerd/rtl-sdr-misc. Take note of heatmap.py inside rtl-sdr-misc/heatmap.
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
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
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.
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.
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.
