Tag: SDR

Arsenal Labs at Black Hat 2022

Hello Factoria Labs readers! As you may know, Black Hat USA happened earlier this month in Las Vegas. As well as teaching an in-person SDR class, I was also honored to present a hands-on project at the Arsenal Labs – we had a great turnout, as you can see from the picture.

Arsenal Labs
Black Hat 2022 – Arsenal Labs

My project was an end-to-end, RF reversal of a simple garage door protocol. Although the signal produced by the garage door remote was not terribly complicated, the project provided a full view of the reversing process, including:

  • scanning for the remote’s signal
  • capturing the signal to disk
  • tuning and demodulating to produce a digital baseband waveform
  • identifying the framing and encoding of the baseband waveform and then extracting the bits
  • building a simple transmitter to implement the reversed protocol
  • building a more complex transmitter to implement brute force attacks

If you caught my presentation and wanted to look at starter and solution projects, it’s all at:

https://github.com/paulgclark/garage_door

I’ve also included a PDF of the printed handout we had for Arsenal attendees.

If you’re curious, the garage door remote used in the lab was this model:

https://www.amazon.com/dp/B08RSDQKM9

Thanks for reading!

Updated gnuradio Install Instructions

As some of you have noted, the installation instructions for gnuradio and HackRF contained in our Field Expedient SDR series no longer work. To remedy this I’ve created a set of installation scripts that automate nearly all of the steps required, updated for newer versions of gnuradio/uhd/osmosdr and supporting the Ubuntu 18.04 LTS.

The scripts install from specific releases and commits of the source code, so they should be much more stable than previous iterations of the instructions.

TLDR

On an Ubuntu 18.04 installation perform the following:

  1. Open a new terminal (Ctl+Alt+t) and type:
    sudo apt -y install git
    mkdir -p install
    cd install
    git clone https://github.com/paulgclark/grc-install
    cd grc-install/install_scripts
    sudo ./grc_from_source.sh
    (This will install both gnuradio and the UHD drivers. It will take between 0.5 to 1.5 hours.)
  2. Open a new terminal and type:
    cd install/grc-install/install_scripts
    ./hackrf_from_source.sh
    (This will install the hackrf tools and the osmocom blocks. It will take only a few minutes.)
  3. Open a third terminal and start gnuradio companion with:
    gnuradio-companion
  4. Depending on the hardware you have available, you can open the following flowgraphs inside gnuradio-companion to test your setup:
    ~/install/grc-install/grc/hackrf-test/fm_receiver_hardware.grc
    ~/install/grc-install/grc/uhd-test/fm_receiver_hardware.grc

Installing gnuradio 3.8

By default the gnuradio install script installs version 3.7.13.5, the latest release before 3.8. If you want to try out the new version, simply type:
sudo ./grc_from_source.sh 3.8

Note that the osmocom team hasn’t yet updated the blocks used for interfacing with the HackRF such that they work with version 3.8 of gnuradio. I’ve instead used Igor Freire‘s fork of their repository (actually, it’s his fork of Mickey Vänskä‘s fork of the osmocom repo). Thanks to both Igor and Mickey!

Installation Scheme

One of the big benefits of the PyBOMBS scheme we originally used in the book was the fact that it installs everything to a target directory under your home directory, rather than doing a global install to root-owned directories. The environment is then loaded with a simple call to a setup_env.sh script generated by the install process (which is automatically added to your ~/.bashrc).

This means if something goes wrong, you can just rm -r the target directory and delete a single line from your .bashrc file. You can then start over without worrying about the previous install polluting your environment.

I’ve preserved this scheme in the new scripts as well. By default the scripts will use the following directory for the target:
~/install/sdr

If you want to use a different target, simply run the script with the new target directory as the second argument. If installing 3.7 this would be:
sudo ./grc_from_source.sh 3.7 ~/install2

For 3.8, it would be
sudo ./grc_from_source.sh 3.8 ~/install2

This installation flow also allows you to easily keep multiple versions of gnuradio on disk. You simply install 3.7 to one target directory and 3.8 to another. You then enable the setup_env.sh file corresponding to the one you want to use at any given moment.

Conclusion

I’ve tested these scripts on numerous laptops and believe I’ve worked out all the issues with both Ettus and HackRF hardware. If you do have an issue, please let me know on GitHub or via email.

SDR Training in Seattle

Hello readers! Until now, our schedule has only allowed time for SDR training at customer sites or at conferences such as Black Hat and the Wild West Hackinfest. After many requests, we’re finally able to offer an open class, where individual students can sign up and learn the ins and outs of Software Defined Radio.

As always, these are small class sizes full of intensive, hands-on learning. They’ll be held in the greater Seattle area (the suburb of Kirkland to be specific) from the 5th to the 8th of November. First will be our Intro to SDR class, then our Intermediate Digital class. If there’s enough demand, we’ll add on our Reverse Engineering and Python+gnuradio classes (email us if you’re interested).

You can register here, and if you sign up on or before the 3rd of October, you’ll get a discounted rate.

If you have any questions about the classes, please contact me at paul<at>factorialabs.com.

See you there!

Learn SDR with us at Black Hat Vegas!

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:

  • scanning for and intercepting signals
  • reverse engineering transmissions
  • building your own programmable RF systems for exfiltration

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:

  • OOK, FSK, GFSK and PSK modulation
  • handling preambles, payload encodings and CRCs
  • clock synchronization!
  • and much more

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!

Getting Started with SDR on Black Hills InfoSec Webcast

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!

Installing gnuradio with Lime, HackRF and UHD support

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).

Updated gnuradio Install Instructions

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.

HackRF One’s Minimum Sample Rate Spec – There for a Reason

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:

Top Block_012

Even as low as 2 Msps, the triangle wave was clearly visible. At 1 Msps, though, things started to break down for some boards:

Top Block_019

But not others:

Top Block_018

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.