Wireless Microphones and HackRF

[Updated with GNU Radio flowgraph picture and .grc file link.]

I and my HackRF software-defined radio spent some time at a big software conference recently. Because I can’t resist gently sticking my nose where it doesn’t belong, I decided to investigate the wireless microphones being used on the conference stages.

If you’re not familiar with a software-defined radio, it’s pretty disruptive technology. A software radio is a radio that doesn’t know anything about AM, FM, Bluetooth, ZigBee, cellular — any of that. Instead, it just digitizes or transmits raw signal data. It relies on a computer running software that knows about different wireless technologies. And because the bulk of the work is now done in software instead of being set in stone (in hardware), the software can be updated to speak virtually any wireless technology — past, present, or future. You don’t need to buy a new, different radio, just use different software. This vast flexibility also makes software-defined radio a great technology for investigating wireless security vulnerabilities.

So back to the conference. I wanted to learn more about the security vulnerabilities these wireless microphones might pose. Here’s the process I followed:

Step 1: Discover what kinds of microphones were used. At this conference, the sound engineers were set up at the back of the room and would frequently leave their equipment unattended, sitting on a table in plain view. I was able to walk up and copy down the FCC equipment authorization IDs off the back panels of the microphone receivers. Armed with those IDs, I went to the FCC OET Web site and looked up internal photographs, test reports, and user manuals for the receivers. I discovered that the microphones operated in the 524 to 542 MHz range. I also learned that these microphones used simple frequency modulation (FM). This should be easy!

Step 2: With the HackRF and GNU Radio, I did a survey of the 524 to 542 MHz frequency range, looking for signals that had the tell-tale spectrum symmetry of an FM transmission. I found several candidates.

Step 3: I worked up a quick GNU Radio Companion flow graph of an FM demodulator, based on several FM demodulator examples I found on the Internet. As I tuned to each candidate frequency, the spectrum analysis of the demodulated signal turned from white noise to a much lower noise floor with bursts at the rate of typical conversation. A quick check on my laptop’s audio output confirmed I had access to the audio directly from the microphone!

What are the security implications of these wireless microphones, used in this situation? A few things come to mind, in increasing levels of evil-ness:

  • I could record the audio directly from the microphones. And if several microphones are in use, but with carriers all within HackRF’s 20 MHz bandwidth, I could record all the microphones at the conference with a single radio.
  • I could overwhelm the microphone signals with my own transmissions, replacing the audio the audience hears with my own audio.
  • With a good high-gain, directional antenna, I could monitor presentations at conferences, from outside the perimeter of the building. I could listen to conferences I am not invited to, and purloin information I am not otherwise privy to.

How are these problems addressed? The most obvious answer, aside from using wired microphones, is to move to a digital modulation, digitize the audio, and encrypt the audio data stream. There are microphones on the market that address this — though I suspect they are expensive and power-hungry, much like digital mobile phones were when they were introduced as the replacement for analog “AMPS” phones. But until convention center customers express concern over the security of their conference content, venues will continue to use their cheaper FM systems, and digital systems will continue to be a niche product and expensive. Big, public conferences may not care too much about this vulnerability, but private groups and organizations may feel otherwise.

8 thoughts on “Wireless Microphones and HackRF”

  1. Hey, I saw this post tweeted by Michael Ossmann. Nice work on the Jawbreaker to tune in to those FM microphones! I figured I would chime in a little here since I dealt a lot with wireless microphones when building white space networks in that same frequency band. Since white spaces use the UHF/VHF frequencies, they have to deal with wireless microphones. I spent a lot of time in this space learning about wireless microphones to learn how to reduce interference with them from white space networks, and as a result we met with a lot of wireless microphone operators (e.g., those that run the Super Bowl) and directly with the manufacturers themselves (e.g., Shure).

    You’re right, it’s totally insecure and easy to eaves drop on. They’re very narrow signals without any sort of encryption. At the end you kind of question why they don’t go digital in your post, and I thought I’d touch on this.

    The main arguments that I’ve heard from talking to these people is one that centers around audio quality and spectrum efficiency. If you think about large events/venues, they have dozens of active microphones. I’ve seen the microphone data from the NBA all star game and Super bowl, and they literally have over 100 microphones. To operate in that spectrum, these signals need to be extremely narrow and packed in. Yet, they need to carry high quality. It is *very* hard to meet the needed dynamic range of audio and the necessary resolution (e.g., of music) in digital microphones while achieving high spectrum efficiency and narrow signals. To do digital, the audio typically needs to be compressed to reduce the required RF bandwidth, and as a result they lose the professionally needed audio resolution and quality. This is a killer for them, and as a result: the industry has stuck with the more spectrum efficient analog FM signals. Think about trying to carry a professional level audio quality over a 250-500KHz digital signal that maintains real-time requirements, and you should now see the problem :) Look at how crappy Bluetooth audio is with a 1MHz signal. They’d easily need a few MHz to carry professional level quality, and that crushes their spectrum efficiency.

    Now, this kind of quality is obviously not needed in a lecture hall, but this general view in that community has simply kept the microphone systems designs in this way. There are digital systems out there, but they’re typically more expensive.

    I hope this sheds some light on the situation! I think that the wikipedia page touches on this a bit: http://en.wikipedia.org/wiki/Wireless_microphone#Digital

    I’ve also got some more details of wireless microphone systems in my paper:

    You could easily “DoS” a mic system by transmitting over the area of the “squelch tones” … I’m pretty sure it would cause the microphone to mute entirely. However, note that we found FM mic systems to actually be highly resistant to wideband digital interference due to the FM capture effect in the mic systems.

  2. This is actually a very interesting experiment that could have quite significant repercussions. Putting aside the larger events such as the Superbowl for a minute, my mind goes to corporate events such as kick-offs and marketing presentations – many of these (in Europe anyway) are held at event venues and expo halls rather than in corporate offices; and if these venues use the FM-type modulation you describe, it seems like it would be a piece of cake for competitors to figure out (there are tons of ways) when you’re holding an event and then simply park a White Van in the parking lot outside and listen in on your coming products and campaigns. Sounds like a perfect solution for corporate espionage if you ask me.

  3. I’m unable to replicate this working.. Having a number of errors..

    Under RTL-SDR: Ch0: Bandwidth (Hz): will not accept “5M” as a value. syntax error

    Under Freq Xlat FIR Filter: Taps: module “firdes” does not exist

    under FM Demod: Channel Rate will not accept “384K” as it is another syntax error.

    Any suggestions or ideas for this to work?

  4. @mrmookie: Most of these issues sound like GNU Radio version mismatches. If you’re not using GNU Radio 3.6.5, objects are probably named and organized differently, which is causing the problems. The “5M” error is likely due to HackRF not supporting a 5MHz sample rate. I’m pretty sure I’d used 10MHz in my .grc, so a “5M” error is a surprise.

  5. That was in fact the problem. I’m too dumb to fix it in the new version but it works fine using the version that you used! :p Thx.

  6. Impressive overview of wireless mike decoding. Very sophisticated.

    I am super-excited about HackRF. Just got mine the other day. For a Windows user and newbie to Linux, where do you recommend I start to get this running?


Comments are closed.