The Amp Hour #185

Chris and I interviewed Hank Zumbahlen, analog expert, on Episode 185 of The Amp Hour.

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!

The Amp Hour #177

I joined Dave and Chris again on Episode 177 of The Amp Hour. Happy Festivus!

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.

Unintended Acceleration, Software, and Sadness

A few years ago I became concerned about reports of sudden unintended acceleration in Toyota vehicles, especially when some of my family members started driving new Toyotas. At first I was skeptical of the reports, but they kept coming. In time, a friend of a friend had a terrible accident, and I was only two trustworthy people removed from a firsthand experience.

I started paying more attention to the reports, and I developed a very strong suspicion that software was to blame. Three simple facts led me to this suspicion:

1. The engine throttle was controlled by software.
2. The brakes were controlled by software.
3. Nobody knows how to make software without bugs.

The first fact surprised me a little. The second surprised me a lot. The third is common knowledge to anyone who has ever developed software, but it may be surprising to those who haven't.

When I first learned how to program in BASIC as a child, I was taught that computers don't make errors; people do. If you write a perfect program, the computer will do exactly what you expect. This is a tantalizingly optimistic view, and it helped me challenge myself to become a better programmer. Unfortunately it is not true.

During those early years my programs were small and simple. Sometimes I could write an entire program in a single page of text. It seemed very possible that programs could be perfectly correct, but somehow they never were. There was always a bug, and almost every time the bug was my own fault. As time went on, I started working on larger and larger software projects, and it became clear to me, as it should to any software developer, that the likelihood of bugs increases when software complexity increases.

This is a Big Problem. It is so big that many of the greatest minds in computer science have devoted their lives to it. Some very interesting progress has been made, but it is still largely an unsolved problem in real-world systems. It is hard to create a program that correctly implements a specification. It is hard to create a correct specification. It is hard to implement a programming language correctly. It is hard to build correct interfaces to other programs. It is hard to build computers that reliably execute programs correctly, especially in environments with high levels of electrical noise like the engine compartment of a car.

By the way, I often use "is hard" to mean "might be impossible".

Not all software is equally buggy, of course. It is possible to create computer systems that are more reliable than others (consider the hardware and software on spacecraft, for example), but it is difficult to do. It is a very different problem than the problem of building reliable mechanical systems.

The problem of software bugs is probably the biggest reason that computer security is so awful. We don't know how to make software without bugs, and bugs tend to undermine security. This is why people in the information security community seem to understand and expect bugs more than most other people; we spend our lives discovering, analyzing, exploiting, and fixing bugs. We find bugs that others miss. We break things that are supposedly unbreakable.

To me, the unintended acceleration reports smelled like buggy software from the very beginning. Few of the reports were identical, but all of them involved the inability of the driver to influence a computer that controls the engine throttle.

Some of the reports agreed on a particular point: Pressing harder on the brake pedal did nothing. This is terrifying to imagine. Your car accelerates rapidly even while your foot is on the brake pedal. You press harder and harder until the pedal is at the floor. Maybe you have time to switch off the ignition or shift into neutral, but how long would it take you to think of that? It might take only a second of unintended acceleration to cause a fatal accident.

At first Toyota denied the problem. Then they recalled floor mats. At the time, I thought that was a pretty stupid response to what seemed like a software bug. Then they recalled pedals. Then they blamed the drivers. They repeatedly said that they couldn't recreate the problem when testing the software (but any software developer knows that an inability to reproduce an error rarely means that a bug doesn't exist).

I started wondering: Have any information security professionals audited the software? Has anyone actually skilled at finding bugs looked for bugs? As far as I could determine, the only people who had tested the software were automotive engineers employed by Toyota. Automotive engineers might not know anything about finding bugs, but they should at least know something about fail-safe design.

To me, the most troubling part of the whole thing was that the brakes and all fail-safe mechanisms were also under computer control. Really? You would make a car with software throttle and also give it software brakes? Don't you know that an automobile is a lethal weapon? Have you never seen software fail? How about a traditional brake system just in case, even if it is only activated when the brake pedal is fully depressed? How about a mechanical linkage that limits the throttle when the driver slams on the brakes?

