Earlier this week, Dr. Andrew Zonenberg of IOActive published a security advisory and blog post describing weaknesses in the SimpliSafe home security system. He showed that components of the system, such as the keypad, transmit unencrypted radio signals that can be captured and replayed. He also pointed out the significant problem that SimpliSafe devices are physically incapable of being reprogrammed with improved firmware that might address such vulnerabilities.

I know Andrew and have great respect for his reverse engineering and hardware hacking talents. He implemented a replay attack by making small modifications to SimpliSafe devices, monitoring and controlling them from his own hardware platform. To demonstrate the impact of the technique, he showed how it could be used to replay a PIN that disarms a SimpliSafe system. While I found his attack very effective, I was intrigued by his inability to fully decode PINs. I wanted to take a crack at the problem myself, and I thought it would be worthwhile to confirm that the radio interface of the system can be attacked at a lower cost to the attacker, without any SimpliSafe hardware, and without physical proximity to the target system.

I borrowed a SimpliSafe system to use as a target system, and I took the approach I have demonstrated in my presentation, Rapid Radio Reversing, using a combination of Software Defined Radio (SDR) and non-SDR tools. The primary tool I used was YARD Stick One with RfCat software.

First I used HackRF One to monitor transmissions from the SimpliSafe keypad. I visualized a captured radio waveform with inspectrum and quickly identified an Amplitude Shift Keying (ASK) signal being transmitted by keypad. Andrew labeled this On-Off Keying (OOK), but the difference between ASK and OOK is subtle and does not affect his findings.

After determining the frequency, modulation, and symbol rate of the transmission, I turned to YARD Stick One for further analysis. Within seconds I was able to decode raw symbols being transmitted by the keypad. It was easy to identify which packets were transmitted by the keypad after entering a PIN, so I entered a few different PINs and saved the resulting packets for analysis.

It took me a couple hours of staring at packets and fiddling with short decoding functions in Python before I was able to understand the encoding. This was the most difficult part of the project. The system uses a somewhat uncommon Pulse Interval and Width Modulation (PIWM) to encode data onto the ASK signal, and the order of bits was not immediately obvious. With a little time, however, I was able to implement real-time decoding of received packets and to recover the PIN entered on the keypad by another person at a distance. I was also able to replay keypad transmissions.

I could have implemented capture and replay even without fully decoding the packets. This is what Andrew was able to accomplish with his hardware hack. Full decoding, however, demonstrates that some additional attacks are possible. An attacker with a good antenna can monitor PINs from a great distance and can, without ever transmitting a radio signal, learn those PINs and later use them at the keypads. An attacker can craft packets with chosen PINs or other contents, so an automated brute force attack on a PIN is possible even if the attacker has not observed the valid PIN. The system uses 4-digit pins, so only 10,000 guesses are required for an exhaustive brute force attack.

I could have accomplished all of this with only HackRF One or only YARD Stick One, but I used the combination of the two for convenience. If I had to choose just one for a project like this, it would be YARD Stick One which, at $100, costs less than half of the equipment used by Andrew. It could be done with almost any 433 MHz ASK transceiver, including the covert TURNIPSCHOOL or my favorite children's toy, the IM-Me, but YARD Stick One with RfCat is the most convenient tool for the job in my toolbox.

Andrew included with his blog post a video demonstrating his attack over-the-air. In his video, he mentions that his hardware hack was the "quickest and easiest way" to accomplish his attack. That may be true for Andrew, but personally I found it easier to use radio tools. I wrote dozens of lines of Python compared to his hundreds of lines of C, and I never needed to crack open any SimpliSafe device. It took me about half a day, and most of that time was spent puzzling over the data encoding. I could have implemented a simple capture and replay within seconds of identifying the radio signal.

Andrew's video shows him disarming an alarm from only a few inches away which unfortunately could be interpreted as meaning that his attack is only effective at such close range. His attack, in fact, works from anywhere the keypad can operate. According to the manual, it works within 100 feet of the base station. Even greater range can be achieved easily with the use of low cost radio test tools instead of a modified keypad. I estimate that, for less than the $250 Andrew spent, an attacker can execute PIN replay from about a mile away.

