GreatFet Feature on Hackaday
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!
Shutting Down GSG Project-Specific Mailing Lists
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:
The History of LUNA
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!
Talking about GreatFET with Limor "Ladyada" Fried at Adafruit, 2019
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.
Reverse Engineering Black Box Systems with GreatFET, Troopers 2018
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.
GreatFET on Hak5
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!
GreatFET One Has Arrived
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.
Crème Brûlée Camp
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.