HackRF Present and Future

At CSAW THREADS in November I gave a talk about the present and future of the HackRF project (video). I reviewed the new HackRF One design, and then I showed all sorts of different things that people are already doing with HackRF Jawbreaker. It's pretty exciting to see all the applications that people are coming up with!

Multiplexed Wired Attack Surfaces

Kyle Osborn and I presented Multiplexed Wired Attack Surfaces at ToorCon 15. This was the second time we gave the talk. The first was at Black Hat USA 2013, but the ToorCon video was posted first.

The basic idea is that connectors on electronic devices are often used in unexpected ways and that some devices, especially phones and tablets, even multiplex several functions onto a single connector. We demonstrated how we are able to access an interactive shell on certain Android phones by connecting a special serial adapter to the phone's USB port; although we were physically connected to the phone via the USB port, we were not using USB.

Similar multiplexed interfaces are present on a wide variety of portable devices, often accessible via USB or headphone connectors. An excellent example using a headphone jack was published earlier this year. We hope that our talk will raise awareness about the attack surfaces presented by these types of interfaces.

The talk at ToorCon was a lot of fun. We got a shell and activated adb on a phone handed to us by a volunteer from the audience. I hope you enjoy the video, but you should also read the paper we wrote for Black Hat.

We've posted links to several resources related to the talk.

Introducing Daisho

At TROOPERS13, Dominic Spill and I presented Introducing Daisho, Monitoring Multiple Technologies at the Physical Layer (video, slides). It was the first public presentation about Daisho, a new project to build an open source hardware platform for in-line monitoring of several different wired communication media at the lowest possible layer. The project targets high speed communication technologies (Gigabit Ethernet, SuperSpeed USB 3.0, and HDMI in particular) for which limited tools exist today.

A basic principle of Project Daisho is that we want to monitor communication media at the physical layer or as close to the physical layer as we are able to achieve. Since any monitoring platform is capable of reconstructing activity at the monitored layer or higher, we think that security applications will be best served by monitoring at the lowest possible layer.