Since Andrew's advisory, SimpliSafe has responded in predictable fashion while information security professionals filled their bingo cards. One of the things SimpliSafe has pointed out is that customers are notified whenever their systems are disarmed. Unfortunately this is only true for those customers who pay an extra $10 per month for SMS and email notifications. Moreover, in my testing, I verified that it is possible for an attacker to wirelessly command the SimpliSafe system to enter test mode even while the system is armed. This is something that normally can be done from the SimpliSafe keypad only while the system is disarmed. Alarms and notifications are disabled in test mode, but the documentation states that test mode is indicated in the online dashboard available to customers who pay for notifications.

Following Andrew's lead, I am not publishing any attack software developed during my testing. However, it is important to realize that I employed only tools and techniques that are well known and commonly used throughout the wireless security community. Effective attacks, including PIN replay, can be implemented without writing a single line of code. Passive monitoring attacks, such as the ability to learn a PIN at a distance, require somewhat more reverse engineering effort but can be implemented with even less expensive equipment such as off-the-shelf TV tuners that cost as little as $10.

Andrew's and my investigations only scratch the surface of the security of the SimpliSafe system. Andrew's key finding is not that PINs can be replayed but that the absence of basic cryptographic protections illustrates a total lack of wireless security engineering. Further weaknesses will very likely be discovered if anyone takes the time to look for them. For example, the cellular interface is an attack vector that remains unexplored as far as I know.

SimpliSafe is not alone in deploying alarm systems with vulnerable wireless interfaces. Sadly, almost every wireless alarm system I've ever looked at suffers from similar weaknesses. As we hurtle toward a future of ubiquitous digital wireless technology embedded in the objects of our daily lives, we would be wise to pay more attention to the security of those wireless interfaces. Burglar alarm systems seem like a good place to start.

P.S. Dr. Zonenberg's dissertation is fascinating.

In this video of Michael Ossmann’s presentation at ToorCon 2015, he demonstrates how helpful it can be to use a combination of both SDR and non-SDR tools for reverse engineering wireless systems. Michael uses both HackRF One and YARD Stick One to reverse engineer a wireless cabinet lock.

You can download and watch the video on Internet Archive here.

The code from the presentation is in Michael Ossmann’s stealthlock repository.

We've fallen behind on shipping Free Stuff and even further behind on announcements, but we're catching up!

Tariq Ahmad wrote to us representing the M5 hackerspace at UMASS Amherst. M5 has several ongoing projects including their Experimental College where students can take as well as teach classes just for the sake of learning. Tariq, we hope you and everyone at M5 can learn some new skills with your new HackRF One!

This week we started shipping YARD Stick One, our latest test tool for radio systems operating below 1 GHz. The first thing you should know about it is that, unlike our popular HackRF One, YARD Stick One is not a Software Defined Radio (SDR) platform. Although we think that SDR is the overall best tool for the greatest number of wireless applications, sometimes it is beneficial to have a simpler tool for certain jobs.

The architecture of YARD Stick One is similar to Ubertooth One; it is a wireless transceiver IC on a USB dongle. The IC takes care of digital modulation and demodulation, giving you an easy-to-use interface for your own software running on the attached host computer. YARD Stick One is the quickest and easiest way to start experimenting with low speed digital wireless technologies including industrial control systems, wireless sensor networks, smart meters, home automation systems, garage door openers, and remote keyless entry systems.

The YARD Stick One story started when Travis Goodspeed introduced me to the IM-Me one snowy night at ShmooCon in 2010. He showed me how to use his GoodFET to program firmware on the IM-Me, and we successfully tested radio transmission from the IM-Me in the hotel bar. After returning home, I acquired an IM-Me, soldered up the GoodFET Travis had given me (which was the first surface mount PCB I ever assembled), and immediately set to work developing a spectrum analyzer application which, to this day, remains perhaps the most useful software available for the popular, hackable toy.

Months later, Travis and I presented Real Men Carry Pink Pagers in which we encouraged others to use the CC1110-based platform for testing and experimenting with digital radio communication systems. About a year after that, atlas started showing people how to use the CC1111, the USB-enabled version of the CC1110, to accomplish the same things with a dongle connected to a laptop. His RfCat software allowed people to do things in a few lines of Python that Travis and I achieved only by compiling C for the 8051 microcontroller inside the CC11xx.

