As I’ve mentioned, I’m teaching two SDR classes at Black Hat this August: an Introductory and an Intermediate class. Well, the latter has just sold out! The Introductory class still has a few seats left, though.
Thanks for your interest, and looking forward to seeing many of you in Vegas!
Hello Readers
Just wanted to let you know that I’ll doing a webcast with the fine folks at Black Hills InfoSec next Thursday. I’ll be talking about a frequency hopping SDR system I built using Python and the gnuradio API. It was intended as a proof-of-concept RF exfiltration system, but you could use the framework for any number of things.
The host transmits requests for data downstream to the exfil device, along with the frequency at which the information should be sent back. The concept is fairly straightforward, but it’s not always clear how build these types of systems with gnuradio. Specifically, there are a number of complications to getting payload data out of gnuradio flowgraphs and into Python code where you can act on that data. I’ll show you how I did this, as well as some best practices for building code-only gnuradio systems (i.e. without using the gnuradio-companion GUI).
The webcast will be next Thursday (11-Apr) at 2pm EST aka 11am PDT. You can register here.
If you want more information about how to build radio applications with gnuradio, I do have a class that you might be interested in. Please contact me if you’d like more information.
I believe it takes 4 days to learn the basics of software defined radio, even if you’ve never done a single radio-related thing in your life. Less than a week.
If you lay that solid foundation in SDR and gnuradio, you’ll be far more effective in your future endeavors, whether that’s:
Join us this August at Black Hat to get started with SDR. We have a two-day introductory class that’s perfect for beginners. You don’t need to know a thing, and you don’t need to bring a thing. You’ll use our laptops and SDR hardware. No pre-class installation homework, just show up and sit down. You’ll learn the basics of gnuradio, RF theory and SDR operation – which will enable you to build analog transmitters and receivers.
You can then move on to our Intermediate Digital SDR class, where we’ll work through all the stuff you need to build digital radios:
If you’ve already spent some time with SDR and know the basics of gnuradio, you can jump straight to the intermediate class. Feel free to contact us if you have any questions about this. We can also chat about our advanced classes in reverse engineering or gnuradio application development.
Hope to see you in Vegas!
After learning to build analog and digital radios, a number of our customers had the perfectly reasonable question: “What next?” Over the last year, we’ve developed two additional SDR courses that provide an answer.
The first course focuses on reverse engineering RF devices with SDR, with a host of practical exercises and real hardware to attack.
The second shows you how to build SDR-based radio applications, focusing on the especially tricky part of programmatically extracting data from gnuradio flowgraph objects. Getting data out of flowgraphs is a problem that stymies a number of folks, but I’ll save you a ton of time by showing you powerful methods to get this done cleanly.
As with our previous courses, we first taught them to carefully chosen lead customers. Now, after numerous improvements and tweaks, they’re ready for primetime.
You can contact us at paul@factorialabs.com if you’d like to arrange a private training for your organization. We are also planning on two public training sessions this year: one in the greater DC area and a second in Seattle.
Yesterday, I had the privilege of giving a talk about a project I’d been working on to the Wild West Hackinfest in Deadwood, SD. Over the last year or two I’d been wanting to build a clean radio communication system using SDR and gnuradio. There were a number of not-so-obvious things I’d learned over the years, and I thought releasing some code that implemented such a system could help out folks that may have been struggling with some of the same things that I did.
The project I settled on was an RF exfiltration system, with a host laptop sending commands to a headless Raspberry Pi 3 B+. The twist, however, was that each time the host requested data, it also told the xfil box how to send the data: what frequency, modulation scheme, preamble, etc. The goal was to be able to communicate in a manner that was as flexible as possible, even capable of changing the RF parameters with each transmission.
The code is still at “proof-of-concept maturity” but it should help you see how to get digital payloads from external Python code into a flowgraph (on transmit) and vice versa (on receive). You can see it all here:
http://github.com/paulgclark/exfil
I’m incredibly grateful to John Strand and all the folks who made the conference happen. It’s an awesome event with great people both running and attending. If you haven’t been, you should definitely go in 2019.
PS There was a camera running, so I’ll provide an update post when the video is posted.
Hello SDR fans. A long-standing wish of mine is to have a grc block that detects a preamble on an incoming byte stream and tags it with a fixed length. There has been a block in grc for a long time called the Correlate Access Code – Tag Stream (kind of a mouthful, I know) which almost does this but not quite. This original block scans the 32 samples after the preamble and tries to extract a frame length field, which it will then use for the tag value. That function is kind of neat if you’re building your own transmitter/receiver pair, but it doesn’t help when you’ve got a mystery signal on your hands that won’t have that header in place.
So for a while a worked around the issue. On short projects, I’d use the now-deprecated Correlate Access Code block, dump the data to a file and whip up a quick Python script to handle things (you can see some examples of this in Volume 3 of our book series). For more complex situations, I employ WaveConverter, which I built to extract and analyze large amount of payload data. Despite these options, I always wanted a simple grc-only method of quickly looking at payload data.
All of which brings me to the block I built, Correlate Access Code – Tagged Stream – Fixed Length (yeah, I didn’t really reduce the mouthful any). I simply created a new module and block with the gr_modtool utility and copied over the *.cc, *.h and *.xml files from the original block. I then cut out the header parsing and added a property for you to set the Packet Length. After a bit of debug and cleanup, I had a useable block, which you can grab from:
https://github.com/paulgclark/gr-reveng
The example flowgraph below shows how easy it is to use:
The new block allows you to detect the preamble and tag it such that the subsequent Tagged Stream to PDU block can convert the payload (and only the payload) to a Message PDU, which you can then print out with a Message Debug sink. The PDUs simply appear in the console window as you run your flowgraph.(I’m using the print input of the Message Debug block because I have ASCII data, but if you have binary data, you should use the print_pdu input instead.)
Note that you can also dump the message PDUs to a File Sink, which gives you a nice file containing only payload data, none of the preamble or inter-frame dead air. A couple lines of Python can read this file and extract each payload into a list, from which you can do all sorts of fun stuff.
I’ll be on the Black Hills InfoSec webcast tomorrow talking about all the things you need to know to get started with SDR. You can register for the webcast at the link below:
https://register.gotowebinar.com/register/3587817882602530306
Please bring your questions on SDR hardware, software, installation issues or anything else you can think of. See you there!
The LimeSDR Mini is a great combination of things: affordable, full-duplex and incredibly configurable. Until recently, though, it wasn’t the easiest thing to get running. Scanning the forums at MyriadRF (the folks who make the Lime products) shows that a number of people have been able to get the Mini working but also that a number have not had so much success.
I was a pre-production supporter of the CrowdSupply campaign and had my LimeSDR Mini delivered in March. At first it was rough going, but after numerous attempts, I’ve been able to get a repeatable installation flow that works on Ubuntu 16.04 and supports UHD and HackRF hardware as well (it may support BladeRF, but I don’t have the hardware to test it).
You can grab the install script from my GitHub at:
https://github.com/paulgclark/grc-install
The git bundle also contains a number of simple grc files to validate your installation versus each of the three hardware platforms. After installation, my advice is that you test things with:
./grc/audio_tone.grc
./grc/lime-test/fm_receiver_hardware_lime.grc
(make sure to tune to one of your local stations)
Next, if you’ve got a second SDR (and computer) you can use the GFSK transmit and receive flowgraphs to send simple digital data back and forth between them. You should be able to send and receive from any combination of the three SDR platforms, though you will likely need to adjust the squelch levels depending on the physical distance between your SDRs. If a HackRF is involved, you’ll also need to fine tune the receiver flowgraph to compensate for their frequency error.
One thing to note about this install flow: you get version 3.7.10 of gnuradio-companion, not the latest as you’d get with a PyBOMBS installation.
Hope this helps!
Addendum: This flow will work for Ubuntu 18.04, but you’ll need to go into the install script and tweak one line per the commented instructions. You’ll also need to adjust the device args for the hackrf transmit flowgraphs to “driver=hackrf,soapy=0” (but do NOT type a space between the comma and “soapy”). A bonus to using 18.04 is that you’ll get a slightly newer version of gnuradio companion (3.7.11).
We’ve gotten some feedback recently from a number of our readers that the gnuradio installation process documented in our books (and on our books’ web site) has a few glitches. We knew that we’d need to update the instructions at some point, and the time had definitely come. If you’re planning on installing gnuradio any time soon, please see our updated instructions pdf.
The HackRF One is an awesome entry platform into the wonderful world of SDR. I do, however, want to point out one thing to be careful about: operating at too low a sample rate.
In a recent class I was teaching, I introduced a new project: one in which students transmitted a simple triangle wave at a specified frequency. As good RF citizens, we of course transmitted these signals at very low power, and for short duration in an appropriate band.
I had tested this exercise several times prior to adding it to the class syllabus, but during the class itself, something went wrong. About half of the students were able to generate a transmission that could be received, demodulated and identified as a clear triangle wave… and about half couldn’t. Since each student had their own HackRF One, we swapped hardware and tried executing the flowgraphs again. Sure enough, all of the flowgraphs worked with some of the HackRF devices, and all of the flowgraphs failed with the other HackRFs. Since we were nearing the end of the class I didn’t have time to do much live debug, but it sure seemed like some of the HackRF boards were behaving differently than others.
After I got back to my lab, I did some research as well as contacting Nooelec – where I had bought the boards. A very quick response from the Nooelec folks (thanks!) led me to assume that I might have burnt out the RF amplifier chip by exposing the HackRF to excessive RF energy. Nooelec has seen this a number of times and recommends putting a 10 dB attenuator in series with your antenna. It’s easy to miss this note, but documentation does state this:
https://github.com/mossmann/hackrf/wiki/HackRF-One#receive-power
I then prepared for PCB surface mount surgery on one of my HackRFs using the following info:
http://www.t4f.org/articles/repairing-the-hackrf/
Before I made the incision, however, I decided to check a few more things. I set up an Ettus B200 in receive mode and tried to fiddle with several HackRF boards in transmit mode. The Ettus board has better ADCs, a better RF front end… pretty much better everything than the HackRF. My hope was that I could figure out a little more about the failure mode of the HackRFs. After poking around for a bit, I came to a startling conclusion: the boards were fine, I just made a boneheaded mistake!
You see, I was a little concerned about the performance of the laptops that my students might be bringing to the class, or that they might be trying to use a VM for the class exercises. As such, I had the not-so-brilliant idea of reducing the sample rates of the class exercise to 1 Msps. The documentation recommends a minimum sample rate of 8 Msps, but I’ve always played a bit fast and loose with that figure without too much trouble. Even as low as 1 Msps, I’d often gotten usable results.
When I upped the sample rate to 8 Msps, however, it was clear that the boards I had thought broken were just fine:
Even as low as 2 Msps, the triangle wave was clearly visible. At 1 Msps, though, things started to break down for some boards:
But not others:
After all of this, I took a look back at the specs, and sure enough, I noticed the 2 Msps is the listed minimum sample rate after all.
A happy, if slightly embarrasing, ending.
