ShareBrained Technology makes electronic kits and devices for music, radio, and timekeeping. The Chronulator is our first product -- an analog, retro-ish clock with modern, programmable guts. Like all our (future) products, the Chronulator hardware and software are open-source. So you can customize it to look and work however you choose. Read more about the Chronulator or take a look at our gallery.
I got my LCD + audio + controls “shield” for the HackRF Jawbreaker working reasonably well, and wanted to show it off, doing wideband spectrum analysis:
I’m bringing this thing to DEF CON and Black Hat, and would be happy to show it to anybody who’s interested. :-) Just look for me (Jared) in the DEF CON Hardware Hacking Village or Wireless Village. I’ll also be at Black Hat Arsenal with Mike Ossmann, discussing all things HackRF. See you there?
I gave a talk on Tuesday about reverse-engineering the 1982 arcade game Robotron: 2084. Using the schematics from the original game, we located the major elements of the design, derived the system architecture, and then analyzed individual blocks of circuitry. We discussed the video subsystem — how pixels get to the screen and how the game deals with inverting the video image in a cocktail version of the game.
I’ve posted my PDF slides of the talk to the Open Source Bridge wiki. The slides file is very large (114MB) due to the vast number of schematic images I used. Sorry about that… While you wait for the PDF to download, here’s a few slides to whet your appetite:
A few weeks ago, Darren Kitchen of Hak5 rolled through Portland on his Hack Across America tour. I showed him around my neighborhood, and talked with him a bit about Mike Ossmann’s HackRF project and my Chronulator kit. Of course, Darren had a camera pointing at me the whole time — that’s his job! :-)
[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.
Here’s some details of my radio spectrum analyzer hack at Maker Faire. But first, a quick video of the hack in action:
This project is built around the HackRF, a software-defined radio transciever. I programmed it to sample 20MHz of radio spectrum from an antenna, do a frequency analysis on the data, and display the results on a Noritake vacuum fluorescent display. I added the tuning wheel mid-afternoon on Sunday, and it really improved the interactivity of the display. It felt really cool to spin the wheel around and watch the spectrum scroll back and forth. Too bad I didn’t capture that in the video…
The ARM grabs 512 complex samples at a time from the radio analog-to-digital converter (ADC). It applies a window function that reduces artifacts from sampling arbitrary chunks of a radio signal. The windowed samples are converted to frequency domain data through a 512-point fast-Fourier transform (FFT). The frequency data that comes out of the FFT (frequency vs. a complex vector) is converted to real magnitudes. I take the logarithm of each magnitude to get values vs. frequency that resemble decibels. Then, I scale the log-magnitude data to fit nicely on the vacuum fluorescent display, which is 384 x 32 pixels. For each frequency in the scaled data, I render a bar into a frame buffer I maintain in RAM, using cute bit-shifting tricks. Then, I render marks at 1MHz intervals to provide a tick-mark scale on the display. In the left corner of the display, I render minimum and maximum sample buffer values for each of the two sampling channels — this is so I can tell if I need to turn up or down the gain on the receiver. I draw the current tuning frequency in MHz at the center of the display. Lastly, I scan out each of the pixels, one byte at a time, into the VFD’s parallel 8-bit interface, using the display’s “Graphic DMA” mode.
The optical quadrature encoder runs purely on interrupts. Whenever a positive- or negative-going edge is detected on either of the two optical sensors, an interrupt is generated. Based on the current and previous values of the optical sensors, the software (borrowed from PJRC’s Encoder Library) decides if the wheel has moved, and if so, which way it has moved. Based on that decision, the tuning frequency is incremented or decremented.
There was a hairy bit of wiring between the HackRF and the VFD. I needed to interface the HackRF, which is a 3.3 Volt device, to the VFD, which communicates at 5 Volts. So I needed to translate several signals between those two voltages. I had an old circuit board from my Robotron-FPGA project that did exactly that, for a completely different purpose. But with enough wires and headers and disgusting rewiring, I made it work. But it wasn’t pretty. I had to keep poking it and twisting it, as some signals were intermittent and sometimes needed my help.
The Faire Experience
The HackRF can tune from below 10MHz (where it’s mostly amateur radio and AM radio stations), up through 6GHz. That includes *almost* every signal in common use. Until I added the tuning dial, I left the HackRF at about 840MHz, right in the middle of one of the cellular (mobile phone) bands. As you’d imagine, lots of cellular phones were in use at Maker Faire, so a lot of signals were jumping about on the display. People who really got the display would soon pull out their phones to make a call. Most of the time, their phones were operating in other cellular bands, but a few times we got lucky and could clearly see activity that came and went depending on whether they were in a call or not.
Late Saturday, a couple of hams (amateur radio operators) came by with their portable radio transcievers. I tuned the HackRF up to 440MHz and we could see peaks when they were transmitting. They were amused…
The first half of Sunday, I attached the optical encoder wheel and wired up the optical interrupters to the HackRF. The wheel was laser cut acrylic, cut before I left for Maker Faire. I cut a bunch of different designs, since I wasn’t sure exactly how everything would fit together ahead of time. The wheel was mounted on a Lazy Susan apparatus I bought at a hardware store. I drilled the wheel assembly to my display whiteboard, and then started attaching the optical interruptors with hot glue. Unfortunately, I needed a couple of 470 Ohm through-hole resistors to control the current through the interruptors’ LEDs, but I didn’t bring *any* resistors with me. So I went begging at the Radio Shack “Learn to Solder” tent, and they were kind enough to bust open one of their $60 electronics kits to give me $0.07 worth of resistors. While I was gone, somebody had forcefully cranked the wheel and broken off several of the teeth. I should’ve seen that coming! Fortunately, I had lots of other options from my laser cutting binge. I settled on a sandwich, consisting of the tooth pattern cut in paper with clear thin plastic on either side.
Once I got the encoder software working, I added a frequency display in the middle of the VFD. People would walk up and give the wheel a spin, looking around for interesting signals. There’s a lot of underutilized spectrum (at least where we were), so it wasn’t too exciting outside the cellular and 2.4GHz bands. The environment was also quite electrically noisy, so with a fairly insensitive receiver, long-distance bands (e.g. aviation) didn’t really show anything — those weaker signals were jammed by all the motors and Tesla coils nearby. I’m sure my antenna also wasn’t the best…
Despite the last-minute additions and general hackiness of the project, I had a lot of fun building it and talking with people about it. Events like Maker Faire are great as a reminder that you’re not the only person in the world who likes to nerd out on such obscure things!
I recently completed my first 8-layer PCB design, for Michael Ossmann’s Daisho project. Among the challenges: a 780-pin Altera Cyclone IV FPGA, a USB 3.0 chip with 0.8mm ball spacing, very high-speed parallel and serial buses, tight power constraints, and keeping the cost down. Oh, and did I mention I was using only open-source schematic and PCB tools (KiCAD)?
It’s back from manufacturing, and the first few subsystems are being assembled. Any bets on whether it’ll work the first time? :-)
First fabricated Daisho project main boards are back from manufacturing.
In embedded software development, there’s frequently a need for a FIFO implementation. Right now, I need to buffer data between my CC3000 Wi-Fi module and an HTTP parser. The CC3000 most efficiently delivers data from a Web server in large blocks (“large” in the embedded world meaning 256 bytes or more). But my HTTP parser will want to consume received data in single-byte increments — looking for breaks between header lines, for instance. So I need something between the two entities to hold on to the extra data that comes out of the CC3000 while the HTTP parser is doing its work. That’s where a FIFO comes in. I can read large blocks from the CC3000 when the FIFO gets empty, filling it back up, and the HTTP parser can grab bytes one at a time.
I had the (perhaps obvious) thought that the Linux kernel developers must also need FIFOs. Sure enough, they have a FIFO implementation called “kfifo“. And what an implementation! Through an exceptionally elegant trick of modular arithmetic, the code is so simple, it’s almost non-existent.
A FIFO needs to keep two indexes into a buffer array — an “in” index to where data is added to the FIFO, and an “out” index to where data is removed from the FIFO. When data is added, the data is placed at the “in” index of the array, and the “in” index is incremented. When data is removed from the FIFO, data is obtained from “out” index in the array, and the “out” index is incremented. This works just fine until the “in” and “out” indexes go past the end of the array. So you have to add code to check the “in” and “out” indexes after you increment them, and wrap them around to the start of the array when they go past the end. It’s also important to prevent adding new data if the FIFO is full, and prevent removing data if the FIFO is empty. More code, more conditionals, more spaghetti.
The kfifo code simplifies all those concerns. Instead of checking for “in” and “out” going past the end of the buffer array, it just lets them keep growing past the end. By observing that the wrap-around is just a form of modular arithmetic, and by requiring kfifos to have a length that’s a power of two, they can take the “in” and “out” indexes and logically-AND them with a bit mask that’s the length of the array minus 1. This turns an index into the value it would’ve been had you done the bounds checking and wrapping I described above. And because the “in” and “out” indexes no longer wrap, you don’t need complex code to calculate the difference between “in” and “out” to know how full the FIFO is — you just subtract “out” from “in”! But wait! What if you get to the point where “in” and “out” are so large that they wrap around the maximum value for their data type (probably an unsigned 32-bit or 64-bit integer)? Well, modular arithmetic again saves the day. If “in” equals 10 and “out” equals 2^32 – 10 (4294967286), and you subtract “out” from “in” using 32-bit math, you get… 20! How cool is that?!