RfCat made experimentation with low speed digital wireless systems easier than ever before, but it wasn't adopted as widely as I hoped it would be. Probably the biggest reason for that is the fact that, for a long time, the only way to get RfCat up and running was to buy a CC1111 development board, assemble a GoodFET yourself, and then use the GoodFET to write RfCat firmware onto the CC1111 board. It became apparent early on that we needed a device designed specifically for RfCat, one that ships with RfCat firmware and is ready to use. I designed the ToorCon 14 badge, which was a great success, but I wanted to make an even better platform available to the world.

YARD Stick One was intended to be the ideal platform for RfCat. In addition to shipping with RfCat firmware, YARD Stick One is designed to operate effectively over the entire frequency range of the CC1111. All of the previous CC1111 boards that I know of are designed to work in only one frequency band. For example, you can get a CC1111 development board for 900 MHz or one for 433 MHz, but, prior to YARD Stick One, you couldn't find a CC1111 board that worked well in both those bands.

Where previous development boards have had built-in antennas, YARD Stick One has an SMA connector that allows the use of higher performance external antennas. It also has receive and transmit amplifiers for improved RF performance. Like everything we make, YARD Stick One is open source hardware.

It took a long while to complete YARD Stick One and get it manufactured, but we are finally shipping. Over the past couple years I've been able to get pre-release boards out to atlas and a few other folks who are active in wireless security research. For example, Samy Kamkar used YARD Stick One for the remote keyless entry system research that he presented at DEF CON in August.

To get started with YARD Stick One, I recommend atlas's videos along with several blog posts written by early adopters of RfCat. You'll notice that, even though the users of RfCat tend to be well versed in SDR, they find RfCat useful to get hacking even faster on digital wireless communication systems.

Today I submitted the following comment on the FCC's Notice of Proposed Rulemaking (NPRM) on Equipment Authorization and Electronic Labeling for Wireless Devices.

Thank you for inviting comments on the proposed rules for Equipment Authorization and Electronic Labeling for Wireless Devices.

I am the owner of Great Scott Gadgets, a US company that makes open source test equipment primarily for the information security industry. As a designer and manufacturer of communications equipment, I commend the Commission for seeking to clarify and streamline the rules for equipment authorization. I believe that, on the whole, the updated rules will benefit the electronics industry. However, I am concerned that the rules regarding software control of radio parameters place an undue burden on device manufacturers and unnecessarily restrict the actions of end users.

My concerns arise from rules already in place for Software Defined Radio (SDR) devices. I am encouraged to see that the Commission is eliminating certain special rules for SDR equipment and seeks to treat SDR and non-SDR devices in the same way. However, while the Commission notes that "the existing SDR rules have proven to be insufficiently flexible," the proposed rules broaden the reach of those rules to non-SDR equipment.

The requirement to implement security measures preventing the modification of software has long been unpopular in the SDR community. Software security is difficult, expensive, and unreliable, and it undermines reconfigurability, a principal benefit of SDR. The proposed rules extend this absurd requirement to all radio equipment with any software control, encompassing most radio devices manufactured today.

Under the proposed rules, all radio device manufacturers would be required to devise software security mechanisms that do not exist today, and they would have to prepare for each new device software documentation that is currently not required. Makers of integrated circuits would have to develop entirely new product lines that provide device manufacturers with security mechanisms, killing off existing product lines that lack such controls.

These requirements seem particularly onerous when considering the fact that computer security is largely an unsolved problem. Where manufacturers have had limited success preventing modification of software in electronic devices (e.g. in mobile phones), it has been accomplished only through great effort and expense. The engineering effort required to devise effective security measures (not to mention the cost and power consumption of cryptographic controls) may exceed the effort required to design many digital radio devices made today. A likely outcome is that software security mechanisms implemented in compliance with the proposed rules will prove ineffective and a waste of effort.