I can't imagine any engineering culture within Toyota that would fail to consider such things unless it is simply a case of automotive engineers putting too much trust in software because they don't understand software failures. Maybe they tested the things ten thousand times, unaware that they should have tested ten trillion different conditions.

As I became more and more convinced that a software bug was to blame and that nobody was properly looking for it, I started planning a blog post. I considered trying to reverse engineer a car. Even better, perhaps I could convince someone more skilled than me to try to find the bug.

Then the unexpected happened: Tin whiskers were implicated as a cause of unintended acceleration in Toyota vehicles. I had convinced myself that software must be to blame, but suddenly a seemingly plausible alternative arose. I understood tin whiskers well enough to believe that they could explain at least a portion of the failures, yet tin whiskers were just mysterious enough that I didn't question whether or not they might explain all of the failures.

Then I failed. I stopped paying attention after I heard about the tin whiskers. I didn't consider the likelihood of software bugs vs. failures due to tin whiskers. I didn't follow through on making recommendations for mechanical fail-safe (which could prevent fatal accidents regardless of the root cause of the problem). I didn't notice when Toyota denied that tin whiskers caused unintended acceleration. I never went back and reviewed the notably weak software analysis results of the NASA report that first implicated tin whiskers. I ignored the fact that the United States government stopped investigating the problem.

This week I read that a court of law found Toyota's faulty software to blame in a case of unintended acceleration. A software audit for the plaintiff revealed that coding standards for safety-critical software were not followed and that the software is buggy and incredibly complex. The audit even identified a particular failure mode in which a driver could press harder on the brake pedal with no effect, which is as close to a "smoking gun" as we could hope to see. The case clearly indicates negligent software development and deployment practices on the part of Toyota.

This shouldn't have happened if the automotive engineers were appropriately skeptical of software. This shouldn't have happened if the executives were appropriately skeptical of software. This shouldn't have happened if the software engineers were appropriately skeptical of software.

At the very least, the software engineers should have known better. If I were developing software that could kill someone in an error condition, I would feel a moral obligation to tell people about the potential for error. However, as everyone in the information security community knows, developers tend to overestimate the quality of their own code, and very few software developers are skilled bug hunters.

Unfortunately the software source code still has not been made available to the public. We have to trust the analysis of the plaintiff's expert witness (or trust Toyota) to understand how the software works. The details from the expert witness that have been reported, however, seem very credible to me. The jury found in favor of the plaintiff, so Toyota failed to effectively argue against the analysis.

I'm pretty confident in agreeing with the analysis, but it would be nice to be able to verify. If the software were open source, that would be possible. In fact, if the software were open source, others could have done the same analysis years ago and likely would have been able to fix bugs and save lives. How many people will have to die before we decide that open source is as important for safety as seat belts?

I am deeply sad for the people who died in automobile accidents for years before Toyota's negligence was revealed, I am sad for the people who will die in future accidents, and I am sad and ashamed that I never followed through on my own suspicions about the bugs at the heart of the problem.

Appearance on The Amp Hour

In case further evidence is needed to demonstrate that I am a terrible blogger, I submit this: I had a wonderful time as a guest on Episode 161 of The Amp Hour and forgot to mention it here for nearly eight weeks! We discussed HackRF, Daisho, Ubertooth, wireless security, and how I came to the world of open source hardware from a background in information security. Thanks for having me on the show, Chris and Dave!

HackRF is on Kickstarter

I launched HackRF on Kickstarter today. I hope you'll take a look, pledge your support, and spread the word. Thanks for your support!

HackRF LEGO Car

In the Hacker Lounge at Open Source Bridge last week, the well-stocked LEGO table caught my eye. In particular, I spotted an antenna protruding from the pile, and I followed it down to a radio-controlled LEGO car platform! The controller was quickly located, a battery replaced, and I found that it worked pretty well.