The platform is designed to be used as a pair of circuit boards that work together. (If you look up "daisho" you'll find that it is a word for a pair of swords; our Daisho is a pair of boards.) The mainboard consists primarily of an FPGA and a SuperSpeed USB 3.0 port for connecting to a host computer. The front-end module has a pair of transceivers and connectors for a particular target communication medium. Each target technology will have its own front-end module. Data arriving at one connector on the front-end module are passed to the FPGA on the mainboard and then exit the other connector on the front-end module. This man-in-the-middle architecture allows us to perform in-line monitoring and should also permit future active applications including injection or modification of transmissions on the target medium.

Dominic and I are joined on this project by Marshall Hecht, Jared Boone, Mike Kershaw, and Benjamin Vernoux. It is a big project, and we are thankful to have support from DARPA's Cyber Fast Track program.

The project is entirely open source hardware and software, and it has many potential applications beyond monitoring of communication systems. We're especially excited to be producing the world's first open source USB 3.0 device core for implementation of SuperSpeed USB with a transceiver IC and FPGA. (The USB 2.0 functions are already working!)

Announcing the HackRF Beta

Jared Boone and I had the honor of presenting the keynote at ToorCon 14 over the weekend. In our talk, HackRF: A Low Cost Software Defined Radio Platform, we described our project to build a low cost, open source, wideband, portable Software Defined Radio peripheral. You can watch video of the presentation or download the slides.

In addition to introducing HackRF to the ToorCon audience, we announced the HackRF beta test program. Thanks to DARPA's Cyber Fast Track (CFT) program, we are able to build a few hundred HackRF Jawbreakers and will distribute them to ToorCon attendees as soon as they are completed (hopefully around December). Each attendee of ToorCon 14 (and also the recent GNU Radio Conference) received a unique beta invitation code that can be redeemed for a Jawbreaker as soon as the hardware is ready to ship.

Jared and I are very excited to be able to give away so many beta units. I'm not sure if any open source hardware project has had such a well funded beta program, but we think that giving away hardware in exchange for feedback (and hopefully some code) is a good trade in keeping with open source ideals.

If you have an invitation code, look for an announcement on the HackRF page around December telling you how to redeem your code for a Jawbreaker. I know there are many of you out there who wish you had an invitation code, and I'm sorry that our funding for the beta program is finite! The redemption system, once it is live, will include a way to sign up for a waiting list if you do not have a code. There will probably be some extra beta units that we will distribute to as many on the waiting list as we can.

My hope for the beta program is to validate HackRF Jawbreaker, resulting in a well-tested open source design that anyone can build or modify. I also plan to release a commercial HackRF product (similar to Jawbreaker) that will be available for purchase after the beta.

Thanks for all the kind words of support at ToorCon and since!

Programming Pink Pagers in Style

After two and a half years of programming the IM-Me by soldering wires to the test points in the battery compartment, I finally got around to making a GoodFET/IM-Me spring pin adapter. I call it GIMME. Now I can install my spectrum analyzer application or any other firmware onto an IM-Me by simply removing the batteries and pressing the GIMME against the test points while the attached GoodFET does all the tricky stuff. GIMME is designed with KiCad. You can find the design files in the contrib directory of the GoodFET repo.

To mark this occasion, I decided it was high time to post the video from my talk with Travis Goodspeed at ToorCon 12, Real Men Carry Pink Pagers. It was probably the most fun I've ever had giving a talk at a hacker con. Maybe it was the song. Maybe it was the bourbon in pink shot glasses. Maybe it was the total lack of preparation resulting from Travis injuring himself the day before. Maybe it was the ridiculous T-shirt Nick DePetrillo made me wear. (I still haven't figured out how to get him back. I don't believe it is possible to embarrass the man.)

With ToorCon 14 coming up, I decided to have several GIMME PCBs made to give away. If you see me at the con this weekend and would like one, just ask. I also took it upon myself to make some GoodFET41 boards since Travis won't be around being his usual Johnny Appleseed of open source hardware. Plus, I will have a GIMME and GoodFET available to borrow, so bring that IM-Me that has been sitting in a drawer with factory firmware!

Spread Spectrum Clock Generation, Emission Security, and You

The following is a transcript, more or less, of a short talk I gave at ToorCon Seattle 2011. There was no video made of the presentation, so I'm doing this instead. The talk was a preview of some research into how spread spectrum clock generation affects the risk of eavesdropping on unintentional Radio Frequency (RF) emanations from electronic devices.

Probably half of you are sick of hearing me talk about Project Ubertooth and the other half will be, so today I'm talking about something completely different: clocks. Not the kind of clocks you hang on a wall but periodic electrical signals that drive the timing of digital electronics and the circuits that produce those clock signals. Every digital electronic device has a clock. When you talk about your fancy, new, 3.0 GHz computer, you are referring to the clock frequency.

A traditional clock signal looks like this. The top graph shows how the voltage changes over time. The timing is fairly consistent. If you plot the signal in the frequency domain, the bottom graph, you get a sharp spike at the clock frequency. Note that I am ignoring harmonics here and have zoomed in on the region around the fundamental clock frequency.

About twenty years ago, some guys in Kentucky had this idea to modulate the frequency of a clock over time. They called the technique Spread Spectrum Clock Generation (SSCG). A spread spectrum clock signal looks something like this. The frequency of the signal varies over time. If you look at the signal in the frequency domain, the bottom graph, you see a plateau over a range of frequencies instead of a narrow spike. (If you are familiar with spread spectrum communication systems, note that I'm talking about something only vaguely related.)

SSCG became popular, first with PC manufacturers and more recently for other electronic devices. The technique is used for one and (as far as I know) only one reason: to make it easier to pass electromagnetic compatibility (EMC) testing required by the FCC and other regulatory bodies around the world. EMC regulations are intended to limit RF emissions of electronic devices in order to avoid harmful interference to radio systems and other neighboring electronics. SSCG doesn't do anything to reduce the radiated power of such emissions; it simply shifts their frequencies around so the EMC test equipment doesn't register too high a power level at any one frequency. The electronics manufacturers are playing a shell game with their clock frequencies in order to evade detection.

A few of you may have seen a recent blog post of mine, If it isn't open, it didn't happen. In it I proposed a citation boycott: scientific works not open to the public shouldn't be considered to have been published at all and should not be cited. Well, I'm about to break my own boycott. Actually I am declaring an exception, an exception for ridicule: It is okay to cite a non-open scientific work if the citation is made for the purpose of ridiculing said work.

About ten years ago, there was growing concern that SSCG might be bad for electromagnetic compatibility. It was clear that the practice resulted in electronic devices that produced higher overall radiated emissions. Plus people were starting to get the idea that wideband interference from devices with spread spectrum clocks could be worse for radio signals than narrowband interference from traditional clocks, even when comparing the two at the same radiated power level. In response, Harry G. Skinner and Kevin P. Slattery of Intel published a short paper called Why Spread Spectrum Clocking of Computing Devices is Not Cheating. It is a truly awful paper. The authors, Intel, and the IEEE should all be embarrassed to have their names on it. It features bad theory, bad analysis, bad experimentation - just about everything that could be wrong with scientific literature is evident in this biased piece of garbage. I will limit myself to pointing out just one fallacy in detail.

The authors claim that concern over the wide bandwidth of SSCG emissions is misplaced because the emissions aren't actually wide at all. If you configure your test equipment the way the FCC requires, then the emissions appear to cover a wide range of frequencies. This doesn't tell the whole story, they say.

They propose looking at the emissions over shorter windows of time. A quick snapshot would show a signal that is actually narrowband, similar to the frequency spike produced by a traditional clock. Subsequent snapshots show that the signal is still narrow but shifted to different frequencies. (Click the graph for sophisticated and professional-looking animation.)

To some extent, the authors are correct, but they conveniently leave out a rather important detail. If you look at the signal the way the FCC requires, you see a wideband emission consisting of power at various frequencies under the regulatory limit.

If, however, you look at the signal the way the authors propose, you see a narrowband emission that exceeds the regulatory limit. You can't have it both ways, guys. You either show that the signal is wide, averaged over a range of frequencies, or you reveal that the radiated power exceeds the legal limit and that your spread spectrum clock is exploiting a loophole in the peculiarities of the FCC test specification.

Amazingly enough, this unscientific trash seems to be pretty much the last word on the subject. I think it is time for fresh eyes to look at spread spectrum clock generation. I've been looking at it for a little while and have developed two hypotheses.

Hypothesis #1: The increasing prevalence of spread spectrum clock generation is detrimental to the operation of a wide variety of radio systems. SSCG is becoming popular not just in PCs but in smartphones, LCD panels, and other high speed electronic devices. It is required by interface standards such as SATA and SuperSpeed USB. As more and more of these devices are deployed (probably billions per year), the noise floor is raised for everyone trying to use the radio spectrum. This hypothesis is hard to test, so I'm skipping it.

Hypothesis #2: Devices with spread spectrum clock generation are more susceptible to eavesdropping than those without. I'm talking about emission security, the problem that electronic devices tend to unintentionally emit radio signals that can reveal otherwise secret information. Someone might be able to discover the password for your bank account, for example, by monitoring radio signals produced by your computer.

There are two reasons I think SSCG results in an increased susceptibility to eavesdropping. The first is that SSCG devices produce stronger emissions. This is almost by definition: the reason SSCG is deployed in the first place is to get away with emissions stronger than those that would be permitted from a device without SSCG. The second is that SSCG emissions feature spread spectrum signatures that make it easier for an eavesdropper to pick the signals out of the noise. This will be a little more difficult to demonstrate, but techniques from the field of digital radio communication could be applied to the problem.

In the coming months I will attempt to test hypothesis #2. I'll start by analyzing the waveforms produced by popular spread spectrum clock generator integrated circuits, and then I will apply the knowledge gained to the problem of eavesdropping on consumer electronic devices. If you are interested in helping with this research, I would love to hear from you!

Project Ubertooth: Building a Better Bluetooth Adapter

Video of my presentation, Project Ubertooth: Building a Better Bluetooth Adapter, at ShmooCon 2011 is now online. You can download the entire video in high quality from shmoocon.org or watch it in your web browser. In the presentation, I demonstrated Ubertooth One, the world's first open source, widely available, low cost Bluetooth test tool, and I described my two year design journey starting as an electronics novice. This was one of the most fun talks I've ever given, and I want to thank ShmooCon for making it happen and everyone who attended for participating. I'm making the slides available, but, as is typical of my presentation slides, they really don't stand alone.

Shortly before the presentation, I was interviewed by Hak5. The interview covered a lot of ground and included quite a bit of discussion beyond the content of the presentation.

At ShmooCon I announced the start of a pledge period on Kickstarter to fund an initial production run of Ubertooth One boards, and the pledge goal was met in just four days! There is still time remaining in the pledge period for anyone who would like a board. Thank you to everyone who has pledged support!

Ubertooth video and news

Video of Ubertooth Zero, a preview, my talk at ToorCon 12, is now online (part 1, part 2). This includes the first public demonstration of Bluetooth sniffing with the platform. Since ToorCon, I've been working hard on Ubertooth One hardware and software. I've had to work through some production delays and errors with Ubertooth One circuit boards, but I have a good feeling about the next revision which is in production now.

I am excited to announce that my talk, Project Ubertooth: Building a Better Bluetooth Adapter has been accepted for ShmooCon 2011. This will be a longer presentation telling the complete story of the development of Project Ubertooth and demonstrating new capabilities of the platform (hopefully with working Ubertooth One prototypes). ToorCon was a preview, but ShmooCon will be the big debut.

I posted a new file release of the Ubertooth project repository tonight. This includes the new bluetooth_rxtx firmware that is starting to resemble my vision for the USB interface. The host code doesn't do much more than the ToorCon demo at this point, but quite a bit has been done to enable future enhancements.

Bluetooth Keyboards: who owns your keystrokes?

I gave a talk at ShmooCon 2010 on the security of Bluetooth keyboards and mice. After a restoration of the ShmooCon archive, the full video is once again available. I have also published the slides and such.

Most of my previous Bluetooth work had been done using software radio techniques requiring somewhat costly hardware. For this talk I focused on what is possible for both attack and defense using low-cost off-the-shelf Bluetooth equipment. It turned out that quite a lot of interesting things were possible that had not been demonstrated before. Even so, many essential capabilities such as passive monitoring remained out of reach without more expensive hardware which is why I've since turned my attention to Project Ubertooth.

Ubertooth Zero, a preview

Last weekend at ToorCon 12 I unveiled Project Ubertooth, something I've been working on for more than a year. The goal of the project is to produce a low cost 2.4 GHz wireless development platform suitable for Bluetooth sniffing (among other things). If you are familiar with previous work on Bluetooth monitoring, then you know that good tools are expensive. Commercial equipment costs $10,000 or more, and even the open source solution requires a hardware investment of at least $1000.

In my talk, Ubertooth Zero, a preview, I demonstrated Bluetooth sniffing for the first time with Ubertooth Zero, my first prototype hardware model. The platform is based on the Texas Instruments CC2400 wireless transceiver paired with NXP's LPC1758, an ARM microcontroller with USB. You can build an Ubertooth Zero for less than $50 in parts. The hardware design and host code are published in the svn repository at http://ubertooth.sourceforge.net/, and firmware will follow as soon as possible (probably a couple weeks). Everything is open source.

Over the coming weeks I'll be working on the next model, Ubertooth One, which I hope to have available in early 2011. It will be compatible with the Ubertooth Zero software but will have an improved RF front end, comparable to a Class 1 Bluetooth device. I hope to produce Ubertooth One commercially, making it available to those who don't want to solder 0402s, but rest assured that the product will remain fully open source. I'm also working on firmware, host software, and documentation so that the platform will be easier to build and use.

I would love to hear from you if you decide to build an Ubertooth Zero. Keep in mind that this is a preview release with much work still undone. So far I've built three working boards, one of which fetched $275 in Sunday night's ToorCon Foundation auction, supporting technology education in developing countries. I have three more that I hope to get working soon, and then I'll start work on Ubertooth One.

So far I have implemented only single channel Bluetooth monitoring. The device sits on a single channel and receives a small subset of packets from all Bluetooth devices in range (the target devices use frequency hopping, so they only transmit a small percentage of their packets on that particular channel). This is sufficient to provide a good survey of Bluetooth activity. With some work on software in the future, the platform should be capable of hopping along with a target, receiving every packet on that piconet. Once that is working, it should be possible to use the Ubertooth platform for raw frame injection, an important capability that has been out of reach of wireless security researchers since Bluetooth's introduction. The platform could also be used for several non-Bluetooth functions such as spectrum monitoring or 802.11 FHSS

ToorCon was a blast, as always. Thanks to everyone who attended the Software Defined Radio Workshop, Real Men Carry Pink Pagers, and the Ubertooth talk. Thanks to Travis for making our talk so much fun. Thanks to Dominic for making the trip from London. Thanks to George, Tim, and David for putting on a great con and making me feel so welcome. Thanks to all the friends, both old and new. Thanks(?) to Nick et al. for embarrassing the hell out of me. Thanks to Laen for running the DorkbotPDX PCB service. Most of all, thanks to Jared Boone who couldn't be at ToorCon but who has supported my effort to develop Project Ubertooth more than anyone.

building an all-channel Bluetooth monitor

video (179M) of my presentation with Dominic Spill at ShmooCon 2009 has been posted.

Black Hat video up

Video (warning! 283 MB!) of my talk, Software Radio and the Future of Wireless Security, at Black Hat USA 2008 is now available along with all the other presentations from the event.

thanks, ShmooCon

Dominic and I had a great time at ShmooCon. Our talk was fun and well attended. Video of the talk will be posted "soon." Slides (PDF, ODP, PPT) and code are up.

We met a lot of great people and had some interesting feedback and discussions of new ideas. We're still working on this stuff, so hopefully we'll have something even better to show off later this year.

software radio at Black Hat and DEFCON

My Black Hat talk, Software Radio and the Future of Wireless Security went very well. Thanks to everyone who showed up. I've posted the final slides, demo code, and mystery signal stuff here.

Also at Black Hat were Olle's Mobitex talk and Kevin and Yoshi's talk on implantable medical devices. The Mobitex presentation was full of technical protocol details and described a method of decoding Mobitex traffic in software using sound card input from a radio receiver (more here). The medical devices talk was less technical but briefly covered wireless attacks on medical devices using the USRP (more here).

At DEFCON, NYCMIKE spoke about software-based decoding of pager networks. This was far less technical than Olle's talk, but it was nice to get a perspective from someone who just likes monitoring/scanning stuff. The canceled talk on MBTA vulnerabilities would have included a bit on using the USRP for everyone's favorite new hobby, attacking Mifare Classic RFID cards. It would have been nice to see their code. Thanks to the EFF for helping out on this one.

In his presentation at DEFCON, Rick pointed out the fact that the ath5k driver can be easily modified to tune wireless cards to a fairly impressive range of licensed bands. He also hinted that the cards might be able to be used as software radio devices for non-802.11 functions. I'm skeptical of this because it appears that ADC and DAC are tightly bound to PHY in the Atheros chipsets, but there are some interesting things like "i/q calibration" and "AR5K_ADDAC_TEST" that might be worth a closer look.

Software radio is certainly exploding in the security community. Maybe I should have called my talk, Software Radio and the Present of Wireless Security.