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.

1. 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.

2. 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.

3. 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.

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.

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

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.

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.

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.

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.

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.

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!

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!