The controller was clearly marked with a sticker indicating operation at 27 MHz (FCC ID: NPI71646). That would have been my first guess anyway as it is a very popular frequency for radio-controlled toys. Since several of us were having a HackRF party, I decided to see if I could control the car with my HackRF Jawbreaker.

After verifying that the car worked with the original controller, I recorded several waveforms with the hackrf-transfer utility. I made eight separate recordings, one for each active controller state: forward, backward, left, right, forward/left, forward/right, backward/left, and backward/right.

The recordings were quite clean even though 27 MHz is below Jawbreaker's official operating range (30 MHz to 6000 MHz). In fact, I had captured some apparently good recordings of NFC transactions at 13.56 MHz just the day before. The major drop-off in performance I've observed on Jawbreakers I've tested has been just below 10 MHz.

The first HackRF transmission I tried was by building a small flowgraph in GNU Radio Companion to replay the captured waveforms with my Jawbreaker one at a time. With the car's controller switched off, I was able to make the car move with a simple replay! The best waveform worked at a distance of up to 20 meters even though I put very little effort into cleaning up the waveform or adjusting the power level.

Although I didn't have much time left before I had to catch my flight home, I wanted to see if I could synthesize control transmissions in software on my laptop instead of replaying captured waveforms (that included received noise and minor defects such as quantization and DC offset).

The first step toward synthesizing control transmissions was to analyze the captured waveforms. I found that each transmission consisted of a series of pulses at 27.145 MHz. The pulses were all at the same power level. Each pulse lasted one of two durations and was followed by a pause of consistent length. It looked like On-Off Keying (OOK) with data encoded in the number of consecutive short pulses.

Each transmission featured a repeated pattern of four long pulses (each 1.875 ms long, separated by 0.625 ms pauses) followed by some number of short pulses (each 0.625 ms long, separated by 0.625 ms pauses). The repeated pattern continued for as long as the controller was held in a particular state. The number of consecutive short pulses depended on the state of the controller:

• forward: 10 short pulses
• forward/left: 28 short pulses
• forward/right: 34 short pulses
• backward: 40 short pulses
• backward/left: 52 short pulses
• backward/right: 46 short pulses
• left: 58 short pulses
• right: 64 short pulses

That's as far as I got.

HackRF Beta Distribution

I've been working day and night to test, rework (You don't mind a few scorch marks, do you?), and ship HackRF beta units over the last four weeks. It has been a bigger job than I planned on, but the end is near. I expect to ship the last of the beta units before the end of June. I will have shipped a total of 500 units with more than 200 of those going to people who signed up for the waiting list.

The main reason that it has taken so long is that there has been more testing and rework required than I expected. The test procedure I gave to the contract manufacturer wasn't good enough, mostly because it performed RF tests over the air instead of over a cable with fixed characteristics. Since changing the procedure to operate over an RF cable with an attenuator, I am getting very consistent results. Unfortunately those results aren't always positive, so I've had to do a lot of rework. Plus, I've had to spend a great deal of time running the tests at my kitchen table.

Allergy warning: cats have climbed into boxes full of HackRF Jawbreakers!

I've fallen a bit behind on email while doing all this work, but many of those messages contain frequently asked questions about beta distribution that I will list here:

Q: How many people registered for the beta and how many beta units will ship?

A: I received a total of 2288 registrations. Over 400 units have shipped already. A total of approximately 500 units will ship. About 225 of those will go to people on the waiting list (those who registered without a valid beta invitation code). I wish I could give a board to all 2288 of you, but unfortunately supplies are limited. Still, I am proud to have accomplished such a large give-away of open source hardware.

Q: What are my odds of receiving a Jawbreaker?

