Event Logs

Collapse

• Hack Chat Transcript, Part 1

  Dan Maloney • 09/09/2020 at 20:07 • 0 comments

  Hi all, welcome to the Hack Chat. I'm Dan, I'll be moderating today for our guest Michelle Thompson, who's here to tell us about what goes into designing hardware challenges for cons. I'm not sure I saw her log in yet, though - are you out there, Michelle?

  Abraxas3d12:00 PM
  Yes! Hello and thank you so much.

  Jacques Gagnon joined the room.12:01 PM
  

  Hi Michelle, welcome to the Hack Chat!

  Abraxas3d12:01 PM
  I very much appreciate the opportunity. I have some things written to start us off.

  Abraxas3d12:02 PM
  Greetings all! I'm Abraxas3d (Michelle Thompson W5NYV), MSEE from USC in Information Theory, Senior Member IEEE, IEEE Vice Chair San Diego Chapter Information Theory Society, IEEE Distinguished Visitor 2017-2019, co-founder and current CEO of Open Research Institute, Inc., Chair of GNU Radio Conference, ARRL Life Member, 10-10 Life Member, Yikes Did I Let my TAPR Membership Lapse Again?, AMSAT Director 2019-2021, DEFCON, Burning Man, Pokemon, and Formula 1! Thank you for welcoming me here today.

  I've coordinated a Capture the Flag (CTF) competition at GNU Radio Conference over the past few years. CTFs are competitions that are very much like sports events. There are challenges that require skill to solve. Points are awarded. There is usually a limited time, sometimes a day or a weekend. There's often prizes, sometimes cash awards. They go on all the time - there is usually one every weekend that you can do remotely.

  Most CTFs are software-based and information security focused. They are somewhat easy to do remotely.

  For GNU Radio Conference, we wanted to do something that let people use the DSP framework with their software defined radios to figure out puzzles from real hardware on site at the event. This meant real hardware (and software) for the challenges and real hardware and software used by the participants.

  So what kind of puzzles or challenges have we had?

  Many modern signals sound exactly like noise in a general receiver, so sometimes just figuring out they are even there is a big first step. There are several types of radio signals that can lurk beneath the noise floor, like spread spectrum. Some hop around, like you might have seen near 915MHz in the US. Not knowing where the next burst of information will show up can make intercepting a signal tricky!

  In order to receive, you have to demodulate a signal. That means figure out what shape or kind of electromagnetic waveforms are being used, how large is the set of waveform symbols (sort of like what alphabet a human language uses), and how to best capture those wiggly waveforms.

  Once that's known, for a digital signal, you then should have a lot of 1's and 0's. If it's encoded, to protect from errors or to provide secrecy, then you have another layer to work through. And so on! There may be multiple levels and different types of coding. There are some codes that are theoretically impossible to crack. There are some that are possible to crack but take too long to realistically spend time on. For friendly competitions, we use modulation and coding that aren't too difficult. There may be a clever trick, or a technique with special utility. Our emphasis has been on friendly competitive learning, and hints and explanations are OK during the competition.

  A great walk-through of reverse engineering a signal is Matt Knight's GNU Radio Conference presentation on LoRa:

  You can see how you peel back the onion layers!

  There are many modern radio signals that use protocols that mix data types, like in Radio Data System, an FM broadcast format. https://en.wikipedia.org/wiki/Radio_Data_System

  What we did with an RDS challenge is set up a very low power (legal) FM station at the conference. We created some content, programs, commercials, and so on. Some of answers could be found in the main audio content. However, RDS has several subcarriers. And we used them as well, to communicate information like the weather report, but we altered them slightly,...

  Read more »

View event log