Great Scott Gadgets designs and manufactures Open Source Hardware (OSHW). The OSHW community includes a small but rapidly growing segment of the electronics industry that is committed to the ideals that end users have a right to fully control their own equipment and that anyone should be able to study, make, use, modify, and sell devices based on our published designs. OSHW makers recognize that, just as Open Source Software has resulted in great advances in the software industry, Open Source Hardware will enable future generations of hardware innovation.

As an OSHW designer, I have often been troubled by the Commission's rules for SDR. Great Scott Gadgets manufactures and sells HackRF One, an open source SDR platform popular for research and education. HackRF One is sold as test equipment, making it exempt from equipment authorization. As Open Source Hardware, however, it is a design that may be modified and sold by anyone. If someone were to use HackRF One as the basis for more specialized open source radio equipment that is not subject to the test equipment exemption, this new equipment would require authorization and would be subject to software security requirements that are incompatible with the open source license. We cannot grant open source licenses to users while locking out those same users.

This fundamental incompatibility with open source licensing greatly concerns me. The software security requirements, now that they will apply to non-SDR devices under the proposed rules, will adversely impact not just designers and users of Open Source Hardware but anyone making or using Open Source Software with any radio equipment. Today innovation is stifled by rules that make it difficult or impossible to sell OSHW SDR devices that are anything other than test equipment. Under the proposed rules, even more innovation will be curtailed.

I urge you to eliminate the software security requirements for both SDR and non-SDR equipment.

Additionally I am concerned about the proposal to grant automatic long-term confidentiality to certain types of exhibits. The Commission's Equipment Authorization database is a great public resource that is better protected by the existing rule that grants long-term confidentiality only upon request.

Jared Boone of ShareBrained Technology gave demonstrations of his new PortaPack H1 at the DEF CON 23 Demo Lab. I joined him at his table to help talk with people about the add-on for HackRF One.

PortaPack H1 turns HackRF One into a portable SDR platform. With an LCD, navigation control, and audio input and output, the device can be used as a handheld spectrum analyzer and can implement a wide variety of useful radio functions. A microSD slot on the PortaPack can be used for waveform or firmware storage, and a coin cell keeps the real-time clock and a small amount of configuration RAM going while the device is turned off.

Of course, the hardware designs and firmware for PortaPack H1 are published under an open source license. Jared has done an amazing job of implementing SDR functions for PortaPack that run entirely on HackRF One's ARM Cortex-M4 microcontroller.

To use PortaPack H1, you'll need a HackRF One, and you'll probably want a USB battery pack to make it a fully portable solution. Another popular add-on is the beautiful milled Aluminum enclosure for PortaPack. Jared provides a ShareBrained Technology guitar pick with every PortaPack H1. It is the perfect tool for opening your HackRF One's injection molded plastic enclosure prior to PortaPack installation.

There was a wonderful moment at the Demo Lab when Jared tuned his PortaPack to a frequency being used by Ang Cui at a nearby table. Jared's PortaPack was plugged in to a small speaker, so we could all listen to the AM radio transmission originating from a printer at Ang's table. The printer was physically unmodified but was running malicious software that transmitted radio signals with a funtenna! For more information about Ang's implementation, visit funtenna.org.

Over the next several days, thousands of hackers will gather at the Chaos Communication Camp in Germany. An electronic badge for the event is being prepared, and it is based on my design for HackRF One!

At DEF CON over the weekend, I was fortunate to be able to meet up with Ray, one of the members of the Munich CCC group responsible for the rad1o badge. Ray was wearing one of the prototype units, so I was able to take a close look.

The design is a variation of HackRF One. It includes a small LCD and an audio interface, so it is a bit like having a HackRF One plus a PortaPack H1 on a single board. A slim, rechargeable LiPo battery is mounted on the back. The visual design of the PCB looks like a traditional AM/FM radio receiver complete with an antenna (which is not the actual RF antenna) and a dial (which is not really a dial).

There are some design modifications, especially in the RF section, that seemed strange to me at first. The reason for many of these changes is that the rad1o team was able to get certain chip vendors to agree to sponsor the badge by donating parts. By redesigning around donated components they were able to reduce the cost to a small fraction of the cost of manufacturing HackRF One, making it possible to build the rad1o badge for several thousand campers.