A: If you registered with a valid beta invitation code, a beta unit should have been shipped to you already (100%). If you registered without a code, you will receive a Jawbreaker only if you were among the first 11% or so of people who registered. If you heard about beta registration from the GSG-announce mailing list, irc (#hackrf on freenode), or by following me on twitter and acted quickly, you have a good chance of getting a board. If you signed up later without a code, you probably will not get a board.

Q: Will I receive a confirmation email even if I do not get a beta unit?

A: Yes. If you included a valid email address with your registration you will receive an email either way. If a beta unit is shipped to you, I will send you an email that day. As soon as beta supplies are exhausted I will send an email to everyone still on the waiting list letting you know that you will not receive a unit.

Q: How are beta units shipped?

A: I'm shipping all beta units via USPS First-Class Mail or First-Class Package International Service. I realize that this isn't the speediest service for international beta testers and that time in customs can vary greatly, but keeping the cost low is part of how I am able to ship so many total beta units.

Q: What if my Jawbreaker fails?

A: Unfortunately I expect some hardware failures in the field. Even units that passed my improved test procedure might fail in the future. I've already seen (and replaced) one such unit that had a weak solder joint that failed after being shipped to a beta tester. I can't guarantee you a working beta unit, but I will do my best to repair or replace units that fail. If you suspect a hardware failure or have any other technical concerns, post your question or test results to the hackrf-dev mailing list.

Q: When can I buy a HackRF board?

A: I will make an announcement about commercial availability soon. If you want to be among the first to hear about it, sign up for the GSG-announce mailing list.

Giving Away HackRF

The HackRF project has been open source from the very beginning. Even before we started the project, Jared Boone and I wanted to have an open source hardware platform for Software Defined Radio (SDR). Our early prototype designs were published in our repository along with every step of our hardware and software development, and we used open source development tools including KiCad and GCC.

We felt that the world needed an open source hardware design for SDR. GNU Radio had been around for several years, leading a thriving community of open source software development for SDR, but no general purpose SDR hardware designs were available under an open source license. Both Jared and I had started our own businesses devoted to open source hardware development because we felt strongly that open source is simply the right thing to do, and we thought that an SDR peripheral would be an important contribution we could make to the open source hardware and SDR communities.

More than a year later, I am sitting in my lab testing the first sample Jawbreakers from the factory while hundreds more are being assembled and tested. Jawbreaker is the HackRF beta design, and I'm getting ready to ship beta units to as many people as possible. It is a USB-powered SDR peripheral that can transmit or receive virtually any radio signal from 30 MHz to 6 GHz, a range of operating frequencies even wider than our original, ambitious goal.

More than 500 Jawbreakers are being produced right now, and I plan to give nearly all of them away. It is incredibly exciting to be giving people actual hardware in addition to giving away the design! As far as I know, this is the largest beta give-away of any open source hardware project to date. We are thankful for the support of the DARPA Cyber Fast Track program that enabled us not only to develop HackRF in the first place but to produce and distribute so many beta units.

If you would like to participate in the beta program and receive your own Jawbreaker, you can register today. It's free! I distributed beta invitation codes to the attendees of ToorCon 14 and the 2012 GNU Radio Conference last fall. Each of those codes may be used now to register for a spot at the top of the beta list. There are more Jawbreakers than codes, so you can also get on the waiting list for additional units even if you do not have a code. I don't know how many codes will be redeemed, but there is a good chance it will be less than 100%. In order to be fair to the people on the waiting list and to avoid having a large pile of unused Jawbreakers, I established a deadline for the use of invitation codes. The deadline (20 May 2013) is approaching rapidly; if you have any friends who were at ToorCon 14 or the 2012 GNU Radio Conference, this would be a good time to remind them to use their codes!

Benjamin Vernoux, one of the HackRF developers, sent me an enclosure he designed for Jawbreaker, and it fits very nicely. It is based on the Sick of Beige case design from our friends at Dangerous Prototypes. I will not be shipping enclosures with the beta units, but you can download the design and either order one for yourself or make one on your own laser cutter. Don't have a laser cutter? Maybe it's time to make some new friends at your local hackerspace!

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

Register for the HackRF Beta Test

It is now time to register for the HackRF beta test. Invitation codes that I distributed at ToorCon 14 and at the 2012 GNU Radio Conference may be redeemed for a HackRF Jawbreaker by registering for the beta test. If you do not have a code but would like a beta unit, register without a code and you will be placed on a waiting list for excess units.

I expect the beta units to ship by the end of May. Thanks for your patience, everyone!

Jawbreaker Components Ready to Ship

The last components needed for the HackRF Jawbreaker beta production are now ready to ship to China for manufacturing. Unfortunately some additional delay caused us to run into Chinese New Year (bane of electronics designers), so the parts will not be shipped until after the extended holiday. This means that assembly will start around the end of February. I should have the finished boards in March.

Meanwhile work continues on the software. We have fixed a few bugs and now are able to operate at 16 million quadrature samples per second (and still hoping for a little more). Currently, thanks to Benjamin Vernoux and helpful denizens of our IRC channel, we are fixing some bugs in libhackrf on Windows. Although our primary development focus is on Linux, we hope to support other popular operating systems too.

The delay has given me time to focus on some other projects as well. It is going to be a fun year!

Funtenna!

I just watched Hacking Cisco Phones: Just because you are paranoid doesn't mean your phone isn't listening to everything you say, an excellent presentation by Ang Cui and Michael Costello at 29C3. I particularly liked that they coined the term "funtenna" to describe the potential capability of malware using the off-hook switch in a VoIP phone as an antenna to transmit data over RF.

I appreciate that they credited me with the idea, but I would like to set the record straight. I met Ang and Michael at a Cyber Fast Track event a couple months ago, and they approached me with the idea of exfiltrating data from the phone by toggling a GPIO pin on the embedded CPU at radio frequencies. My only contribution was looking at the hardware and suggesting that the wire extending to the off-hook switch was probably the best candidate antenna for the hack.

Although it hasn't been implemented yet, I think the idea has merit. I don't know how fast a GPIO pin can be toggled on the platform, but the CPU operates at something like 800 MHz. That makes it very likely that the maximum GPIO toggle rate is at least in the tens of MHz, maybe even over 100 MHz. I don't know the resonant frequency of the wire extending to the off-hook switch, but it is probably a few hundred MHz. If my guesses are close, then it is likely that the funtenna could be used to transmit data a short distance, perhaps through a wall or two. It isn't a very good radio, but it should work to some extent. Even a short range wireless transmission is very interesting when it originates from unmodified hardware not intended for wireless operation.

With Ang and Michael's approval, I would like to formalize the definition of "funtenna" a bit: A funtenna is an antenna that was not intended by the designer of the system to be an antenna, particularly when used as an antenna by an attacker. In the case of the Cisco phone, the funtenna could be used to transmit data from the phone. In certain systems, it may be possible to use a funtenna to receive radio signals as well. (I even know of some people working on a way to inject data into an untouched device using nothing but a high power radio signal; it is a very limited capability but theoretically possible.) The field of emission security studies unintentional radio emissions that leak data, and I would call any radiating element (a cable with poor shielding, for example) that leaks useful or sensitive information a funtenna.

Whenever I crack open an electronic device for the first time, I now look for potential funtennas. Maybe you will too. :-)

