At ShmooCon 2015, Dominic Spill, Michael Ossmann, and I discussed our progress recreating USB implants and interception devices in the NSA ANT catalog. Dominic demonstrated USBProxy, a USB man-in-the-middle device for USB 2.0. Mike showed his TURNIPSCHOOL prototype, an implant built into a USB cable that allows remote access to a host computer’s USB ports. I showed my progress on a USB 3.0 man-in-the-middle device based on the DARPA CFT-funded Daisho project. Here’s the full video of the talk, courtesy of ShmooCon, archive.org, and… whoever the kind people were who recorded the video of all the talks. Yay!
Electronics for Curious Brains.
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.
Getting caught up… I gave a talk at ToorCon 2013 on my exploration of the Tire Pressure Monitoring System, mandated in the US for cars sold in the US as of 2008. The upshot is that people driving newer cars are transmitting unique identifiers to anyone within 20 meters. Definite privacy concerns there, methinks.
I have all the parts and PCBs for 500 units. I am now waiting on the assembler to start cranking them out. I wish I could give a firmer update at this point, but the assembler has not yet scheduled assembly. Once assembly starts, I’ll post another update and let you know how it’s going. Maybe with pictures, even!
In the meantime, if you want me to e-mail you when the PortaPack H1 is available, please leave at least your e-mail address here:
The PortaPack H1 is progressing. The hardware design is stable — just tiny tweaks at this point. I have purchased and received enough components to build 250 units. There are a few components I’m having trouble sourcing, but have some good leads and am optimistic I’ll have that resolved by early next week. I have several quotes for assembly and have picked my preferred assembler.
So what’s left? There’s the lead time for the remaining components (I’ve been told “4 to 6 weeks”), the lead time for the production PCBs (3 weeks), and assembly (about a week). The remaining components and PCBs are both requirements for assembly. So it could be 5 to 7 weeks before I can ship to Kickstarter backers and my retailers. It’s getting close. All this cat-herding is a lot of work!
If you want me to e-mail you when the PortaPack H1 is available, please leave at least your e-mail address here:
With the Kickstarter HackRF Ones shipping out soon, I’ve made some progress on the PortaPack add-on. I have a revised prototype, adapted to attach to the HackRF One.
I’ve added a few features to the Jawbreaker prototype I showed last year. Here’s what new the PortaPack has to offer:
- 240 x 320 RGB LCD. High update rate permits display of spectrum, time-domain data, and other real-time radio parameters.
- 9-way navigation control. Outer ring is four-way directional control (moving a cursor/selection). Middle ring is a rotating ring quadrature encoder. Center is a select button.
- Touch screen. For direct entry of information or scrolling through data.
- Audio I/O via a 3.5mm mobile phone jack. It accepts iPhone-style headphone/microphone combinations. Sound quality is good due to using a *real* music player style audio codec. Headphone power is considerable (a.k.a. “painful”).
- Micro SD card slot for storing or playing back data.
- Lithium coin battery to power HackRF’s internal real-time clock (RTC). Great for logging applications.
Like the HackRF, the PortaPack is more of an open-source development platform than a finished radio tool. But I’m confident the HackRF community will eagerly embrace an entirely portable SDR and develop some awesome applications for the hardware. I will do my part to provide enough code to make the PortaPack do *something* interesting. Right now, I have basic spectrum analysis and AM/FM/WBFM demodulation working.
I’m still working through pricing the cost of acquiring all the parts and getting PCBs and assembly done. My target retail price is less than $100 US. If you’re interested in getting your hands on a PortaPack for your HackRF One, please follow me via Twitter (sharebrained) or leave your e-mail address via the form below, and I’ll let you know when it’s ready to order!
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! :-)
HackRF Spectrum Analyzer
[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.