Great Scott Gadgets

Free Stuff - January 2026

2026-03-17T12:00:00

The January 2026 recipient for the Great Scott Gadgets Free Stuff Program is Hank Fordham, a cybersecurity specialist and public speaker from Alberta, Canada! Hank, better known online as “Hank the Hacker” delivers live hacking demonstrations at conferences, higher education institutions, CTF competitions, and public sector events. We have sent Hank a HackRF One and YARD Stick One to use as core components of these demonstrations at upcoming conferences this year. He tells us that his presentations focus on demystifying wireless attacks by showing audiences how real-world RF threats work in practice. Rather than relying solely on slides, he builds controlled, responsible live demos that visualize and explain attack techniques such as sub-GHz replay attacks, insecure remote control protocols, legacy IoT communications, and signal analysis fundamentals. Hank says that with HackRF One, he will be able to perform real-time spectrum visualization and modulation demonstrations, helping audiences see how signals occupy and move across frequency space. The YARD Stick One will be used to demonstrate sub-GHz protocol weaknesses in a safe, controlled environment - never targeting real-world systems but displaying how improperly implemented rolling codes, static identifiers, or unencrypted transmissions can be captured and replayed. This is especially impactful when teaching non-RF specialists, such as IT leaders, students, and defenders, who often understand TCP/IP security but have little exposure to RF-layer threats. Hank’s ultimate goal is to highlight and raise awareness of modern cybersecurity threats and promote responsible defensive research. We are glad we were able to support Hank’s endeavors and wish him luck at his events this year!

Free Stuff - December 2025

2026-03-16T12:00:00

The December 2025 recipient for the Great Scott Gadgets Free Stuff Program is Nikos Gerogiannakis, applying on behalf of the Epictetus Wireless Security & Signal Research Initiative at the Hellenic Mediterranean University. Nikos says that their group has established a solid foundation in digital signal analysis and embedded security through hands-on projects such as an FPGA-based logic analyzer and Smart Locker systems. With the HackRF One we have sent their way, the group plans to proactively audit systems like their RFID scanners, probing for real-world vulnerabilities such as signal replay to develop genuinely robust, open-source access controls. They also plan to incorporate software-defined radio into their hands-on certification program and foster an environment where students can safely explore the security implications of the wireless protocols that surround them, turning theoretical risks into tangible, understandable lessons. We wish Nikos and their team well on their educational journey and are excited to hear about their academic accomplishments!

Self-Repair Guide for HackRF Pro USB-C Connector

2026-03-15T12:00:00

Since HackRF Pro began shipping at the end of 2025, we have become aware of an ongoing issue with USB connectors on some units received by customers. Our engineering team has investigated further and discovered that the connector manufacturer changed tooling between our prototypes and full production, resulting in less reliable ground/shield contact. The next production round has started and we have corrected the issue by using a replacement part, so this issue should only affect units from the r1.2.1-p1 round.

If your HackRF Pro tends to lose USB connectivity easily when the USB cable is touched, first try a different cable. In many cases, unreliability is caused by the cable or by a combination of cable and connector. If the issue persists, you may want to try the relatively simple self-repair described below!

First, remove the lid from your HackRF Pro enclosure - if you haven’t done this before, we suggest taking a look at this video from Jared Boone. HackRF Pro’s case is a little easier to open than HackRF One’s and can typically be opened without tools.

Next, bend the connector’s external shell contacts inward with a small tool, such as a miniature screwdriver.

Exchanging units through the reseller you purchased your HackRF Pro from is also an option, but we cannot guarantee the new unit won’t have the same issue, since it could be from the same production run as the faulty one. If you are still interested in receiving a new unit, please contact the reseller you purchased your HackRF Pro from.

If you still have questions, are seeking advice, or would just like to join in on HackRF Pro and Great Scott Gadgets related discussion, we encourage you to join our Discord server!

Free Stuff - November 2025

2026-02-19T12:00:00

The belated November 2025 recipient for the Great Scott Gadgets Free Stuff Program is Srajan Sonkesriya from India! Srajan is currently working on an open source project where he is turning an Android device (Realme 5 Pro, RMX1971) into a portable RF experimentation and learning platform. His goal is to show that a smartphone, when paired with a properly customized kernel and open-source tools, can function as a compact RF workstation for students and beginners who cannot afford other common equipment. He says that so far, he has successfully built a custom kernel for Android 16 and added multiple patches to support external Wi-Fi adapters, improved USB peripherals, enhanced debugging options, and prepared the system for integration with SDR devices. He is now working on additional wireless-related patches, including research into frame injection support and improving compatibility across various external radios. Once the kernel environment is stable and fully documented, his next project is to build a small, phone-controlled system for satellite signal tracking and visualization. He aims to create Android-friendly scripts, tutorials, and tooling that allow users to receive, demodulate, and interpret low-Earth-orbit satellite signals directly from a mobile device. This will be released publicly so anyone with limited hardware can experiment and learn. Srajan’s ultimate purpose is education-focused and is to create a low-cost, open-source RF learning platform powered by an Android phone, so that more students—especially those without access to laptops—can explore wireless and SDR topics. We have sent Srajan a HackRF One to assist him in his development and are happy to help someone who is focused on education and community impact!

Free Stuff - October 2025

2026-02-19T12:00:00

The belated October 2025 recipient for the Great Scott Gadgets Free Stuff Program is Alex Barnes, who applied on behalf of Amateur Radio and Electronics Society (QUB_ARES) at Queen’s University Belfast! Alex has informed us that they are an academic society primarily focused on running regular educational events around radio and electronics. So far they have run lessons and training for their members to get UK Foundation Amateur Radio licenses, worked with a local Scouts group for Jamborees on the Air, and she ran a series of events last year where she demonstrated using an SDR and a few 433 MHz ASK modules to reverse engineer the protocol used by wireless doorbells. The society has deep roots within the history of Queen’s University Belfast, although for most of the past 25 years it was non-existent! Alex tells us that students restarted the society almost two years ago, and are still trying to acquire equipment for them to use for events. We sent the Amateur Radio and Electronics Society a HackRF One, which they plan on using for future educational events, including more amateur radio license training and demonstrations that will be hands-on and allow participants to go on the air. We are looking forward to seeing what the members of ARES are able to accomplish with their new HackRF One!

Free Stuff - September 2025

2026-02-19T12:00:00

The belated September 2025 recipient for the Great Scott Gadgets Free Stuff Program is Ashen Chathuranga, a university student from Sri Lanka. He is working on a project involving the development of an open source satellite monitoring station and requested a HackRF One to conduct his research. He will also be researching radio wave penetrating materials for his university. Being able to assist students in need of equipment for academic research and goals is one of our primary goals for our Free Stuff Program, so we are happy we were able to help Ashen out!

HackRF Pro Shipping Update

2026-01-16T12:00:00

After additional unexpected delays to our original projected shipping window for HackRF Pro, our staff worked hard over the holidays to ensure that reseller preorders would ship as soon as stock was received into our warehouse inventory. We are excited to announce that as of this week, all prepaid reseller preorders have shipped and are beginning to arrive! More units are in production and expected to arrive and ship in early February.

Here is a list of authorized resellers who are carrying HackRF Pro as of the date of this post:

We ask that members of our community please be patient and courteous with our resellers as they work to begin dispatching orders! HackRF Pro would not be possible without their endless support, and we are so grateful to have such an excellent roster of shops working with us to put open source tools into the hands of innovative people.

Learn More:

Visit the HackRF Pro product page for full specs and reseller links. We also invite you to join the discussion in the #hackrf channel on our Discord server!

HackRF Pro Receive Sensitivity and Noise Figure

2025-12-03T18:00:00

In the HackRF Pro specifications we’ve mentioned improved RF performance compared to HackRF One. Now that we’ve finalized any last tweaks to the RF front-end and production is well underway, we’d like to share some more details about the improvements.

One key metric for radio systems is sensitivity, which measures the minimum signal strength that a receiver can detect. However, for software defined radio hardware, sensitivity is difficult to define in a useful way as it changes depending on the modulation scheme in use and even the software implementation.

Instead we can look at noise figure: this measures the degradation in signal-to-noise ratio caused by components in the RF signal chain, so it gives a good representation of the hardware’s contribution to achievable sensitivity. The higher the noise figure of the hardware, the more noise and/or loss it contributes, so we would like the noise figure to be as low as possible.

We’ve been using noise figure measurements throughout HackRF Pro development to optimize the RF front-end and the tuning algorithm that picks LO/IF frequencies. We do this by using a switchable wide-band noise source that generates a known level of noise (HP 346B) along with SDRAngel’s noise figure measurement plugin.

Below is a comparison between HackRF One and a final prototype of HackRF Pro:

This shows typical expected values, measured from single HackRF One and HackRF Pro prototype units; there may be small changes from unit to unit and also if we make further changes to the tuning algorithm. The measurement is also quite susceptible to external interference, so the result can be affected by ambient RF signals in the lab.

The plot shows a solid improvement across almost the whole tuning range, with significant improvement at higher frequencies. In particular the extra tuning range above 6 GHz is now more useful. The plot is also much smoother, thanks to better PCB layout and signal integrity and an improved tuning algorithm.

I wanted to do some extra testing to demonstrate how this plays out in a real-world example, so I set up a head-to-head comparison between HackRF One and HackRF Pro receiving ADS-B location data from planes. I set both of them up in a window in a fairly challenging location with limited sky view and no view of the horizon, so most signals would be reflected off buildings and be pretty weak. They each used a simple dipole tuned for 1090 MHz attached directly to the HackRF, so no extra amplification or filtering.

The plot below shows maximum observed coverage after collecting data for a few hours, with HackRF One in red and HackRF Pro in blue:

In this test the HackRF Pro generally got around 15 to 50 km extra maximum range, and also received double the number of valid messages.

Then to see how well it could do in good conditions, I took the HackRF Pro up a hill with almost 360° horizon view, and received some positions out to almost 400 km!

I was really impressed to see that sort of reception range with just an antenna directly attached. These ADS-B observations have made it clear that our hard work to reduce HackRF Pro’s noise figure resulted in improved receive sensitivity in the real world, and we’re excited to see what interesting applications people have for it.

How to Apply For the Great Scott Gadgets Free Stuff Program

2025-12-01T12:00:00

Great Scott Gadgets is committed to supporting the open source community. One way we give back to the community is by giving away Free Stuff! If you or your community organization would like Free Stuff from Great Scott Gadgets, please fill out our Free Stuff Application to the best of your ability.

Our team judges applications based on community impact and clarity of project description, so please be detailed. Please know that this program is focused on supporting communities and requires your project be open source. We send hardware out to people looking to spread education, support community projects, or contribute to open source projects or research. We are not interested in sending hardware out to companies or to individuals for strictly personal use at this time.

Still have questions or need some advice? Here’s a basic walkthrough of the application!

Demographics

These questions help us get to know about you or your community organization and the projects you do. Information from this portion of the application is also essential for posts for the Great Scott Gadgets Free Stuff blog posts - we want to make sure all of our information is correct!

Please tell us your:

Full name (and group name if you are applying as a group or organization!)

Email address (so you may be contacted if your application is selected)

Country

Pronouns (she/her, he/him, they/them, etc.) - Please note that failure to answer this question in a respectful manner is grounds for automatic disqualification! If you need help with this question, feel free to ask. Note: if applying for multiple people, it is okay to put they/them to refer to the collective group, or the pronouns of each individual member applying.

Social media accounts where you share your project work, if applicable

Project Details

These questions help us determine the eligibility of your project for our Free Stuff Program. Applications that are accepted are usually as detailed as possible and give us a good idea of how one of our products will be incorporated into a project.

Please tell us:

What Free Stuff would you like to receive? Please note that we typically only send out one device to a recipient, unless otherwise appropriate.

Please describe the project you will be using the requested device for. Please note that applications that are accepted are usually 200+ words, so please be as descriptive as you can! A good start to an application can look like…

”We are a student-run hardware design lab at a university looking to give students access to tools they may not typically be able to afford or find in maker spaces. We offer workshops and have a planned curriculum planned to incorporate a HackRF One into a series of lessons on software-defined radio, wireless security testing, and digital signal analysis.”

”I am a university student seeking a HackRF One to implement into my thesis project where I will be building a digital radio receiver for decoding NOAA weather signals with open source software.”

”I’m an educational content creator looking to create a series of videos covering advanced RF projects that users at home can follow along with, backed up by open source documentation.”

While applications that typically get rejected look like…

”It’s my birthday and I want a Cynthion”

”I think it would be cool to have a HackRF One”

”I want to learn about SDR”

What work have you already completed on your project? (Please include a link to an open source repository if you’ve got one).
Why is the device you requested the right one for the project you are working on?
What open source licensing are you using on your project? Examples of this can include MIT License, GNU Licenses, and Apache License, and more. Reminder that we typically require candidates’ projects to be open source.

Please do not submit any content that has been created or altered by a large language model or similar technology, including but not limited to ChatGPT, CoPilot, and Gemini.

Please note that Free Stuff Program applications remain valid through each calendar year. If you are not selected by the end of the year, your application will be considered void, but we encourage you to apply again when the next round of applications opens! If you have any questions about the application process, the status of your application, or the Free Stuff Program in general, you can email freestuff@greatscottgadgets for assistance.

Receiving WWVB with HackRF Pro

2025-10-31T18:00:00

We advertise 100 kHz as the lower edge of HackRF Pro’s operating frequency range, but that isn’t a hard limit. While working on the design, I realized that it should work fairly well to pick up longwave time signals such as WWVB, broadcast at 60 kHz from Colorado, USA.

WWVB provides a stable frequency reference and time code. If you have a radio-controlled clock in North America, it probably uses the signal from WWVB to maintain the correct time. WWVB can also be used to discipline a laboratory frequency standard, eliminating the need for a local atomic clock in many cases.

Why use WWVB?

Nearly every electronic device contains some sort of oscillator or clock. HackRF Pro, for example, contains a temperature-compensated crystal oscillator (TCXO) which is better than the crystal oscillator (XO) used in HackRF One. Having a better internal clock means that radio frequencies received or transmitted by the device are more accurate. If I receive a radio signal at 1 GHz with HackRF One, I can’t be sure if the signal over the air is at exactly 1 GHz. The received frequency as detected by HackRF One might be 10 or 20 kHz off. With HackRF Pro the frequency uncertainty is an order of magnitude smaller, thanks to the built-in TCXO. I would be confident that any inaccuracy at 1 GHz is no more than about 1 or 2 kHz, even without performing any calibration.

I need to use an even better clock in my lab to be certain that the oscillators in our products perform as expected. I could use a HackRF Pro to measure the frequency error of a HackRF One, but how do I know I can trust the HackRF Pro? I would need a more trustworthy frequency reference such as an atomic clock. A good alternative to an expensive atomic clock would be an oven-controlled crystal oscillator (OCXO) that has been recently calibrated or that is disciplined by a remote atomic clock.

One such remote frequency reference is WWVB which has several orders of magnitude less frequency uncertainty than the TCXO in HackRF Pro. WWVB also provides a digital time code indicating the time of day.

Why not a GPSDO?

Folks like me who need a lab frequency standard typically turn to a GPS disciplined oscillator (GPSDO). I could purchase an off-the-shelf GPSDO that disciplines an internal OCXO with a signal received from GPS (or other GNSS) satellites. Such a device would cost a few hundred dollars, much less than the thousands of dollars required to buy a small atomic clock.

Before GPSDOs became available, some test equipment manufacturers sold WWVB disciplined oscillators, but these products are no longer made. They had already become unpopular before the broadcast format of WWVB was changed in 2012 with the introduction of phase modulation that broke compatibility with commercial oscillators. There is no reason that a new WWVB disciplined oscillator could not be made. In fact, many hobbyists have made their own or have modified older oscillators to make them compatible with the new phase modulation.

I like the idea of having my own WWVB disciplined oscillator, partly because a GPS receiver needs an active antenna placed somewhere with a view of the sky whereas a WWVB receiver can be located indoors. I like that a WWVB receiver can have a relatively simple design and does not need to constantly track multiple moving satellites. I like that WWVB is stable and will not be adversely affected by Kessler syndrome.

I like that a WWVB receiver implementation with HackRF Pro can be used to directly measure the frequency error of the HackRF Pro itself by simply measuring how far off from 60 kHz WWVB appears to be. I don’t even need to build a whole WWVB disciplined oscillator to do this. (In theory I could do the same thing with GPS, but it would require significantly more complex software.)

Most of all, I think that receiving WWVB is a fun project!

An active antenna for 60 kHz

Radio antennas are generally sized in proportion to wavelength, and the wavelength at 60 kHz is very long, about 5000 m. A vertically polarized quarter-wave monopole antenna for 60 kHz would be the tallest structure in the world! To avoid such an impractical construction, the WWVB transmit antenna has a more complex design. Although small compared to the wavelength, the broadcast antenna is comprised of hundreds of meters of cable and multiple towers.

WWVB receivers use small loop antennas which detect changes in the magnetic field. Several amateur radio operators have constructed air core loop antennas for WWVB with diameters of one to two meters while radio-controlled clocks use much smaller ferrite core (“loopstick”) antennas. I thought it would be fun to build a small active loopstick antenna that is compatible with HackRF Pro.

For my initial experiment, I pieced together a few RF amplifier and filter test PCBs and connected them to a loopstick antenna pulled from an AM radio kit. I used a VNA to tune the antenna for 60 kHz with a parallel capacitor. With two amplifier ICs (which I had previously tested for the URTI project) and a low-pass filter, I was barely able to detect a faint signal at 60 kHz one afternoon using a HackRF Pro. Later that evening the signal was stronger and easily identifiable as WWVB. I live in Ontario, Canada, over a thousand miles away from WWVB, and I think it’s pretty nifty that I could pick up the signal from such a long distance on my first attempt!

Based on this success, I designed Teewee, an active loopstick antenna named for (the popular name of) the similarly shaped Tetris block. Teewee consists of a small PCB that performs amplification and filtering, a hand-wound ferrite core, and a 3D-printed enclosure. While my initial experiment required an external power supply, Teewee is powered by HackRF Pro’s built-in bias tee.

Inspired by an older design, I used an instrumentation amplifier for Teewee’s first stage. The purpose of this is to isolate the magnetic field (which is seen by the amplifier as a differential signal) from the electric field (which is seen as a common-mode signal). Instrumentation amplifiers have high common-mode rejection, eliminating much of the electric field noise that likely originates locally.

My first test with Teewee was disappointing. I detected WWVB not at all, instead picking up pulses of broadband noise. After a frustrating couple of days, I decided to reproduce my original setup and found that it had the same poor result! The reason was that I had recently rearranged my lab and had placed my PC tower on my desktop, close to the antenna test area. While Teewee is designed to reject electric field interference, it is highly sensitive to magnetic interference, something my PC evidently produces quite a bit of. Fortunately, I was able to eliminate this near-field interference by moving the antenna just half a meter farther away from the PC.

After solving the near-field problem, I found that Teewee actually performed quite well. While my original setup was useful only during periods of favorable ionospheric propagation at night, I was able to pick up WWVB at any time of day with Teewee.

Observing the WWVB signal

A distinguishing characteristic of WWVB is that the very precise carrier frequency of 60 kHz turns off and back on once per second with varying pulse duration. With most receivers it looks like on-off keying (OOK), but it is actually amplitude-shift keying (ASK) where the “off” periods are 17 dB lower power than the “on” periods. At times when propagation is good, I can barely detect the signal during the “off” periods with Teewee.

Pulse width modulation (PWM) carries time of day and other status information in 60-second data frames. The falling edge of each pulse occurs at the start of each second. Once every ten seconds there is an extra-long “off” period. This pattern makes it easy to identify the signal when there is sufficient signal-to-noise ratio to observe the modulation.

Since 2012 the phase of each pulse carries a second data stream. The last time I experimented with WWVB was prior to 2012, so I hadn’t observed the phase modulation before. The phase modulation is binary phase-shift keying (BPSK) at one bit per second with the phase transition happening 0.1 seconds into the “off” period. Using a derived phase plot in inspectrum I was able to see the phase abruptly change from one pulse to the next.

In theory, the BPSK modulation makes it possible to implement a receiver capable of detecting a weaker signal than can be achieved with an ASK receiver, particularly once per hour when the BPSK stream carries an extended symbol sequence that lasts 6 minutes and includes a fixed 106-bit synchronization word. I think it would be interesting to try detecting this “medium mode” from farther away, maybe even on another continent.

When using WWVB as a frequency reference, the digital modulation can be ignored except that the detector (software, in my case) must be designed to tolerate BPSK.

Measuring Doppler shift with WWVB

Shortly after getting Teewee working, I traveled to British Columbia, so I decided to try picking up WWVB on my flight across Canada, hoping that I would be able to see the Doppler shift from the motion of the aircraft relative to the transmitter. I found that I was unable to detect the signal with the antenna at my seat in the aircraft but that I could pick it up by placing Teewee in a window, connected to a HackRF Pro by an SMA cable. I captured the signal from WWVB for a full hour while the aircraft headed west, starting from a point roughly north of the transmitter.

I analyzed the hour-long capture and found that the Doppler shift was, in fact, evident when plotting the received WWVB frequency over time. About halfway through the capture, the aircraft changed course, and this caused an abrupt change of frequency that clearly confirmed that I really was seeing the Doppler effect.

As further confirmation, I later downloaded ADSB flight data and used it to plot the expected Doppler shift. This correlated quite well with the WWVB observations. Apart from some blips due to interference, the primary discrepancy between the expected and observed Doppler shift was an offset of 15 mHz due to the HackRF Pro TCXO being 250 ppb slow. (This TCXO was better than average. I typically see frequency error of approximately 1 ppm.)

I had hoped to acquire an even longer capture on the return flight to Ontario, but there was too much interference, perhaps from avionics or from a jet engine. This was on a smaller aircraft, and I was seated at the front edge of the wing, adjacent to an engine.

Try it yourself

I’ve published the Teewee design for anyone who would like to build their own. Teewee is intended for use with HackRF Pro, but I’ve also had some limited success with HackRF One even though it has significantly worse 60 kHz performance than HackRF Pro.

HackRF Pro Production Timeline Update

2025-10-24T12:00:00

Since our previous timeline update, we have encountered additional unexpected delays in our production progress. These delays are the result of a necessary hardware revision to account for MacOS users. During late stage testing, our team encountered issues with USB signaling on Mac devices, and while able to find potential workarounds, agreed that the next step would be to modify the PCB design to address this issue. HackRF Pro will ship as r1.2.1, our final revision. We decided that this revision was imperative to ensure that all users could have an equal user experience with HackRF Pro, regardless of operating system.

As a result, our new projected shipping window is December 2025.

We appreciate the patience and support we have received during this exciting transition period for Great Scott Gadgets. While another board revision was not in our original plans, we are confident in our decision to prioritize quality and user experience over meeting our original deadline.

Learn More:

Visit the HackRF Pro product page for full specs and reseller pre-order links. The open source design, migration guide, and user documentation will be published prior to initial shipment. We invite you to join the discussion in the #hackrf channel on our Discord server!

Free Stuff - July 2025

2025-10-03T12:00:00

The belated July 2025 recipient for the Great Scott Gadgets Free Stuff Program is Murat Sever, a professor from Turkey who teaches at TOBB ETU University and recently ran a workshop titled “Simple Replay Attack Demo with GNU Radio.” In this workshop, Murat utilized several open-source software and hardware tools to demonstrate how to receive and transmit RF signals. Workshop participants then used SDR and GNU Radio to perform replay attacks with the captured radio signals. We sent a handful of HackRF Ones to Murat for participants to learn and experiment with in this workshop. He has also informed us that the HackRF Ones will be put to use in the course he is teaching this fall on SDR applications! We are glad that we could continue to support Murat’s efforts to educate others about the capabilities of software defined radio and wish him and his students best of luck with their fall term!

Free Stuff - June 2025

2025-10-02T12:00:00

The belated June 2025 recipient for the Great Scott Gadgets Free Stuff Program is Joe Caton from the United States! Joe has requested a HackRF One for his senior project. He has the opportunity to work with a local wildlife preserve and assist them in an ongoing project to track and study the behavior of the large population of eastern box turtles nearby. Joe will be aiding the nature center in developing quality, low cost alternatives to their current tracking technology. He plans to refine their current VFH tracking modules and implement HackRF One into a more compact system that will enable image recognition capability in the field to identify specific turtles. He hopes that this could lead to similar systems being replicated for other wildlife preserves and contribute to an open source repository so foundations with less funding can have access to accurate and successful DIY monitoring systems. We are looking forward to hearing about the progress and outcome of Joe’s project and excited to assist in this unique application of our hardware!

Free Stuff - May 2025

2025-10-01T12:00:00

The belated May 2025 recipient for the Great Scott Gadgets Free Stuff Program is Nagamani C Gunjal, a university student who has requested a HackRF One for an academic project that involves research and demonstration of real-world vulnerabilities in consumer and commercial drones by analyzing and manipulating radio communication protocols. Her focus is on ethical hacking and the security testing of drones that operate using RF signals, specifically targeting control signals transmitted between the radio transmitter and onboard radio receiver module of the drone. This project is part of a broader study on UAV (Unmanned Aerial Vehicle) security with an ultimate goal of proposing and implementing improved countermeasures for secure UAV communication. She has told us that the requested device will be essential for capturing, decoding, and replaying drone communication signals in controlled environments for testing purposes!

Free Stuff - April 2025

2025-09-30T12:00:00

The belated April 2025 recipient for the Great Scott Gadgets Free Stuff Program is Ashen Chathuranga from Sri Lanka! Ashen is a university student who plans to use the HackRF One we are sending him for multiple academic projects, including an open source satellite monitoring station and researching radio wave penetration. We are glad we could provide Ashen with equipment to further his education and support his academic journey!

Free Stuff - March 2025

2025-09-29T12:00:00

The belated March 2025 recipient for the Great Scott Gadgets Free Stuff Program is Mrinal Kumar from India! Mrinal is currently running a small, free cybersecurity learning group for young adults aged 18-21 who come from financially limited backgrounds. Currently, there are about 15 students who actively participate in regular meetings to study the fundamentals of cybersecurity, ethical hacking, and responsible digital security practices.

We will be sending Mrinal and his students a HackRF One so he can introduce them to software-based cybersecurity and the world of wireless and RF security. He tells us that they will explore signals, learn about vulnerabilities in everyday wireless systems, and will safely demonstrate examples of real world attack and defense scenarios. His vision of providing accessible, hands-on learning for students who would not otherwise have an opportunity to dive into the world of open source hardware and software defined radio aligns pretty perfectly with ours! We are excited to see what Mrinal and his students accomplish and discover with their new equipment.

HackRF Pro Production Timeline Update

2025-09-05T12:00:00

Since our June announcement, we’ve made substantial progress toward the HackRF Pro launch, and we’d like to share an update on the project timeline.

Progress So Far:

All of the production parts that we expected to have a long lead time (which were ordered months in advance of our initial announcement in June) have been delivered to our contract manufacturer.
We completed two additional hardware revisions to improve RF performance. We are now on HackRF Pro r1.1.1, which we anticipate will be the final revision. If there are further changes, they will be minor and will not include a PCB layout change.
We delivered production files to our manufacturer in mid-July 2025.
All other parts for production have been purchased.
Sample PCBs have been ordered for RoHS and internal testing and are expected to be assembled and shipped by next week.
Tooling for the final enclosure is in progress.
Packaging design should be finalized by the end of the month.

Updated Timeline:

One critical component, the crystal oscillator, came with an unexpectedly long lead time. There is no drop-in alternative with a shorter lead time. As a result, SMT is delayed, and we’ve adjusted the expected date of first shipments of HackRF Pro to our resellers from September 2025 to the end of October 2025.

We appreciate our community’s patience and support as we work to ensure HackRF Pro meets the highest performance standards possible before shipment. With production underway and all parts secured, we are confident that the updated end-of-October shipping target is achievable!

Learn More:

HackRF Pro Q+A

2025-06-27T10:23:00

This post is a collection of some of the first questions asked by the community about HackRF Pro shortly after we announced it. Questions were asked by folks across our various social media accounts and in our Discord server. The answers given here are expanded versions of how the folks on our team responded to the public question we observed.

Why is it called HackRF Pro and not HackRF Two?

We felt that “Pro” expressed the idea that this is a refinement of the HackRF One design and that “Two” would more likely be interpreted as a revolutionary design. Our goal was to make a better HackRF One, not to make something as revolutionary as HackRF One was when it was new. We did consider “10”, “360”, and “Tau”.

What is the baseband bandwidth of HackRF Pro?

In normal operation, HackRF Pro supports up to 20 Msps with 8-bit I and Q samples over USB, just like HackRF One. Internally, HackRF Pro uses a sample rate of up to 40 Msps with decimation and interpolation performed in an FPGA. At lower USB sample rates HackRF Pro supports an extended-precision mode with 16-bit samples and an effective number of bits (ENOB) of 9 to 11, depending on the sample rate. We’re also developing a half-precision mode that uses 4-bit samples at up to 40 Msps over USB.

Some tools allow tuning up to 7.25 GHz with HackRF One. Is the limit of 7.1 GHz on HackRF Pro correct or just “suggested”?

7.1 GHz is the highest tuning frequency that should work reliably with HackRF Pro. You can try tuning up to 7.25 GHz, but it may fail (as may HackRF One). Unlike HackRF One, the performance of HackRF Pro up to 7 GHz is pretty good. HackRF One is quite lossy above 6.1 or 6.2 GHz.

Will there be different host tools and libraries for interacting with HackRF One vs. HackRF Pro?

We’re adding features to libhackrf and hackrf-tools. In the future, there may be some software specially written for HackRF Pro, but we anticipate that most software will continue to support any HackRF (including Pro, One, Jawbreaker, and rad1o). Backward compatibility was our primary goal for HackRF Pro. We tried hard to find ways to enhance the HackRF One design without radical changes to the architecture that would make compatibility difficult.

Will the hardware design be published online before this starts shipping?

Yes, like all of our electronic designs, we will publish the entire hardware design under an open source license online before shipping HackRF Pro. Our mission at Great Scott Gadgets is to put open source tools into the hands of innovative people.

Does that mean no more cracking the case open to set up triggers?

That’s right! Both CLKIN and CLKOUT can be configured to connect internally to either the trigger input or trigger output signal.

Is HackRF Pro compatible with Portapack H4M ?

Yes, we’ve tested with H4M and a few other PortaPacks, including the original PortaPack H1 from ShareBrained Technology. To the best of our knowledge, HackRF Pro is compatible with all PortaPacks; however, we can’t guarantee this.

Will Opera Cake be improved so that it can take full advantage of HackRF Pro’s frequency range?

A new revision of Opera Cake is likely, but we are not working on it yet.

How is RF port protection enhanced on HackRF Pro?

HackRF Pro has the same reverse current protection diode on the RF port bias tee that is present on newer revisions of HackRF One. This has been quite effective in improving amplifier robustness in HackRF One r9 and r10. In addition to over-voltage protection provided by the diode, the bias tee on HackRF Pro features over-current protection. HackRF Pro has new amplifiers, replacing the obsolete part on HackRF One. ESD protection has been enhanced on HackRF Pro, and the RF port is also protected from high RF power by a PIN-Schottky limiter.

Will HackRF Pro be suitable for classroom use?

Yes. We even added a little feature with classroom use in mind: It is possible to hardware-disable transmit mode by cutting one trace on the PCB.

Do you have any projects in mind for the extended frequency range of HackRF Pro?

We’re excited to try HackRF Pro with new very low power (VLP) devices that operate in the 6 GHz band. We’ve already had success receiving WWVB at 60 kHz.

Meet HackRF Pro

2025-06-26T16:36:00

We’re thrilled to announce HackRF Pro, the newest addition to the Great Scott Gadgets family of Software Defined Radio (SDR) platforms!

Building on the legacy of HackRF One, HackRF Pro is an SDR peripheral that enables transmission or reception of radio signals from 100 kHz to 6 GHz. Like its predecessor, HackRF Pro is open source hardware and designed for versatility, whether you’re developing wireless tech, researching the security of wireless devices, tinkering as a hobbyist, learning or teaching about the RF spectrum, or building advanced custom firmware.

What Makes HackRF Pro Different?

HackRF Pro takes everything users love about HackRF One and improves upon it with many new enhancements. Here’s what you can expect:

Wider frequency range (100 kHz – 6 GHz operating; tunable from 0 Hz to 7.1 GHz)
Improved RF performance with flatter frequency response
USB Type-C connector
Built-in TCXO for superior timing stability
Upgraded logic from CPLD to a power-efficient FPGA
DC spike eliminated
Extended precision mode with 16-bit samples for low sample rates (ENOB 9–11 typical)
Half-precision mode with 4-bit samples at up to 40 Msps
More RAM and flash memory for custom firmware
Installed shielding for better RF isolation
Trigger input/output via clock connectors
Future-proofed PCB design with space for add-ons
Improved power management
Enhanced RF port protection
Facility to hardware-disable transmit mode

And yes, it’s still:

Compatible with GNU Radio, SDR#, and many other tools
Fully open source
Designed to work seamlessly with accessories like Opera Cake and most PortaPacks and third-party enclosures

Backward Compatible and Forward Thinking

HackRF Pro maintains backward compatibility with HackRF One—your existing software stack will work right out of the box. But we’re not stopping there. We’ll also be releasing a migration guide for developers who want to unlock HackRF Pro’s enhanced capabilities.

Preorder Now — Shipping This September

The HackRF Pro is now available for pre-order through our authorized resellers. Production begins in July 2025, with initial shipments slated for September 2025.

Please note: HackRF Pro comes in a sleek injection-molded plastic enclosure. USB cable and antenna are not included, but we recommend ANT500 as a great starter antenna.

Learn More

Visit the HackRF Pro product page for full specs and reseller pre-order links. The open source design, migration guide, and user documentation will be published prior to the first shipment. We invite you to join the discussion in the #hackrf channel on our Discord server!

Free Stuff - February 2025