HackRF Beta Update

Sorry, folks! HackRF beta manufacturing (that I had hoped would take place in December) has been delayed until late January or early February. The reason for the delay is the most mundane that you can imagine: ordering components and getting them all delivered to the factory.

Generally speaking, it's pretty easy to buy a handful of parts for prototyping, and it is easy to buy tens of thousands for manufacturing. Buying 500 units of a part at a reasonable price for low volume manufacturing isn't always easy, however. A few of the components took several weeks to source, but they are all on order as of this week.

One component was particularly problematic, the Si5351C clock generator IC. We weren't sure why we were having so much trouble locating 500 units of Si5351C-A until the Si5351C-B suddenly appeared on the market. The new revision is only a little different than the old one, but it has some advantages; the biggest advantage is availability! I had a few units overnighted to me and tested them. Unfortunately changing to the new revision required that I add a single resistor to the Jawbreaker design. It's a very minor change, but even small changes have the potential to cause delays. In this case, the long lead time for some of the components has given us enough extra time that we can make such a change as necessary.

The good news is that we were finally able to order everything at pricing close to what I anticipated. Beta units will likely be shipped in February, so look for an announcement around that time.

So You Want to Track People with Ubertooth. . .

Dominic started a blog for Project Ubertooth recently, so I will publish most future Ubertooth related content over there. My first post is a FAQ for people wanting to use Ubertooth to track the movements of Bluetooth devices.

