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.
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.
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.
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.
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.
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.
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!
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 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!
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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!
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.
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!
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!
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.
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.
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.
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.
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.
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.
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.
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.
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!
Tim Fogle had some Good Ideas in June, so we sent him a GreatFET One. He wants to build a neighbor for CTF challenges.
subscribe to GSG feed