2025-04-26T12:00:00

The belated February 2025 recipient for the Great Scott Gadgets Free Stuff Program is Cles Facil, one of the oldest French student astronautics clubs, operating at INSA Lyon in France. They are currently working on a project to track rockets in flight using multi-lateration. They plan to use HackRF One on the rocket to transmit signals in the 868 MHz ISM band to multiple ground stations with RTL-SDR receivers and measure velocity using the Doppler effect. The students of Cles Facil will be participating in this year’s C’Space, a national event organized by CNES where students launch experimental rockets.

Cles Facil has finished the design of the rocket’s body and has begun the manufacturing process. Currently, they are designing PCBs in Altium and experimenting with GNU Radio to develop their communication systems. They have told us that HackRF One is the right device for their project because it offers the flexibility and performance they will need for transmitting signals in the 868 MHz ISM band, which is essential for their multi-lateration tracking system. Its ability to operate as a wideband SDR will allow them to experiment with various communication protocols and adapt it to their specific needs, such as Doppler shift measurement for velocity tracking. Additionally, its open source nature integrates well with their existing work in GNU Radio, making it an ideal fit for the rocket’s communication system.

This application for the Free Stuff program stood out to the Great Scott Gadgets team due to Cles Facil’s demonstration of knowledge and in-depth explanation of how HackRF One will benefit their project’s development. We are excited to see the finished result of their project and are wishing them luck at C’Space!

Free Stuff - January 2025

2025-04-25T12:00:00

The belated January 2025 recipient for the Great Scott Gadgets Free Stuff Program is Tobias Trauth on behalf of H.O.M.E. makerspace, which is part of Ravensburg-Weingarten University of Applied Sciences. Tobias has informed us that members of H.O.M.E. are interested in amateur radio (called Amateurfunk in Germany) and have access to older equipment, but are looking to upgrade to more modern gear.

The folks at H.O.M.E. will be creating a portable setup that can communicate over QO-100, a well-known geostationary satellite, consisting of HackRF One, a 5W PA, and a 200Ah LiFePo4 Battery in a custom housing that will contain potential laptop and antenna mounts. In addition, they currently have a parabolic 2.4GHz dish for uplink and are looking into downlink options. Tobias says that the HackRF One will also be their tool to show people that there are more ways of communication that can be accessed digitally and are independent of the internet and mobile phones.

H.O.M.E. hosts all kinds of events that encourage people to bring their project ideas to life. One of their main focuses is to educate people so they are able to become technologically self-sufficient. Tobias also tells us that an important part of their work is the attempt to keep their costs close to zero, so members can explore and create without worrying about their wallet. H.O.M.E. plans on eventually attending schools and universities and bringing amateur radio to the people in their community, rather than luring them into their “dusty shack.”

We are delighted to be able to provide a HackRF One to H.O.M.E. Makerspace so their community can offer workshops and educational experiences for members of their community. We wish them the best of luck and hope they have fun!

Free Stuff - December 2024

2025-04-24T12:00:00

The belated December 2024 recipient for the Great Scott Gadgets Free Stuff Program is Adrian Lam from Victoria, Australia! Adrian is a high school STEM teacher at a small, independent school and wants to create a Wireless Exploration Lab for his students, aimed at teaching the fundamentals of wireless communication systems.

The Wireless Exploration Lab will introduce students aged 14-18 to concepts such as radio wave propagation, spectrum analysis, and digital modulation, linking these concepts to the science/technology curriculum and real-world applications like IoT, mobile networks, and satellite communications. Once the lab is ready, students will lead a project of designing and deploying a school-wide weather data station network using low-power wireless sensors. They will use HackRF One to visualize and analyze the wireless signals sent by these sensors, gaining hands-on experience with software-defined radio. The station will record weather metrics (temperature, humidity, and pressure), transmitting data via RF signals for display on a central dashboard. The program is designed to encourage awareness and an appreciation of sustainability practices in addition to STEM teaching, and include students from other local schools, as well as members from the community.

Adrian says that his students are already familiar with how to use a Raspberry Pi for data collection, and they have developed the initial framework for their weather station network, including the construction of basic sensor modules and a prototype dashboard for displaying data. HackRF One is ideal for the Wireless Exploration Lab because of its versatility, ease of use, and compatibility with educational software like GNU Radio. Its wide frequency range (1 MHz to 6 GHz) will allow students to explore a broad spectrum of signals, from the sensors’ low-power transmissions to real-world signals like Wi-Fi or Bluetooth. As a half-duplex transceiver, it can not only receive signals for analysis but also transmit, enabling students to simulate wireless protocols and test their designs. HackRF One’s programmability will allow them to introduce advanced topics such as modulation techniques and spectrum efficiency, fostering a deeper understanding of SDR technology.

We will be sending Adrian a HackRF One to support his students in their ongoing development of the Wireless Exploration Lab and weather monitoring project. Thank you Adrian for introducing your students to the wonderful world of open source hardware and wireless communication! We are looking forward to seeing what you all accomplish together.

Free Stuff - November 2024

2025-04-23T12:00:00

The belated November 2024 recipients for the Great Scott Gadgets Free Stuff Program are the folks at iMagineLab makerspace in Antwerp, Belgium! iMagineLab is home to a community of students and tech enthusiasts alike that gather weekly to collaborate on and share knowledge for open source projects.

Thomas Janssen from iMagineLab has informed us of the makerspace’s upcoming project to build a digital radio receiver for receiving and decoding NOAA weather signals using open source software. Their goal is to then visualize NOAA weather images and collect and display data to create a weather monitoring station based on RF signals!

Thomas has also mentioned that iMagineLab hosts and participates in workshops and hackathons, covering a variety of topics such as software-defined radio (SDR), IoT, and embedded systems. He says that the availability of HackRF devices would significantly enhance their group’s ability to offer hands-on learning experiences in these areas. Additionally, having HackRF devices at the makerspace will allow members to conduct practical experiments and contribute to open source SDR projects, such as GNU Radio.

This application for the Free Stuff program stood out to the team here at Great Scott Gadgets because of its focus on community impact and education. The HackRF One will not only be used to develop a weather monitoring station, but find life after the project’s completion and be used in upcoming educational curriculum and open source contributions. We are excited to see what the iMagineLab team accomplishes with their new HackRF One!

Free Stuff - October 2024

2025-04-22T12:00:00

The belated October 2024 recipient for the Great Scott Gadgets Free Stuff Program is Dustin Chambliss, who teaches at Pearl River Community College in Mississippi! Dustin currently teaches a 2 year electronics program and aims to revive an older and outdated communication course to focus on more modern technology. By obtaining a HackRF One, Dustin will be able to teach students about wireless communication including Bluetooth, Wi-Fi, and cellular, and provide hardware for the updated curriculum. We are excited to be providing Dustin and his students with a HackRF One to continue their educational journeys and stay up to date with the ins and outs of modern wireless communication!

Comments to USTR Opposing Tariffs and Tariff Increases

2025-03-11T10:45:00

The United States Trade Representative invited comments from the public this past month to assist them in making recommendations about how to address so-called “unfair trade practices by other countries” and “non-reciprocal trade relationships”. This is the public comment I left today on the USTR docket. I have also submitted similar comments to my senators and representative in Congress.

“I am deeply alarmed by the Trump administration’s decision last week to impose tariffs on Canadian and Mexican goods, as well as further increase tariffs on imports from China. As the CEO of Great Scott Gadgets, a small Colorado-based business that designs, manufactures, and distributes open-source computer hardware to domestic and international resellers, I am directly impacted by these policies. The total tariff on the goods we import from China has now skyrocketed to 45%, placing an unsustainable burden on our company.

Our business relies on a stable global supply chain, free trade, and strong relationships with resellers and suppliers worldwide—relationships that have taken over a decade to build. The imposition of these tariffs jeopardizes our company as well as countless other US businesses that depend on international trade. Tariffs will not only damage the U.S. economy but have already deeply strained our relationships with our closest allies and trading partners.

The reality is that technology companies like ours depend on China’s well-established supply chain, advanced manufacturing infrastructure, and specialized technical expertise, resources that are in critically short supply in the U.S. The Section 301 tariffs imposed in 2018 have already harmed our business, yet they did nothing to create viable alternatives. Raising these tariffs further will not miraculously generate the resources needed to shift manufacturing away from China; it will only worsen the damage.

The administration attempts to justify more tariffs on Chinese goods by pointing out the U.S.-China trade deficit, but this deficit is not China’s fault—it is the result of decades of inadequate U.S. investment in technical education, supply chain infrastructure, and domestic manufacturing capacity. If the U.S. wants to compete, we are going to have to commit to long-term, strategic investments in these areas, as China’s government has been doing for a generation. The CHIPS Act was a step in the right direction, but its benefits will take many more years to materialize. In the meantime, businesses like ours are being pushed to the brink.”

Emulating a PS5 Controller with Cynthion

2025-02-07T10:41:00

We’ve recently published the second video in our Cynthion training series, so if you want to go deeper into exploring and experimenting with USB, this is for you. In this video, Martin explains the basics and evolution of Facedancer and demonstrates how to use Cynthion and Facedancer to emulate a PS5 controller. If you haven’t already, check out the first video- Sniffing PS5 Controller Packets with Cynthion.

Free Stuff - September 2024

2024-12-22T12:00:00

The belated September 2024 recipient for the Great Scott Gadgets Free Stuff Program is Allen Paschel of Orlando, Florida in the United States. Allen is the president of The Maker Effect Foundation which exists to inspire everyone to create! The Maker Effect Foundation is a non-profit organization that runs a maker space and teaches classes at schools, libraries, and events. The maker space has CNC machines, laser etcher/cutters, 3D Printers, vacuum forming equipment, welding tools, electronic tools, and other arts tools. Soon they will be able to add software-defined radio to that list of tools as we are sending them a HackRF One! Once received, The Maker Effect Foundation will use their HackRF One to develop interest in software-defined radio in their community.

Free Stuff - August 2024

2024-12-21T12:00:00