The firmware for rad1o is derived from HackRF One firmware but is in a separate repository. Because of the LCD and other differences between the two hardware designs, they are not firmware-compatible. When using rad1o as a USB peripheral, it is fully supported by existing software that supports HackRF One. Future rad1o firmware will use a USB product ID of 0xCC15 assigned from the Openmoko pool, but the shipping firmware will borrow HackRF One's product ID. This will ensure that any existing software for HackRF One will work with rad1o during camp. The new product ID (0xCC15) is already supported in libhackrf release 2015.07.2, so it should be easy for people to update to it in the near future.

If you are new to Software Defined Radio and are looking forward to using the badge as a way to get started with SDR, I recommend starting with my video series. You might want to download the videos before leaving for camp. Also take a look at Getting Started with HackRF and GNU Radio and the recommended software for rad1o. If you plan to do firmware or hardware hacking, be sure to clone the rad1o repositories. For examples of Digital Signal Processing (DSP) on the LPC43xx, I suggest studying Jared Boone's firmware for PortaPack H1. Also check out the video of Jared's Software-Defined Radio Signal Processing with a $5 Microcontroller at BSidesLV 2015.

As an open source hardware developer, it is extremely satisfying to see folks start with my design and do something amazing like the rad1o badge. I'm excited to be attending camp for my first time ever, and I can't wait to see the projects people will come up with!

Today I submitted the following comment on the Bureau of Industry and Security (BIS) Proposed Rule: Wassenaar Arrangement Plenary Agreements Implementation; Intrusion and Surveillance Items.

Thank you for inviting comments on the Wassenaar Arrangement Plenary Agreements Implementation for Intrusion and Surveillance Items. As a member of the information security community, I am concerned about the effects of the proposed implementation on my industry.

I'll keep this brief by voicing support for the comments made by other prominent members of the community: Google, Katie Moussouris, Robert Graham, and Sergey Bratus et al.

My greatest concern is clarity of the proposed rule. If you must provide an answer to a frequently asked question about what a rule means, it may be because the rule was not written clearly. I was particularly troubled by the publication of the FAQ regarding the proposed rule, partly because it indicated a lack of clarity in the rule but also because the answers didn't seem much clearer. Had the answers been clear, I would still be concerned that the text of the rule would not be interpreted in the future in the same manner as your present interpretation. The text matters, and it is overbroad and unclear even to well informed members of the information security community.

Unfortunately, computer security is an unsolved problem. The people who are working to improve the state of the art of computer security are diverse members of a global community of researchers. The proposed rule directly prevents the sharing of information among those researchers, and it will have a negative impact on the security of computing systems and software for the entire world.

Software is a form of information, and control of the flow of information is very different from control of the transport of physical goods. I urge you to remove software from the scope of the Wassenaar Arrangement at the annual meeting of Wassenaar Arrangement members in December 2015.

If you are a full-time university student and would like a free ticket to this summer's Black Hat Briefings, send an email to freestuff@greatscottgadgets.com today. We have two tickets to give away, and we would like to give them to students who share our interests. You must meet Black Hat's criteria, and you will be responsible for your own travel and lodging.

We'll be busy at Black Hat USA this year. I'm teaching two sessions of my Software Defined Radio class, and I will be giving a talk at the Briefings about the NSA Playset. Additionally, Taylor and I will show off a new project called YARD Stick One at the Black Hat Arsenal.

We've decided to advertise the fact that HackRF One operates all the way down to 1 MHz, not just to 10 MHz. This isn't a change to the hardware design; it is simply an acknowledgment that the hardware has always worked at such low frequencies and that we support operation down to 1 MHz.

In fact, HackRF One can even function below 1 MHz, but the performance drops considerably as the frequency decreases. The curve is reasonably flat down to about 1 MHz, so we consider that to be the lower limit for most uses.

Now that we've seen consistent low frequency performance across multiple manufacturing runs, we're comfortable changing the official specification: HackRF One operates from 1 MHz to 6 GHz. Try attaching a long wire antenna to listen to shortwave radio!

Although HackRF One has reasonable performance down to 1 MHz, it performs better at higher frequencies. To get the best possible performance down to 1 MHz and lower, I recommend using an external upconverter/downconverter such as the excellent Ham It Up, open source hardware designed by Opendous.