The ToorCon 14 Badge

I designed an electronic badge for ToorCon again this year. It features a CC1111 sub-1 GHz wireless transceiver IC with USB connectivity. This chip has the same radio as the CC1110 in the popular IM-Me. While the badge is certainly hackable hardware-wise, I hoped that it would allow people to explore radio applications without having to heat up any soldering irons.

The ToorCon 14 Badge shipped with RfCat firmware and a USB bootloader installed, so conference attendees were able to start experimenting with just a USB cable, a laptop, and the RfCat software. Although I am a fan of software defined radio, sometimes a wireless transceiver IC is all you need to do some interesting things, and RfCat is the easiest way I know to get started.

The badge is designed to be similar to and firmware compatible with the CC1111 EMK (aka "Don's Dongle"), but it has a few extra goodies. Most notably, it shipped with RfCat firmware and CC Bootloader installed. It also features a GoodFET compatible programming header and a row of test points that would have been compatible with the GIMME had I measured correctly. (Oops! Aren't you glad there is a USB bootloader?) The badge also has an option to install an external antenna connector, allowing better performance across the whole frequency range of the CC1111 than previous designs.

I held a badge hacking contest and was happy to see several people working on interesting ideas at the con. One group blew everyone else away: the Root the Box team built a multi-user wireless chat system. They implemented their own network protocol, user interface, and even HTTP tunneling from the ground up using RFCat's rflib Python library. (in two days!) Check out my video of the demonstration they gave me. They even posted the source code for their winning entry.

These were the same guys who won the ToorCon 13 badge hacking contest by implementing a simple game with 2.4 GHz wireless connectivity. Check out their Root the Box CTF event coming up in January!

There were a few extra badges made. Look for them to go on sale soon at HakShop and Ada's Technical Books.

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!

HackRF Jawbreaker

Last week at the GNU Radio Conference I showed off Jawbreaker, the first unified HackRF board. I had assembled it just prior to leaving for the conference. It is completely built (including a couple of minor corrections), and I am about three-quarters of the way through validating the design.

Jawbreaker integrates three separate designs into a single circuit board, making it smaller and easier to handle. Since my previous post, I tested multiple wideband front-end designs, eventually settling on one called Licorice. Jawbreaker is a combination of Licorice, Lemondrop, and Jellybean into a single USB-powered software radio transceiver peripheral designed to operate from 30 MHz to 6 GHz.

This week I plan to finish validating the design and ordering PCBs of the next (likely final) revision. While I validate and revise the hardware design, Jared is hard at work on a USB driver for the LPC43xx microcontroller on the board. Prior to combining the three boards into Jawbreaker, I successfully tested both transmit and receive paths from the antenna all the way to the microcontroller, but the "last mile" USB communication from the microcontroller to the host computer was still incomplete.

I had planned to bring a finished Jawbreaker for everyone attending my software radio workshop at ToorCon San Diego later this month, but unfortunately it doesn't look like I'll have enough working units by then. Instead I will provide alternative hardware that will fully enable everyone to participate in the workshop exercises, and I will send Jawbreakers to the attendees when they are finished later. (There are still a couple of seats open in the workshop, by the way.)

A puzzling feature you might have noticed on Jawbreaker is the integration of a PCB trace antenna for the 900 MHz band. Although the board is designed for operation over a much wider frequency range, this antenna allows people to start experimenting with the board in the 900 MHz band immediately without any antennas, connectors, or anything at all other than a USB cable and computer. I want it to be easy for people to get started with the device because Jawbreaker is intended as the beta test platform for the HackRF project. We plan to assemble quite a few Jawbreakers and will distribute them to beta testers in the coming weeks. Beta hardware availability will be announced at ToorCon.