The belated August 2024 recipient for the Great Scott Gadgets Free Stuff Program is Murat Sever! Murat teaches a Communication Systems Laboratory course at TOBB ETU University, Ankara, Turkey. In his labs, Murat uses two HackRFs to transmit signals of interest, which students receive via RTL-SDRs. Murat has requested an Opera Cake so his students can study Pseudo Doppler direction finding and to teach students about antenna switching and spectrum monitoring. For more information about Murat’s course, his and his students’ research projects, and their outreach programs, please check out their website (https://ele361l.github.io/).

This application for the Free Stuff program stood out to the team here at Great Scott Gadgets because Murat demonstrated his knowledge of RF and digital signal processing in his application. We know that he’ll be able to make excellent use of the hardware that we send him. We look forward to getting updates from Murat soon!

Free Stuff - July 2024

2024-12-20T12:00:00

The belated July 2024 recipient for the Great Scott Gadgets Free Stuff Program is Scott Carter from Ontario, Canada! Scott operates a SETI station that uses a radio telescope he built using software defined radio. He says the radio telescope has been in operation for six and a half years, and it needs a receiver upgrade to allow scanning of frequencies above 2 GHz. We are sending Scott a HackRF One so he can make his radio telescope upgrade! Scott’s long-term goal is to make his SETI station accessible remotely for educational purposes so more folks can learn about radio astronomy.

One story Scott shares with us about his SETI station is that he helped two young astronomy students in the Philippines do drift scans of the sun using his system, which he had configured for 1420 MHz. At the time, the telescope was remotely accessible via a web page and command line tools, which worked pretty well, although it was limited to changes in elevation only. Since that experience, Scott has begun modifications for azimuth control, and he will be upgrading to a 10-foot dish. We are also happy to see that the software he uses for digital signal processing is being rewritten and will be available as open source.

This application for the Free Stuff program stood out to the team here at Great Scott Gadgets because it focuses on radio astronomy, which we’d like to see HackRF One be used for more often. We also really appreciate the work Scott is doing to support astronomy fans from all over the world. Free Stuff applications like this that describe specific projects in detail really stand out. We look forward to getting updates from Scott soon!

Free Stuff - June 2024

2024-12-19T12:00:00

The belated June 2024 recipient for the Great Scott Gadgets Free Stuff Program is Evan Metzinger. Evan is the president of the Cybersecurity club at Mt. San Antonio college in Walnut, California in the US. We will be sending Evan a HackRF One so he and his club can get some hands on experience with signals processing and participate in wireless capture the flag competitions.

Free Stuff - May 2024

2024-12-18T12:00:00

The belated May 2024 Free Stuff recipient for the Great Scott Gadgets Free Stuff Program is Anik Mahanta from India! Anik is a student who is part of the CyRaksha Cybersecurity Club of Kolkata. CyRaksha is a free-to-join club that hosts their meetups both in-person and online. They will be using the HackRF One we are sending them to create CTF challenges, host informal meetups about RF technologies, and to create open access materials on how to use HackRF One safely while respecting Indian law.

Support Our Work at Great Scott Gadgets

2024-12-02T08:00:00

Like every open source company, Great Scott Gadgets thrives with support from you, our community. The most direct way to support us is to buy our hardware, but for folks who already have our hardware, are more interested in our software, or just want to see us grow, we have a few other options. For example, we appreciate contributions to our GitHub repositories, documentation edits, and hearing your use cases and feedback for our products and projects. If you want to know other ways you can get involved, check out our “Support our Work” page.

Free Stuff - April 2024

2024-11-28T12:00:00

The belated April 2024 Free Stuff recipient for the Great Scott Gadgets Free Stuff Program is Necati Sari! Necati is a radio amateur who is looking to build a single board computer (SBC) with HackRF One. Necati is developing this SBC to help support his local amateur radio community, TRAC Kadikoy in Turkey, in bringing in new members and to make software-defined radio more accessible to folks that are just starting in this discipline.

This application for the Free Stuff program stood out to the team here at Great Scott Gadgets because it focuses on community support and it proposes a project that we would like to see become reality. Free Stuff applications that describe specific projects in detail really stand out. We look forward to getting updates from Necati soon!

Sniffing PS5 Controller Packets with Cynthion

2024-11-27T08:00:00

In our latest training video Martin uses Cynthion to sniff PS5 controller packets. The video guides you through how to set up Cynthion, how to use Packetry, and what PS5 controller packets look like. If you are just getting started with Cynthion or learning about USB, we suggest checking out this video.

Free Stuff - March 2024

2024-11-26T12:00:00

The belated March 2024 Free Stuff recipient for the Great Scott Gadgets Free Stuff Program is Benjamin Pieres! Benjamin is a newly licensed amateur radio operator who is excited to contribute to the amateur radio community and share his passion for radio communication through workshops and innovative experiments.

One of the workshops Benjamin envisions hosting is focused on introducing basic radio communication principles to beginners. Participants will learn about radio wave propagation, antenna design, and the fundamentals of operating amateur radio equipment. Additionally, Benjamin plans to organize workshops on emergency communication preparedness, where attendees will learn how to establish communication networks during disasters or emergencies. The workshops will be held at Radio Club Bariloche (LU1VZ), located in the city of Bariloche, in the heart of the Argentinean Andes mountains. Benjamin says Bariloche is renowned for its vibrant amateur radio community and that it is home to one of the largest concentrations of ham radio repeaters in Argentina.

Benjamin will also be using the HackRF One we are sending him to explore the potential of low-power, long-distance communication using digital modes such as FT8. By experimenting with different antenna configurations and propagation techniques, Benjamin aims to demonstrate how amateur radio operators can establish reliable communication links over significant distances using minimal power. The experiment will involve setting up portable radio stations in remote locations and attempting to make contacts with stations located hundreds or thousands of miles away. He will document the experiment thoroughly, including equipment setup, operating procedures, and results analysis. The findings will be shared through articles, videos, and presentations to inspire other radio enthusiasts to engage in similar experiments.

This application for the Free Stuff program stood out to the team here at Great Scott Gadgets due to its breadth, description of topics covered in proposed workshops, focus on community support and involvement, and clear description of what the HackRF One we are sending him will be used for. We are excited to see what Benjamin achieves!

Reverse-engineering a VNA ECal Interface With Cynthion

2024-11-13T08:00:00

Recently I’ve been working on a little reverse-engineering project, hoping to make some of my electronics test equipment more convenient to use.

Often when doing reverse-engineering, a general strategy that I follow is to make (informed) guesses about how something might work and then I go looking for ways to prove that right or wrong. In this project, Cynthion was really useful for that process as I could use it to emulate part of the target system, so that I could quickly and easily test out theories about the protocol.

This write-up goes over some of the progress I’ve made so far and hopefully it will provide some helpful techniques you can use in your own projects!

Background

In my work and hobby projects, I’m often using a Vector Network Analyzer (VNA) to measure RF components. Ideally, on each power-up and whenever the measurement parameters are changed, the VNA should be calibrated by connecting and measuring a set of four standards in turn on each of the two measurement ports. This can get a little tedious if you need to re-calibrate often, so an alternative option is to use an Electronic Calibration module (ECal) which only requires one connection per port and then has internal switches to select between the different standards automatically. ECal modules are available for my VNA (an Agilent E8803A), but they’re rare and expensive, so I’d like to figure out how the VNA communicates with them so that I can implement it myself in an open-source ECal.

Reverse-engineering options

Of course, the easiest way to do this would be to connect an ECal module and capture the USB traffic (with Packetry!), but an actual ECal is too elusive.

The next option is to disassemble and analyze the software running on the VNA, which I spent a bit of time doing, but it was slow going as I’m not too familiar with the APIs on Windows and how it uses them for USB. However, there are some quick things to learn by looking at the software. It’s split into many DLLs, so it’s easy to see the imports and exports of each and get an idea of the functionality we might expect from the USB ECal:

$ winedump -j export ecalusb.dll 
Contents of ecalusb.dll: 33280 bytes

[...]

  Entry Pt  Ordn  Name
  00001F50     1 ReadModule
  00002160     2 SetState
  00001F90     3 ReadModule1K
  000016D0     4 Reset
  00001FD0     5 ReadModuleData
  00002010     6 WriteModuleData
  00002210     7 EraseSector

Done dumping ecalusb.dll

So, it should have ways to read and write data on the module, which makes sense as it needs to store S-parameter data describing the characteristics of the different standards to be used for calibration. It also has SetState, which probably sets the switch positions to select different standards on each port.

Device Emulation

I decided to go down the route of emulating the ECal device, then seeing what the VNA tried to request of it and iterate from there. Using Cynthion with the Facedancer library you can easily emulate a USB device by writing a Python script, and quickly make changes to try out different things.

I started with the template.py example from the Facedancer project. Usually, a USB host will identify a particular device by looking at the vendor ID & product ID and/or the manufacturer/product/serial strings. From searching on forums and other test equipment groups, I found the expected values for the target device and I modified the template with these:

#!/usr/bin/env python3

from facedancer         import main
from facedancer         import *

@use_inner_classes_automatically
class ECalDevice(USBDevice):

    vendor_id                : int  = 0x0957
    product_id               : int  = 0x0001

    manufacturer_string      : str  = "Agilent Technologies"
    product_string           : str  = "USB ECal Module"
    serial_number_string     : str  = "S/N 12346"
    device_speed             : DeviceSpeed = DeviceSpeed.FULL

    class ECalConfiguration(USBConfiguration):

        class ECalInterface(USBInterface):

            class ECalInEndpoint(USBEndpoint):
                number               : int                    = 1
                direction            : USBDirection           = USBDirection.IN
                transfer_type        : USBTransferType        = USBTransferType.BULK
                max_packet_size      : int = 64
                
                def handle_data_requested(self):
                    self.send(b"Hello!")

            class ECalOutEndpoint(USBEndpoint):
                number               : int                    = 1
                direction            : USBDirection           = USBDirection.OUT

                def handle_data_received(self, data):
                    print(f"Received data: {data}")

main(ECalDevice)

Running this script and then clicking “Detect Connected ECals” on the VNA gives the following output:

$ python ecal-emulate.py --suggest
INFO    | __init__       | Starting emulation, press 'Control-C' to disconnect and exit.
INFO    | moondancer     | Using the Moondancer backend.
INFO    | moondancer     | Connected FULL speed device '__main__.ECalDevice' to target host.
INFO    | device         | Host issued a bus reset; resetting our connection.
INFO    | moondancer     | Target host configuration complete.
WARNING | device         | Stalling unhandled OUT VENDOR request 0x04 to DEVICE [value=0x0000, index=0x0000, length=0].

This shows that the script got a vendor-specific request from the VNA, but doesn’t yet have the code to handle it so it returns a STALL response (which is the terminology for how USB devices respond to unhandled requests). Since I ran it with the --suggest argument, stopping the script gives me a suggestion for code that I can add to handle the request!

^CINFO    | moondancer     | Disconnecting from target host.

Automatic Suggestions
These suggestions are based on simple observed behavior;
not all of these suggestions may be useful / desirable.


Request handler code:

  @vendor_request_handler(number=4, direction=USBDirection.OUT)
  @to_device
  def handle_control_request_4(self, request):
      # Most recent request data: bytearray(b'').
      # Replace me with your handler.
      request.stall()

I add the suggested handler to my script, but change the response from stall to ack and also print out the request:

--- a/ecal-emulate.py
+++ b/ecal-emulate.py
@@ -34,4 +34,11 @@ class ECalDevice(USBDevice):
                def handle_data_received(self, data):
                    print(f"Received data: {data}")

+    @vendor_request_handler(number=4, direction=USBDirection.OUT)
+    @to_device
+    def handle_control_request_4(self, request):
+        print(request)
+        request.ack()
+
+
main(ECalDevice)

I ran the script and got a new message saying that there was also a vendor request number 2 to be handled, so I went through the same process to handle that too. After doing that, I got a lot more output - now it sent many #2 vendor requests with values counting down from 0x400 (1024) by 6 each time:

OUT VENDOR request 0x04 to DEVICE [value=0x0000, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x0400, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x03fa, index=0x0000, length=0]
...
OUT VENDOR request 0x02 to DEVICE [value=0x0010, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x000a, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x0004, index=0x0000, length=0]

This looked very promising, as I was expecting it to read out 1 kB of memory from the hints in some of the DLL exports mentioned earlier. However, I was a bit confused at this point because, while it seemed to be addressing the memory, I couldn’t see any way that the device could actually return the data. Due to the way USB control transfers work, there isn’t a way for an OUT request to return any data - it can only ACK or NAK.

I wanted to see if there might be something else happening on the bus that I might be missing. Fortunately, I have a few Cynthions about so I hooked up a second one in-line to do a packet capture and see if I could learn more:

Doh! Of course, the template example I was working from was also setting up a BULK IN endpoint to return “Hello!”. After each address vendor request, the VNA would request data on the bulk endpoint and receive those 6 bytes, then adjust the address accordingly and repeat. If I had realised, I could have just added a print to the handler to see that happening rather than setting up the packet capture.

Now that I had a pretty good idea of how the data was being read out I could go ahead and implement it properly, but I needed some appropriate data to return. Fortunately I was able to find some memory dumps that another user had shared online for the 8506x series ECal modules. They had shared them as ASCII hex dumps, so I converted them to binaries with xxd:

$ head HP85062-60006.txt 
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2021.09.29 21:47:04 =~=~=~=~=~=~=~=~=~=~=~=
dump 0 040000

000000: 48 50 38 35 30 36 30 43 20 45 43 41 4C 00 E8 D1  | HP85060C ECAL... | 
000010: 31 83 C4 02 64 00 4E 6F 76 20 32 38 20 31 39 39  | 1...d.Nov 28 199 | 
000020: 34 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF  | 4............... | 
000030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  | ................ | 
000040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  | ................ | 
000050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  | ................ | 
000060: FF FF FF FF 30 30 33 36 37 00 31 C0 50 E8 88 08  | ....00367.1.P... | 

$ xxd -r HP85062-60006.txt HP85062-60006.bin

$ hexdump -C HP85062-60006.bin | head
00000000  48 50 38 35 30 36 30 43  20 45 43 41 4c 00 e8 d1  |HP85060C ECAL...|
00000010  31 83 c4 02 64 00 4e 6f  76 20 32 38 20 31 39 39  |1...d.Nov 28 199|
00000020  34 00 ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |4...............|
00000030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000060  ff ff ff ff 30 30 33 36  37 00 31 c0 50 e8 88 08  |....00367.1.P...|
00000070  33 35 46 33 35 46 20 4d  57 31 00 c4 04 56 e8 fb  |35F35F MW1...V..|
00000080  08 83 c4 02 38 20 41 75  67 20 32 30 30 31 20 00  |....8 Aug 2001 .|
00000090  41 47 49 4c 45 4e 54 2f  4d 54 41 00 b8 f8 6a eb  |AGILENT/MTA...j.|
000000a0  93 83 3e 94 06 00 74 1e  a1 82 06 83 c0 41 a2 98  |..>...t......A..|

Then I modified my Python script to load that file and return the data from the bulk endpoint, and tried again to detect the device from the VNA:

--- a/ecal-emulate.py
+++ b/ecal-emulate.py
@@ -14,6 +14,9 @@ class ECalDevice(USBDevice):
     serial_number_string     : str  = "S/N 12346"
     device_speed             : DeviceSpeed = DeviceSpeed.FULL
 
+    address = 0
+    data = open('EEPROM/HP85062-60006.bin', 'rb').read()
+
     class ECalConfiguration(USBConfiguration):
 
         class ECalInterface(USBInterface):
@@ -25,7 +28,10 @@ class ECalDevice(USBDevice):
                 max_packet_size      : int = 64
                 
                 def handle_data_requested(self):
-                    self.send(b"Hello!")
+                    # Respond with 32 bytes of EEPROM data
+                    dev = self.get_device()
+                    addr = dev.address
+                    self.send(dev.data[addr:addr+32])
 
             class ECalOutEndpoint(USBEndpoint):
                 number               : int                    = 1

Success! …sort of. It detected something, which is great progress, but the output is a mess. After staring at it for a while, I realised my silly mistake - I’d forgotten to update the address when receiving vendor request 2:

--- a/ecal-emulate.py
+++ b/ecal-emulate.py
@@ -44,6 +44,7 @@ class ECalDevice(USBDevice):
     @to_device
     def handle_control_request_2(self, request):
         print(request)
+        self.address = request.value
         request.ack()

I added that, re-ran everything, and… nothing! It didn’t detect anything anymore. Something about that mistake actually made it work better.

Something that’s very common in file formats is to start with a header that includes some magic value and the parser will check that value before doing anything else. With the mistake in place, the script was returning the first 32 bytes of data to every request, so that was probably enough to pass the header check and show a detected device. However, that suggests that upon implementing the addressing, now the script wasn’t returning the header whenever the VNA was expecting it.

I had a look back at the pattern of #2 vendor requests:

OUT VENDOR request 0x02 to DEVICE [value=0x0400, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x03e0, index=0x0000, length=0]
...
OUT VENDOR request 0x02 to DEVICE [value=0x0040, index=0x0000, length=0]
OUT VENDOR request 0x02 to DEVICE [value=0x0020, index=0x0000, length=0]
^CINFO    | moondancer     | Disconnecting from target host.

Two things stood out to me about those:

The VNA starts by requesting with value=0x400 and then counts down - that’s a bit odd, I’d expect it to start at address 0 and count up.
The VNA never actually sends a request with value=0x0, so the script never sends the header at all with the addressing in place!

This got me thinking that maybe there’s some quirk in the addressing and it should actually be reversed (so that a request with value=0x400 goes to address 0x0). I made that change and re-ran the test:

--- a/ecal-emulate.py
+++ b/ecal-emulate.py
@@ -44,7 +44,7 @@ class ECalDevice(USBDevice):
     @to_device
     def handle_control_request_2(self, request):
         print(request)
-        self.address = request.value
+        self.address = 0x400 - request.value
         request.ack()

Bingo! The device is detected and all the information about it looks correct now.

While there are some other details still to figure out, I’ll wrap it up there as I think it’s demonstrated the process pretty well. Hopefully it provides some inspiration, please let us know if you use these techniques and tools in your own projects!

For anyone interested, the full code and any further research is available here: https://github.com/miek/ecal-reversing

Free Stuff - February 2024

2024-10-15T12:00:00

The belated February 2024 Free Stuff recipient for the Great Scott Gadgets Free Stuff Program is Adam Drake! Adam, a teacher in Canada, sponsors three clubs at his high school - a competitive robotics club, a model railway club, and a D&D club. All of these clubs are fully funded from either internal school funds, the school PAC (Parental Advisory Council), or the NSHSS. This summer, Adam ran an RF Comms summer school where 18 students gained their amateur radio certification!

Following the success of the RF Comms summer school, Adam is now starting another after-school club: “RF Communications.” This club will teach students all about wireless communications, such as Bluetooth, Wi-Fi, cellular, and radio (HF, VHF, UHF, etc). Students will learn the theory of RF (radio frequency) communications, but the focus will be on practical uses of the technology. Students who do not yet have their radio licenses will have more chances to study and gain Canadian Amateur Radio licenses through this club.

We will be sending Adam a HackRF One to support these clubs and the students they impact. Thank you, Adam, for all you do in your community!

Cynthion is Here!

2024-09-16T12:00:00

We’re pleased to announce that Cynthion is now available for purchase from our authorized resellers! This FPGA-based hardware platform from Great Scott Gadgets powered by LUNA gateware is your new go-to tool for discovering and exploring the world of USB at a fraction of the cost of existing High Speed USB analyzers. Whether you’re experienced with USB or you’re new and learning about it, Cynthion is a great multipurpose addition to your hardware experimentation toolbox! We’ve also developed custom open-source software tools that work with Cynthion:

Packetry is a fast and intuitive open-source software that allows you to capture and analyze traffic between a host and Low-, Full-, or High-Speed USB devices.
Moondancer is a Facedancer backend that enables you to reverse engineer USB devices and even create your own!

Cynthion comes in a beautiful and protective milled aluminum enclosure so that despite its small size (it fits in the palm of your hand) it has a solid feel and a nice weight. It is also currently available for sale without an enclosure at a lower cost. We’ve offered this option to make Cynthion as financially accessible as possible for hobbyists, students, and small teams.

You can learn more about Cynthion, including where to purchase it, by visiting our Cynthion webpage.

Free Stuff - January 2024

2024-08-27T12:00:00

The January 2024 recipient for the Great Scott Gadgets Free Stuff Program is Marc, the author of PySDR.org. Marc is interested in learning more about HackRF One and potentially adding a chapter on HackRF One to the PySDR.org documentation. We look forward to working with Marc on this update to PySDR.org and helping even more folks with finding new ways to interact with their HackRF One.

Cynthion is at Mouser

2024-07-02T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-is-at-mouser

An 885 lb / 401.43 kg shipment of thousands of Cynthions has been received by Mouser (who will fulfill Cynthion orders for Crowd Supply)! We expect the Cynthions to start shipping to backers around the 5th of July. You will receive a notice when your Cynthion has shipped.

While you wait for your shipping notice and for your device to arrive, take a moment to read the Cynthion documentation. Cynthion does not ship with USB cables, so take a look at the connection diagrams in this documentation for different use cases and make sure you have all the cables you will need.

As you receive your Cynthions we would love to see your first pictures with your device! Please tag Great Scott Gadgets on X, Mastodon, Instagram, or post in the #show-your-gsg channel in our Discord.

Cynthion Shipping Soon!

2024-05-29T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-shipping-soon

The first few Cynthions have come off of the manufacturing line! Once the first full batch of Cynthions is completed we will send them to Mouser who will ship them to you, our backers. Shipping will happen soon, so please make sure your address on Crowd Supply is up-to-date. If you need assistance with an address change please contact Crowd Supply. We will post another update once the first orders leave the Mouser warehouse. Until then, please enjoy these photos from our contract manufacturer.

Batch of Cynthions before last USB component was soldered on.

Enclosed Cynthion ready to ship

Batch of enclosed Cynthions ready to ship

Free Stuff - December 2023

2024-05-08T12:00:00

The December 2023 recipient for the Great Scott Gadgets Free Stuff Program is a STEM Camp where students will have the opportunity to use the requested HackRF One to do a Quantum Physics experiment with laser light and modulated RF. We are excited to see how the experiment goes and to see pictures from the camp!

Free Stuff - November 2023

2024-05-06T12:00:00

The November 2023 recipient for the Great Scott Gadgets Free Stuff Program is Ryan. Ryan works as a wireless systems administrator for a public school. He coaches robotics and programming teams after school. Ryan has asked for a HackRF One to show the students in his clubs how to interact with the wirelss devices around them and to inspire them to explore RF as future career options.

Cynthion Manufacturing Progress

2024-04-30T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-manufacturing-progress

Cynthion update time!

Final samples have been manufactured, some of them have been sent for RoHS testing (and each of them has passed), and manufacturing is under way. Everything’s going great so far, and we’re on track for June shipping!

Here is your first glimpse of finished Cynthions in their enclosures and in the boxes we will be shipping them in.

The significance of RoHS testing is that Cynthion had to pass that test in order for us to earn our CE marking, which allows us to sell Cynthion in the EU. RoHS stands for “Restriction of Hazardous Substances in Electrical and Electronic Equipment” and this directive requires that electronic and electrical equipment does not exceed certain thresholds for lead, cadmium, mercury, and other hazardous substances. RoHS testing is completed by a third-party lab and the lab we chose used “destructive testing methods” which meant that we had to send a few completed Cynthions, including enclosure and packaging, for them to destroy.

Cynthion Has Passed EMC and Tycho Has Shipped to Our Manufacturer

2024-02-27T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-has-passed-emc-and-tycho-has-shipped-to-our-manufacturer

The title says it all! Cynthion has passed EMC testing which means it is ready for manufacturing and Tycho, our Cynthion-testing quality assurance rig, has been shipped to our manufacturer. Our next steps are to work closely with our manufacturer to create final product samples, ensure the QA process is achieving the results we expect at factory level, and receive the final product samples and test them in-house here at Great Scott Gadgets. We’ll have more for you soon!

Cynthion Design Work Completed

2024-01-24T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-design-work-completed

We are happy to say that early this month we completed the design work for Cynthion! This milestone is the culmination of yet another three months’ worth of work. Since our October update we have:

revisited the EMC testing lab for another round of pre-compliance testing,
used the EMC testing results to improve signal integrity on Cynthion and produce another hardware revision,
ordered another revision of the Cynthion enclosure prototypes,
designed and ordered prototypes of the Cynthion packaging,
produced another Cynthion hardware revision to fix minor issues,
rearranged the Cynthion schematic,
updated documentation in Cynthion-related repositories,
ordered a production sample of Cynthion,
worked on the Cynthion manufacturing test jig and test scripts,
worked on apollo, luna, saturn-v, packetry, and Facedancer (all of which are used in conjunction with Cynthion or as part of manufacturing testing), and
scheduled another visit to the EMC testing lab for this week and taken Cynthion in for final evaluation.

Since we’ve only recently reached the milestone of finishing the design work, it means Cynthion delivery will be delayed until June to allow time for manufacturing and shipping. Here is what the current timeline to delivery looks like:

January

Since the completion of Cynthion’s design, we have pivoted to finishing up the hardware test jig (which we have named Tycho) that we will send to our manufacturer so they can test each Cynthion as it comes off the production line. Designing this test jig has required multiple revisions that have changed slightly with each revision of Cynthion. Since Cynthion is so unique in its design we have even had to develop custom cables for Tycho. This is a story we are looking forward to telling you all about once the Tycho team has completed their work.

February

Our manufacturer is based in China and they will be unavailable almost all of February due to Chinese New Year celebrations. We will spend this month continuing to work on Tycho, documentation for Cynthion and related projects, and improving software, firmware, and gateware. By the end of this month we will ship Tycho to our manufacturers.

March

Cynthion will be in manufacturing for month one of two. In this month our manufacturers will produce the Cynthion PCBs, enclosures, and packaging. PCB production is expected to take about 2-3 weeks. As soon as the PCBs are produced, we will get a few production samples from the manufacturer for extra verification and testing by our team at Great Scott Gadgets. During this month we at Great Scott Gadgets will continue working on all of the Cynthion-related repositories and documentation.

April

Cynthion will be in manufacturing for month two of two. In this month Cynthions will be assembled, tested, and packaged by our manufacturer. Like March, we at Great Scott Gadgets will continue working on all of the Cynthion-related repositories and documentation. Additionally we will provide technical support to the manufacturing test team.

May

Cynthions will be on their way from our manufacturer in China to Crowd Supply’s fulfillment partner (Mouser) in the United States. At minimum this is expected to take two weeks, but we have scheduled an entire month for shipping as there can be lengthy customs delays when shipping internationally. This means that if there are no customs delays you may get your Cynthion sooner! Wish us luck.

June

The moment you’ve been waiting for! Cynthions will be shipped to you! If you have moved, you’ll want to make sure that you’ve updated your address on Crowd Supply before this point. Don’t worry, we will post an update before June reminding you to update your address.

Free Stuff - October 2023

2024-01-02T12:00:00

The October recipient for the Great Scott Gadgets Free Stuff Program is the Illinois Space Society, which is a student-run non-profit 501(c)3 aerospace organization at the University of Illinois Urbana-Champaign campus. The Illinois Space Society hosts a variety of technical projects and educational outreach programs. One of their largest technical projects, Spaceshot, is aiming to be one of the first collegiate teams to build and launch a two stage rocket to 100km, also known as the Kármán line, the beginning of space.

Over the past two years they’ve been working on creating flight computers that can accurately conduct state estimation at extreme high altitude. The group says “GPS is undoubtedly the most accurate form of positioning we can utilize, but most consumer grade modules are not rated for those extreme altitudes or speeds. Our hope is to use the HackRF One as a GPS simulator to help test our modules in an easily reproducible manner without the need for an expensive test flight. With that said, a HackRF One would also allow us to expand beyond the range of our RTL-SDR to help debug our ESP32-S3 wifi modules and our upcoming wireless 5GHz video systems.” The Illinois Space Society also plans to use the HackRF One we send them to help kickoff their radio club. We look forward to seeing what projects the Illinois Space Society does from here!

2023 Winter Break

2023-12-21T12:00:00

We hope everyone has a great holiday season! If you are trying to get in touch with the Great Scott Gadgets team please know tomorrow (December 22nd) will be our last day in the office until the 2024 calendar year! This means that we will not be available through email, on Discord, or via GitHub. See you all in January!

Free Stuff - September 2023

2023-11-06T12:00:00

The September recipient for the Great Scott Gadgets Free Stuff Program is Erik. Erik is an Ojibwe filmmaker and artist. He has only had his amateur radio license for a short while but he is already assisting in running community demonstrations on how amateur radio can help in emergency situations. We are sending Erik a HackRF One so he can build a mobile training station and take his emergency preparedness demonstrations on the road to Native communities. As an avid camper and road tripper, Erik is also excited to eventually take his demonstrations into wilderness settings and rural communities. We look forward to seeing Erik’s mobile training station and getting updates on where he has taken it.

Improvements to Cynthion Hardware

2023-10-24T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/improvements-to-cynthion-hardware

Since our last hardware design update in April, we have been hard at work refining the Cynthion design in preparation for production. Believe it or not, we’ve completed and tested six design revisions since r0.6 described in April!

In r0.7 we increased the maximum pass-through current by selecting FETs with lower resistance and by improving heat dissipation of the PCB layout. We added filters to the buttons, reducing the need for debouncing in firmware and gateware. We added a zero ohm series resistor to the oscillator so that it could be replaced easily with a higher resistance if indicated by electromagnetic compatibility (EMC) testing. We also updated several component selections and added or removed various pull-up and pull-down resistors, ensuring that we follow recommendations for the FPGA and microcontroller.

After testing these improvements, we decided that the design was ready for pre-production. We updated a few component selections, refined some nuances of the PCB layout, and bumped the hardware version number from r0.7 to r1.0.0.

Hardware Semantic Versioning

At this time we adopted an internal standard for hardware semantic versioning. It can be difficult to know how to version hardware designs, so we chose to make our decision process easier by establishing a set of rules adapted from the popular semantic versioning standard for software. While the software semantic versioning standard is focused on the software’s Application Programming Interface (API), our standard for hardware focuses on the hardware/software interface.

As an example, a change to the PCB layout that has no affect on software would warrant a bump from 1.0.0 to 1.0.1, but swapping pin assignments on a microcontroller (necessitating different firmware behavior) would require the version number to be bumped from 1.0.0 to 1.1.0. While software version numbers are often prefixed with “v”, we use “r” for hardware, making it easier to tell if we are referring to a software version or hardware version.

Although r1.0.0 differed very little from r0.7, we bumped the major version number to indicate that it was the first version handed off for volume production. It later turned out that further revisions were required, but r1.0.0 was the first version that conceivably could have ended up in your hands.

The Component Shortage Strikes Again

As mentioned in Cynthion Delivery Timeline Update, we soon learned that the power monitoring component used in r0.6 through r1.0.0 was no longer available. While many thousands were available just three weeks earlier, they all had vanished in the short time between prototyping r0.7 and purchasing components for production!

Fortunately, we were able to find just enough of an alternative component, so we snatched it up and designed and tested another revision, r1.1.0, using the new part. Because the new part is the same IC in a different package, nothing needed to change in r1.1.0 except for the PCB layout and some pin assignments.

Around this time, we received new enclosure samples, updated for the larger PCB size introduced in r0.6. The samples were great, but we noticed that they made the buttons feel inconsistent. It was very difficult to center the PCB in the enclosure such that the button plungers all extended the same distance. A certain amount of play in the placement of the PCB within the enclosure is unavoidable, but for some reason it seemed to be nearly impossible to center the PCB perfectly.

Upon further investigation, the problem turned out to be with the PCB design, not the enclosure. When I had added a new button in r0.6, I accidentally placed it 0.1 mm closer to the PCB edge than the other two buttons. It wasn’t noticeable at first, but, once the board was placed in an enclosure, it was possible to feel the difference! We corrected this tiny discrepancy in r1.1.1.

Electromagnetic Compatibility Challenges

After our first round of EMC pre-compliance testing we hoped that we would be able to pass a second round with some software modifications and minor hardware updates (such as increasing the value of the oscillator series resistor). While some of these measures were effective, they weren’t enough to pass the emissions test. After our second test we determined that another hardware design revision was required to reduce electromagnetic emissions.

In r1.2.0 we significantly improved power supply connectivity and decoupling for the FPGA which seemed to be the principal remaining source of emissions. Most of these changes were enabled by updating the PCB from four layers to six. Additionally we added series resistors to the ULPI bus that connects each USB PHY to the FPGA. We suspected that these resistors may be unnecessary (except perhaps the ones on the ULPI clock signals), but it is much easier to swap in different resistances than it was before we added those resistor array footprints.

Our next pre-compliance test clearly indicated that we had successfully quashed emissions from the FPGA, but the we still had a borderline result. One of our configurations passed the test but with very little margin. We felt that we needed to reduce emissions further to ensure success in the formal test.

With the FPGA noise out of the way, it had become possible to detect emissions from the USB PHYs. After some experimentation, we determined that these emissions could be reduced with further modifications to the PCB design and enclosure.

We addressed PHY noise in r1.3.0 by improving shielding and PHY power supply decoupling and by installing common-mode chokes on the USB data signals. Additionally we made a change to FPGA control that makes it easier to recover a Cynthion bricked by bad gateware, and we fixed a power supply start-up bug that was introduced in r1.2.0.

I’m pleased to report that r1.3.0 passed EMC pre-compliance testing! There are some small bugs that need to be corrected in one more hardware revision, but we are now confident that Cynthion will pass the formal EMC test.

Viewing the Design

Most of the changes since r0.6 are unlikely to ever be noticed by a Cynthion user, but they all enhance the quality of the product in some way. The most significant functional change is that pass-through power now supports up to 3 A of current.

Design documents and fabrication outputs for each of these hardware revisions have been released in the new cynthion-hardware repository. Previously the design was included in the LUNA repository which now contains only the LUNA gateware library.

Free Stuff - August 2023

2023-09-26T12:00:00

The August recipient for the Great Scott Gadgets Free Stuff Program is The Factory, a student-run hardware design lab at McGill University in Montreal, Canada. The Factory aims to give students access to advanced tools for their hardware projects, space to work on their projects, and support in developing technical skills.

The Factory has previously offered workshops on VIM, VHDL, C, and PC building. They also run a Hackathon called The Forge. In one instance of The Forge students formed teams and built a line tracing robot to race against the other teams. In non-event related times, students in this lab have completed projects such as an IoT system for the trash cans on the McGill campus to alert the cleaning teams when a trash can is full, custom video game controllers, and an automated watering system for plants. About 40-50 students currently frequent The Factory, and they are all passionate about electronics, hardware, and related research.

We are sending The Factory a HackRF One so their lab members can fulfill their hopes of offering workshops and creating materials on wireless systems, satellite communication, and spectrum analysis. Good luck and have fun!

Moondancer: A Facedancer backend for Cynthion

2023-09-19T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/moondancer-a-facedancer-backend-for-cynthion

One of the core features promised in the Cynthion announcement is the ability to create your own Low-, Full- or High- speed USB devices using the Facedancer library – even if you don’t have experience with digital-hardware design, HDL or FPGA architecture. If you’ve been eagerly anticipating this feature, we’re pleased to introduce Moondancer, a new Facedancer backend for Cynthion.

What is Facedancer?

Facedancer is a host-side Python library for writing programs that remotely control the physical USB port(s) on Facedancer boards such as the original Facedancer21, GreatFET One, and Cynthion.

Using Facedancer to control a physical USB port gives you direct control over the data encoded in USB streams and allows you to do things like:

Emulate a physical USB device such as a keyboard, mass storage device, or serial interface,
Act as a programmable proxy between a device and its host with the ability to inspect and modify the data stream,
Fuzz host-side USB device drivers by deliberately sending malformed data that can trigger faults in the device or host software.

Facedancer Example

Let’s say you need to automate the operation of a computer running some software that can only accept input via keyboard:

A USB keyboard connected to the Target Operating System.

By connecting a Facedancer board such as Cynthion to the computer (called the “target”) in place of the USB keyboard, you can now use a second computer (called the “host”) to run a small Python script to control USB traffic between the target computer and Cynthion:

A Facedancer emulation of a USB keyboard connected to the Target Operating System.

Whenever a new USB peripheral is plugged in, the target operating system will first send a standard set of USB enumeration requests to the peripheral asking it to identify itself to the operating system. In the diagram above, Cynthion is the peripheral receiving enumeration requests from the target. However, instead of replying directly, Cynthion will forward any enumeration requests it receives to the Facedancer host. The Facedancer host will then respond to the target with a set of USB descriptors corresponding to the peripheral you are emulating. Once the target operating system has received a set of known USB descriptors, it will load the appropriate device driver for controlling the USB peripheral. All subsequent USB transfers initiated by the device driver will also be received by Cynthion and forwarded to the Facedancer host. By using a Facedancer emulation that responds appropriately to the command set of the peripheral being emulated, Cynthion can respond to the target operating system as if it were any actual physical device.

In our example, we can use Facedancer’s USBKeyboardDevice object to provide the USB descriptors and transfer commands required for a keyboard that follows the USB human interface device class specification:

import asyncio
from facedancer.devices.keyboard import USBKeyboardDevice

device = USBKeyboardDevice()

async def type_on_keyboard():
    # Type ls.
    await device.type_letters('l', 's', '\n')

main(device, type_on_keyboard())

What is Moondancer?

Moondancer is a new backend for Facedancer that adds support for Cynthion.

Facedancer supports a variety of boards by providing different backends for each supported board. For example, GreatFET One uses a backend called “greatdancer” while RPi + Max3241 boards use the “raspdancer” backend. In keeping with Cynthion’s lunar origins, we decided to call the new backend “Moondancer”.

What makes Cynthion different from other Facedancer-compatible boards is that, instead of being based on a microcontroller, it is built around an FPGA connected to three USB 2.0 PHY chips under control of the open source LUNA USB gateware library. While this provides us with more direct access to USB signals and their behaviour it also represented a significant engineering challenge for our team. The most significant challenge was how to control the USB controllers. On previous Facedancer devices, the controllers have been under software control via device firmware running on the device CPU. However, being an FPGA-based platform, Cynthion does not have a CPU!

At first glance, we had two choices for controlling the USB 2.0 PHY chips:

Implement the control logic as gateware.
Integrate a microcontroller into the Cynthion hardware design.

In principle a Facedancer device merely acts as a forwarder between the USB controllers and the controlling host. This means a gateware implementation could be as simple as exposing the registers controlling LUNA’s “eptri” triple-fifo endpoint peripheral via a set of USB Vendor Class commands. On the other hand, integrating another microcontroller into Cynthion would increase the design complexity significantly and add substantially to the bill of materials cost. All things being equal, we may have ended up with a gateware implementation were it not for the recent emergence of high quality, libre-licensed RISC-V implementations. Hosting a microcontroller as a “soft-core” on an FPGA is not a new idea but RISC-V’s open Instruction Set Architecture (ISA) removes many barriers to implementation such as licensing, compilers and tools. Therefore, while a Facedancer device implementation in gateware would be a very cool hack indeed, we thought it would be even cooler to take an approach that would also let you use Cynthion as a tool for getting started with RISC-V, System-on-Chip (SoC) design, and Embedded Rust while exploring USB in embedded environments.

How does Moondancer work?

Moondancer consists of several distinct components:

moondancer-soc: A custom RISC-V SoC that integrates a libre-licensed RISC-V CPU with the LUNA USB peripherals.
lunasoc-pac and lunasoc-hal: Embedded Rust support crates for moondancer-soc peripherals.
smolusb: A lightweight, low-level USB stack appropriate for LUNA USB device controllers.
Moondancer firmware: The device-side implementation of the Facedancer command protocol.
Moondancer backend: The host-side Facedancer backend for communication with the Moondancer firmware.

moondancer-soc

At the heart of Moondancer lies a stripped-down RISC-V SoC design described in the Amaranth Hardware Description Language (HDL):

SpinalHDL VexRiscV CPU
Full RV32IMAC instruction set support
60 MHz clock speed
64 kilobytes of SRAM
4 kilobytes L1 instruction cache
4 kilobytes L1 data cache
2x GPIO peripherals
6x LED peripherals
1x UART peripheral
1x Timer peripheral
3x LUNA USB eptri peripherals

While the feature set may be modest in comparison to most commercial micro-controllers, the full gateware source of every single component integrated within the design is libre-licensed with all four freedoms intact.

Moondancer SoC Architecture

After bringing up our “hardware” platform for the Moondancer firmware, we faced another set of challenges. In commercial SoC development, there are usually multiple teams tasked with creating the tooling, device drivers and development libraries for a new design. While we would still have to develop device drivers and libraries, we did not need to create yet another fork of GCC to implement our own custom toolchain with compiler, debugger, linker, and sundry utilities. Thanks to the efforts of many contributors, both commercial and from the broader community, the GNU toolchain has been shipping RiscV support for some time now, and Rust (via LLVM) can compile binaries for many RiscV variants right out of the box.

None of this would have been possible even a few years ago, and it is thanks to the efforts of a wide community that we were able to do it within the time and resources available to us:

lunasoc-pac

One of the fundamental building blocks in any Embedded Rust project is a Peripheral Access Crate (PAC) which provides safe register-level access to the processor’s peripherals. While there are already existing PACs and even HALs for RISC-V chips from companies such as Espressif and AllWinner there existed no equivalent for working with a custom-defined SoC implemented as gateware.

Fortunately, what most Rust PACs have in common is that their code is largely generated from an SVD description of the processor and its peripheral registers with the help of the svd2rust tool. Therefore, we extended the luna-soc library with the ability to export SVD files generated directly from the SoC design allowing anyone to easily generate a PAC for any luna-soc design.

lunasoc-hal

While it is entirely possible to develop an entire firmware using just a PAC crate, it would be nice to offer a friendlier programming interface and the possibility of code re-use across different processors. Normally, a chip will come with some form of vendor-provided HAL that provides higher-level abstractions for communicating with the peripherals and some compatibility with other products in the vendor’s product line. The Embedded Rust community took a slightly different approach to this problem with the embedded-hal project which provides a set of centrally defined traits to build an ecosystem of platform-agnostic drivers.

By adopting embedded-hal for our luna-soc design, we’ve made it possible for other luna-soc users to easily target their own custom designs even if the underlying peripheral implementations differ. It also means the Moondancer firmware can be more easily ported to any other platform with an embedded-hal implementation.

smolusb

Given that Facedancer requires direct access to the USB peripheral to perform emulation, and our SoC only has 64 kilobytes of RAM, we’ve developed ‘smolusb’, a new lightweight device-side USB stack that provides:

a set of traits for implementing HAL USB device drivers
data structures for defining device descriptors
data structures for defining class and vendor requests
device enumeration support

‘smolusb’ does not require Rust alloc support, uses a single statically allocated buffer for read operations, and supports zero-copy write operations. It supports high-level operations such as device enumeration but also provides several “escape hatches” that allow for direct control of the underlying peripheral for the purposes of device emulation and other Facedancer features.

Moondancer firmware and backend

Moondancer manages the communication between the Facedancer library and the remotely controlled USB peripheral and is split into two components:

Moondancer firmware written in Rust and running in the SoC on Cynthion. The Moondancer firmware implements the Facedancer command set and controls Cynthion’s USB ports.
Moondancer backend written in Python and running on the host. The Moondancer backend handles all communication between Facedancer and the Moondancer firmware.

To mediate communication between the Moondancer backend and the Moondancer firmware we’ve used a Rust implementation of the same libgreat RPC protocol used by GreatFET and other Great Scott Gadgets open-source projects. The power of libgreat is its ability to generate and expose simple explorable APIs via Python, allowing for flexible communications between computers and embedded devices, embedded drivers, and more without having to get into the murky details of driver development, transports or serialization protocols. We hope this design decision will also allow others to more easily develop and integrate their own custom firmware for embedded USB applications with host software!

On the host side, the Moondancer backend is responsible for translating calls from Facedancer into libgreat commands which are then received on Cynthion’s CONTROL USB port, deserialized by libgreat and forwarded to the Moondancer firmware which is responsible for operating the Cynthion’s TARGET USB port.

Finally, the Moondancer firmware implements the Moondancer API for directly controlling the USB peripheral via operations to manage port connections, reset the bus, set the device address, manage endpoints, and send/receive data packets.

Wrapping up

If you have access to Cynthion hardware and would like to try out Moondancer please feel free to check out the Cynthion repository. Also, if you’re interested in custom SoC development and Embedded Rust, you can check out the luna-soc repository. Most of the non-USB functionality has also been tested on other ECP5 devices so, with a little bit of luck, you might be able to get something going with your favorite development board.

Acknowledgements

We would like to express our sincere gratitude to two individuals without whom Moondancer would not have been possible.

In particular, our work builds on the research of Travis Goodspeed who developed the original Facedancer board and software, and Kate Temkin who extended the software and generalized it for other platforms.

You can learn more about the history of Facedancer and LUNA in our fifth Crowd Supply update: “The History of LUNA”.

Great Scott Gadgets is now on Mastodon

2023-09-13T12:00:00

Great Scott Gadgets is on Mastodon! You’ll get a lot of the same information as you get on our other social media profiles, but if Mastodon is your platform preference, we now have you covered.

Free Stuff - July 2023

2023-08-30T12:00:00

The July recipient for the Great Scott Gadgets Free Stuff Program is Joona. Joona plans to use the YARD Stick One we are sending him to develop and test radios. He will be writing documentation and creating tutorials on his projects.

Cynthion Delivery Timeline Update

2023-08-10T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-delivery-timeline-update

Hello, campaign backers and other supporters of Cynthion and Great Scott Gadgets! In this update, we hoped to tell you that manufacturing was in progress and that we were getting close to delivering the first Cynthions to you. Unfortunately, we have encountered more delays while getting the hardware ready to go to manufacturing.

The first delay was caused by another component availability barrier, which is now solved. After our last hardware update, we placed an order with our contract manufacturer for the additional components added to the Cynthion hardware design in r0.6. At the time of engineering r0.6, all of the new components added in this major revision were widely available, and we had no indications that there would be issues acquiring them. However, when we received the BOM quote for these additional components from our contract manufacturer, we learned that the power monitor part we had planned to use, PAC1954T-E/J6CX, was no longer in stock, and the quoted lead time was 20 weeks. Focused on getting the product delivered to you on time, we ordered a substitute part right away, and our engineering team immediately got to work on another hardware revision to instead use a PAC1954 package that was in stock, PAC1954T-E/4MX. This revision was relatively minor, but we did have to order another round of prototypes for verification and testing. Each time we order and test a new round of prototypes, the process takes 3-4 weeks. We named this new Cynthion revision r1.1.0 and went to an independent test lab for the necessary pre-compliance testing before ordering the production PCBs.

Before going to manufacturing or putting Cynthion on the market, we must certify that the final product conforms with applicable regulations and standards in all the countries we will be shipping to. One of the important standards Cynthion must comply with is electromagnetic compatibility (EMC). Cynthion’s compliance with EMC includes two components: emissions and immunity. Emissions compliance means that the Cynthion won’t emit electromagnetic interference (EMI) that can adversely affect other devices in its environment, and immunity compliance ensures that the Cynthion itself won’t be affected by electrostatic discharge (ESD). So far, we have had two rounds of testing in an independent EMC testing lab, each evaluating Cynthion on the emissions and immunity standards we’ve identified as applicable to Cynthion. In the first round of testing, Cynthion passed neither emissions nor immunity tests. By the second round, a couple of weeks later, the engineering team had solved the immunity problems, and Cynthion passed with flying colors– no such luck with the emissions portion of the test.

Since then, we have worked very hard to solve the EMC emissions issues with Cynthion. The engineering team identified software and gateware modifications that significantly reduced emissions and also found some small hardware changes that helped. Although great progress was made in a short period of time, it became apparent that a new hardware revision (r1.2.0) would be required to test modifications that we think will clear the final hurdle. As of today, we are waiting for another round of prototypes to be delivered so that we can test the new revision, and we hope that these will be the pre-manufacturing prototypes that will successfully pass EMC at the lab.

Although it is only possible to precisely estimate when Cynthion will ship once we have solved the emissions issues and manufacturing is underway, you will see that the expected delivery date for Cynthion fulfillment has changed to January 31st, 2024, which is our best estimate. In this new proposed timeline, we allow ourselves another month to resolve the EMC emissions issues and pass pre-compliance testing. After that, we estimate that manufacturing and quality control testing will take about three months, and we are allowing another two months for logistics and fulfillment. We will have a better idea of whether this timeline is realistic or not after the next round of EMC pre-compliance testing at the independent lab, and we will be sure to update you again if things change again with the timeline. In the meantime, we assure you that delivering Cynthion to you is our priority, and thank you for your patience as we continue to work hard to accomplish this goal we have been working towards for so long. Please accept our apologies for not updating you as often as we’d like to. The engineers who are best equipped to write these updates are very busy working on getting Cynthion to you as soon as possible!

Free Stuff - June 2023

2023-07-19T12:00:00

The June recipient for the Great Scott Gadgets Free Stuff Program is Daniel. Dan is planning to use the HackRF One we are sending him to run workshops in his school and with his amateur radio group. He will also be creating videos with his new HackRF One on his YouTube channel “Radio Dan ZL2DTL”. Please welcome Radio Dan to the software-defined radio community!

Free Stuff - May 2023

2023-07-14T12:00:00

The May recipient for the Great Scott Gadgets Free Stuff Program is the UCLA IEEE Wireless, RF, and Analog Project (WRAP). Participants in this club have the opportunity to learn hands-on radio engineering skills by designing, building, and testing a 2-way radio system capable of operating in the 100s of MHz. Through this project, students can learn digital and analog radio techniques like implementing filters and a mixer from discrete diodes and using coils for up/downconversion. WRAP asked for a HackRF One to aid in debugging wireless links, where they will use the HackRF One both as a modulated waveform generator for receiver testing and a real-time spectrum analyzer for transmitter and device debugging. We really look forward to seeing their end projects.

Updated Cynthion Enclosure

2023-06-30T00:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/updated-cynthion-enclosure

About a year ago, we announced an FPGA substitution on the Cynthion project due to supply chain issues. Since then, the Great Scott Gadgets team has redesigned and enlarged the Cynthion board to accommodate the larger FPGA, and Timon has adapted the enclosure to fit the larger board.

The updated Cynthion enclosure measures 60 mm (2.36 inches) in width, 72 mm (2.83 inches) in length, and 15 mm (.59 inches) in height. The weight of the enclosure with a Cynthion inside and all hardware, comes to 99.5 grams. In comparison to the previous enclosure, the new one is 8 mm wider, 7 mm longer, 1 mm taller, and 3.5 grams lighter due to extra milling for Pmod connectors and other small changes.

Once I received the 3D model files from Timon, I got to work designing the final graphics for the Cynthion enclosure, which are shown in the image below.

In this image, the black lines are the edges of the enclosure, connector holes, and hardware holes. The blue text and images are the graphics and labels that will be etched into the case. Once etched, these graphics will appear white-grey in colour. A rendering of the case is below:

The differences from our early enclosure design include a complete change in graphics on the top of the case, moving the port labels to the edges, adding labels for the Pmods, and a debossed (not etched!) Great Scott Gadgets logo on the back.

Free Stuff - April 2023

2023-05-30T12:00:00

The April recipient for the Great Scott Gadgets Free Stuff Program is Adnane. Adnane is a software development and cybersecurity student in SoliCode School in Tangier, Morocco. He is always looking for new tools and technologies to enhance his learning and explore new avenues in the field. Adnane is planning to use his HackRF One to learn more about wireless security testing, digital signal analysis, and software-defined radio. He will share his knowledge and skills in the SoliCode Cybersecurity Club. Good luck and have fun!

Development of a Universal Radio Test Instrument

2023-05-04T13:44:00

The Great Scott Gadgets team is thrilled to announce our newest research and development project: a Universal Radio Test Instrument (URTI). We have decided to call this project URTI as a working title. With the support of ARDC in partnership with TAPR, we aim to develop an open-source SDR platform with an unparalleled set of radio investigation and experimentation functions in one versatile device. URTI will offer radio amateurs, researchers, educators, and professionals an affordable, compact RF test tool that could be used in place of multiple expensive pieces of traditional radio test equipment.

Design and Functionality

Our goal for URTI is to design a single hardware platform capable of serving as many popular types of one-port or two-port RF test instruments. We plan to build a directional coupler into a wideband, full-duplex SDR platform to enable URTI to function as a:

spectrum analyzer
vector network analyzer
vector signal generator
vector signal analyzer
antenna analyzer
power meter
frequency counter
full-duplex SDR transceiver

Incorporating these test equipment functions into a compact form factor with a handheld user interface will make URTI portable and convenient to use in the field. We also plan to develop a lower-cost variant that will provide the same test equipment functions but as a computer peripheral device without the handheld user interface, making the tool more accessible for every budget.

Development Plans

The Great Scott Gadgets engineering team will develop URTI in eight overlapping phases. These phases will include:

Mainboard component selection and sub-circuit evaluation
Initial mainboard hardware design
User interface board component and sub-circuit evaluation
Mainboard firmware and gateware development
Host software development to enable use of the mainboard as a USB peripheral
Final mainboard prototype design
User interface board hardware design
Handheld user interface firmware development

Once we have a complete and fully documented final design, we plan to assemble and distribute 50 prototypes of the USB peripheral version and 50 prototypes of the handheld version to select beta testers to promote feedback and community involvement. We have already started working on the first phase of development: mainboard component selection and sub-circuit evaluation. Our priority is selecting components that are widely available and cost-effective so the completed design can remain relevant and accessible for as long as possible.

All phases of the URTI project will be published concurrently with development in public repositories within the Great Scott Gadgets organization on GitHub. In keeping with Great Scott Gadgets’ commitment to putting open-source tools into the hands of innovative people, we will publish all hardware, software, firmware, and documentation for URTI under open-source licenses, making these resources available to all. You can view our current progress on URTI in the lab notes repository on GitHub.

Thank Yous and Getting Involved

We are excited to bring the URTI project to life over the coming year, and we hope it will transform how people experiment with radio. We thank ARDC and TAPR for supporting this project and contributing financial resources to make it happen!

We would love to hear your feedback on this project and invite you to join us on our Discord server to chat about this or other Great Scott Gadgets projects.

Free Stuff - March 2023

2023-05-01T12:00:00

The March recipient for the Great Scott Gadgets Free Stuff Program is Jan. Jan is the author and maintainer of RadioLib, an open-source library for embedded devices controlling various wireless radio modules like SX1276, CC1101 or RF69.

We are sending Jan a HackRF One to aid in the development of RadioLib. Until now, Jan has been doing development using an RTL dongle. The lack of TX ability, and other issues, have made the dongle a bit less than practical. We hope the HackRF One helps, and we look forward to watching this project continue to evolve!

Cynthion Hardware Design Update

2023-04-14T00:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/cynthion-hardware-design-update.

We’ve completed the Cynthion r0.6 design! As mentioned in previous updates we needed to modify the design to accommodate new components due to supply chain issues. In this revision additional changes were made to resolve some problems beta testers identified with both power input and power output.

Issues Found During Beta Testing

Power input issues: When you plug Cynthion into a host computer, it is expected that Cynthion powers up and that the host computer will recognize that a device has been attached. Our beta testers found a couple of situations in which those things would not happen reliably. These scenarios were caused by a confirmed issue with excessive reverse leakage through a diode and a suspected issue with loading of the CC pins on the USB Type-C connectors.

Power output issues: Cynthion can pass power from a host computer (either the control host or a target host) through to a target device. Although this worked reliably, there was a problem that caused excessive power consumption and another problem that could theoretically damage a component on Cynthion.

Rethinking Power Distribution

As we investigated various power input and output issues over the past year or so, we sketched solutions planned for r0.6. When it came time to design r0.6, however, we realized that those solutions were insufficient.

Additionally, we realized that older versions of Cynthion were vulnerable to damage from high voltage input on any of the USB Type-C connectors. Originally designed with Micro-B connectors, Cynthion was later updated with Type-C connectors, introducing a much greater probability of accidental high voltage.

Micro-B connectors are intended to carry 5 V power, but Type-C connectors were designed to support up to 20 V, later extended to 48 V. USB hosts and power supplies are supposed to supply only 5 V unless the device asks for a higher voltage, but a noncompliant implementation could supply up to 20 V without negotiation.

Partly out of concern for overvoltage, we had implemented very limited Power Delivery (PD) capabilities in previous hardware revisions, minimizing the probability of input voltages higher than 5 V. However, our PD implementation may have contributed to other problems, and it did nothing to protect Cynthion from overvoltage from a noncompliant power supply.

We decided to completely rethink both power input and power output. After multiple rounds of design, simulation, and test, we’re happy to report that Cynthion’s capabilities are better than ever before!

image caption: a prototype board, essentially a Cynthion with everything removed except power distribution and monitoring

What’s New in r0.6

The USB ports are now renamed:

CONTROL is the primary port for control of Cynthion. Both the FPGA and the on-board debugger are now controlled over this port, so a second connection to the control host is no longer required.
TARGET C connects to a target host.
TARGET A connects to a target device and is directly connected to TARGET C, passing through data signals and allowing USB analysis.
AUX is an auxiliary port that can be used for various purposes, including MitM or as a secondary control port for development.

Cynthion now supports power passthrough up to 20 V, the highest voltage allowed in PD’s Standard Power Range (SPR). Power can now pass through to the AUX port in addition to the TARGET ports. PD’s Extended Power Range (EPR) is not supported.

A 5 V power supply is still required on either CONTROL or AUX to power Cynthion itself, but the hardware now allows the user to select which port to use if 5 V supplies are available on both ports. Overvoltage protection automatically shuts off either input if it exceeds 5.5 V.

Power input and power passthrough are now two separate functions, no longer entangled with one another. All power output is strictly passthrough, not an output of an internal supply rail. Overvoltage shutoff of an input does not affect passthrough. There is no longer a diode drop reducing passthrough voltage.

All four ports now feature voltage and current monitoring, allowing Cynthion to measure passthrough power as well as its own power usage. The power monitoring capability can be used to implement flexible overvoltage, overcurrent, or reverse current protection for external hosts or devices, though with a slower response time than Cynthion’s internal overvoltage protection.

TARGET C and AUX now each have a Type-C controller implementing bidirectional PD communication on the CC pins. This significant improvement in PD capabilities was made possible in part by the power distribution redesign. The Type-C controller additionally allows VCONN output that can be used, for example, to power electronically marked cables.

A new USER button provides input to the FPGA, allowing direct interaction with gateware running on Cynthion.

The Pmod connectors are moved to the same edge of the board making Cynthion compatible with dual Pmods. A new mezzanine connector provides additional expansion capability.

Cynthion is now physically larger. The PCB dimensions increased from 48x48 mm to 56x56 mm. This will accommodate future revisions with physically larger FPGA packages or other components. During the r0.6 design phase we unexpectedly received some delayed components which we will use in the first production to reduce risk, but we need room to allow future use of alternative parts purchased during the shortage.

New mounting holes in the corners allow the PCB to be firmly fastened to an enclosure. 3D render of Cynthion r0.6

Next Steps

Prototypes of Cynthion r0.6 have been assembled, and we are testing them now. We anticipate one more hardware revision before production, but we expect it to include only minor updates. Initial testing of r0.6 is going very well, probably because we already prototyped smaller sections of it separately.

Taylor and Martin are now working hard on designing a test jig and software for factory testing. Much of this work couldn’t be done until the r0.6 redesign was complete, but we are now making rapid progress.

Timon has already completed an update of the enclosure design for new form factor, and we will have samples made very soon. Once we have samples that pass inspection we’ll be able to design packaging.

All of these steps will take time, and they were delayed by the r0.6 redesign effort. As a result, we expect to begin shipping LUNA in August 2023 instead of June 2023, but we think the many improvements in the latest revision will be worth the wait. We’re thrilled to be making steady progress after many months of waiting and wondering about component availability.

We greatly appreciate your patience and continued support!

Packetry: Building a High Performance Protocol Analysis Tool

2023-04-07T12:00:00

In a previous update, we introduced our work on Packetry, our new front-end software for using Cynthion to capture and analyze USB traffic on the wire. In this update, we’re going to talk a bit more about the design of that software and explain some of the work we’re doing to make it as fast and easy to use as possible.

The Need for Speed

One of the most exciting features of Cynthion is its ability to serve as a protocol analyzer, letting you intercept and capture USB traffic on the wire, in the field, from real devices.

Fully benefiting from this feature requires the help of some very efficient software on the capture host. A high-speed USB capture, including metadata, can generate over half a gigabit per second of raw data. To see what’s happening in real time as the capture progresses, all that data needs to be processed at least as fast as it’s captured, which is close to 50 megabytes per second.

In fact, real-time performance isn’t really enough in practice. When opening a saved capture from a file, the software needs to process packets many times faster than real time. At real-time decoding speed, a busy minute-long capture would also take a whole minute to load. So we need a solution that can process USB packet data many times faster than real-time speeds, which means a throughput of hundreds of megabytes per second at least.

Because of these requirements, we’ve designed Packetry from the ground up to achieve the fastest possible decoding speeds and to scale seamlessly to captures of unlimited size, bounded only by disk space. We’re also thinking ahead: Packetry has been developed for USB 2.0 analysis with Cynthion, but in the future we may want to use it to analyze higher speed protocols.

All these factors have made performance critical to success: so how did we achieve it?

Laziness as a Virtue

To achieve the speed and scalability we need, we must do the minimum work necessary for each packet at capture time. We don’t need to fully interpret all traffic as it’s captured: we just need to follow each packet’s effect on the protocol and store things in a form we can efficiently access later.

Rather than constructing individual data structures to represent packets, transactions and other protocol elements, we simply write all captured packets out into a flat bytestream in order. In this form, the capture can be very efficiently written to a file as it progresses.

As we do so, we build a set of indexes which describe where to find the start of each packet, the start of each transaction, and so forth. Those indexes are how we describe the protocol structure. They are designed to provide just enough information for the UI to later look up any part of the capture, decode it on demand, and display it.

Each index is a monotonically increasing sequence of integers. Because of that, we can store them very efficiently. We use a simple compression scheme to minimize the storage overhead of the indexes. To ensure scalability, these indexes are also streamed to files themselves. As such, capture size is limited only by available storage, never by available memory. All data structures in memory have a bounded size which is independent of the size of the capture.

In this approach, we gain scalability by giving up a little speed at display time. This is a good tradeoff to make, because, unlike capturing or loading data which may happen at extremely high speeds, displaying data is constrained by the bandwidth of the human user. There can only be so many things on screen at once, and the user can only browse through them at human speeds. We do not have to make rendering the display very fast for it to feel instantaneous.

Traffic Display

USB is a highly structured protocol: packets are grouped into transactions, transactions into transfers, and transfers are attached to specific endpoints on devices. Our UI displays traffic hierarchically according to that structure, making captures easy to understand and explore. A similar design approach was pioneered in ViewSB, but in Packetry we’ve now made it fast and scalable to large high-speed captures.

Our GUI has been built on GTK 4, which has built-in support for displaying large lists and trees by lazily loading only the parts currently visible on screen, recycling UI widgets for efficiency, and preloading ahead of scrolling. When you scroll through the traffic view in Packetry, the packets required are loaded on demand using the capture indexes, decoded on the fly, and used to generate the summaries you see of packets, transactions and transfers. All this happens live, too: if you’re running a capture, you’ll see new traffic appear, and the descriptions of existing items may be updated as further packets come in. When you load a capture from a file, you can start exploring it immediately, even while the packets later in the file are still being indexed.

Threading Model

It’s been a while since individual CPU cores got significantly faster; these days performance gains usually come from parallelization to take advantage of multiple cores. However, some tasks just can’t be parallelized, and the only option is to make them as fast as possible on a single thread.

When analyzing packets captured on the wire, every packet matters to the overall state of the protocol. The need to deal with invalid packets and protocol errors means it’s not possible to make assumptions about structure. Interpreting traffic correctly requires looking at every packet one by one, in order, and updating the protocol state at each step. That means our packet decoder has to run as a single thread and be highly optimized for throughput.

We can, however, move everything else out to separate threads so that the core decoder can run as fast as possible. Packetry runs as three threads, each feeding data to the next:

The capture thread deals with streaming captured packets from a Cynthion device over USB.
The decoder thread processes captured packets, stores them and builds the capture indexes.
The UI thread runs the user interface, reading from the indexes and stored packets to display the captured traffic in a human-readable view.

A key feature of the design is that all the interactions between these three threads are lock-free: they cannot block each other. The capture thread supplies packets to the decoder thread through a FIFO queue. The decoder and UI threads use our own lock-free stream implementation, which allows a single writer and any number of reader threads to efficiently share a growing data stream whilst it is being buffered and written out to storage, then mapped back into memory as needed.

Keeping these threads decoupled from each other helps us ensure that capture will always continue to run at a consistent throughput, no matter how complex the the traffic is or what analysis is being done in the UI.

Head to Head

So how fast is it? To give a quick illustration, here’s Packetry and Wireshark loading the same file, side by side. The file is a 300MB capture in pcap format of a HackRF in use.

Packetry finishes loading the file 10x faster — but you don’t even need to wait for that to happen to start exploring the capture. The view is ready to interact with as soon as the first packets are decoded. That happens almost instantly, and you’re up and running immediately with a fully hierarchical, human-readable view of the traffic.

Trying it out

Packetry is still in active development and we don’t have releases or binary downloads yet. If you’re really keen to play with Packetry you can build it from source and try it out with the example capture files that are included in the repository for testing. Build instructions are in the repository.

HackRF One Availability Update

2023-03-20T12:00:00

In December of 2022, we published a post about the HackRF One shortage and the hardware revision our engineering team completed so that we could continue manufacturing HackRF One. This hardware revision was necessary because we had difficulty sourcing critical components during the global chip shortage, mainly MAX2837- the RF transceiver IC used in every revision of HackRF One before r9. At the time of that post, we had a significant backlog of orders, and we were uncertain about how long production would take with COVID-19 slowing down operations at the factory in China. Today, we have good news: production of r9 went very smoothly, and the finished HackRF Ones started shipping to our warehouses in late February. As of now, all of the backorders for HackRF One have shipped to our resellers.

With over half of this last production sold and shipped due to the backlog, we are already preparing for a second 2023 production run in quick succession. Some lessons we learned from this HackRF One shortage are to invest in components early for products we know we want to keep producing and that components on the shelf are preferable to components on order if we can find them in stock at a reasonable cost. Fortunately, we found more MAX2839s (the substitute component for MAX2837 in r9) with good date codes and purchased them for a second production of HackRF One r9. We have also already purchased production quantities of several other HackRF One components that have very long lead times, like the clock generator chip, the CPLD chip, and the microcontroller. These components are on the shelf and ready for us to use in the upcoming production, so we don’t have any immediate concerns about unreliable chip distributor lead times impacting our production schedule. Most likely, it won’t be as easy to find more MAX2939s for future productions because that part is obsolete. That means there will only be one more production of r9, and subsequent hardware revisions will use MAX2837.

We are already ordering components with long lead times for HackRF One productions as far out as 2024. Before the chip shortage, it was entirely realistic to acquire all the components needed for HackRF One and complete a production run within six months. That is no longer practical because even though purchasing conditions are improving for some components, chip destributors are still quoting lead times of up to a year for several key HackRF One components. MAX2837 availability in particular remains scarce; the average lead time has tripled and the manufacturer price has nearly doubled. The MAX2837s we ordered in 2021 for Fall 2022 production have yet to arrive, although we do expect them to be delivered finally this summer. We plan to use those in a third 2023 production near the end of this year. We don’t know when (or if) things will return to normal with the chip market. So to prevent future production bottlenecks caused by one or two missing essential components, we will continue to plan manufacturing schedules and component orders further ahead of time.

We appreciate our resellers for their cooperation while we navigated the challenges presented by the global chip shortage, and their customers who waited patiently (some for months) for their HackRF One orders to be delivered. Thank you for being so supportive! We can’t understate this: you are the reason we are still here!

Free Stuff - February 2023

2023-03-10T12:00:00

The February recipient for the Great Scott Gadgets Free Stuff Program is Mihajlo. Mihajlo is a student in Serbia who will be studying Electrical Engineering in college. He plans to use the HackRF One we are sending him to teach people in his community about SDR, RF, LRPT images from NOAA, and other fun signals. Mihajlo is also an open source contributer to projects focused on providing simple scripts and instructions to set up low-cost base stations. We are proud to support Mihajlo in his projects as he gives back to his community in so many ways!

Free Stuff - January 2023

2023-03-06T12:00:00

The January recipient for the Great Scott Gadgets Free Stuff Program is Guillermo. Guillermo is from Spain. He had a career in computer security about ten years ago before switching to another career. He’s back now and excited to use the HackRF One we are sending him to explore interesting topics like RF, Lora, Zigbee, and BLE. We are happy to support Guillermo on his journey back into computer security.

Renaming LUNA Hardware to Cynthion

2023-02-15T00:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/renaming-luna-hardware-to-cynthion.

Until now, the name LUNA has referred both to our USB multitool hardware platform and to the USB gateware framework that supports it. From now on, we want these projects to have separate names. We’ve decided to name the hardware platform Cynthion. The gateware framework will continue to be called LUNA.

Why are we making this change?

This renaming is happening because we have often had conversations, both internally and with external folks, in which we’ve had to say, “Wait. Are you referring to LUNA hardware or LUNA gateware?” Additionally, we’ve repeatedly fielded questions from folks who have been confused about different features supported by the gateware framework vs. the hardware platform. One common point of confusion in conversation is that LUNA gateware supports SuperSpeed USB while the Cynthion hardware does not. Lastly, projects like ORBTrace and Amalthea use the LUNA gateware framework to drive their projects, but they do not benefit from the association with Cynthion. It would be nice for these projects if they could indicate that they are supported by LUNA gateware without making them seem like add-on boards for Cynthion. Meanwhile, Cynthion is no longer just a development platform for the LUNA gateware, it is its own product and we need a name to refer to just the hardware while in conversation.

What happens next?

In the next few weeks, you can expect to see the hardware design files move from the LUNA repository into a new Cynthion repository we will create in the Great Scott Gadgets organization on GitHub. Following that, you will see the hardware documentation migrate into a folder in the Cynthion repository. Before you receive your hardware, Cynthion, its enclosure, packaging, and marketing materials will be updated to reflect the new name.

All LUNA gateware framework materials will remain as they are in the LUNA repository. There should be no need for existing projects to change how they are interfacing with LUNA.

Why the name Cynthion?

When choosing a name for this hardware platform, we wanted to pick something moon-related like LUNA. As we scrolled lists of moon-related words, “apocynthion” and “pericynthion” stood out to us. We played with subwords like “pericynth” but as a team, we eventually settled on Cynthion. The word Cynthion means “related to the moon” and is derived from Cynthia, an alternative name for Selene, the Greek personification of the moon.

Free Stuff - December 2022

2023-02-06T12:00:00

The December recipient for the Great Scott Gadgets Free Stuff Program is Shiva. Shiva is new to hardware and IoT. We have sent Shiva a GreatFET One so they can do some research on devices they have in their own home. We are looking forward to hearing about their results!

LUNA Revision 0.5 Completed

2023-01-30T00:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-revision-0-5

We are happy to say that hardware revision 0.5 for LUNA has been completed and that revision 0.6 is well under way! Some highlights from revision 0.5 are an upgrade to using KiCAD 6, adding some of our planned part substitutions, and improving labeling. Full details of hardware revision 0.5 can be viewed in the GitHub pull request for that task https://github.com/greatscottgadgets/luna/pull/190. As for hardware revision 0.6, our current set of tasks can be seen in this GitHub issue: https://github.com/greatscottgadgets/luna/issues/185. Progress has been made on almost every item in the r0.6 checklist and we will check the items off as they have been finalized and put through our review process. We look forward to giving you more updates soon!

Getting Hired at Great Scott Gadgets

2023-01-02T00:00:00

Once in a while, we get emails from people in the community who want to know what they can do to increase their chances of getting hired at Great Scott Gadgets (GSG) when we do happen to open up a position. We really appreciate this enthusiasm! Below we outline some of the skills and topics we assess when hiring someone to join our small, completely-remote team.

Know our products and projects. Our products are listed on our website. The Software and hardware details for our products and projects are in the repositories on our GitHub. When we interview we ask which of our products you are familiar with, if there are any you are excited to work on, and if you have experience with any of them. While it is not required for an applicant to have used our products, it really helps when applicants have an idea of what our company does and what they would like to do when they join us. Yes, we often hire with a specific project in mind, but we do want to make sure the position fits the person and can often make adjustments.
Have skills in the tools and languages we use. Take a look at our GitHub repositories and see what technologies and programming languages we use. We are a company dedicated to open source and most of our development happens in the open by team members forking a repository, making changes in a branch, and then submitting a pull request just as anyone in the community is able to do. We do like to see GitHub contributions from new team members within the first few weeks of working at GSG so it is important to know at least one of the languages we work with well enough that you can jump right in.
Contribute to open source or build a project to talk about in interviews. Our interviews do not have any whiteboarding, homework, or any other excessively long skills testing process. We currently assess applicants on two phone screens and on code, projects, documentation, and writeups you have posted publicly. We do understand that some of the people eager to join GSG are coming from a career filled with NDAs or restrictions on personal projects and contributing to open source. If you don’t have public materials for us to review, please let us know and we’ll work with you to make accommodations.

If you have more questions about working at Great Scott Gadgets or our hiring process, please reach out to careers@greatscottgadgets.com.

Ubertooth Retirement

2022-12-22T17:44:00

After 12 years and 17 production runs, Great Scott Gadgets is retiring our first product, Ubertooth One, from our hardware catalog.

GSG’s founder Michael Ossmann designed Ubertooth One because he wanted a device that could detect and monitor Bluetooth. At the time, such instruments existed but cost at least five figures—prohibitively expensive for most security researchers. His goal was to design an open-source, affordable-to-make tool that anyone in the security community with basic soldering skills could assemble. At the project’s inception, his intent was not to sell hardware but to provide a solution to a problem that no one else had solved. However, demand from the community prompted him to start GSG and launch a Kickstarter campaign that funded the first production.

Ubertooth One enabled more than starting a company; it became an essential part of the wireless security professional’s toolkit and aided research that improved Bluetooth security and function. One notable example is Mike Ryan’s Bluetooth Low Energy (BLE) security research. Through this work, Mike contributed BLE capabilities to Ubertooth and became a core developer of the project. More recently, Ubertooth One was instrumental in research into Apple’s Continuity protocol presented by Sam Teplov at ShmooCon in January 2020. Over the years, Ubertooth has equipped researchers to improve the Bluetooth protocol’s function and reverse engineer countless Bluetooth devices and even non-Bluetooth 2.4 GHz wireless systems such as electric skateboards. Talking to Michael this week about his journey with Ubertooth, I learned of an encounter at a conference in Asia where a stranger approached him and said “Thank you for Ubertooth. I couldn’t have done my Master’s thesis without it.”

At the time Ubertooth One was designed, BLE didn’t yet exist. The protocol now known as Bluetooth Classic was the only Bluetooth protocol. It was common for Bluetooth devices to operate in non-discoverable mode, making them invisible to all but the most expensive monitoring tools. Ubertooth One made it possible to detect and identify non-discoverable Bluetooth devices, an essential function for wireless security practitioners and researchers. Today, most Bluetooth devices use BLE rather than Bluetooth Classic, and several low-cost options are available for monitoring BLE. For more esoteric capabilities, including the detection of non-discoverable Bluetooth Classic devices, researchers can use Software Defined Radio platforms such as HackRF One to implement the same functions as Ubertooth. Even though Ubertooth is still a valuable and widely adopted tool, it is no longer the only option.

When the global chip shortage struck, our small team faced difficult choices about which products to redesign for available components. After considering changes in the Bluetooth landscape, the amount of redesign effort required, and the work cycles available to our team, we decided it was time to retire Ubertooth One. Consistent with our mission, we will continue to prioritize making and maintaining tools that, like Ubertooth in the early years, allow innovative people to do things they haven’t previously been able to do.

Even though we are now sold out of Ubertooth One, you may still be able to buy a unit made by GSG while reseller stock lasts. The Ubertooth project is open source, so if you can’t purchase an Ubertooth One, you are welcome to use the design files in the project repository to make your own. We will continue to monitor the repository for issues and pull requests, but we have no plans for hardware or software enhancements.

The Ubertooth project has meant a great deal to Great Scott Gadgets, and we’d like to sincerely thank our users, our resellers, and all the people who have supported us and contributed to the project over the years for coming on this journey with us. Special thanks to Dominic Spill, who started gr-bluetooth, which was foundational to Project Ubertooth; Jared Boone, who mentored Michael in the original hardware design; and Mike Ryan, who made significant contributions to the project. If you have any stories you’d like to share about Ubertooth One, please come tell them in the Great Scott Gadgets Discord server or email us at info@greatscottgadgets.com.

Free Stuff - November 2022

2022-12-19T12:00:00

The November recipient for the Great Scott Gadgets Free Stuff Program is Alex of the CCCSBG Hackerspace. A group of people at the CCCSBG Hackerspace are making an effort to explore the protocol spoken between ancient IBM3270 terminal equipment and their controller. Alex points out that Andrew Kay has done similar work for text-only traffic [1], but mentions that his hackerspace wants to chip away at the graphics capabilities of the IBM 3270. We have sent Alex and CCCSBG a GreatFET One so they can sniff the traffic that is going through the NS DP8340 and NS DP8341 chips on the devices.

[1] https://ajk.me/building-an-ibm-3270-terminal-controller

HackRF One Shortage

2022-12-19T12:00:00

The past couple of years have been challenging for Great Scott Gadgets. The global chip shortage in particular has put demands on our team unlike anything we’ve faced in the past, and we have been working hard to navigate its effects on our supply chain for HackRF One and our other products. Revenue from the sale of hardware sustains our business, allows us to improve our existing products, and helps us to continue the research and development work that brings new and innovative open source tools to the community. If you have tried to purchase a HackRF One recently, you may have found that many of our resellers are sold out. That is because our resellers have orders in with us that we haven’t been able to manufacture and deliver (yet).

Despite careful planning and ordering components more than a year in advance, we are off-schedule with production of HackRF One. This is primarily due to the unavailability of two components that don’t have simple substitutions: HackRF’s clock generator chip (SI5351C) and RF transceiver IC (MAX2837). We made deposits to chip suppliers for these two components in Autumn of 2021, and had planned to complete production in Autumn of 2022. Based on the lead times given to us when we placed our orders, this should have been a realistic timeline. However, in the second quarter of 2022, we learned from our contract manufacturer that MAX2837 would be delayed to June of 2023, almost a year later than promised. SI5351C was delayed to March 2023. We even had a backup order of SI5351C that was canceled by the supplier completely.

These component delays could have delayed the production planned for Autumn of 2022 to late Summer 2023 and caused a lengthy HackRF One shortage. Thankfully the Great Scott Gadgets team responded quickly to identify and source two available substitute components that (with significant redesign effort) allowed us to begin a production run of HackRF Ones this year. Since identifying substitute components earlier this year, our engineering team has completed a new revision of HackRF One to accommodate the substitutions while continuing to deliver the performance users expect from HackRF One. Production of this new revision is currently in progress.

Thanks to the diligent work of our engineering team, the HackRF One shortage will not be as long as we had initially feared based on the component delays. However, our warehouse shelves are empty at the moment as we wait for our China-based contract manufacturer to complete production. We currently have almost 2,000 units in HackRF One backorders from our resellers waiting to be filled. Last week, we learned that the COVID-19 outbreak in China will delay production into January 2023, and possibly into the Chinese New Year holiday, when the factory will close for a couple of weeks near the end of January. That means that we can expect delivery to resellers in February 2023 if there are no further unforeseen delays.

If you have a preorder in with one of our resellers for HackRF One, please be patient with them. It’s likely that, like Great Scott Gadgets, they planned ahead and did everything they could to keep HackRF One in stock, but there are many things happening right now that are beyond their (and our) control. We thank you for your continued support of our resellers and of Great Scott Gadgets.

Updated Delivery Date

2022-11-28T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/new-delivery-date

With almost every project, delays tend to happen. LUNA is no different. In good news, we have received all of the components needed for LUNA. In not-so-good news, we have not been as lucky in gathering components for the other products at Great Scott Gadgets. Over the last couple of months, we’ve had to move our head hardware designer (Michael Ossmann) from the LUNA project and onto redesigning some of our other hardware so Great Scott Gadgets can continue to exist through this chip shortage. The result is that we are behind on redesigning LUNA to accommodate the larger FPGA, as discussed in a previous update.

As of now, we have three more hardware revisions we need to complete for LUNA. Revision 0.5, with the original FPGA, has some bug fixes that need to be completed. Then, revision 0.6, with the new FPGA, needs to be started, tested, and finalized. Lastly, revision 1.0, the one we will send out to all of you, needs to be started, tested, and finalized. In the best-case scenario, revision 1.0 will be only a relabeling of revision 0.6. Along with hardware redesigns, we also need to design a slightly bigger case to accommodate the bigger LUNA board and build a test jig that will be used to test the quality of LUNAs built by our manufacturer. We expect these hardware tasks to take three months to complete. Following our hardware work, we will be manufacturing LUNA and shipping it out to you. The manufacturing and shipping processes are expected to take three months.

Altogether, our current delay in getting LUNA to you is another six months. This puts LUNA in your hands in June 2023. We are very sorry about this delay. Every week that we were working on keeping Great Scott Gadgets going, we thought “this is the last week of non-LUNA hardware, we’ll be back to LUNA hardware next week”, but new chip shortages and other roadblocks continued to appear. As soon as those issues were overcome, we reviewed our timeline and wrote you this post. We thank you very much for your patience and continued support as we work to get LUNA into your hands.

Free Stuff - October 2022

2022-11-21T12:00:00

The October recipient for the Great Scott Gadgets Free Stuff Program is M0nkeyDrag0n! M0nkeyDrag0n has requested a GreatFET One in order to explore a potential bug he found in Windows. We love supporting researchers and look forward to hearing about what M0nkeyDrag0n finds.

Packetry Preview

2022-10-26T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/packetry-preview

Due to the delays caused by the chip shortage, there’s not been a lot to report on the LUNA hardware front recently – but behind the scenes, we’ve been hard at work on the software stack which will accompany it. Over the next few weeks, we’ll be making some more updates about that work.

One of LUNA’s key features is its ability to act as a passive sniffer: it can be connected between a computer and the USB devices connected to it, capturing all the traffic between them. This is a powerful capability for debugging, reverse engineering, security research, or just learning how things work.

Up until now, USB capture and analysis with LUNA has primarily used ViewSB, an open source USB-specific application developed here at GSG. ViewSB displays captured traffic as a tree view that follows the structure of the USB protocol: packets are grouped into transactions, which are grouped into transfers. The tree view makes a USB capture easy to understand at a glance. It’s also possible to view LUNA captures with Wireshark, but although that’s a popular and capable tool, Wireshark’s USB dissector provides only a packet-by-packet view of the capture.

As we started to test more and more demanding use cases with LUNA, we began to find that neither tool delivered the performance we wanted to see. Wireshark can take considerable time to load or filter captures with many millions of packets, despite its mature C implementation. ViewSB is written in Python, an interpreted language that generally relies on gluing together native libraries to attain high performance. As we started to deal with larger captures from LUNA, ViewSB’s speed became the bottleneck, and we began to work on moving more of its work into native code.

We started to prototype a new capture and decoding pipeline, focusing on a new data structure design that would be fast to both construct and access, and that would scale to large captures. Initially we worked in C, with some UI code in Python, and intended on integrating this work into ViewSB.

Another issue we wanted to address was the ordering of items in the view. When multiple transfers happen simultaneously, a conventional tree view can become confusing or misleading, as the tree structure may not match the chronological order of events. Fixing this needed deeper changes, especially when combined with the need for efficient handling of large captures.

As development on both issues progressed, we came to the conclusion that we could make quicker progress, and achieve a better end result, if we directed our efforts into a new application written in Rust. That project is now approaching readiness for its initial release, and we’ve named it Packetry.

Packetry isn’t just ViewSB rewritten in Rust; the underlying design is fundamentally different, and it has been redesigned from the ground up. Our goals when developing Packetry were:

To provide the best possible end user experience for USB analysis with LUNA.
To handle large captures effortlessly, with minimal loading time and instant UI response, regardless of capture size or complexity.
To present a new visualization approach: one that maintains the hierarchical advantages of a tree view whilst keeping timing relationships visible.

As with everything we develop, Packetry is open source, and you can follow the work in progress on GitHub. Over the next few weeks, we’ll be merging in the various feature branches we’ve been working on as we get ready for the initial release. As we go along, we’ll make some further updates here on Crowd Supply, explaining the new design in more detail.

Free Stuff - September 2022

2022-10-20T12:00:00

The September recipient for the Great Scott Gadgets Free Stuff Program is Brett! Brett volunteers at the Wasatch 100 in Utah. The Wasatch 100 is a 100 mile endurance run through the Wasatch National Forest. Brett is planning to use the HackRF One we are sending him to streamline the race aid station communications. We look forward to seeing the solution he comes up with.

Introducing Opera Cake

2022-10-03T13:00:00

Starting this week, we are shipping Opera Cake, our multi-use antenna-switching add-on for HackRF One!

This add-on board has two primary ports, each connected to any of eight secondary ports, and it is optimized for use as a pair of 1x4 switches or as a single 1x8 switch.

As a 1x8 switch, Opera Cake can connect your HackRF to a variety of antennas at once, such as a long wire antenna for HF bands, a discone for VHF and UHF, a dipole for 2.4 GHz, and a dish for a satellite band. Once connected to your Opera Cake you can switch between all of your antennas in software instead of making physical hardware swaps.

When set up as a pair of 1x4 switches you could use Opera Cake as a switched filter bank. To do this, connect port A1 to B1, A2 to B2, A3 to B3, and A4 to B4 through physical SMA filters and cables of your choosing. This setup allows you to change your transmit or receive to be through the filter of your choosing without having to reconnect hardware every time you would like to use a different filter.

You can control Opera Cake for HackRF One manually with our command-line software hackrf_operacake, or you can configure HackRF One’s firmware to automatically switch Opera Cake ports based on frequency or time. Automated antenna switching and hackrf_operacake are both available in the latest HackRF One release. You can learn more about Opera Cake’s modes of operation in our HackRF documentation.

If you are looking to pick up an Opera Cake of your own, please check our website for the list of Great Scott Gadgets Opera Cake resellers. We hope you enjoy Opera Cake and stop by our Discord, or tag us on Twitter or Instagram, to show us your Opera Cake projects!

Pseudo-Doppler Redux, ShmooCon 2018

2022-09-19T12:00:00

Back in 2018 Michael Ossmann teamed up with Schuyler St. Leger at ShmooCon to present “Pseudo-Doppler Redux”; a talk about taking a modern approach to the implementation of pseudo-doppler direction finding (DF) with Software Defined Radio (SDR). This presentation demonstrates what pseudo-doppler direction finding is and gives an example of Opera Cake usage.

We hope you enjoy watching the presentation!

Free Stuff - August 2022

2022-09-03T12:00:00

The August recipient for the Great Scott Gadgets Free Stuff Program is Trevor! Trevor is working on a project called Hack365 where he is attempting to blog about one hack (or make or break or fix or learn) each day until next DEF CON. We are excited by how enthusiastic Trevor is about documentation, sharing his experiences with the community, and learning new things. One of the projects Trevor plans to take on is learning about his ceiling fan’s RF receiver, which is an excellent place to start when you are learning about RF. Trevor plans to share his progress with the DEF CON group DC612 as he progresses. We wish Trevor happy hacking and hope he continues to share what he learns so all of the community can benefit!

GreatFet Feature on Hackaday

2022-08-15T12:00:00

Back in 2019 over on Hackaday, Mike Szczys wrote a piece called “Hands-On: GreatFET is an Embedded Tool That Does it All”. This article covers:

a review of the GreatFET One hardware,
our matching GreatFET One sticker,
the wiggler,
a test run of GreatFET One and an I2C OLED display,
Facedancer and USB emulation, and
how to do a quick recovery using DFU.

We hope you check it out!

Free Stuff - July 2022

2022-08-10T12:00:00

The July recipient for the Great Scott Gadgets Free Stuff Program is Manoj Kumar Mondal from India! Manoj requested a HackRF so he could take some security courses at his university; having a HackRF is a pre-requisite for the course. We look forward to hearing from Manoj as he progresses through the course!

Free Stuff - June 2022

2022-07-11T12:00:00

The June recipient for the Great Scott Gadgets Free Stuff Program is Kyle from SkullSpace. SkullSpace is a hackerspace located in Winnipeg, Manitoba, Canada. Kyle plans to put together a group of SDR and wireless enthusiasts. This group will put on classes, host labs, and lead projects that help the community learn more about SDR and wireless. If you are ever in Winnipeg on a Tuesday evening we hope you take advantage of SkullSpace’s open night and check out their hackerspace!

FPGA Substitution on LUNA

2022-06-15T17:17:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/fpga-substitution

Global supply chain issues continue to be difficult to traverse, but once in a while we do get a little bit lucky! In a previous update [1] we mentioned that Lattice had pushed out the lead time on our FPGAs for LUNA from 30 weeks to 60 weeks. Well, the expected delivery date for those FPGAs got pushed out again. Thankfully, we were able to purchase another ECP5 part for the first batch of LUNAs from an authorized Lattice distributor in a 381-ball package rather than a 256-ball package. We already have the 381-ball FPGAs in hand, so we don’t have to worry about those lead times changing again. We are still waiting on other components though, so with this FPGA substitution our estimated shipping date for LUNA will still be December 2022.

Changes to LUNA

Both FPGAs are from the same manufacturer and are part of the same line. The firmware and software we are creating will work the same regardless of which of the FPGAs is present on a given LUNA board. The primary difference impacting LUNA is that the substitute FPGA is slightly bigger than the original FPGA we had picked out. The original FPGA was 14x14 mm and the substitute FPGA is 17x17 mm. To accommodate this change in size we expect to increase the board area of LUNA to 51x51 mm instead of its original 48x48 mm.

This change adds 297 millimetres squared of available space. 93 millimetres squared of the extra space will be taken up by the bigger FPGA which leaves 204 millimeteres squared to use. The Great Scott Gadgets team has not yet settled on what we will be doing with the extra space but we will update you all as soon as we finalize our decisions. If you would like to make requests for or share your thoughts on what to use this space for, please come discuss in our Discord server.

[1] https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-delayed

Free Stuff - May 2022

2022-06-14T12:00:00

The May recipient for the Great Scott Gadgets Free Stuff Program is C.J. who is a Broadway tour sound engineer that works backstage with wireless RF microphones. Every week the tour moves to a new location and C.J. has to re-coordinate wireless frequencies for the show. He’s hoping to use the HackRF we are sending him to improve his RF monitoring and create more precise RF layouts for the travelling shows.

Free Stuff - April 2022

2022-05-04T12:00:00

The April recipient for the Great Scott Gadgets Free Stuff Program is Anmol, a high school student in India! Anmol learned about Great Scott Gadgets after watching Michael Ossmann’s video on complex numbers, which is part of his Software Defined Radio with HackRF training video series. Anmol is the IT president of their school and is excited to use the HackRF we will be sending them to share the world of Software Defined Radio with other students.

Free Stuff - March 2022

2022-04-05T12:00:00

The March recipient for the Great Scott Gadgets Free Stuff Program is Katerina Autumnrain! Katerina had such an enthusiastic and detailed application to the Free Stuff Program that we just had to send her the HackRF One she requested. In her application she had this to say:

“I believe that the HackRF could enable me to open up the oft more confusing aspects of radio, particularly modulation modes like QAM and digital systems like satellites and P25/DMR. I’d also like to try and promote the higher frequencies (33cm and beyond). Once the bandwidth and frequency limitation is lifted I can more or less apply that knowledge I’d gain from those systems and make both learning experiences and some pretty neat tech for people to explore, utilize, and build themselves. I ultimately believe I could cultivate a sort of resurgence in radio geekery in my area, as it unfortunately seems to be on the downturn somewhat, and promote higher levels of curiosity.”

It’ll be really exciting to follow Katerina’s updates on her HackRF-fueled radio journey!

Free Stuff - February 2022

2022-03-11T12:00:00

The February recipient for the Great Scott Gadgets Free Stuff Program is Matthew Hilts! Matthew is a student at the University of Dayton who will be spending his Spring semester learning about and using GNU Radio. To help enhance his studies we have sent Matthew a HackRF One. We look forward to hearing about what he learns!

HyperRAM controller for USB analysis

2022-02-09T12:00:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/hyperram-controller-for-usb-analysis.

One of LUNA’s core features is the ability to perform protcol analysis of USB 2.0 low-speed, full-speed, and high-speed. For most target devices, LUNA can endlessly stream the capture directly to a host PC over its own high-speed port. However, for high-bandwidth target devices that can’t be streamed in real-time, LUNA has 8 MiB of memory on board to buffer captured data before sending it upstream.

On LUNA we’re using HyperRAM, a type of pseudo-static RAM, which is capable of achieving relatively high speeds while being much simpler to work with than DRAM as it handles refreshing of the memory array by itself. Recently we’ve been working on our Amaranth gateware that interfaces with the RAM, implementing support for memory-space reads/writes and speeding it up so that we can keep up with USB analysis.

Speed

For USB analysis, we need to be able to stream data through the RAM at a nominal 480 Mbit/s but, since the ram is half-duplex, we need to hit at least double that. We also need to allow for some overhead for the RAM protocol. In our controller we run the RAM at 120 MHz DDR for a nominal rate of 1920 Mbit/s, which gives us plenty of margin to keep up with high-speed USB.

The Lattice ECP5 FPGA used on LUNA has a nifty feature in the I/O cells called gearing, which serializes/deserializes data to allow the I/O pin to run at a high speed without requiring the FPGA fabric to match it. For our HyperRAM controller we use the IDDRX1 and ODDRX1 cells, which take a 2-bit signal and read from/write to I/O pin at double the speed.

Timing challenges

A challenging part of interfacing with HyperRAM is the wide range of data-valid timing. The datasheet specifies that the data lines can be valid anywhere between 1 ns and 7 ns after a clock transition, and become invalid anywhere betwen 0.5 ns and 5.5 ns after the next clock transition. Running at 120 MHz the time between clock edges is only 4 ns, so this means that there is no fixed window in which to sample! The diagram below shows some examples of how the data-valid window could be shifted relative to the clock:

We solve this by using the ECP5’s I/O delays to shift the data-valid window and align it with a clock edge. These delays are variable so we can adjust them during operation to find the range of values that result in successful memory reads, then pick the value in the middle for the ideal sampling point.

Debug tooling

For projects like this, it’s important to have good tools for debugging! As part of this work we wrote a HyperRAM decoder for glscopeclient, an open source frontend for oscilloscopes. This makes it easy to interpret waveform captures from the real hardware, and verify that everything is working as expected. The decoder has been merged upstream, so it’ll be available with any recent glscopeclient install.

Free Stuff - January 2022

2022-01-27T12:00:00

The January recipient for the Great Scott Gadgets Free Stuff Program is Rüzgar Erik and the Sivas Science High School Science and Tech Club! The club has about 35 students who meet weekly to learn about various topics and develop their own projects. We will be sending this club their very own HackRF One so they can upgrade from their current SDR which they made from an old tv tuner SDR and Rüzgar Erik’s Baofeng radio.

Once they have received their HackRF One, the club will try to receive images from NOAA, find number stations, and dive into the world of RF.

Free Stuff Program Refresh

2022-01-11T17:50:00

Free Stuff is a program where we at Great Scott Gadgets give free hardware to a person or group once per month. We’ve been running this program since February 2015 by having interested parties email us their free stuff requests.

Starting now, Great Scott Gadgets has a new Free Stuff Program application process where, instead of emailing us, anyone interested in getting free hardware from Great Scott Gadgets can apply using our new application link. The application link and extra details on the Free Stuff Program are available on our Free Stuff page.

Free Stuff recipients are chosen once per month out of all applications we have received over the last twelve months. We typically give out one piece of hardware free of cost, pay for shipping, and feature Free Stuff recipients on our blog. With this refresh of the Free Stuff Program we are currently at zero applications so now is the best time to apply. We look forward to seeing your applications!

Free Stuff, October 2021–December 2021

2022-01-05T12:00:00

October

Charles, a computer science student in the UK, asked us for a HackRF One because he wants to learn about device interactivity and to search for potential vulnerablities in his own devices.

November

The Free Stuff recipient for November is UW Orbital, a new student design team at the University of Waterloo (Canada) with over 40 active members. They are developing a 3U CubeSat for the Canadian Satellite Design Challenge (CSDC). They say, “The team is working on an imaging payload that will allow amateur SDR radio operators from around the world to request an image of their location from orbit, with the goal of attracting beginners to ham radio as a hobby and providing education in communications systems. The HackRF One will be crucial to the team’s prototyping phase to test uplinks and downlinks to the CubeSat, and could potentially even be used as the team’s ground station transceiver.”

December

Noah in Kentucky asked us for an Ubertooth One for his son Saul to use in an upcoming STEM night at his school. Saul wants to help other kids learn about wireless technology, so he’s planning to demonstrate something exciting.

Free Stuff, July 2021–September 2021

2021-12-16T20:00:00

July

July’s recipient is Nick with Urban Rivers. This organization is building a floating park in the Chicago River that has been getting a lot of bird layovers. Nick wants to integrate a HackRF One into Motus Wildlife Tracking System to study migratory patterns and capture a more complete picture of avian travel.

August

Kevin runs the Roanoke Robotics Club and asked us for Free Stuff to teach kids about electronics, etc. We sent a box of Throwing Star LAN Tap Kits so they can practice soldering.

September

Tandin is a person of many talents, technical and artistic, in Bhutan. They asked for an Ubertooth One for fun, experimentation, and learning.

Free Stuff, April 2021–June 2021

2021-12-16T18:00:00

April 2021

Eric wrote to us on behalf of the Chaffey High School (Ontario, CA) Tech Club, asking for a HackRF One. He’ll be graduating from the University of Tulsa soon and as a past president of the club, he zooms into the club’s meetings to offer help with computer science and cybersecurity topics. Now he’ll be able to help the students use a HackRF One for their own projects. They’ll also be holding workshops on RC Car Hacking, Listening to and Broadcasting AM/FM Radio Signals, and Mapping Planes with ADS-B Signals.

May 2021

The Free Stuff recipient for May is João Pedro Polito, a student at the Universidade Federal de São João del Rei, Brasil. He needs a HackRF One for a ground station for nanosats and stratospheric balloons.

June 2021

In June, Amy asked us for a HackRF One to explore the intersection of radio and cybersecurity. She’s studying for her CISSP certification and is the only woman in her local Amateur Radio club, so she wants to mentor and encourage others to join the community.

Free Stuff, January 2021–March 2021

2021-12-16T12:10:00

January 2021

The first Free Stuff recipient of 2021 is Christos Voutichtis, an artist in Gemany who asked for a HackRF One for his project, Order of Sound. He tells us, “This is an arrangement of five complex antenna receivers which make the electromagnetic waves that permanently surround us audible. This data, which we perceive as sound, is processed in a program (VVVV) that I have designed which enables the analysis to translate them into graphical elements, which are then rendered as an abstract architecture in the form of a real-time projection. The viewer enters an immersive megastructure of abstract data landscapes in a highly aestheticized, scenographic context. The visualization is created as a 3-D virtual Space and allows the participant to wander through emerging data structures.”

February 2021

In February, we received a HackRF One request from Anil Karki, the president of Innovative Ghar Nepal, a non-profit for the development of innovative products and services in Nepal.‘Ghar’ in Nepali means ‘Home’and their organization is a home for students, developers, makers, technologists, and artists to gather to promote, educate, explore, create and share their skills and curiosity. They need their new HackRF One for their autonomous medical drone project.

March 2021

Mike in New Jersey asked us for an early graduation present: a YARD Stick One to develop an app for use in his new job.

LUNA Now Uses Amaranth HDL

2021-12-15T17:17:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-now-uses-amaranth-hdl

Over the next while we will be updating the LUNA project to use “Amaranth HDL”, which is the new name whitequark and other maintainers have chosen for their project. Amaranth is the hardware description language used in LUNA. The Amaranth gateware provided with LUNA enables you to create USB devices in gateware, firmware or both. Amaranth also enables LUNA to customize itself to the task at hand, which gives it access to unique features like user-defined hardware triggering and simultaneous capture of additional external or internal signals. The GitHub location for the Amaranth HDL project is https://github.com/amaranth-lang/ and if you want to talk with other Amaranth users you can join the #amaranth-lang IRC channel on http://libera.chat.

Testing a HackRF Clone

2021-12-07T14:21:00

Like every open source hardware company, we’ve seen clones of our products for sale on the Internet. These clones arguably provide a valuable service to the community, making our designs more widely available and at a price more people can afford. However, they also have negative effects such as an increase on our technical support burden without a corresponding increase in revenue to pay our staff. When the quality of a clone is poor it may also degrade the reputation of our products.

Our most frequently cloned product is HackRF One. While we have every reason to believe that some of the HackRF clones on the market are perfectly functional, we’ve seen users struggle to get others to work at all. Some of the clones have been completely dead on arrival or have had other hardware problems. In general, it seems that few of the clones have been tested by their manufacturers. This can be particularly problematic if returns are not accepted.

We recently decided for the first time to order a HackRF clone and test it to see how well it performs. We chose this particular clone because it has an updated design claimed to improve upon our own design. We’re interested in potential improvements we can make to our own product, and it seemed that the easiest way to test these modifications would be to simply buy the modified clone.

When we plugged the clone in, it appeared to function normally. It had shipped with firmware built from the Havoc repository. This makes some sense as the seller also sells a clone of Jared Boone’s excellent PortaPack. If someone were to purchase both products, the PortaPack would work out-of-the-box with the installed firmware. We weren’t testing with a PortaPack, so we did some initial tests with the installed firmware and then replaced the firmware with a fresh build from our repository.

After confirming basic functionality, we executed a sweep to test the maximum output power across the entire 6 GHz frequency range. We did this by scripting a sequence of hackrf_transfer transmit commands while the device was connected to a spectrum analyzer. The results were troubling.

The clone clearly suffered from performance problems above 1 GHz, generally getting worse at higher frequencies. At 6 GHz, this culminated in a whopping 22 dB of loss compared to the GSG HackRF One. (That means that the GSG device produced more than 150 times the output power of the clone.)

It is important to realize that we tested just one sample clone, so our results may not be representative of the average performance of this model. On the other hand, although these results are compared to a single Great Scott Gadgets HackRF One, we know that every GSG HackRF One is factory-tested to ensure that it meets our performance standards.

Next we tested the receive performance by using QSpectrumAnalyzer with the hackrf_sweep backend. We set the gain to 40 in QSpectrumAnalyzer which results in moderate values for the two internal RX gain stages but leaves the RF amplifier off. We connected the device to a signal generator producing a -30 dBm signal, slowly swept across the 6 GHz frequency range.

The receive results were even worse than the transmit results. While the transmit test indicated performance problems above 1 GHz, the receive test revealed problems across the entire frequency range. Above 5 GHz the received signal was buried in the noise floor, completely undetectable above 5.6 GHz by QSpectrumAnalyzer with these settings. Note that the RF amplifier was disabled in the receive test but had been enabled in the transmit test.

At this point we ran the clone through our factory test procedure which, in agreement with the previous results, indicated multiple failures at both high and low frequencies. This unit would not have passed our quality control.

We suspected that there may have been multiple reasons for these failures including problems with the design changes as well as manufacturing defects. We didn’t think it would be worth our time trying to isolate every problem, but we did want to explore the effect of the most interesting modification to the design, a protection circuit purported to reduce susceptibility to damage in the RF front end. The simplest way we thought of to test the performance impact of the modification was to remove it and retest the board without the protection circuit in place.

A repeat of the transmit test allowed us to see how the protection circuit affected signal power at various frequencies. As we suspected, a significant portion of the loss at higher frequencies was eliminated by removing the protection circuit. However, the average performance below 5 GHz was little changed, suggesting the presence of additional design or manufacturing flaws.

10 dB of loss at the high end of the frequency range seems to us like a steep price to pay for some protection. HackRF One is already weakest at 6 GHz. If it were that much weaker, I’m not sure we would be comfortable advertising 6 GHz capability.

We are interested in increasing the robustness of the HackRF front end, but any changes we make would need to maintain acceptable RF performance. Perhaps some performance loss in exchange for protection could be acceptable if the protection were proven by test results. We have not seen any test results for the effectiveness of the protection circuit on this HackRF clone, but it is clear from our tests that its effect on RF performance is not acceptable.

HackRF One has an RX input rating of -5dBm. To the best of our knowledge, it is not possible to damage the front end without exceeding this level. We are working on identifying reproducible scenarios that can cause damage to the RF front end so that we can set up reliable and repeatable tests for front end protection. This will enable us to test changes that might increase the RX input rating and reduce the chance of damage in the field.

We’re able to continue supporting and developing HackRF One and other tools thanks to the many people who choose to purchase genuine Great Scott Gadgets products. Every GSG HackRF One is tested for quality at the factory. We provide technical support for our products, and we accept returns of faulty units through our authorized resellers.

Hopefully some of the HackRF clones on the market perform better than the one we tested. The best way we know of to ensure delivery of a working HackRF is to buy it from one of our resellers. If you’ve bought hardware from us for this reason or just because you want to support our ongoing open source development, thank you very much!

Shutting Down GSG Project-Specific Mailing Lists

2021-12-01T17:17:00

Thank you to everyone who has been a part of the GSG project mailing lists. We at Great Scott Gadgets appreciate all of the conversations and friendships that have been forged on these lists. Over the last few years we have not given our project-specific mailing lists the attention they deserve; instead we have been focusing our efforts on Discord and GitHub. As such, we will be disabling all the mailing lists except for GSG-announce. Links to the mailing list archives for Ubertooth, YARD Stick One, GreatFET One, and HackRF will all remain available on their individual product pages. Current links to the archives are here:

We hope to see all of you on Discord and GitHub soon!

LUNA Delayed

2021-11-10T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/luna-delayed

LUNA is delayed. All of us at Great Scott Gadgets are sad to have to give this news, but the global chip shortage and supply chain chaos has impacted our LUNA manufacturing and delivery timeline more deeply than anticipated. Unfortunately, LUNA is now expected to start shipping December 2022 because the lead time for the ECP5 FPGA chip we use on LUNA doubled between July and September. There isn’t a suitable substitute component for the ECP5, so our timeline depends on Lattice’s production schedule for this chip. Please know that getting LUNA into your hands as soon as possible is our highest priority, and has been since before the Crowd Supply campaign was launched.

During our Crowd Supply campaign planning, we did a lot of prep work to make sure we had the most accurate estimate of LUNA time to delivery possible. Our planning involved getting seven quotes and lead times from four different contract manufacturers in the time leading up to the campaign. One of these manufacturers stood out to us and we have now requested quotes and lead times from them twice. We received the first quote from this manufacturer on July 10th, which was prior to the campaign, and the second on September 17th, which was just after we got the the funds from the campaign.

The July 10th quote indicated that the microcontroller (ATSAMD11) on LUNA would be the component with the longest lead time at approximately 52 weeks. This was unsatisfactory as we did not want to wait over a year to get LUNA to you. We started looking for substitutions and alternative component sourcing methods immediately. We found an alternative source for the ATSAMD11 very quickly but did not know how many to order since our crowdfunding campaign hadn’t ended and we didn’t yet have the funds to order components. The day the campaign ended we put our order in for the microcontroller. We are happy to say that we received these components at the end of September! Our next step is to ship these parts from our office to our manufacturer.

The component with the next longest lead time on the July 10th quote was the ECP5, which is the main FPGA on LUNA. Our manufacturer gave us a 30-week lead time on this component in that quote, which is what we based our LUNA timeline on. When we got the September 17th quote, the lead time jumped from 30 weeks to 60 weeks. The ECP5 is now the LUNA part with the longest lead time. Until recently, the longest we typically have had to wait on any one part for a Great Scott Gadgets product was 16-20 weeks so many of these lead times are outside of our usual expectations.

Since receiving the bad news about the ECP5 lead time, we have made efforts to reduce the time to delivery. First, we attempted to shorten the ECP5 lead time by contacting Lattice directly to see if they could work with our manufacturer to supply ECP5s for LUNA. This attempt led to a dead-end and did not improve our timeline. Next, we worked with our manufacturer to source the ECP5s from another parts distributor; we had some success there as the manufacturer was able to find another source of ECP5s with a 50-week lead time. We have asked them to put an order in for these ECP5s. At the same time we found another parts distributor that was able to sell us ECP5s quoted 36 weeks, and we ordered them immediately. The next day we received an email from the distributor of the second round of ECP5s we ordered and they updated their lead time from 36 weeks to “to be determined”. Neither of these ECP5 orders are cancellable so we’ve invested heavily in getting LUNA to you as soon as we can. We hope that one order or the other will come in sooner than the 50-week lead time. We will keep you updated!

While we are disappointed that we’ve had to revise our estimated ship date to account for the component delays caused by the global chip shortage, we do have some good news. The delay gives our small team even more time to hone the LUNA software and experience before getting it into your hands. We will use this time to collect and address more feedback from our beta testers, create extra demos and training material, and continually improve our documentation.

If you have any questions, thoughts, or suggestions please reach out to the Great Scott Gadgets team through GitHub or Discord at any time. We would especially welcome any leads about ECP5s!

Pmod Host Ports Added to Encased LUNAs

2021-09-21T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/pmod-host-ports-added-to-encased-lunas

In one of our updates on CrowdSupply we asked you all for feedback about whether populating the optional Pmod host ports would be a welcome addition to LUNA, and whether they should be added to bare board LUNAs, encased LUNAs, or both. We got many comments through our Discord, direct messages, email, and GitHub. The feedback was overwhelmingly in favour of adding Pmod host ports to encased LUNAs only, so we are going ahead with that change!

LUNA General-Purpose Digital I/O

Our main goal in adding the Pmod host ports/footprints to LUNA was to add general-purpose digital I/O functionality to the board. This functionality can be used, probably most importantly, as trigger inputs or outputs that are synchronous with USB operations on LUNA or a device connected to LUNA. We’ve already used this I/O ourselves to test a circuit option that is now included in the latest LUNA design! Mike Walters has also used the Pmod host ports to stream data from a proprietary thermal camera interface.

Pmods and Pmod Host Ports

Pmod stands for “Peripheral Modules”. Pmods are external boards that can be plugged into Pmod host ports on a host board to add functionality to a microcontroller or, in LUNA’s case, an FPGA on that board.

“This functionality includes audio amplifiers, GPS receivers, USB to UART interface, seven-segment displays, accelerometers, H-bridges with input feedback, analog-to-digital converters, and much more” [1]. Pmod host ports are made of 6-pin sections where one pin is for power, another is for ground, and the last four provide digital I/O [2]. These 6-pin sections can be used for plugging in Pmods, or they can be used as needed for general-purpose digital I/O. Digilent has blog posts and videos that dive into Pmods a lot further if you want to learn more.

LUNA and Pmods

While LUNA’s Pmod host ports are intended to be compatible with Digilent’s specification for Pmods [2], we do not have plans to provide dedicated software support for any particular peripherals. Fortunately, the flexibility of the LUNA framework and nMigen enables you to write your own I/O functions for Pmods that you’d like to use with LUNA. Tom Keddie has already provided an example of this [3]. We suspect that the Pmod host ports will likely be most useful to USB device developers, testers, and security researchers.

Physical changes to LUNA and case

The only visible difference to encased LUNAs will be a 12-pin Pmod host port face on either end of the case. If removed from the case, each Pmod host port will extend 8mm out from either end of the previously encased LUNA. This will make previously encased LUNAs 16mm longer than bare board LUNAs that don’t have the Pmod host ports populated. The Pmod host ports will only extend 5mm above the board, which is not as high as the USB Type-A connector already present.

Pmod footprints will remain on bare board LUNAs so Pmod host ports can be soldered on later by those that wish to have them.

References

[0] https://digilent.com/blog/where-to-plug-in-your-pmod-fpga/

[1] https://digilent.com/blog/digilent-pmods-an-introduction/

[2] https://www.digikey.ca/htmldatasheets/production/2033310/0/0/1/pmod-interface-specification.html

[3] https://github.com/greatscottgadgets/luna/pull/112

Second LUNA Enclosure Update

2021-08-26T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/enclosure-details-and-contest-winner

Enclosure Update

We have an update on the enclosures! We have received 10 enclosures from our manufacturer and we are impressed.

A LUNA in a case measures 2 inches by 2.5 inches and weighs 103 g with the hardware and lightpipes installed. I’ve been carrying mine around constantly like a pet rock since it has such a comfortable weight. The case has held up really well, regardless of the wine, pesto, sesame oil, and other sauces I’ve gotten on it while cooking. The USB-C ports have a satisfying amount of hold which means that any cables won’t get knocked out easily.

Enclosure Modifications (?)

The members of the Great Scott Gadgets Discord did get a preview of the LUNA enclosure a couple weeks ago and have already given us some feedback, which we greatly appreciate. If you have any opinions on the suggestions made, or have suggestions of your own, we’d love to hear them. We make our devices for you all and this is your chance to bring up any enclosure design or usability concerns before we start production.

One enclosure design choice that is currently being debated is whether we should populate the Pmod connectors on LUNA, shown on the left edge of the enclosure in the picture below.

In the case, the Pmod connectors don’t change the form factor, but on the bareboard LUNA the Pmod connectors would extend 5 mm above the board (which is not as high as the USB Type-A connector), but they would each add 8 mm of length to the board.

Please let us know whether you would like to see LUNA come with Pmod headers pre-installed on both LUNA in a case and bareboard LUNA, one or the other, or neither by voting with emoji on the relevant question posted in the feedback channel in our Discord server.

Case Contest Winner

To wrap up this post on the LUNA case design, we are happy to congratulate Rémy on winning the case contest with their design. Rémy will receive the only LUNA case with his winning design etched in the case:

AMA on CrowdSupply

2021-08-20T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/ama-update

On August 18th we held an “Ask Me Anything” session where anyone interested in LUNA could ask us questions in real time. The full transcript of this AMA is available to view in the #luna-ama channel in the CrowdSupply Discord server.

The History of LUNA

2021-08-11T22:16:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/the-history-of-luna

Starting Great Scott Gadgets

Ten years ago this summer I quit my day job at a radio research lab and made Great Scott Gadgets (GSG) my full-time job. I dedicated myself and the company to our mission: to put open source tools into the hands of innovative people. One of the first things I did at that time was to make a list of products I was interested in making. That list included “USB swiss army knife”. I didn’t know how to make such a thing at the time, but it was something I had in mind from the start. I soon started referring to the concept as “usbstar” in my private notes and envisioned that it would be shaped something like a three-pointed version of the Throwing Star LAN Tap. I wanted it to have three points with one USB port each for implementing Meddler-in-the-Middle (MitM) or active monitoring. One port would be connected to a target host, another to a target device, and the last to the monitor/control host.

A year later I hired Dominic Spill. Around that time Travis Goodspeed released his Facedancer software along with hardware based on his GoodFET project. Facedancer was exciting because it allowed rapid development of USB devices in Python, making it highly useful for security testing of USB hosts.

In 2013, Travis, Dominic, and I had a chat in a pub where we discussed ideas for next-generation Facedancer hardware similar to the usbstar concept. We thought that we could make a microcontroller-based platform similar to GoodFET with two or three USB 2.0 ports that would be faster and more capable than the target USB port on Facedancer. In that conversation, one of us (Dominic, I think) first proposed the name “GreatFET” for a Great Scott Gadgets variant of GoodFET, although we imagined at that time that GreatFET and Facedancer would be two different hardware platforms.

Daisho

After releasing HackRF One, we had expanded the usbstar idea into a greater vision that became Daisho. This project had an FPGA-based mainboard with pluggable modules, each for a different high speed communication technology: one for SuperSpeed USB 3.0, one for Gigabit Ethernet, and one for HDMI. It was a big project, but, thanks to some outside funding, we were able to hire help.

With Daisho we implemented SuperSpeed USB MitM capability, demonstrated by Jared Boone who designed both the mainboard and the USB module. It was only just working in time for the demonstration, but it was an effective proof-of-concept of FPGA-based USB MitM.

When our funding for Daisho ran out, however, we realized that we had created a good tool for our research but hadn’t created a viable product. We felt that Daisho was too big and expensive to have much hope of commercial success in our community. It was an overly ambitious project, but we learned a lot in the process.

One nice thing that came out of the project was the Daisho USB 3.0 device core developed by Marshall Hecht. This was the world’s first open source USB device core for FPGAs, and it has since been ported to other platforms and used in actual products.

Around the end of the Daisho project, Dominic visited the GSG lab in Colorado for some project planning. In a brainstorming session, he, Taylor Streetman, and I sketched out a usbstar design together: It had an FPGA in the middle, surrounded by three USB 2.0 PHY chips. The idea was to take what we had learned from Daisho but to scale its USB capabilities down to a single board that was simpler and more affordable.

We wanted to start working on it immediately, so I ordered an FPGA development kit to arrive during Dominic’s visit. By the time the kit arrived, however, we had talked ourselves out of the project!

One reason we didn’t pursue the usbstar concept at that time was that neither of us had very much FPGA experience. Without external funding to hire folks like those who had helped us with Daisho, we felt our progress would be slow. We also weren’t excited about building an open source product that relied on proprietary (and in some cases expensive) FPGA development tools. We liked the idea, but we prioritized GreatFET instead.

GreatFET

Another reason we abandoned usbstar was that we had expanded our vision for GreatFET. Instead of the minimal microcontroller I had used in my initial prototype, we chose the LPC43xx series that we had used in HackRF One. With this part we were able to place two USB interfaces on GreatFET One with potential for a third USB port on an add-on board (called “neighbors” in honor of Travis). By making GreatFET “greater” in this way, we tried to enable the most important capabilities of the usbstar concept without having to additionally pursue the FPGA-based project. While GoodFET and the original Facedancer hardware were two different platforms, GreatFET combined those functions into a single board.

While we were developing GreatFET, Dominic started collaborating with Kate Temkin on some USB projects. Kate single-handedly ported/rewrote Travis’s Facedancer software for GreatFET One and other platforms, and the two of them worked on GlitchKit and USBProxy. We hired her as a contractor to develop USB training courseware and GreatFET software, and she eventually joined us as a GSG employee.

Not long after joining the GSG team, Kate started developing Rhododendron, a GreatFET neighbor for High-speed USB analysis. Rhododendron was designed to be the simplest, lowest cost circuit for passive monitoring of High-speed USB. Kate and Mikaela Szekely demonstrated Rhododendron at Teardown 2019 along with ViewSB, their new USB analysis software.

LUNA Hardware

In the months following that demonstration, we worked toward manufacturing Rhododendron, but Kate started questioning whether or not it was really the best approach. Rhododendron was designed to be ultra-low-cost, but it additionally required purchase of a GreatFET One. She began thinking about making a much more sophisticated and capable tool in the same price range as the combined cost of GreatFET One and Rhododendron.

We didn’t see Kate at the lab for a couple weeks late in 2019, and then one day she appeared and announced that she had designed a new USB multitool. LUNA was born! She showed us the design, and I immediately recognized the FPGA-based usbstar concept that Dominic and I had sketched several years prior. Design work we thought would have taken us months Kate had accomplished in two weeks! Additionally she had included a fourth pass-through port for passive monitoring, making LUNA a hybrid of usbstar and Rhododendron.

One of the exciting aspects of Kate’s initial design was that LUNA was based on the ECP5 FPGA which had only recently become supported by an open source toolchain thanks to gatecat and other members of the open source FPGA community. We felt that, with the availability of open source tools, the time was finally right for GSG to make an FPGA-based design. The ECP5 was a perfect choice for LUNA as it has the performance necessary for multiple High-speed USB interfaces at a low cost.

Another thing that excited us about LUNA was Kate’s vision for gateware based on whitequark‘s nMigen, combining the flexibility and power of FPGAs with the rapid development of Python.

The Impact of COVID-19

Sadly, at about this same time the SARS-CoV-2 virus that causes COVID-19 first infected humans. We didn’t know about it until January of 2020 when it quickly became a major concern for us at GSG. We learned on the 24th of January that due to the lockdown in China we had lost access to a warehouse containing thousands of our products, the first of several pandemic-related supply chain problems that have affected us over the past year and a half.

Although we suffered a dramatic loss of revenue in the first quarter of 2020, we were able to continue paying our staff thanks to pandemic relief loans from the US government. Applying for loans was a stressful and lengthy process due to high demand and to the government and our bank having to rapidly develop new policies and procedures. We took on debt, some of which has been forgiven, but we felt that it was worth it to continue supporting our team of eight through the pandemic.

We began requiring remote work in early March. With everyone working at home and with supply chain issues limiting our hardware sales, we made LUNA development our top priority. We felt that investing in our team was the best use of pandemic relief funds and that LUNA was the best focus for the team’s efforts.

Team and Community Contributions

Kate focused on the all-important gateware and software development. She wrote code to quickly bring up her initial prototypes and validate basic functions, and she has since built the framework to support more advanced LUNA capabilities.

I took over as hardware designer after Kate’s r0.2 design. My work was made easier by the fact that Kate’s initial two designs were (incredibly!) fully functional almost without modification. Over the last year I still found enough things to refine that I ended up rerouting every trace on the PCB.

Mike Walters contributed to LUNA by developing hardware and gateware for Amalthea, an experimental Software-Defined Radio platform based on LUNA. This is important work because we see LUNA not just as a USB multitool but also as the basis for diverse future USB-connected GSG projects.

Mikaela worked on ViewSB and Facedancer software, providing the user-facing tools that will allow folks to do powerful things with LUNA.

Taylor focused on mechanical aspects of the design, such as creating a prototype enclosure. He also coordinated with contract manufacturers and component suppliers to ensure manufacturability at our target price.

Elizabeth Hendrex planned this Crowd Supply campaign while maintaining business operations and keeping everyone employed throughout the pandemic.

Straithe took the lead on technical support and documentation for all GSG products and projects, including LUNA. She also assumed responsibility for community communication such as these updates, Twitter, and Discord.

We engaged Timon Skerutsch to design the milled aluminum enclosure and help us with sourcing.

Meanwhile several members of our open source community contributed code to LUNA and related projects, and we launched this campaign as a way for the community to ensure that we will be able to put LUNA into the hands of innovative people. It has been wonderful to witness the team and the community come together to make LUNA a reality!

Thank You

With this campaign we’ve begun a new chapter in LUNA’s history. Kate and Mikaela have recently resigned from their roles at GSG and will no longer be a part of the project. We thank them for the outstanding work they’ve done to make LUNA what it is today, and we look forward to continuing our team effort to bring LUNA’s exciting capabilities to the community. Thank you all so much for your support. We couldn’t do this without you!

Open Source Clair de Lune

2021-08-05T22:16:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/open-source-moon-music

Open source is at the heart of everything Great Scott Gadgets does. When we design hardware, we publish the KiCad design files, firmware, and software under open source licenses. We try to ensure the documentation, tutorials, research papers, and videos we publish are openly licensed as well. It is the GSG way. While preparing for this Crowd Supply campaign, we took our commitment to open source even further by ensuring the music used in our campaign video is openly available too.

As we started thinking about our campaign video, we began to wonder what music we should use. While electronica is a traditional choice, I thought we might consider a more diverse set of options, including classical or acoustic music. I started my search by investigating music inspired by the moon.

I looked through a list of moon songs for ideas but decided it would be too much of a hassle to get rights for a popular song. Then I looked at a classical list and realized I had sheet music for some of the pieces. I sat down at my piano and tried to play a few. Straithe was listening, and when I started playing Debussy’s Clair de Lune she immediately said, “Use that one.”

Shortly thereafter, I suggested Clair de Lune in a planning meeting with Elizabeth and Kate. They both thought the idea had some merit, but neither was excited about it. Elizabeth ended the debate by volunteering to take on the challenge of editing the video and making the final music selection.

A few weeks later, Elizabeth shared a draft video with us, and I was pleasantly surprised she had used Clair de Lune for the music! She said she had investigated a number of other options but kept coming back to Debussy. Although she didn’t favor Clair de Lune for the video at first, it was a piece of music she had always loved. The idea of accompanying LUNA with beautiful music inspired by moonlight grew on her. Unfortunately, we didn’t have rights to use the recording in that draft. We looked around for royalty-free options but couldn’t find any we liked.

At this point we briefly entertained the option of making our own recording. At least three of us in the company were theoretically capable of doing so, but it would have taken a lot of work. Practicing, tuning a piano, acquiring recording equipment, and setting it up would have required several days of effort before even starting the actual recording and editing. We felt it was more important to spend our time focused on LUNA development and preparation for production.

Then it occurred to me: We could hire my brother, David O. He’s a professional musician who could probably record the entire piece in one day. Normally most of his work is in musical theater, but during the pandemic musical theater hasn’t been a thing. Small gigs like this are more important to him now than they have been in the past, and we liked that our project would help support an artist. Additionally we realized we could pay him to release the recording for others to use! Great Scott Gadgets is not in the music business, but, as long as we were producing music, we wanted to do so in the most GSG way possible.

David considered recording with an acoustic piano but decided to use a digital keyboard instead. This process allowed him to edit nuances of his performance such as the timing or velocity of a single keypress and to share his work as a MIDI file. This appealed to the Great Scott Gadgets team as it is in the spirit of the Open Source Hardware Definition which requires design files to be published “in the preferred format for making changes”.

Please enjoy and use his recording, a portion of which is used in our video. In addition to the audio track, he has released the MIDI file that can be edited in sequencing software. When you listen, imagine the beautiful light of the moon or of the LEDs on LUNA!

LUNA's USB-C Connectors

2021-07-29T12:31:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/cynthion/updates/q-and-a-session-on-luna-hardware-connectivity

Hi, friends!

As community manager for Great Scott Gadgets, one of my favourite tasks is finding answers to questions that come in through email, Twitter, GitHub, and Discord. Thankfully you all are great at asking questions, especially about the USB Type-C connectors on LUNA! In this blog post Michael Ossmann responds to most of the USB Type-C queries I’ve received (and asked) about LUNA in the last few weeks.

Community Question: Old pictures of LUNA feature Micro-USB connectors but the latest pictures show USB Type-C connectors. Why the change?

Kate’s original LUNA design used Micro-USB connectors, but we decided to switch to Type-C connectors a couple of revisions later. Based on the USB specification, Micro connectors may be the best choice for LUNA, but I don’t know anyone who actually likes them. They can be difficult to insert properly and they are less reliable than other USB connectors. Maybe the best thing about them is that the cable that tends to wear out and not the receptacle.

Straithe Question: So other than likeability, are there other reasons USB Type-C connectors were chosen?

Type-C connectors are more robust and easier to insert than Micro-USB, particularly since they function when inserted in either orientation. They have become quite common, so we think folks are likely to already have cables. Significantly, Type-C is the only connector specified for the recent USB 3.2 and USB4 standards, so we see it as the most future-proof option in regards to cable acquisition.

Straithe Question: Were there any concerns about switching to USB Type-C connectors?

Our biggest concern about switching to Type-C connectors was that it might give a false impression that LUNA supports SuperSpeed USB, often referred to as USB 3.0. We’ve noticed more and more USB 2.0 devices with Type-C connectors over the past couple years, so our hope is that few people would be confused by this.

Type-C connectors also cost more than Micro connectors, which was an important consideration for us since there are three of them on LUNA. One of the ways we have tried to make LUNA accessible is by making it affordable. Fortunately, we were able to find USB 2.0 Type-C connectors that cost less than USB 3.0 Type-C connectors that include SuperSpeed signals.

Community Question: Will LUNA be able to support SuperSpeed with software changes?

No. A Type-C connector can be used on a USB 3.0 device for SuperSpeed, but it can also be used on a USB 2.0 device such as LUNA at Low-speed, Full-speed, or High-speed. Although the LUNA software framework includes some experimental support for SuperSpeed USB on alternative hardware platforms, the LUNA hardware platform is a low-cost device supporting only USB 2.0 speeds.

Straithe Question: You’ve mentioned a number of different USB speeds. To recap, what are the different USB speeds and what USB versions do they line up to?

There are four speeds in the USB 2.0 and USB 3.0 specifications:

Speed	Data Rate	First Appearance
Low-speed	1.5 Mbps	USB 1.0
Full-speed	12 Mbps	USB 1.0
High-speed	480 Mbps	USB 2.0
SuperSpeed	5000 Mbps	USB 3.0

(Additionally there are extensions of SuperSpeed in USB 3.1 and above.)

Although the USB 2.0 specification updates previous specifications and includes both Low-speed and Full-speed, a lot of folks refer to High-speed USB as “USB 2.0”. Similarly, people often refer to SuperSpeed USB as “USB 3.0”, even though it can be found in various versions of the specification higher than 3.0. The USB 3.0 specification supplements USB 2.0, adding SuperSpeed signals on additional wires while following the USB 2.0 specification on other wires within the same cable.

Community Question: Does LUNA come with any cables?

Partly because of our switch to Type-C connectors and partly to save cost and packaging, we have decided not to include cables with LUNA. One of the reasons for this is that it is difficult to predict what cables folks will need for different applications. As an illustration, I used LUNA recently in-line on a connection between a PC and a HackRF One. This required four cables:

A-to-C cable between the PC and LUNA’s Target C port
A-to-Micro between LUNA’s Target A port and the HackRF One
C-to-C cable between my laptop and LUNA’s Host port
A-to-C cable between my laptop and LUNA’s Sideband port for programming

This particular selection of cables depended on the available ports on the laptop, the PC, and the HackRF One. In order to accommodate most of the combinations we anticipate, we would have to include at least half a dozen different cables, making LUNA needlessly expensive and its packaging overly bulky. Instead we decided to keep LUNA small and affordable by relying on LUNA users to acquire their own cables for their individual needs.

Community Question: Does LUNA pass through SuperSpeed signals when used as a USB analyzer?

To use LUNA as a USB analyzer, you use one cable to connect a USB host to LUNA’s “Target” Type-C port and another cable to connect a USB device to LUNA’s “Target” Type-A port. Both of those ports on LUNA are USB 2.0 connectors, so they only pass through the USB 2.0 data signals. LUNA does not pass through SuperSpeed signals or any of the ancillary signals supported on some Type-C devices such as those used for Power Delivery (PD) communication.

Community Question: I guess LUNA doesn’t have any PD capabilities then?

Although we don’t pass Power Delivery signals through LUNA, the hardware is designed to have some ability to transmit and receive PD signals:

Port	PD Transmit	PD Receive
Target A	no	no
Target C	yes	yes
Host	no	yes
Sideband	no	yes

We added these capabilities to the hardware design when switching to Type-C connectors, but we currently do not have a plan to implement gateware for PD. If you have a specific use case for which you would like software support, please let us know. At a minimum it will be possible to implement your own PD solution in nMigen. Note that LUNA’s Type-C ports are not tolerant of voltages above USB’s standard 5 V, so some PD experiments could put your LUNA in danger of overvoltage.

For more sophisticated PD testing and experimentation, including passive monitoring, I recommend checking out Rod Whitby’s USB-PD Add-On for Glasgow currently in development. Rather than adding similar circuitry to LUNA (and making LUNA larger and more expensive), we think this is a great application for a special-purpose design such as Rod’s board.

Community Question: Does LUNA support any USB Alternate Modes?

LUNA’s hardware design also permits 3.3 V I/O on the SBU1/SBU2 signals of all three Type-C connectors. This should enable experimentation with some lower speed Alternate Modes such as those used by some serial debuggers, but it will not support video modes.

Straithe Question: Thank you for answering our questions today. Do you have any last comments?

Thanks for curating these great questions! I just want to give a big thank you to everyone who is supporting LUNA on Crowd Supply. We truly appreciate each and every one of you!

LUNA enclosure progress

2021-07-22T20:44:00

Note: This is a crosspost of a Cynthion update on Crowd Supply: https://www.crowdsupply.com/great-scott-gadgets/luna/updates/a-look-at-current-progress-on-lunas-case-and-a-contest

Background

Initially, we planned on creating a laser-cut acrylic enclosure for LUNA. We had started sketching out a design when Michael Ossmann saw the beautiful design work Timon of Diodes Delight did on the milled aluminum case for Glasgow. Mike contacted Timon right away to ask for his design help as we knew a milled aluminum case would be a high quality option, more durable and protective than our original layered acrylic idea. Soon after, Timon accepted our request and started working on a case.

Progress

We have worked with Timon on the case design over the past few months, which has been a delight. He did a nice job of shaping the interior to maximize mass and give the case a comfortable (yet light) weight while still accommodating all of LUNA’s components. Timon even found light pipes that suit LUNA’s tightly spaced LEDs, which are less than 2 mm apart! Recently, Timon sent us the following 3D renders, and we knew we had our design.

A little over two weeks ago we approached our manufacturers with the case design to get the first prototypes made. In the time since the campaign launched, we have received pictures of the freshly milled top pieces of the enclosure.

Once milling is finished, these prototypes will be sandblasted, anodized, and laser etched. Sandblasting will remove the tool marks from the interior of the cases, anodizing will coat the aluminum and turn it black, as shown in the 3D renders. Laser etching will add the labels, GSG markings, and other symbols to the case.

We really look forward to receiving these prototype cases soon, testing them, and uploading pictures/updates for you shortly after!

Announcing the LUNA Crowd Supply Campaign!

2021-07-15T20:44:00

Today marks the day that our campaign to fund LUNA launches on Crowd Supply! Over the next six weeks (from July 15th to August 26th) anyone will be able to pre-purchase a LUNA and support our goal of bringing this low-cost multi-tool for building, analyzing, and hacking USB devices to market. If you want to learn more about LUNA, we have a detailed writeup of the device on our Crowd Supply campaign page that we hope you will read!

Talking about GreatFET with Limor "Ladyada" Fried at Adafruit, 2019

2021-06-17T20:44:00

In this interview, Michael Ossmann visits Adafruit in New York and chats with Limor “Ladyada” Fried about GreatFET and HackRF. The two talk about what GreatFET neighbours are, how to design GreatFET neighbours, and Mike demonstrates how to use a wiggler to separate neighbours from a GreatFET. This is followed up with a short discussion on HackRF and Portapack and how they work together.

Free Stuff, October 2020–December 2020

2021-04-29T12:26:00

October 2020

Kyle Kaminky from Arvada, Colorado emailed us in October to ask for a HackRF One. He’s an EE with a young family who told us, “After becoming familiar with my HackRF One and GNU Radio, I hope to use it to begin making tutorials on wireless communications and other RF topics. I picture a series of follow-on classes to Michael Ossmann’s DSP course. I would also enjoy getting enough experience and expertise to be able to write my own GNU Radio blocks and post them online for others to use to aid in their SDR projects. Ultimately I want to get others excited and informed about SDRs and the awesome things they can do.” He also told us to hold him accountable, so let’s have an update, Kyle.

November 2020

For November, we sent a handful of Throwing Star LAN Tap Kits to Bobby Dominguez in New Mexico because he wants to learn about networking and soldering.

December 2020

James is a teenager in Australia who is really interested in experimenting with RF and hacking embedded devices, so we sent him a YARD Stick One.

Free Stuff, July 2020–September 2020

2021-02-26T12:10:00

July 2020

Anna from South Carolina had a lame quarantined birthday in July, so we sent her a present- a GreatFET One. She recently started taking cybersecurity classes and wants to learn about hardware hacking.

August 2020

Ed from the Suffolk County (NY) Radio Club wrote to us in August to ask for free stuff for learning activities with their new members, mainly scouts and their parents. We sent a bunch of Throwing Star LAN Tap Kits, and hopefully they’ll be able to get together to use them soon.

September 2020

Axell Macclawd is a security researcher in Brazil. He requested a HackRF One for his project developing open source equipment and techniques to fight cargo theft and protect drivers, a large problem in Brazil. Drivers are held hostage and sometimes killed by thieves who use jammers to thwart the transportation companies’ GPS and GSM trackers. Axell’s goal is to prevent more loss of life.

Free Stuff, April 2020–June 2020

2020-12-04T12:00:00

April 2020

Dave Ferguson of the Woodinville (WA) Emergency Communications Team asked us for a HackRF One in April. This volunteer ARES group is turning a donated fire department aid truck into a mobile communications center that will service local public events (runs, bike rides, etc.) as well as provide essential communications via ham radio during emergencies. Their new HackRF One will allow them to watch communications across the entire spectrum and to potentially automate their systems.

May 2020

We sent a couple of YARD Stick Ones to the MCH2021 Badge Team. We can’t say any more than that, other than they are planning to make something really cool. And we sure are looking forward to 2021 and in-person hacker camps!

June 2020

Tim Fogle had some Good Ideas in June, so we sent him a GreatFET One. He wants to build a neighbor for CTF challenges.

Free Stuff, January 2020–March 2020

2020-09-24T17:00:00

January 2020

The Free Stuff recipient for January was Gabriel Sheeley, who runs an electrical engineering/embedded software meetup in Columbus, Ohio. They do do everything from soldering workshops, to tearing apart smart TVs, to automating chicken coops to keep out raccoons. Gabriel asked for a YARD Stick One to use in a talk about RF hacking, and now that the meetup is remote, the group will have to take turns with their new gadget.

February 2020

We sent a HackRF One to the CU Boulder Sounding Rocket Lab Avionics Team for their ground station. They told us that they are “building an 18-foot-tall rocket from scratch (all student-built) that will leave this humble planet for a brief period of time, before drifting gracefully back to earth and our eagerly waiting hands. We intend to shatter the records for collegiate and amateur rocketry at our upcoming launch later this year. Our most up-to-date simulations project a maximum altitude of 190km and speeds topping out at Mach 7. During the entire flight we aim to maintain contact with the vehicle so we can continuously monitor its physical (and emotional) state.”

We are looking forward to attending the launch, hopefully in 2021.

March 2020

In March, Luis Salha asked us for a YARD Stick One to use for RF encryption research for his current Swiss army knife project BlackBox. He says he’s been experimenting with RF capture, analysis, replay, and brute force attacks, and he hopes to learn more about key rolling/hopping and cracking keeloq encryption using readily available hardware.

Free Stuff Update, September 2019–December 2019

2020-08-26T12:03:00

September 2019

In September, we gave Chuck McManis a GreatFET One to experiment with. He owes us an update!

October 2019

Paul wrote to us from his shed in County Kildare to ask us for a few Throwing Star LAN Tap Kits to teach his kids how to solder.

November 2019

Way back in the Before Times, the organizers of the WOPR Summit 0x01 asked us to contribute a couple of GreatFET Ones for a hardware hacking booth. They planned to let attendees use the GreatFET Ones to run through some hands-on demos, then give them to the most passionate experimenters. That was a GreatPlan, but sweeping gesture. They are hoping to have a virtual event sometime in September 2020.

December 2019

Daniel Valdez, a student from Mexico City, requested a YARD Stick One. He is working on the development of a communication system through a router that sends a series of packets to an embedded system in order to automate control of devices in the home. He also wants to test the security protocols in the transmission of data from the different devices connected to the router.

Daniel Valdez, un estudiante de la Cuidad de México, solicitó un YARD Stick Uno. Está trabajando en el desarrollo de un sistema de comunicación por medio de un rúter que envía una serie de paquetes a un sistema embebido para poder tener el control de una casa por medio de domótica. Él también quiere probar la seguridad para establecer los protocolos de seguridad en lo que es la trasmisión de datos de los diferentes dispositivos comunicados con el rúter.

Exploring Open FPGA Hardware

2020-05-20T12:15:00

Last month, Kate Temkin began her blog series aimed at comparing FPGA families that have open source toolchains available. In the first post she reviews the pros, cons, and features of the Lattice iCE40 LP/HX, Lattice iCE40 UltraPlus, and Lattice ECP5 families.

Excerpt:

“The world of FPGAs has traditionally been full of closed-source mysteries: designs have long been crafted using expensive, multi-gigabyte vendor tools, and the inner working of vendors’ hardware and software have remained closely guarded secrets.

This changed when Claire Wolf created her IceStorm project, which reverse engineered Lattice’s low-cost iCE40 FPGAs, and led to an expansive ecosystem for creating FPGA designs using entirely open-source tools. Today, open-source toolchains exist targeting a handful of FPGA families; and a huge swathe of compatible FPGA hardware exists.

In this series, I’ll ‘show off’ a variety of hardware you can use to develop your own designs using open-toolchains– and hopefully help people to get a feel for the ecosystem.” Read the full post here.

Free Stuff, July and August 2019

2019-12-12T14:05:00

Julio y August 2019

This summer we heard from two biomedical engineers. Juan Ignacio Cerrudo es nuestro receptor de julio. Él es el Jefe de Trabajos Prácticos en Laboratorio de Prototipado Electrónico y 3D en la Universidad Nacional de Entre Ríos (Argentina). He plans to use his HackRF One to assess security in medical devices and in classes to introduce students to signal processing.

Roy Morris with Gift of Life International asked us for a HackRF One in August. Roy travels throughout the developing world helping children with congenital heart defects receive the medical care they need. He’s going to use the HackRF One to troubleshoot the aging telemetry systems that send medical data to patient monitors.

If you’d like to be considered to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message with lots of details about your project.

Free Stuff, May and June 2019

2019-12-12T14:00:00

May 2019

We sent a bunch of Throwing Star LAN Tap Kits to a high school in California in May. The computer science department will use them in several classes.

June 2019

Brooklyn Research is an interdisciplinary creative space focused on technological innovation. They provide a platform for established artists, technologists, and researchers to foster engaging discourse and experimentation. One of their groups is going to use their new HackRF One to experiment with finding a way to translate satellite signals to G-Code for a printer which will deposit nutritional paste for a slime mold culture. That slime mold culture will be a pretty artifact/visualization of the satellite signal as it grows and expands based on where the nutrients have been deposited. The shape of the slime mold growth then may be used for experimenting with new antenna shapes.

Tools of the KNOB Attack

2019-08-16T16:58:00

This week at USENIX three researchers published information about a new attack against classic Bluetooth. Known as KNOB, the attack takes advantage of a weakness in the Bluetooth specification to force target Bluetooth connections to use 8-bit encryption keys instead of larger keys that would be resilient against brute-force attack.

This weakness in classic Bluetooth (not Bluetooth Low Energy) is a big one. I don’t recall seeing such a significant vulnerability in Basic Rate Bluetooth security since pairing was improved with the introduction of Secure Simple Pairing in Core Specification v2.1 in 2007.

One of the things that intrigued me when I heard about the KNOB attack this week was that it sounded very familiar. After chatting with Dominic Spill, we’re pretty sure we discussed the potential for this attack about ten years ago. I’m fairly certain that I had highlighted Encryption Key Size Request in a printed copy of the specification around that time.

What we didn’t have back then was a way to test for this vulnerability. The specification allows for devices to reject key sizes they consider too small, and I guessed at the time that vendors would enforce a more reasonable minimum key size than the smallest (1 byte) allowed by the specification. As demonstrated this week by Daniele Antonioli, Nils Ole Tippenhauer, and Kasper B. Rasmussen, I was wrong!

In order to test this attack it is necessary to modify the behavior of the Link Manager, the part of a Bluetooth chip that creates logical links with other Bluetooth devices. The Link Manager Protocol (LMP) is the low layer protocol that Link Managers use to communicate with one another and negotiate things including encryption for protection of higher layer protocols. LMP messages are not visible over the Host Controller Interface (HCI) that carries information between a Bluetooth chip and an application processor. If you only have the ability to control a Bluetooth chip by modifying an Operating System driver, you can alter behavior at the HCI level but not the LMP level. Ten years ago I was working on creating tools for monitoring Bluetooth signals, and I used off-the-shelf Bluetooth adapters for security testing, but I didn’t have any tools capable of active attacks below the HCI layer.

Last year things changed when Dennis Mantz released InternalBlue along with his award winning master’s thesis. Dennis reverse engineered the firmware of a popular Bluetooth chip and with InternalBlue provided a method to alter the firmware, enabling modification of Link Manager behavior for the first time. Since then Dennis and Jiska Classen have published a series of papers and presentations demonstrating powerful uses of this important tool.

It was InternalBlue that enabled the KNOB researchers to test attacks against key size negotiation for the first time. They used InternalBlue to implement a man-in-the-middle attack that inserted requests for a key size of one byte and successfully demonstrated the attack against nearly every Bluetooth device they tested. This weakness existed in the Bluetooth specification for twelve years, but nobody had tools to test it. Once a tool became available, KNOB was discovered within a year.

Another tool used by the KNOB researchers was Ubertooth One, the open source Bluetooth monitoring platform I designed almost a decade ago. They used Ubertooth One to eavesdrop on encrypted packets in order to prove the weakness of the encryption after forcing a key size of one byte. They correctly point out in their paper that Ubertooth One lacks an effective ability to follow the hopping sequence of classic Bluetooth connections (it is better at this with Bluetooth Low Energy, thanks to Mike Ryan), but they worked around that problem by capturing a single packet and then iterating over all possible clock values to interpret the packet. This ingenuity allowed them to use the low cost Ubertooth One instead of a Bluetooth analyzer costing tens of thousands of dollars.

The KNOB researchers demonstrated that Wright’s Law still holds true after all these years:

“Security will not get better until tools for practical exploration of the attack surface are made available.” –Josh Wright

Reverse Engineering Black Box Systems with GreatFET, Troopers 2018

2019-07-03T15:56:00

In this presentation at Troopers 2018, Kate Temkin and Dominic Spill used GreatFET One and the Facedancer software framework to demonstrate techniques for reverse engineering embedded USB hosts.

It is often fairly simple to set up an environment for reversing a USB device; you just plug it into a host that you control. Then you can manipulate software on the host to test or monitor USB communications between the host and device. Even if the host operating system doesn’t provide a way for you to monitor USB (hint: it probably does), you can run it inside a virtual machine that runs on top of Linux and use Linux’s usbmon capability.

But how do you sniff USB if the USB host is an embedded platform that you don’t control? What if it is a game console or a photocopier with software that you can’t run in a virtual machine? Kate and Dominic show how you can use GreatFET One and a laptop to proxy USB between a device and a host without controlling software on either the device or the host. With the USBProxy solution they implemented in Facedancer, it is possible not only to monitor USB communication but also to modify USB data in transit.

Additionally they demonstrate how the Facedancer software for GreatFET can be used to emulate a USB device, allowing them to reverse engineer “black box” USB hosts and test them for vulnerabilities.

download video
download slides

Making USB Accessible, Teardown 2019

2019-06-26T10:00:00

On Sunday, Kate Temkin and Mikaela Szekely presented Making USB Accessible: Developing Ultra-low-cost, Open USB Tools at Teardown 2019 in Portland. In this well-received talk, they debuted ViewSB, a USB analyzer that supports various capture backends including GreatFET, OpenVizsla, and usbmon.

In the days leading up to the talk, Kate went on a tear, developing ViewSB to complement the hardware solutions for USB capture that she and Mikaela had been working on. I asked, “Why do we need ViewSB when we already have tools such as PulseView and Wireshark?”

Her answer was that the existing open source software tools for USB analysis don’t present data in a way that is useful enough for USB developers. I recalled my past confusion about USB nomenclature and how the most essential thing I learned from Kate’s training class at hardwaresecurity.training last year had been an understanding of the differences between USB packets, transactions, and transfers. Thinking back to the tools we used in that class, I realized that she was right that a new tool was needed. In fact, the limitations of the existing tools were probably largely responsible for my confusion!

As you can see in this video, ViewSB presents low level USB packet data in a visual format that groups packets together into transactions, something that I had previously seen only in software for proprietary USB analyzers. It makes USB much easier to understand. I wholeheartedly agree with Mikaela and Kate that their work makes USB accessible!

Code used in the presentation can be found in the usb-tools organization on GitHub.

download video
download slides

GreatFET on Hak5

2019-06-24T10:00:00

I recently sat down with Darren Kitchen to record a couple Hak5 episodes. First we introduced GreatFET One to his viewers and demonstrated using its Facedancer capability to emulate a USB device. Then we did some infrared hacking with Gladiolus, a prototype GreatFET neighbor we plan to release later this year. Thanks for having me on the show, Darren!

Free Stuff, April 2019

2019-06-20T13:40:00

More students! The TARDIS Team from Sapienza University of Rome, Italy was selected for the [REXUS/BEXUS] (http://rexusbexus.net/) program. The German Aerospace Center (DLR) and the Swedish National Space Agency (SNSA), in collaboration with the European Space Agency (ESA), jointly allow students from universities and higher education colleges across Europe to carry out scientific and technological experiments on research rockets and balloons.

Their experiment, named TARDIS (Tracking and Attitude Radio-based Determination in Stratosphere), will be launched on a balloon in October from Kiruna (Sweden), reaching 30 km of altitude. The experiment’s main objectives are to determine the position and the attitude of the balloon by digital processing of VOR navigation system signals.

And, yes, their acronym, [TARDIS] (https://tardis.s5lab.space/), may have influenced our choice this month!

Free Stuff, March 2019

2019-06-20T13:30:00

More students got free stuff in March. The University of Split - Flow Design Team makes autonomous drones and will use their new HackRF One to improve their score in competitions. They will be competing in the [AUVSI SUAS] (http://www.auvsi-suas.org/) again this year. They won the Most Stubborn Team Award last year!

Free Stuff, February 2019

2019-06-20T12:58:00

HHSec received an Ubertooth One as the Free Stuff recipients for February. They are a group of students from the Hague University of Applied Sciences and plan to use it in their IoT research. They look like an enterprising team and we are happy to encourage them.

Free Stuff, January 2019

2019-06-20T11:59:00

January was a strange month for the freestuff mailbox. We had some pranksters and people who never replied, so we didn’t send anything. Instead, we are going to reopen January for submissions. Starting… now!

If you’d like to be considered to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message with lots of details about your project. We have a GreatFET One just dying to escape the lab!

Free Stuff, December 2018

2019-06-20T11:58:00

In December, we sent a HackRF One to Jærgruppen av NRRL Norsk Radio Relae Liga, an amateur radio group in southwest Norway. They run radio courses every year and work with their local scouting groups. They hope to use their new HackRF in this year’s JOTA (Jamboree on the Air).

GreatFET One Has Arrived

2019-05-08T12:31:00

It’s happenning! We started shipping GreatFET One to resellers last week, which means that very soon (probably even today) it will be available for you to order online from your favorite reseller of Great Scott Gadgets products. Hint: if your shop of choice doesn’t carry it yet, let them know you’re interested!

It was January of 2016 when Mike Ossmann gave his firetalk at Shmoocon titled GreatFET: A Preview, in which he explained how he bought the GoodFET project from Travis Goodspeed in a Las Vegas bar for $5. That was the beginning of the project that came to be known (humorously, at first) as GreatFET. At that time, GreatFET One was known as Azalea, and was still in the development stage. Three years and countless hours of engineering, development, and manufacturing effort later, we have completed the first production run.

GreatFET One is a general purpose (and like all of our tools, open source) USB peripheral. When we say it’s general purpose, we mean that there are a whole lot of interesting things a hardware hacker, or maker, or tinkerer can customize it to do, especially through the addition of add-on boards called neighbors. But you don’t need to add anything on to start using this versatile this tool; there is plenty of USB hackery to be accomplished with GreatFET One on its own. Check out what Kate Temkin has been up to over the last year or so!

Very soon, we will also start offering a clear acrylic case and Daffodil, a solderless breadboard neighbour. To learn more about the GreatFET project and to see which resellers are already stocking GreatFET One, visit the GreatFET One product page.

Goodbye, Dominic

2019-03-15T11:39:00

Just over ten years ago I sent my first email to Dominic Spill:

“We haven’t met, Dominic, but I hope you don’t mind being included on this message. I thought you two might be interested in some work I finally got around to writing up. . .”

I had been exploring the use of software-defined radio for Bluetooth monitoring and had found Dominic’s paper on the subject. He and I quickly began collaborating on the development of tools and techniques that improved upon the methods in his paper. Just three months later, we presented Building an All-Channel Bluetooth Monitor at ShmooCon 2009.

We met in person for the first time the day before our talk at ShmooCon, and we have been friends and research partners ever since.

Over the next two years I learned electronics and designed Ubertooth One, a low cost test tool that implemented some of the techniques Dominic and I had developed. Ultimately this me led to create Great Scott Gadgets as a way to put such tools into the hands of innovative people around the world.

When Great Scott Gadgets began to become too much work for me alone, Dominic was the first person I turned to for help. He took over development and support for the Ubertooth project as a remote contractor while I turned my attention to developing new tools and growing the company.

Eventually Dominic moved to the United States and joined the GSG team in Colorado as a full-time employee. He played a key role in research and development, provided technical support for our resellers and end users, led our software development efforts, mentored interns, kept our internal IT systems up and running, and even cleaned the refrigerator. His humor, creativity, and patience have been felt by every member of the team.

For ten years Dominic and I have continued collaborating on research and developing new tools. I’ve lost count of the number of conference presentations we’ve given together and of how many times one of us has turned to the other and said, “Here’s a crazy idea. . .”

Yesterday was Dominic’s last day at Great Scott Gadgets. Having decided that he needed a change, he will pursue new adventures.

We will miss Dominic greatly. He will always be a part of the GSG family.

Free Stuff, October 2018

2018-12-17T14:00:00

The Free Stuff recipient for October is the Wave Farm. Wave Farm is a non-profit arts organization driven by experimentation with broadcast media and the airwaves. Wave Farm programs provide access to transmission technologies and support artists and organizations that engage with media as an art form. The Wave Farm Artist Residency Program is located on 29 bucolic acres in New York’s Upper Hudson Valley and supports new transmission art work by visiting artists from around the globe. Wave Farm’s WGXC 90.7-FM is a full-power non-commercial FM radio station committed to radio as a platform for community engagement and artistic experimentation. They do some really interesting stuff - their pond has its own station! Check them out! wavefarm.org

Free Stuff, September 2018

2018-12-05T13:00:00

Bridgewire Makerspace in Sparks, Nevada asked for a HackRF One to use in the Hamshack/wireless research station they are putting together in their electronics shop. Their space is open around the clock for members to create, learn and share. They are a member-funded and -run 501c3 organization that provides a space for working on projects and sharing ideas and knowledge. Check out their website here: bridgewire.org

If you’d like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, August 2018

2018-12-05T12:00:00

Matthias Carneiro is a PhD student in Montpellier, France. He asked for a HackRF One to use in his research on SDR implementation in nanosatellite constellations. When he completes his PhD, he is going to donate the HackRF One to the university for the use of other students.

Crème Brûlée Camp

2018-10-08T17:04:00

We decided to go big at Toorcamp this year and make a jar of crème brûlée for every single person that attended. Delicious? Yes. Too ambitious? Maybe. Open source? You got it.

Image via Patch Eudor

Harnessing the power of GreatFET, we were able to connect a temperature sensor, LCD screen, and some bucket heaters, and cook up a very large amount of crème brûlée inside an average sized cooler while at camp, and it worked… but there were some rough spots. The problem wasn’t necessarily in the cooking process, but in the preparation stage: the cooler was able to fit 120 4oz jars in it for a batch, so someone needs to be cracking 120 eggs and separating the yolks, someone needs to be washing/drying 120 jars and lids from the factory, someone needs to mix the egg yolks, cream, vanilla, and sugar into a huge jug, someone needs to pour the right amount of mix into 120 jars, and someone needs to tighten 120 jar lids to the correct tightness, all while 10 gallons of water heats up in a cooler. Once all this is done, the batch can be placed into the cooking cooler for about seventy-five minutes. Finally, jars can be pulled from the cooking cooler to be sugared and brûlée’d by a person with a blow torch one at a time. Repeat.

As you can imagine, this takes a considerable amount of time and effort for just one batch of 120 jars. Not only that, but there unsurprisingly was not a 100% success rate, as some lids were not tight enough before being cooked and jars were cracked during the blowtorch brûlée phase. Doing this back to back for a few days was a ton of work. We were able to make 695 crème brûlées in one weekend, and everyone that wanted one got at least one! But for anyone thinking about trying this, be prepared to get your hands dirty.

If you want to learn about the R&D process you can check out the talk we gave at Toorcamp or if you’re interested in the source code and set-up, check it out on GitHub.

Comments on the Recent USTR Tariff Action

2018-10-07T07:58:00

In September I made the following public comment on the Office of United States Trade Representative’s (USTR) Proposed Modification of Action Pursuant to Section 301: China’s Acts, Policies, and Practices Related to Technology Transfer, Intellectual Property, and Innovation.

Thank you for requesting comments on the proposed supplemental action in response to China’s Acts, Policies, and Practices Related to Technology Transfer, Intellectual Property, and Innovation (USTR-2018-0026).

As the founder and owner of Great Scott Gadgets, a Colorado small business that puts open source tools into the hands of innovative people, I urge you to refrain entirely from imposing any new duty increases. Additionally I urge you to eliminate all recent increases made as a part of this action.

Due to the inclusion of multiple tariff subheadings in the proposal, I anticipate that Great Scott Gadgets will suffer a significant increase in the cost of products we sell. Ultimately the technological innovators who are the end users of our products will bear this increase. Instead of punishing China, the increased duties will harm American innovators who rely on tools such as ours. Innovators in China and elsewhere around the world will gain an advantage over Americans as a result of the action.

Great Scott Gadgets designs and manufactures open source hardware (OSHW). The OSHW community includes a rapidly growing group of companies 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.

The growth of Great Scott Gadgets and other open source hardware and software companies demonstrates that protection of intellectual property is unnecessary for commercial success in technological markets. This undermines the USTR’s argument that “China’s acts, policies, and practices that effectuate technology transfer burden and restrict U.S. commerce.”

I maintain that open source technology greatly enhances innovation and that the best way to foster rapid development of new technology is to encourage both the free exchange of ideas and free trade of tools, materials, and all goods.

In my opinion, the proposed supplemental action will have little effect on China’s acts, policies, or practices but will disproportionately harm Great Scott Gadgets, our employees, our American resellers, and the American innovators who depend on our tools.

Free Stuff, June and July 2018

2018-08-29T13:14:00

junio 2018

El destinario de Cosas Gratis para junio es Gabriel Martín Miguel de Salamanca, España. Él quiere hacer una plataforma de radio asequible a los nuevos radioaficionados para acercarles las nuevas formas de hacer radio. Él tiene un grupo de Facebook sobre SDR para usuarios, programadores y radioficionados en español, tanto en España como en latinoamerica, aqui: facebook.com/groups

July 2018

CTRL-H Hackerspace of Portland, Oregon asked us for a HackRF One. They plan to use it for SDR workshops and their Electronics Lab Radio Closet, where they'll be capturing and hosting as much data as possible through SDR. It looks like they have made some fabulous spaces for creating, learning and hanging — check them out here: pdxhs.org

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, May 2018

2018-08-21T11:48:00

We sent Oleksandr Tytko a HackRF One. He is studying at Lyceum No 1, Chernivtsi, Ukraine. He and his classmates plan to use the HackRF One to learn about SDR and to write and test their own code. He is also very enthusiastic about starting an open source project studying the influence of radio frequencies on plants and people. He sent us a picture of the greenhouse in his local Botanic Garden where he plans to do the research:

Dan Groeneveld is an instructor at Northland Pioneer College in Show Low, Arizona. He is going to be teaching net security and pentesting courses this autumn, so we sent him some Throwing Star LAN Tap Kits. He is looking forward to teaching his students LAN Tap principles and soldering basics. We can't wait to see pictures of them in their lab.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, April 2018

2018-08-21T09:25:00

April's Free Stuff recipient is EFF (The Electronic Frontier Foundation). EFF is a nonprofit organization that defends civil liberties in the digital world. From their website: Founded in 1990, EFF champions user privacy, free expression, and innovation through impact litigation, policy analysis, grassroots activism, and technology development. We work to ensure that rights and freedoms are enhanced and protected as our use of technology grows.

Andrés Arrieta, Technology Projects Manager, has asked for a HackRF One because: At EFF we are looking how technologies impact our rights in our daily lives. Research has already shown many vulnerabilities in the standards in implementation of mobile communications and we want to continue research in this space. Understanding how 2G-4G have really been implemented not only by Telcos but also in Baseband and how users' privacy is impacted by this. Beyond that we'd like to explore the possibilities of offering more secure communications to users and the different ways this could happen.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, March 2018

2018-08-20T16:14:00

The Free Stuff recipient for March is Jan van Katwijk, a hobby programmer from the Netherlands. He plans to use his new HackRF One to finish his work on DAB software by providing a library for HackRF, then for experimenting with wideband receiving issues. His current developments include software support for ACARS and ADS-B decoding.sdfsdfdsf A full overview of his work is available here and here.

If you'd like to submit your project idea for consideration to receive free hardware from Great Scott Gadgets, please visit the Free Stuff page and send us a message!

Free Stuff, January and February 2018

2018-05-09T17:54:00

Drumroll, please! The free stuff recipients for January and February were:

Rushabh Vyas, who is a graduate student at the Purdue School of Engineering and Technology, IUPUI, is receiving four LAN Tap Throwing Star kits for use in his digital escape room projects and in his cybersecurity group, TheDen.

His current forensics class is using a bomb-defusal scenario. He reports: “End goal for the forensics students is to be able to get access to Arduino code (by completing various forensics tasks such as steganalysis, data decoding, and artifact analysis), analyze the code, and be able to cut the correct colored wire for defusal in ~60 minutes.”

Check out Rushabh’s links here:

We sent a HackRF One to the University of Toronto Aerospace Team, Space Systems Division. They are a team of 40 undergraduates who are working on an open source CubeSat for carrying out microbiology experiments in space! Their first satellite, HeronMk II, is slated to launch in early 2020.

One of their team leads, Siddarth Mahendraker, tells us:

“We plan to use the HackRF to build a programmatic interface to our radio communications system, in conjunction with GNURadio. This will make it significantly easier for us to test our on-board computer systems, downlink payload data, and integrate and test additional satellite subsystems”

HERON Mk II is a 3U Cubesat designed and built by the Space Systems division of the University of Toronto Aerospace Team to perform sophisticated microbiology experiments in orbit. The organism of interest is C. Albicans, a yeast that is commonly found in the human gut flora that may undergo changes in its virulence and drug resistance when experiencing microgravity.

Here is their website:

https://www.utat.ca/space-systems/

We also gave away two HackRF Ones in February:

One went to Brian Granby, a PhD student at Liverpool John Moores University. He is doing security research, conducting a study into emerging sensors technologies; with a particular focus surrounding network security of RF connected devices. His main focus is on the potential threats of residential and commercial gas supplier technologies found in smart meters.

The other we are sending to Sudip Kar of Bangalore. He is going to use his HackRF One to introduce SDR to small village schools by helping them to set up their own weather stations that can track NOAA satellites. He is going to send us pictures after the students finish their year-end exams and start using the HackRF later this spring.

2017 Free Stuff Update

2018-05-08T12:05:00

In 2017, we read a whole bunch of requests for free stuff, and we were really impressed with the many excellent submissions we received. Since our last free stuff update, we have given away 16 HackRFs and several Throwing Star LAN Tap Kits to researchers, makerspaces, amateur radio groups, and educators. The 2017 free stuff receipients included:

Dr. Fernando Pena Campos — HackRF One for wireless communications education at the university undergraduate level
New Hampshire Hacker's Association (NEHA) meetup — HackRF One for SDR workshops
Reforge Charleston — Throwing Star LAN Tap Kits and a HackRF One for an education based non-profit makerspace
Cal Poly Amateur Radio Club — HackRF One (with a Clear Acrylic Case) for the equipment shack (special thanks for the T-shirts!)
University of Michigan Rocketry Team — HackRF One (and a Clear Acrylic Case) to help with the development and prototyping of a "from scratch" GPS receiver and other avionics systems
Fred Pelland — HackRF for an amateur radio group
Sebastien Mrozek, teacher at Elsa-Brändström-Schule, a secondary school in Elmshorn, Germany — HackRF One for the school's electronics lab
Juan Moreno, professor at Universidad Politecnica de Madrid — HackRF One to help develop an SDR focused Massive Open Online Course (coming soon: https://miriadax.net/web/software-defined-radio-101-with-rtl-sdr)
Marco Manzoni/Skyward Environmental Rocketry — HackRF One for use in the development of the RF system of a student-made rocket
Make Riga Hackerspace — HackRF one to help this hackerspace's members accomplish interesting projects, like "aiming to reach 100km with a large model rocket + balloon (thus their own gps solution), and another member is rolling out his own gsm stack"
Bill — HackRF One for an SDR workshop given at the New Mexico Hamfest
Carlos Yero for Abertay University Ethical Hacking Society — HackRF One "to be available to all students working on the Ethical Hacking degree with aim to overcome fear of SDR complexities"
Fellow open source hardware designer Manuel Domke of 13-37.org — HackRF to use as a spectrum analyzer for EMC product compliance testing

Sometimes, free stuff recipients send us pictures, like this one from Elsa-Brändström-Schule in Germany (we love it when free stuff receipients send us pictures; it increases the general level of warm fuzzies):

We'll be doing more free stuff updates shortly, so check back soon! Also, please keep the free stuff requests coming. For information about how to request free Great Scott Gadgets hardware, please visit the Free Stuff page.

We Fixed the Glitch

2018-02-28T12:26:00

Around the first of the year our contract manufacturer contacted us about an urgent problem with HackRF One production. They'd had to stop production because units coming off the line were failing at a high rate. This was quite a surprise because HackRF One is a mature product that has been manufactured regularly for a few years. I continued to find surprises as I went through the process of troubleshooting the problem, and I thought it made a fascinating tale that would be worth sharing.

The reported failure was an inability to write firmware to the flash memory on the board. Our attention quickly turned to the flash chip itself because it was the one thing that had changed since the previous production. The original flash chip in the design had been discontinued, so we had selected a replacement from the same manufacturer. Although we had been careful to test the new chip prior to production, it seemed that somehow the change had resulted in a high failure rate.

Had we overlooked a failure mode because we had tested too small a quantity of the new flash chips? Had the sample parts we tested been different than the parts used in the production? We quickly ordered parts from multiple sources and had our contract manufacturer send us some of their parts and new boards for testing. We began testing parts as soon as they arrived at our lab, but even after days of testing samples from various sources we were unable to reproduce the failures reported by the contract manufacturer.

At one point I thought I managed to reproduce the failure on one of the new boards, but it only happened about 3% of the time. This failure happened regardless of which flash chip was used, and it was easy to work around by retrying. If it happened on the production line it probably wouldn't even be noticed because it was indistinguishable from a simple user error such as a poor cable connection or a missed button press. Eventually I determined that this low probability failure mode was something that affected older boards as well. It is something we might be able to fix, but it is a low priority. It certainly wasn't the same failure mode that had stopped production.

It seemed that the new flash chip caused no problems, but then what could be causing the failures at the factory? We had them ship us more sample boards, specifically requesting boards that had exhibited failures. They had intended to send us those in the first shipment but accidentally left them out of the package. Because the flash chip was so strongly suspected at the time, we'd all thought that we'd be able to reproduce the failure with one or more of the many chips in that package anyway. One thing that had made it difficult for them to know which boards to ship was that any board that passed testing once would never fail again. For this reason they had deemed it more important to send us fresh, untested boards than boards that had failed and later passed.

When the second batch of boards from the contract manufacturer arrived, we immediately started testing them. We weren't able to reproduce the failure on the first board in the shipment. We weren't able to reproduce the failure on the second board either! Fortunately the next three boards exhibited the failure, and we were finally able to observe the problem in our lab. I isolated the failure to something that happened before the actual programming of the flash, so I was able to develop a test procedure that left the flash empty, avoiding the scenario in which a board that passed once would never fail again. Even after being able to reliably reproduce the failure, it took several days of troubleshooting to fully understand the problem. It was a frustrating process at the time, but the root cause turned out to be quite an interesting bug.

Although the initial symptom was a failure to program flash, the means of programming flash on a new board is actually a multi-step process. First the HackRF One is booted in Device Firmware Upgrade (DFU) mode. This is done by holding down the DFU button while powering on or resetting the board. In DFU mode, the HackRF's microcontroller executes a DFU bootloader function stored in ROM. The host computer speaks to the bootloader over USB and loads HackRF firmware into RAM. Then the bootloader executes this firmware which appears as a new USB device to the host. Finally the host uses a function of the firmware running in RAM to load another version of the firmware over USB and onto the flash chip.

I found that the failure happened at the step in which the DFU bootloader launches our firmware from RAM. The load of firmware over USB into RAM appeared to work, but then the DFU bootloader dropped off the bus and the USB host was unable to re-enumerate the device. I probed the board with a voltmeter and oscilloscope, but nearly everything looked as expected. There was a fairly significant voltage glitch on the microcontroller's power supply (VCC), but a probe of a known good board from a previous production revealed a similar glitch. I made a note of it as something to investigate in the future, but it didn't seem to be anything new.

I connected a Black Magic Probe and investigated the state of the microcontroller before and after the failure. Before the failure, the program counter pointed to the ROM region that contains the DFU bootloader. After the failure, the program counter still pointed to the ROM region, suggesting that control may never have passed to the HackRF firmware. I inspected RAM after the failure and found that our firmware was in the correct place but that the first 16 bytes had been replaced by 0xff. It made sense that the bootloader would not attempt to execute our code because it is supposed to perform an integrity check over the first few bytes. Since those bytes were corrupted, the bootloader should have refused to jump to our code.

I monitored the USB communication to see if the firmware image was corrupted before being delivered to the bootloader, but the first 16 bytes were correct in transit. Nothing looked out of the ordinary on USB except that there was no indication that the HackRF firmware had started up. After the bootloader accepted the firmware image, it dropped off the bus, and then the bus was silent.

As my testing progressed, I began to notice a curious thing, and our contract manufacturer reported the very same observation: The RF LED on the board sometimes was dimly illuminated in DFU mode and sometimes was completely off. Whenever it was off, the failure would occur; whenever it was dimly on, the board would pass testing. This inconsistency in the state of the RF LED is something that we had observed for years. I had never given it much thought but assumed it may have been caused by some known bugs in reset functions of the microcontroller. Suddenly this behavior was very interesting because it was strongly correlated with the new failure! What causes the RF LED to sometimes be dimly on at boot time? What causes the new failure? Could they be caused by the same thing?

I took a look at the schematic which reminded me that the RF LED is not connected to a General-Purpose Input/Output (GPIO) pin of the microcontroller. Instead it directly indicates the state of the power supply (VAA) for the RF section of the board. When VAA is low (below about 1.5 Volts), the RF LED is off. When VAA is at or near 3.3 Volts (the same voltage as VCC), the RF LED should be fully on. If the RF LED is dimly on, VAA must be at approximately 2 Volts, the forward voltage of the LED. This isn't enough voltage to power the chips in the RF section, but it is enough to dimly illuminate the LED.

VAA is derived from VCC but is controlled by a MOSFET which switches VAA on and off. At boot time, the MOSFET should be switched off, but somehow some current can leak into VAA. I wasn't sure if this leakage was due to the state of the GPIO signal that controls the MOSFET (!VAA_ENABLE) or if it could be from one of several digital control signals that extend from the VCC power domain into the VAA power domain. I probed all of those signals on both a good board and a failing board but didn't find any significant differences. It wasn't clear why VAA was sometimes partially charged at start-up, and I couldn't find any indication of what might be different between a good board and a bad board.

One thing that was clear was that the RF LED was always dimly illuminated immediately after a failure. If I reset a board into DFU mode using the reset button after a failure, the RF LED would remain dimly lit, and the failure would be avoided on the second attempt. If I reset a board into DFU mode by removing and restoring power instead of using the reset button, the RF LED state became unpredictable. The procedural workaround of retrying with the reset button would have been sufficient to proceed with manufacturing except that we were nervous about shipping boards that would give end users trouble if they need to recover from a load of faulty firmware. It might be a support nightmare to have units in the field that do not provide a reliable means of restoring firmware. We certainly wanted to at least understand the root cause of the problem before agreeing to ship units that would require users to follow a procedural workaround.

Meanwhile I had removed a large number of components from one of the failing boards. I had started this process after determining that the flash chip was not causing the problem. In order to prove this without a doubt, I entirely removed the flash chip from a failing board and was still able to reproduce the failure. I had continued removing components that seemed unrelated to the failure just to prove to myself that they were not involved. When investigating the correlation with VAA, I tried removing the MOSFET (Q3) and found that the failure did not occur when Q3 was absent! I also found that removal of the ferrite filter (FB2) on VAA or the capacitor (C105) would prevent the failure. Whenever any of these three components was removed, the failure could be avoided. I tried cutting the trace (P36) that connects the VAA MOSFET and filter to the rest of VAA. Even without any connection to the load, I could prevent the failure by removing any of those three components and induce the failure by restoring all three. Perhaps the charging of VAA was not only correlated with the failure but was somehow the cause of the failure!

This prompted me to spend some time investigating VAA, VCC, and !VAA_ENABLE more thoroughly. I wanted to fully understand why VAA was sometimes partially charged and why the failure only happened when it was uncharged. I used an oscilloscope to probe all three signals simultaneously, and I tried triggering on changes to any of the three. Before long I found that triggering on !VAA_ENABLE was most fruitful. It turned out that !VAA_ENABLE was being pulled low very briefly at the approximate time of the failure. This signal was meant to remain high until the HackRF firmware pulls it low to switch on VAA. Why was the DFU bootloader toggling this pin before executing our firmware?

Had something changed in the DFU bootloader ROM? I used the Black Magic Probe to dump the ROM from one of the new microcontrollers, but it was the same as the ROM on older ones. I even swapped the microcontrollers of a good board and a bad board; the bad board continued to fail even with a known good microcontroller, and the good board never exhibited a problem with the new microcontroller installed. I investigated the behavior of !VAA_ENABLE on a good board and found that a similar glitch happened prior to the point in time at which the HackRF firmware pulls it low. I didn't understand what was different between a good board and a bad board, but it seemed that this behavior of !VAA_ENABLE was somehow responsible for the failure.

The transient change in !VAA_ENABLE caused a small rise in VAA and a brief, very small dip in VCC. It didn't look like this dip would be enough to cause a problem on the microcontroller, but, on the assumption that it might, I experimented with ways to avoid affecting VCC as much. I found that a reliable hardware workaround was to install a 1 kΩ resistor between VAA and VCC. This caused VAA to always be partially charged prior to !VAA_ENABLE being toggled, and it prevented the failure. It wasn't a very attractive workaround because there isn't a good place to install the resistor without changing the layout of the board, but we were able to confirm that it was effective on all boards that suffered from the failure.

Trying to determine why the DFU bootloader might toggle !VAA_ENABLE, I looked at the documented functions available on the microcontroller's pin that is used for that signal. Its default function is GPIO, but it has a secondary function as a part of an external memory interface. Was it possible that the DFU bootloader was activating the external memory interface when writing the firmware to internal RAM? Had I made a terrible error when I selected that pin years ago, unaware of this bootloader behavior?

Unfortunately the DFU bootloader is a ROM function provided by the microcontroller vendor, so we don't have source code for it. I did some cursory reverse engineering of the ROM but couldn't find any indication that it possesses the capability of activating the external memory interface. I tried using the Black Magic Probe to single step through instructions, but it wasn't fast enough to avoid USB timeouts while single stepping. I set a watchpoint on a register that should be set when powering up the external memory interface, but it never seemed to happen. Then I tried setting a watchpoint on the register that sets the pin function, and suddenly something very surprising was revealed to me. The first time the pin function was set was in my own code executing from RAM. The bootloader was actually executing my firmware even when the failure occurred!

After a brief moment of disbelief I realized what was going on. The reason I had thought that my firmware never ran was that the program counter pointed to ROM both before and after the failure, but that wasn't because my code never executed. A ROM function was running after the failure because the microcontroller was being reset during the failure. The failure was occurring during execution of my own code and was likely something I could fix in software! Part of the reason I had misinterpreted this behavior was that I had been thinking about the bootloader as "the DFU bootloader", but it is actually a unified bootloader that supports several different boot methods. Even when booting to flash memory, the default boot option for HackRF One, the first code executed by the microcontroller is the bootloader in ROM which later passes control to the firmware in flash. You don't hold down the DFU button to cause the bootloader to execute, you hold down the button to instruct the bootloader to load code from USB DFU instead of flash.

Suddenly I understood that the memory corruption was something that happened as an effect of the failure; it wasn't part of the cause. I also understood why the failure did not seem to occur after a board passed testing once. During the test, firmware is written to flash. If the failure occurs at any time thereafter, the microcontroller resets and boots from flash, behaving similarly to how it would behave if it had correctly executed code that had been loaded via USB into RAM. The reason the board was stuck in a ROM function after a failure on a board with empty flash was simply that the bootloader was unable to detect valid firmware in flash after reset.

It seemed clear that the microcontroller must be experiencing a reset due to a voltage glitch on VCC, but the glitch that I had observed on failing boards seemed too small to have caused a reset. When I realized this, I took some more measurements of VCC and zoomed out to a wider view on the oscilloscope. There was a second glitch! The second glitch in VCC was much bigger than the first. It was also caused by !VAA_ENABLE being pulled low, but this time it was held low long enough to have a much larger effect on VCC. In fact, this was the same glitch that I had previously observed on known good boards. I then determined that the first glitch was caused by a minor bug in the way our firmware configured the GPIO pin. The second glitch was caused by the deliberate activation of !VAA_ENABLE.

When a good board starts up, it pulls !VAA_ENABLE low to activate the MOSFET that switches on VAA. At this time, quite a bit of current gets dumped into the capacitor (C105) in a short amount of time. This is a perfect recipe for causing a brief drop in VCC. I knew about this potential problem when I designed the circuit, but I guess I didn't carefully measure it at the time. It never seemed to cause a problem on my prototypes.

When a bad board starts up, the exact same thing happens except the voltage drop of VCC is just a little bit deeper. This causes a microcontroller reset, resulting in !VAA_ENABLE being pulled high again. During this brief glitch VAA becomes partially charged, which is why the RF LED is dimly lit after a failure. If VAA is partially charged before !VAA_ENABLE is pulled low, less current is required to fully charge it, so the voltage glitch on VCC isn't deep enough to cause a reset.

At this point I figured out that the reason the state of the RF LED is unpredictable after power is applied is that it depends on how long power has been removed from the board. If you unplug a board with VAA at least partially charged but then plug it back in within two seconds, VAA will still be partially charged. If you leave it disconnected from power for at least five seconds, VAA will be thoroughly discharged and the RF LED will be off after plugging it back in.

This sort of voltage glitch is something hardware hackers introduce at times as a fault injection attack to cause microcontrollers to misbehave in useful ways. In this case, my microcontroller was glitching itself, which was not a good thing! Fortunately I was able to fix the problem by rapidly toggling !VAA_ENABLE many times, causing VAA to charge more slowly and avoiding the VCC glitch.

I'm still not entirely sure why boards from the new production seem to be more sensitive to this failure than older boards, but I have a guess. My guess is that a certain percentage of units have always suffered from this problem but that they have gone undetected. The people programming the boards in previous productions may have figured out on their own that they could save time by using the reset button instead of unplugging a board and plugging it back in to try again. If they did so, they would have had a very high success rate on second attempts even when programming failed the first time. If a new employee or two were doing the programming this time, they may have followed their instructions more carefully, removing failing boards from power before re-testing them.

Even if my guess is wrong, it seems that my design was always very close to having this problem. Known good boards suffered from less of a glitch, but they still experienced a glitch that was close to the threshold that would cause a reset. It is entirely possible that subtle changes in the characteristics of capacitors or other components on the board could cause this glitch to be greater or smaller from one batch to the next.

Once a HackRF One has had its flash programmed, the problem is very likely to go undetected forever. It turns out that this glitch can happen even when a board is booted from flash, not just when starting it up in DFU mode. When starting from flash, however, a glitch-induced reset results in another boot from flash, this time with VAA charged up a little bit more. After one or two resets that happen in the blink of an eye, it starts up normally without a glitch. Unless you know what to look for, it is quite unlikely that you would ever detect the fault.

Because of this and the fact that we didn't have a way to distinguish between firmware running from flash and RAM, the failure was difficult for us to reproduce and observe reliably before we understood it. Another thing that complicated troubleshooting was that I was very focused on looking for something that had changed since the previous production. It turned out that the voltage glitch was only subtly worse than it was on the older boards I tested, so I overlooked it as a possible cause. I don't know that it was necessarily wrong to have this focus, but I might have found the root cause faster had I concentrated more on understanding the problem and less on trying to find things that had changed.

In the end I found that it was my own hardware design that caused the problem. It was another example of something Jared Boone often says. I call it ShareBrained's Razor: "If your project is broken, it is probably your fault.". It isn't your compiler or your components or your tools; it is something you did yourself.

Thank you to everyone who helped with this troubleshooting process, especially the entire GSG team, Etonnet, and Kate Temkin. Also thank you to the pioneers of antibiotics without which I would have had a significantly more difficult recovery from the bronchitis that afflicted me during this effort!

GSG Interns

2017-06-13T13:49:00

Please welcome the Great Scott Gadgets summer interns, Ellie Puls and Jacob Graves. They joined us at the beginning of June, and we are thrilled to have both of these bright students on our team. Ellie is a junior at CU Boulder and Jacob is a senior at CU Denver, and they are both majoring in Computer Science. They plan to write a short blog post every couple of weeks over the summer to let you know what they've been learning and what kind of projects they've been working on. Here's what they've been up to in their first couple of weeks:

"We helped finish a project in Python that fetches information about wireless devices from the Federal Communications Commission's website. We were able to take the information and put it into the user's home directory as well as into a user-friendly database. Additionally, we learned how to use the Lasersaur laser cutter and cut packaging for the new HackRF acrylic cases. Finally, we learned how to test HackRFs to look for any firmware or LED issues on the boards."

Going forward, we want to involve Ellie and Jacob in several of our software and firmware development projects (including GreatFET). They will be mentored by Mike and Dominic, and we hope that their time with us will amount to a meaningful educational and professional experience that they can take with them into their future careers.

GSG is Hiring

2017-05-18T12:08:00

Are you (or do you know someone who is) a match for our open position for a summer intern? See our new jobs page for details. Keep an eye on this page for future job opportunities at Great Scott Gadgets!

Free Stuff, January–June 2016

2017-02-09T23:21:00

It's been a while since we've posted, but yes, we are still giving away free stuff! Even though we can't respond to each and every email, we do read and carefully consider all of them, and we choose at least one awesome group, project, or individual each month to send some free hardware to. Here are the free stuff recipients for the first half of 2016.

ADS-B Out Open Source Project

We gave a HackRF One to developer and pilot Christopher Young, whose latest development project is an in-flight ADS-B Out transponder. ADS-B Out allows pilots to broadcast position, ground speed, and altitude to air traffic controllers and aircraft that are equipped with ADS-B In. This project benefits general aviation pilots because NextGen, the FAA's new plan to increase aviation safety, mandates that all aircraft be equipped with ADS-B Out by the year 2020. Christopher's open source design is intended give pilots a more affordable means of complying with the new requirement (ADS-B out is a piece of avionics equipment that normally costs thousands of dollars). Chris is also the creator of the stratux project, an affordable open source aviation weather and traffic receiver solution based on low-cost SDRs, so we are excited to put a HackRF into his capable hands.

Visible Light Communication Research

We gave a HackRF One to Alexis Duque, a Phd candidate at INSA in Lyon, France. He is researching the possibilities of visible light communication, and wants to use SDR hardware and GNURadio for some tests. He plans to donate his HackRF to CorteXlab at INSA after the research is complete.

Fablab Hackerspace

We received a free stuff request for a YARD Stick One from Pedro, a high school student at a technical school in southern Brazil who has started a hackerspace called Fablab with a group of his friends. Their school has given them space to work in, but due to equipment costs and crippling taxes imposed on electronics equipment there, they have been unable to find the funds to stock their lab and are relying on donations from the community. We sent them a YARD Stick One so that their group can experiment with communications with a drone they received from a local university.

Argentinian Meetup Group

Speaking of South America, we gave a HackRF to Martin Gallo, coordinator of TandilSec, a meetup group in Tandil, Argentina who discuss infosec topics and learn about current trends. They have recently been experimenting with is SDR, and HackRF One was their hardware of choice.

Qspectrum Analyzer

We gave a HackRF One to the Qspectrumanalyzer open source project because it currently only supports rtl-sdr, and the developer of that program wanted to change that. He tells us that a popular request from users is that they would like to see support for HackRF One.

Amateur Radio Equipment Repair

Pavel is a ham radio operator, self-described tinkerer, and software developer. He is involved with a local amateur radio club, but lives in an area where good radio equipment is difficult to obtain, and the equipment they are able to get their hands on is usually in need of repair. Pavel asked us for a HackRF One to diagnose and test problems, which will help him repair the radio equipment of other amateur radio operators in his community.

Stay tuned; more free stuff updates are on the way! Visit our free stuff page to learn how to submit a request.

ANT700 Release

2016-08-20T13:49:00

Today we are excited to announce the official release of ANT700, our new 300—1100 MHz telescopic antenna. Because this general purpose antenna was designed with YARD Stick One users in mind, it has a slim and lightweight form factor that works well with smaller devices. It has an SMA male connector to attach to your device of choice (including HackRF One) and can be extended from 9.5 cm to 24.5 cm.

We started distributing ANT700 last month, and it is already available for purchase from six of our authorized resellers on four continents. To find out where you can purchase yours, please visit the product page.

September 2016 Open House Invitation

2016-07-26T10:09:00

Earlier this month, we packed our things and moved our lab and offices to a new location in Evergreen, Colorado. We are are very excited to be in a bigger space (it was time!) and to celebrate, we are hosting an open house on Friday, September 16th from 5 pm to 8 pm. We welcome our friends, associates, and neighbors to come and see our new lab and enjoy food and drink with us.

Our address is:
31207 Keats Way
Suite 101
Evergreen, Colorado 80439

Please let us know you are coming so we don't run out of provisions! RSVP by September 10th to info@greatscottgadgets.com.

We hope to see you there!

Free Stuff, May–December 2015

2016-04-13T13:54:00

The Great Scott Gadgets team has been hard at work sorting through all the Free Stuff requests for 2015, and now we are finally ready to announce the winners for May through December. We've had many interesting submissions, and we've enjoyed learning about all the ideas you have had for open source projects and education. After much discussion and some tough decisions, we've chosen the following seven individuals and groups to receive free hardware from Great Scott Gadgets.

Open Source Project: Universal Drone API Generator

Richard Doell wrote to us requesting a HackRF One for a project idea he is working on. We were intrigued by the project, and very excited to hear that it is going to be open source. Richard has a background in robotics and computer vision, and he wants to create a universal automatic drone API generator for hobbyists and robotics junkies that will allow remote control vehicles to be controlled from a computer using GNU Radio. His HackRF One will enable him to collect data from the RC vehicles' transmitters. Keep us updated about the progress of your project, Richard!

Information Security Workshops

Stefan Hessel (of the blog Causa Finita) is a security expert who works at the Department of Law and Informatics at Saarland University in Germany. After work, he gets involved in his community through an IT working group, offering free classes at a local clubhouse that help beginners develop skills and knowledge in the areas of Internet safety and security. Stefan asked us to donate a HackRF One to help him teach the basics of SDR to the people who attend his classes and to demonstrate ways that attackers could gain access to private data through hardware hacking. Thanks Stefan, for sharing your expertise and using your workshops to bring awareness to these issues.

Liquid Fueled Rocket Building

Let's Build Rockets is a talented group of young amateur engineers who are designing and building a flyable, liquid-fueled rocket. This has proved challenging because currently most of the commercially available model rocket engine systems and electronics components are designed for solid-fueled rockets. Therefore they have had to design, manufacture, and test all of the system's components themselves. They are planning to use their free HackRF One as a receiver in the downlink portion of the rocket's control system, the design of which is based on the Copenhagen Suborbitals Sapphire Telemetry System. The downlink transfers mission data from the accelerometer, gyroscope, altimeter, compass, GPS, pressure and temperature sensors of the engine and fuel tanks, and atmospheric temperature sensors to a ground control station. Eric Simms wrote to us on behalf of Let's Build Rockets, saying:

“The communication that the HackRF enables will help us recover the rocket after the launch and analyze potential failure points. After doing lots of research, the HackRF is the most accessible receiver we've found, requiring the least amount of additional hardware and providing opportunities for future expansion.”

Let's Build Rockets is publishing all of their design files, code, and test data on github so that others can benefit from their learning and experience. We're excited to support this awesome, educational, open source project. Rocket on!

Emergency Communications

The Wantagh-Levittown Volunteer Ambulance Corps is a dedicated group of paramedics and dispatchers who provide emergency services to their community by answering 911 calls. While each ambulance in their facility has its own radio, this small nonprofit organization has had a difficult time finding the funds to invest in a radio for communications training. Their free HackRF One will enable them to receive and decode multiple simultaneous transmissions on their county's radio system. Mark Tomlin, Chief of Operations, wrote to us saying,

“Communications are vital in EMS, just as important as the vital signs of the patient themselves. Missing information from an incomplete report can be devastating to a patients outcome. Presenting ones self to the doctor correctly on the other end of the radio can be the difference in getting the order for the medication or not. These are things that can only come with experience. We now have the opportunity to present our experience to those who were not physically present at the time of notification. This should greatly improve the time it takes a new provider to get up to speed on medical control notifications.”

We are happy to put a free HackRF into the hands of someone who can use it to make the world a better place. It's very satisfying knowing that somewhere in New York, a HackRF One is enabling communication that could save lives.

MIT Splash Program

Every November, high school students from around the country and even around the world come to MIT for a program called Splash. It is a weekend where they can engage in unique and valuable learning experiences that are unavailable in a normal classroom setting. Riley Drake wrote to us asking for a HackRF One for a Software Defined Radio course he is planning to teach at Splash 2016, which will cover topics such as Digital Signal Processing, Decibels, Data Types, Sample Rates, Negative Frequencies, Quantization Error and Complex Numbers in Digital Signal Processing (course structure mirrors Michael Ossmann's online lessons). Having a HackRF One available for the class will allow students to run their code on a real radio and promote a discussion of the legal and regulatory issues of SDR. Good luck with your class Riley, and please send us pictures! We'd love to know how it goes.

Soldering Workshops

Hacklab Almeria is a growing group of developers and enthusiasts in Spain that are learning and collaborating together. When they first wrote to us in October of 2015, they had 30 members, but when we contacted them last month that number had increased to 50. Jesus Marin Garcia asked for several Throwing Star LAN Tap Kits for a workshop the group are offering to their newer members on electronics fundamentals and soldering. Spread the word, and good luck with your workshop!

OpenWebRX Support

András Retzler is the developer of a remote spectrum monitoring solution called OpenWebRX that gives users access to multiple SDR receivers worldwide. We gave András a free HackRF One, which he is using to improve support for that project. If you haven't already seen OpenWebRX, you should certainly check it out—it's really cool. He also plans to use his HackRF One to serve as a test station for another of his open source projects, qtcsdr, an open source amateur radio transceiver design using a Raspberry Pi 2 as a transmitter and an RTL-SDR as a receiver. As a company that is built on open source principles, we are very enthusiastic about supporting open source projects, and we are especially happy to help András with OpenWebRX.

Thanks again to everyone who has sent us a free stuff request. We are almost all caught up now, and we will announce winners for the first few months of 2016 soon. If you have an idea for a project using Great Scott Gadgets hardware and could benefit from free stuff, don't hesitate to tell us about it. If you don't ask, we can't say yes!

Defeating Spread Spectrum Communication with Software Defined Radio, ToorCon 2013

2016-03-08T13:50:00

Fortunately in this video you can't hear the jackhammers at work in the hotel lobby while I gave this presentation at the ToorCon San Diego seminars in October, 2013. Apart from having to talk over the construction noise, it was great to share SDR techniques that can be used to point out flaws in security claims made about spread spectrum communication technologies.

One of the things I showed in the talk was how Direct Sequence Spread Spectrum (DSSS) communications can be reverse engineered. I used SPOT Connect, a device operating on the GlobalStar satellite network as an example. A couple years later, Colby Moore did a more complete job of showing how the GlobalStar system can be attacked.

If you aren't familiar with the Pastor Manul Laphroaig, mentioned at the beginning of this talk, check out our PoC||GTFO mirror.

download video
download slides

Free Stuff, April 2015

2016-03-08T12:49:00

My, how time flies! The Great Scott Gadgets team has been busy, but we haven't forgotten all of your requests for FREE STUFF! We are working towards getting caught up, so please bear with us as we sort it all out. April had a lot of good submissions, and we are excited to reward several of you with free open source hardware. And to make up for being so behind, we even awarded a YARD Stick One this time, and we shipped it when it was brand new! Read on to learn about April's winning Free Stuff submissions.

Damon Wascom wrote to us requesting a HackRF One to assist AMSAT in testing transmission lines and filters for the next FOX-1C and Fox-1D CubeSats. Damon gave many convincing reasons and compelling arguments as to why we should award him a HackRF One for his project, but perhaps most compellingly Damon wrote:

"It would be awesome to apply this legendary and revolutionary RF hacking tool of the decade into the hacking together of the next amateur built, amateur radio spacecraft!"

Yup! Damon, make it so.

Jesus Sanchez wrote to us on behalf of the Advanced Communications Research Laboratory he founded at his university last February. The Advanced Communications Research Laboratory encourages its members to conduct research in the wide field of SDR and to promote open source software and hardware. We are happy to support these goals by awarding the Advanced Communications Research Laboratory a free HackRF One!

Tamer Çelik is a member of Hackerspace Istanbul. Tamer plans to use his HackRF One to introduce SDR to his hackerspace as well as other hackerspaces in his area. Tamer, thanks for spreading the word and sharing SDR technology with your community!

David De La Hoz Joaquin is a student of Systems and Computer Engineering at Pontificia Universidad Católica Madre y Maestra in Santiago De Los Caballeros, Dominican Republic. David plans to use his HackRF One in his research. He will also be giving talks about SDR at his school and beyond. David is even planning to start a hackerspace at his school. Good luck David!

José Perez Junior is a graduate student at ABC Federal University in Santo André, Brazil. He plans to use his HackRF One to teach students at the university about RF and SDR. He also plans to use it for his own research on SDR and electronic motor control. Congratulations José, and let us know how your research goes!

Sean Semple wrote to us as president of the Association of Cyber Engineers (ACE) at Louisiana Tech University. ACE is an organization that was established a couple of years ago to promote the new Cyber Engineering degree program at Louisiana Tech, but also to help students learn about the cyber landscape as early in their career as possible. Great Scott Gadgets is happy to provide ACE with their very own YARD Stick One!

Once again, thanks to everyone that sent us a request. If you didn't send us a request, why not? It never hurts to ask. We look forward to seeing what you come up with next!

Low Cost SimpliSafe Attacks

2016-02-20T10:49:00

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.

Rapid Radio Reversing, ToorCon 2015

2015-12-29T19:45:00

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.

Free Stuff, March 2015

2015-10-02T14:51:00

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!

Introducing YARD Stick One

2015-09-30T22:16:00

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.

Comments on the FCC NPRM on Equipment Authorization

2015-09-08T17:41:00

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.

PortaPack H1 at DEF CON 23

2015-08-23T16:11:00

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.

My First Look at rad1o Badge

2015-08-11T10:15:00

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!

Wassenaar Comments

2015-07-20T22:36:00

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.

Black Hat Student Pass

2015-06-22T14:29:00

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.

HackRF One at 1 MHz

2015-05-15T11:28:00

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.

Open House Invitation

2015-05-13T00:42:00

For the first time ever, Dominic, Taylor, and I will all be in the same place at the same time in June. We decided we should celebrate, and you are invited!

Please join us at our recently expanded lab in Evergreen, Colorado on 11 June 2015 from 17:00 to 19:00. You can see the lab, talk to us about our projects, check out our latest prototypes, and even learn to solder!

RSVP to info@greatscottgadgets.com by 4 June 2015 so we don't run out of refreshments.

Great Scott Gadgets
27902 Meadow Drive, Suite 150
Evergreen, Colorado 80439
(the Canyon Courier building)

Free Stuff, February 2015

2015-05-12T11:58:00

Great Scott Gadgets is pleased to announce the recipients of our inaugural Free Stuff give-away. This being our first give-away, we got a little overexcited and ended up giving away 5 HackRF One units to people who made requests in February! We were excited to see so much interest in our Free Stuff program, and after much deliberation we were able to narrow the field down to these 5 entrants. Congratulations, and we can't wait to see what you do with your HackRF Ones!

Alex Page wrote to us representing the Interlock hackerspace in Rochester, New York, which has recently begun hosting SDR meetups. They have been encouraging those new to SDR as well as seasoned veterans, and they have made a space where they can all interact. We are awarding Interlock a HackRF One unit to encourage this sharing of knowledge. Thanks Alex, and keep up the good work.

JinGen Lim is a promising student and developer from Singapore. When HackRF One was released he used it as an inspiration to build his own open source device called CCManager. We awarded JinGen a HackRF One unit to see what he can come up with next. Thanks for making your ideas open source JinGen!

Rajesh Kannan is a licensed amateur radio operator and enthusiast as well as a rather successful amateur meteorologist. Rajesh has plans to use his HackRF One to help develop an HRPT satellite receiver with a group of students in India. Thanks Rajesh for igniting the RF spark in the next generation!

Taavi Laadung is a graduate student at the Tallinn University of Technology in Estonia. He is working on a nanosatellite project and plans to use the HackRF One that we give him to help build a ground station. Thanks Taavi for including the HackRF One in your research.

Chris Johns is a student at Spokane Community College in Spokane, Washington, and with the help of a few other members of their technology club Chris plans to use his HackRF One to start an amateur digital TV station. It's an interesting proposition, and we thank you for trying it out, Chris. Good luck!

Thanks to everyone that sent us a request. If you didn’t send us a request, why not? It never hurts to ask. We look forward to seeing what you come up with next!

Discovering the Bluetooth UAP

2014-06-10T17:03:00

During an interview the other day I was asked to describe how we determine the UAP of a Bluetooth address with Ubertooth. A few minutes after the interview I realized that I oversimplified and got one detail wrong: I mentioned whitening when I should have talked about the HEC and CRC. Considering that only a few people in the world have intimate knowledge of our method, I thought it would be a good idea to describe it more thoroughly and correctly for posterity. It’s complicated, and I don’t think we’ve ever attempted to fully describe it anywhere but in the convoluted source code of libbtbb.

I’m writing about classic Bluetooth, by the way, not Bluetooth Low Energy (LE) also known as Bluetooth Smart. In general, these sorts of things are easier with LE, so they do not require such long-winded explanations.

The Upper Address Part (UAP) is a particular 8 bit section of a Bluetooth Device Address (BD_ADDR). In order to fully decode Bluetooth packets, determine a Bluetooth hopping sequence, or do anything else interesting with Bluetooth, we need to know the UAP in addition to the Lower Address Part (LAP) of the piconet’s master device.

The master’s 24 bit LAP is easy to discover using a tool like Ubertooth that can demodulate Bluetooth packets. Every Bluetooth packet includes the master’s LAP as a part of the sync word at the beginning of the packet. It is transmitted in the clear, so we only have to capture and demodulate one packet in order to learn the LAP.

The UAP is harder to determine, but there are multiple methods available to us. The simplest method is brute force search. As Joshua Wright showed in Hacking Exposed Wireless, Second Edition, it is possible to try connecting to a target’s BD_ADDR over and over, guessing a new UAP each time. Because the Non-significant Address Part (NAP) is ignored during the initial connection process, it doesn’t matter what value we use; we only need the correct LAP and UAP. Since the UAP is 8 bits, there are only 256 possible values to try, and a correct match can typically be found quite quickly by prioritizing common UAPs, possible because the UAP is part of the Organizationally Unique Identifier (OUI) assigned to manufacturers (and there is a fairly small number of companies that make the majority of Bluetooth devices). Common UOIs can be identified thanks to the BNAP BNAP project.

Brute force is an excellent method to have in our toolbox, but it has some drawbacks. First, it is an active attack that can influence the behavior of the target devices and that can be detected by a monitoring system. Second, it only works if the master device is in a connectable state. Many devices do not enter the connectable state when they already have an active connection. Annoyingly, many devices are connectable for only brief periods of time (one out of every five seconds, for example), slowing down a brute force search.

The Ubertooth project aims to provide the best possible tools for passive monitoring of Bluetooth systems, so we implement a method of UAP discovery that does not require active transmission.

We think of the problem as being a search for the correct UAP out of a search space that is 8 bits in size (having 256 candidates). We do not have any method to observe the UAP directly, so we instead perform a series of techniques that reduce the search space by a process of elimination until only one possible UAP remains.

Our first technique is to compute the UAP by reversing the Header Error Check (HEC) that appears at the end of the header of every packet that has a header. The HEC is an 8 bit value computed from the master’s UAP and the header bytes. The purpose of the HEC is to allow a receiver to verify that the packet header was received correctly, without any unrecovered bit errors. We assume that we received the packet without bit errors (which is true most of the time). After decoding the HEC and the packet bytes it is possible to determine the one missing variable, the UAP. This is particularly easy because Bluetooth’s HEC algorithm is reversible; we can run it forward to determine the HEC from the UAP and packet bytes, or we can run it backward to determine the UAP from the HEC and packet bytes.

Apart from the ID packet type which is transmitted frequently during inquiry (searching for devices) and paging (connecting), every Bluetooth packet contains a header with HEC. This makes it possible for us to perform this technique frequently for a busy piconet even though we are monitoring only one out of 79 channels.

This may sound like an easy victory, but it is complicated by one significant problem: whitening. Every Bluetooth packet is whitened or scrambled by XOR with a pseudo-random bit sequence before transmission. Since the packet header is whitened, we have to unwhiten it before we can reverse the HEC algorithm.

There are 64 possible pseudo-random sequences that can be used to whiten a packet. The particular sequence is selected by the lower six bits of the master’s clock (CLK1-6) that is used for other things such as synchronizing the frequency hopping pattern.

When we receive a packet, we try each of the 64 possible CLK1-6 values. For each value, we determine the whitening sequence, unwhiten the packet using that sequence, and reverse the HEC algorithm to determine the UAP. This gives us 64 candidate UAP values, so we’ve reduced the search space from 8 bits to 6 bits. Because we have a way to compute the UAP for a particular CLK1-6, we take the approach of trying to determine CLK1-6.

There is one easy way to determine the correct CLK1-6. If a packet has a payload that includes a Cyclic Redundancy Check (CRC), then we can use the CRC to verify that we have unwhitened the packet correctly. If one of our 64 possible CLK1-6 values results in a CRC match, then we win.

Up to this point, this method was described in BlueSniff: Eve meets Alice and Bluetooth.

The main problem with the CRC method is that it only works on packets that have CRCs. If you look through the Bluetooth Core Specification, you’ll find that only certain packet types have payloads with CRCs, and it turns out that these are the minority of Bluetooth packets in the wild. It is very common to see thousands of packets from a piconet without ever capturing one CRC with Ubertooth. Because of this, we needed another method to determine if a CLK1-6 value is correct or incorrect.

The next method we use to validate CLK1-6 is to perform a series of sanity checks on the packet format. The unwhitened packet header includes a four bit packet type field. If, for example, the packet type field is 5, then we know that it is an HV1 packet. HV1 packets do not have CRCs, but they have a payload encoded with a 1/3 rate Forward Error Correction (FEC) method implemented by repeating every bit three times in a row. Since different packet types use different FEC methods, we can perform a sanity check that verifies that every bit is repeated three times for the expected packet length (with some allowance for bit errors). If the FEC check fails, then we can be pretty sure we have the wrong CLK1-6 value.

Up to this point, this method was described in Building an All-Channel Bluetooth Monitor.

Unfortunately, CRC and sanity checks are not as useful as you might think. Originally we thought that we could simply look for correct CRCs, but they turned out to be rare. Then we thought that we could use a process of elimination where incorrect CRCs or sanity check failures would allow us to remove large numbers of candidate CLK1-6 values, but those cases also turned out to be less frequent than we thought.

The main reason we are often unable to eliminate a candidate CLK1-6 value is that Bluetooth has more than sixteen packet types, so the 4 bit packet type field in the header is overloaded. Here’s an example:

For a trial CLK1-6 value, the packet type field is decoded as 10. This could indicate that the packet type is DM3, a data packet carrying 2 to 123 data bytes and a CRC, or it could indicate that the packet type is 2-DH3, an Enhanced Data Rate (EDR) packet that uses a modulation for the payload that cannot be demodulated by Ubertooth One. (We can demodulate the packet header but not the payload.)

Without prior knowledge of the state of the piconet, we don’t know which of the two packet types is present. We assume it is a DM3 packet and check for a CRC. If we get a CRC match then we win, but this is rare. More often the CRC check fails. This means one of two things: Either the CLK1-6 value is wrong, or the packet is actually a 2-DH3 packet that we can’t verify. Since we can’t verify one of the possible reasons for CRC failure, we can’t eliminate that CLK1-6 value from our list of candidates.

Some of our CRC and sanity checks have a positive result indicating a correct CLK1-6. Some of them have a negative result indicating that the CLK1-6 value can be eliminated. However, the majority of our checks have an inconclusive result. This means that the process of elimination is rarely successful with just one packet.

Fortunately Bluetooth piconets tend to transmit packets fairly often, so we can continue the process of elimination across multiple received packets. Once we have the first packet, we can usually reduce the 64 CLK1-6 values to 50 to 60 candidates. With each subsequent packet, we can usually eliminate a few more candidates, but it is tricky.

The trickiness has to do with inter-packet timing. All packets are transmitted in time slots dictated by the master’s clock. We know how often the clock increments, and we have guesses as to the lower 6 bits of the clock. When we receive a subsequent packet, we can measure the time interval from one packet to the next and determine how many time slots have elapsed. This tells us how much to increment our original guesses when testing the new packet.

This would be a fairly reliable method if it were possible to have two clocks perfectly agree with each other. The crystal on Ubertooth One meets the requirements of the Bluetooth specification, so it is just as good as any Bluetooth device (with a frequency stability of 20 ppm). However, we don’t know how much faster or slower the target master’s clock is compared with the clock on the Ubertooth. It might be as much as 40 ppm different. Even if we had the best clock in the universe on Ubertooth, the target master’s clock will still drift by up to 20 ppm (assuming it is operating within spec).

Because of clock drift, we sometimes eliminate a candidate CLK1-6 value that might be correct simply because we counted the wrong number of time slots between packets. Additionally, bit errors in packets may cause us to incorrectly eliminate a candidate (e.g. if the bit error caused a CRC failure on a packet type without an overloaded packet type field). These things happen, and that’s why UAP discovery sometimes fails with zero candidates remaining. In these cases we simply start the process over as new packets arrive, and we usually get a correct result before having to restart very many times.

A nice enhancement to the code would be consideration of the maximum possible clock drift when computing time slot intervals. If we considered three intervals instead of one, for example, we might avoid a lot of cases where we improperly eliminate the correct CLK1-6 value. Additionally, we could benefit from keeping a running estimate of the master’s clock drift after we have determined the UAP.

A problem people sometimes have with Ubertooth is that the correct UAP is determined but is subsequently lost. This happens because a packet is received that doesn’t agree with the previously determined UAP, probably because of bit errors but possibly due to clock drift. Since we have an all-or-nothing approach to determining the UAP, a single disagreement can result in losing the correct value. Another nice enhancement would be maintaining a confidence value for the current UAP (or perhaps for multiple candidates). If a UAP has proven correct for 1000 packets, it would be nice not to throw it out when one packet disagrees. This would complicate some already convoluted code, but it is definitely worth trying.

Overall, we have a very effective method of determining the master’s UAP through passive monitoring. It is complicated, but it is only a small part of the even more complicated process of determining a piconet’s frequency hopping pattern and hopping along.

Ubertooth Release 2014-02-R2

2014-03-12T03:50:00

After a very long break, we are pleased to announce a new release of Ubertooth and libbtbb code. Release notes are given below but for those short on time, the summary is: a major update with complete rewrites of the libbtbb API, greatly improved BTLE support and a migration to GitHub. You can find the release here.

Release Notes

The Ubertooth host utilities in this release require libbtbb-2014-02-R2 or greater.

The release archive is ubertooth-2014-02-R2.tar.xz, it contains binary firmware images and PCB layouts as well as the project source code. The source code links do not include the binary files.

These are just the highlights, for a complete list of changes since the previous release, see the git commit log.

Bluetooth Smart (Low Energy) Support
- Promiscuous and follow modes
- Pcap format packet logging
- Pairing / encryption support when paired with crackle
- Credit for BLE features goes to Mike Ryan
Unified host tool for monitoring Basic Rate
- ubertooth-rx replaces -lap, -uap, -hop tools
- Once UAP is discovered, ubertooth-rx automatically tries to find clock values and begin hopping
- Thanks to Will Code for working on this
Survey tool - ubertooth-scan
- Combining both Ubertooth and a standard Bluetooth dongle
- Ubertooth scans for non-discoverable master devices
- Dongle probes devices for piconet information and features
Cmake now used for the build system
- Improves support for non-Linux operating systems
- More sensible handling of dependencies
- New build instructions
Packaging (Experimental)
- Early stage support for packaging systems
- libbtbb in Homebrew repository, Ubertooth coming soon
- MacPorts availability is under test
- Release already available in Pentoo
GitHub migration
- libbtbb, Ubertooth and gr-bluetooth all hosted on GitHub
- Allows for more open development and collaboration model
- Already seeing an increase in issue reporting and pull requests

Speeding up CRC calculations for Bluetooth Low Energy

2013-05-07T21:19:00

Over the past few days Mike Ryan has been working hard to cram as much of the Bluetooth Low Energy (BTLE) functionality as possible in to the Ubertooth firmware. In doing so he plans to relieve the host system of the work involved in finding and processing packets. In time this will allow Ubertooth to monitor and inject packets in to BTLE connections while running from a very low powered host, or possibly without a host system at all.

This has involved some excellent work using the CC2400 chip to automatically detect BTLE packets, a task which it is unfortunately unable to achieve for basic rate Bluetooth. Once we know where a packet starts we are able to handle the packet data as a set of bytes rather than needing to break the data up in to bits before running through the whitening and CRC algorithms.

While Mike worked on the whitening algorithm, he set the CRC as an open challenge, which I gladly took up. I thought that it may make an interesting post to explain how CRC algorithms are implemented and show how to trade off time for memory, or time for space complexity for the computational theorists among us, by using a look up table (LUT). This may be common knowledge to many people and there are automated tools to achieve it, but I wanted to work it out by hand.

This part is, at least in part, for my own reference when I look at the code in a year’s time and ask “who did that? And how o we know it’s correct?”

Linear Feedback Shift Registers

Linear Feedback Sift Registers (LFSRs) are often used for CRC checks, forward error correction or to generate pseudo-random data. They are computationally cheap and simple to implement in hardware if required, so they are perfect for low cost networking chips. Bluetooth uses them to implement data whitening, header error checks, CRCs and forward error correction on packet data.

The LFSR that implements the CRC on BTLE packets looks something like this:

The LFSR for CRC on BTLE packets as drawn by me. See Vol 6, part B, Section 3.2 of the Bluetooth specification for a better, but non-free version of the diagram. For simplicity we can imagine the LFSR as parts, a shift register and the feedback element, using XOR. Each incoming bit of packet data is XOR’d with the right-most bit of the register, for consistency we’ll assume that the bits are numbered 0-23 from left to right. Bit 23 is XOR’d with the incoming data bit and becomes next_bit. The register is shifted one bit to the right and next_bit is added to the end, becoming bit 0. This is a shift register.

Now for the feedback part, each of those arrows feeding in to the top of the register represents a bit in the register that will be XOR’d with next_bit. T\hat is all you need to know about LFSRs for most usese, in fact it should be trivial to implement one using the above information. Here’s our implementation of the above LFSR:

u32 btle_calc_crc(u32 crc_init, u8 *data, int len) {
    u32 state = crc_init;
    u32 lfsr_mask = 0x5a6000; // 010110100110000000000000
    int i, j;

   for (i = 0; i < len; ++i) {
        u8 cur = data[i];
        for (j = 0; j < 8; ++j) {
            int next_bit = (state ^ cur) & 1;
            cur >>= 1;
            state >>= 1;
            if (next_bit) {
                state |= 1 << 23;
                state ^= lfsr_mask;
            }
        }
    }

    return state;
}

Optimising the LFSR

As you can see, we run through the inner loop for each bit of data, although we only perform the XOR if we next_bit was set. This is a very small optimisation that makes use of the shift operation filling with 0s and the fact that XOR with 0 would have no effect. Logically this process looks a little like this:

The LFSR split in to a shift and a feedback, or XOR, component. The diagram above shows the two stage LFSR, with the second stage containing the different masks to be XOR’d with the register depending on the state of next_bit. This is a two value look up table holding 24 bits od XOR mask.

If we can shift then look up the XOR for one bit, why not more? As long as we shift by the appropriate amount, the XOR result only relies on the incoming data and the state of the register. Even better, there is no feedback in to the lowest byte of the register, so early bits in an incoming byte don’t affect the value of later bits.

Working with Bytes

Taking a byte of input data, we first XOR it with the lowest byte of the register to get next_byte, then we shift the register to the right by a byte and append next_byte. This takes care of the shift.

To finish off we need to apply the eight XOR masks based on the content of next_byte. As the register is shifted for each bit, the masks are XOR’d together with each successive mask shifted by one bit, this is shown in the diagram below.

The final mask is produced by XORing the mask for each bit of next_byte.

The derived mask is specific to the next_byte value of 01101101, so we are able to store it in a table and retrieve it for future use. If we do this for all 256 values of next_byte we can build a full look up table, and use it to calculate the CRC.

The following code implements the CRC using a LUT:

u32 crcgen_lut(u32 crc_init, char *payload, int len)
{
    u32 state = crc_init;
    int i;
    u8 key;
   
    for (i = 0; i < len; ++i) {
        key = payload[i] ^ (state & 0xff);
        state = (state >> 8) ^ crc_lut[key];
    }
    return state;
}

The LUT itself consists of 256 32bit values, so is too large to reproduce here, but it can be found on Github.

While it is possible to write code to that builds the LUT from shifted masks for each value of next_byte, it was easier to use the known good implementation of the CRC algorithm given earlier to provide the final state of the register for all one byte payloads and then XOR it with the pre-mask state, as shown below.

The XOR mask for each key is calculated and then stored in the LUT. After looking at the code, Michael Ossmann pointed out that leaving the key byte blank while building the LUT would yield the same result and avoid a pointless shift operation in the final algorithm. It seems that no matter how nerdy you try to be, someone will out-geek you.

Motivating the Problem

2013-02-07T16:08:00

One of the most difficult aspects of talking to people about Bluetooth packet sniffing is what my university supervisor called “motivating the problem”. What he meant by this was trying to convince others that the problem which you were trying to solve was really as hard as you know it to be.

Over the past five years we have dedicated a lot of time to motivating the problem when we give presentations on Bluetooth security, often resulting in glazed looks from some audience members. This post is intended to go some way towards explaining the challenges facing our project and to encourage anyone interested to participate.

Bluetooth packet sniffing falls foul of the motivation problem because it is so often compared to other wireless protocols that appeared at around the same time, such as 802.11 and Zigbee, which had promiscuous packet sniffing solutions available, using commodity hardware, soon after their release.

Another reason that Bluetooth sniffing is hard to discuss is the set of terms that need to be defined before we can even begin to describe the problems involved. At a minimum, the following are useful to know before entering in to a discussion about Bluetooth packets:

Piconet - A personal area network with one master device connected to potentially many slave devices.

Master device - The device that defines a piconet, often but not always the “smartest” device, e.g. a PC or phone.

Slave device - The device being connected to the master, e.g. a keyboard, mouse or headset.

Bluetooth Device Address - A 48 bit unique device address, usually shown in the same format as IEEE 802 MAC addresses and issued from the same address space. It is common for smartphones to have consecutive Bluetooth device and wifi MAC addresses.

NAP - Non-significant Address Part. The first two bytes of the device address.

UAP - Upper Address Part. The third byte of the device address. Forms the organizationally unique identifier when combined with the NAP.

LAP - Lower Address Part. The lower three bytes of the device address, assigned by the manufacturer.

CLK27 - A 27 bit counter that increments 3200 times per second and wraps in slightly less than 24 hours. Every device maintains an internal clock value, although we are mostly concerned with the master device’s clock. Often referred to as “the clock”.

CLKN - The upper 26 bits of CLK27. This is a clock that ticks 1600 times per second, once per packet “slot”.

AFH Map - Adaptive Frequency Hopping allows Bluetooth connections to avoid using noisy channels, such as channels that overlap nearby wireless networks. The map specifies which channels are available for a given connection.

The feature of Bluetooth that makes packet sniffing so hard is frequency hopping. Originally designed to ensure robust connections, it causes more problems and confusion for packet sniffers than any other feature. The pseudo-random hopping sequence that all devices within a piconet share is determined by the LAP, UAP and CLKN of the master device. To have any chance of extracting useful data from a Bluetooth connection we need to know these three values.

The situation gets even worse for encrypted links. To have any chance of sniffing the pairing process, and using the extracted data to find the pin (see: http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/index.html ), we must know these three values before the target devices begin to communicate.

One solution to this is to begin sniffing all traffic in a target piconet on the assumption that a new device will be paired with it in the future. In many ways it is good that this is not a practical attack vector, however it makes research and investigation in to Bluetooth authentication and encryption a harder task.

Devices that support Bluetooth v2.0+ also support adaptive frequency hopping (AFH), which adds an additional variable to the list that we have to find before we can monitor a connection.

The Ubertooth tools passively monitor each channel in turn to find piconets and build up information on the LAP, UAP, CLKN and AFH map, this behaviour can be seen in the Kismet plugin. Ubertooth-follow is the one exception to this method as it uses a Bluetooth dongle to acquire the values that the Ubertooth needs to follow a hopping pattern.

Hopefully this has provided a crash course in Bluetooth packet sniffing for anyone who wants to get involved or try out the Ubertooth tools. We’re working hard to improve the amount of data that we are able to collect as well as adding features such as packet injection, Bluetooth Low Energy support, integration with external tools such as Wireshark and Kismet and support for more low cost embedded platforms such as ARM (raspberryPi, BeagleBone) and Android.

So You Want to Track People with Ubertooth

2012-11-14T16:15:00

I am contacted frequently by people who want to use Ubertooth One to track the movements of vehicles or pedestrians on highways, at airports, in shopping malls, etc. This is a FAQ.

Q: Can Ubertooth One be used to monitor movements of people carrying Bluetooth devices?

A: Yes. With multiple Ubertooth Ones covering different locations, you can determine the time that a particular target device is present at each location. This could allow you to compute average travel times on highways, wait times in queues, etc.

Q: We currently track Bluetooth devices by using standard Bluetooth adapters performing frequent inquiries. This only detects discoverable devices. Ubertooth One could be used to track non-discoverable devices, right?

A: Yes. However, Ubertooth One only detects devices when they are actively transmitting. An idle target device, discoverable or not, will not be detected by Ubertooth One in passive monitoring mode. Inquiry detects discoverable devices whether or not they were active before inquiry; passive monitoring detects active devices whether or not they are discoverable.

Q: So an optimal solution to identify the largest number of devices would incorporate both inquiry and passive monitoring?

A: To identify the most devices possible, you should use both inquiry and passive monitoring. Additionally you could perform paging or partial paging. Paging is the process used when a Bluetooth device connects to another. Once you have identified a non-discoverable Bluetooth device address with passive monitoring, you can page for that address. This determines whether or not the target device is present even if the device has become inactive.

Q: How is partial paging different than normal paging?

A: The normal paging procedure involves several packets transmitted back and forth between the master (the paging device) and the slave (the paged device). The first packet is transmitted by the master and contains the slave’s address. The second packet is transmitted by the slave in response to the master. It is possible for the master to stop the paging procedure at this point before fully opening the connection. The first slave response packet is sufficient to determine the slave’s presence. (This is analogous to a TCP SYN scan.) This partial paging procedure would be faster than a complete paging procedure. I don’t know of any implementations, but Ubertooth One would be a good platform for developing such a thing.

Q: Could partial paging be used to conduct a brute force search for all possible LAPs (Bluetooth Device Address Lower Address Parts)?

A: Yes, but it would take a while. Even with some optimizations, I estimate that an exhaustive brute force LAP search by partial paging with a single Ubertooth One would take on the order of 100 hours. This is considerably faster than previous implementations but is probably too slow to be useful for tracking applications.

Q: Could packets transmitted by paging or partial paging be misinterpreted by a nearby passive monitor, indicating presence of a device that is not there?

A: Yes. If you implement both paging and passive monitoring, you must take care to ignore the packets transmitted by your own system.

Q: We’re tracking Bluetooth devices anonymously.

A: No, you’re not.

Q: No, really! We are! Aren’t we?

A: Unless your system has been designed carefully for anonymity and has been audited thoroughly for anonymity by an information security professional, it is highly unlikely that you are tracking people anonymously. If you store BD_ADDRs (Bluetooth Device Addresses) of target devices, you are storing individually identifiable information about the owners of those devices. The same is true if you store hashes of BD_ADDRs or encrypted BD_ADDRs unless great care has been taken to irrevocably destroy encryption keys. If you delete stored data without an audited secure erasure procedure, you should assume the data are easily recoverable. Most importantly, if you tell people that their information is being anonymized without properly anonymizing it, you are a bad person.

Q: Are you interested in building a tracking system for us?

A: I am interested, from an academic standpoint, in tracking the movements of Bluetooth devices, and I believe that people have a right to know how they can be tracked by transmissions from wireless communication devices they carry. I would be willing to develop special purpose hardware and software for such applications so long as I am permitted to publish everything I produce under an open source license.

Q: We would like to pay you to develop a proprietary tracking system and grant us exclusive distribution. Will you do it?

A: I develop only open source hardware and software.

Discovering Bluetooth Devices

2012-10-17T23:24:00

In July 2011 Michael Ossmann wrote a blog post entitled “Discoverability is Not a Mitigating Factor” which discussed the Bluetooth security advice being given about discoverable devices by people and organisations that should know better. It is worth reading his post in full, but I’ll quote two important parts here:

“LAP sniffing is easy. Spill and Bittau showed how to sniff LAPs with a USRP for about $1000. Now it can be done with an Ubertooth One for about a tenth of that price. It can even be done using Travis Goodspeed’s method for promiscuous sniffing with lower cost platforms.”

“The UAP is only slightly more difficult for an attacker to learn. Project Ubertooth and gr-bluetooth include software that implements automatic UAP determination based on passive observation of just a few packets.”

I completely agree with Michael on this, the methods for retrieving the LAP and UAP are easy and well known, but we still hear advice suggesting that turning off the discoverable setting for your device will protect it from being found by malicious attackers. So, taking in to account Wright’s law:

“Security will not get better until tools for practical exploration of the attack surface are made available.” -Josh Wright

I wrote a tool that would initiate a standard Bluetooth device scan, but also add devices discovered with the Ubertooth. I call the tool “ubertooth-scan” and it’s available from the master branch of the Ubertooth git repository.

Ubertooth-scan requires an Ubertooth and a standard Bluetooth device on a host with libbluetooth (bluez) installed. First we use the Bluetooth device to perform an HCI scan, this is the same as running “hcitool scan” from the command line. The second part of the tool uses the Ubertooth to promiscuously sniff for Bluetooth packets, retrieving the LAP and UAP values before handing them over to libbluetooth to query the device name. Most non-discoverable devices respond to name inquiries.

I’ve also added an extended query (triggered by the -x option) which will check the device for supported features, chipset version and clock offset from the local device.

Using a dongle to get the clock offset for a remote device allows us to calculate the clock value of the target and use that to hop along with the piconet, dumping packet data to screen as we go. Here’s a quick snippet of the code in action, apologies for the low quality video:

Note from 2022: The video that was in this post is no longer available.

I’ll be presenting this in more detail, along with other recent developments in the Ubertooth project, at Ruxcon this weekend. If you are in Melbourne or are already planning to attend Ruxcon, and would like more detail, please come to my presentation at 2pm on Sunday in track 1.

Ubertooth and libbtbb Release 2012-10-R1

2012-10-11T21:48:00

The latest release of the Ubertooth software is now available. The 2012-10-R1 release contains numerous bug fixes and minor improvements as well as some large architectural changes.

The host code for both Ubertooth and libbtbb is now easier to compile, with major simplifications to the process for the btbb Wireshark plugin. Build instructions can be found on the Ubertooth website.

As development has shifted from a subversion repository to a git repository, we no longer have sequential revision numbers to use for release naming. All future releases will be named using the year and month of release.

When using the latest release it is necessary to update the firmware on your Ubertooth. Binary firmware images can be found in the release package, and flashed to the Ubertooth using the ubertooth-dfu tool (ubertooth-dfu –write <image-filename.dfu> –detach). The host code needs to be built and installed before updating firmware images. Alternatively firmware images can be built using the ARM embedded variant of gcc.

The release notes for the ubertooth 2012-10-R1 release are as follows:

Release Notes

The Ubertooth host utilities in this release require libbtbb-2012-10-R1 or greater, it can be found at https://sourceforge.net/projects/libbtbb/files/.

These are just the highlights. For a complete list of changes since the previous release, see the git log.

libubertooth

The core Ubertooth functions are now packaged as a library, which allows us to have some independence between the core ubertooth functions and the tools that use them, such as ubertooth-* and the kismet plugin. This should also help with future binary packaging.

Firmware flashing

The ubertooth-dfu tool now attenpts to identify Ubertooth devices and put them in to firmware upgrade mode. Multiple arguments can also be passed to ubertooth-dfu and will be executed in the order specified ont he commandline. To flash firmware on to an ubertooth device, use the following command: ubertooth-dfu –write <firmware_image.dfu> –detach

Bluetooth Low Energy (Experimental)

Bluetooth Low Energy (Bluetooth Smart) sniffing is experimentally supported by the bertooth-btle tool. The tool can be used to sniff the connection setup procedure between devices; promiscuous sniffing is available but is extremely experimental. Credit for this achievement goes to Mike Ryan.

Ubertooth-follow

Ubertooth-follow has been added to the set of Ubertooth commandline tools. It retrieves the clock value from a local device using libbluetooth (bluez) and uses the Ubertooth to hop in time with the piconet. To build ubertooth-follow use “make clock_debug=true”.

Since the last release we have moved the source repository from SVN to Git. This should not affect the released code, but makes life easier for those of us working on the code.