Over the past two days, I had the opportunity to attend Michael Ossman’s course “Software Defined Radio with HackRF” at Toorcon XX. This is a course I’ve wanted to take for several years, and I’m extremely happy that I finally had the chance. I wanted to write up a short review for others considering taking the course.

Course Material

The material in the course focuses predominantly on the basics of Software Defined Radio and Digital Signal Processing. This includes the math necessary to understand how the DSP handles the signal. The math is presented in a practical, rather than academic, way. It’s not a math class, but a review of the necessary basics, mostly of complex mathematics and a bit of trigonometry. (My high school teachers are now vindicated. I did use that math again.) You don’t need the math background coming in, but you do need to be prepared to think about math during the class. Extracting meaningful information from the ether is, it turns out, an exercise in mathematics.

There’s a lot of discussions of frequencies, frequency mixers, and how frequency, amplitude, and phase are related. Also, despite more than 20 years as an amateur radio operator, I finally understand dB properly. It’s possible to understand reasonably without having to do logarithms:

• +3db = x2
• +10db = x10
• -3db = 1/2
• -10db = 1/10

In terms of DSP, he demonstrated extracting signals of interest, clock recovery, and other techniques necessary for understanding digital signals. It really just scratches the surface, but is enough to get a basic signal understood.

From a security point of view, there was only a single system that we “attacked” in the class. I was hoping for a little bit more of this, but given the detail in the other content, I am not disappointed.

Mike pointed out that the course primarily focuses on getting signals from the air to a digital series of 0 an 1 bits, and then leaves the remainder to tools like python for adding meaning and interpretation of the bits. While I understand this (and, admittedly, at that point it’s similar to decoding an unknown network protocol), I would still like to have gone into more detail.

Course Style

At the very beginning of the course, Mike makes it clear that no two classes he teaches are exactly the same. He adapts the course to the experience and background of each class, and that was very evident from our small group this week. With such a small class, it became more like a guided conversation than a formal class.

Overall, the course was very interactive, with lots of student questions, as well as “Socratic Method” questions from the instructor. This was punctuated with a number of hands-on exercises. One of the best parts of the hands-on exercises is that Mike provides a flash drive with a preconfigured Ubuntu Linux installation containing all the tools that are needed for the course. This allows students to boot into a working environment, rather than having to play around with tool installation or virtual machine settings. (We were, in fact, warned that VMs often do not play well with SDR, because the USB forwarding has overhead resulting in lost samples.)

Mike made heavy use of the poster pad in the room, diagramming waveforms and information about the processes involved in the SDR architecture and the DSP done in the computer. This works well because he customizes the diagrams to explain each part and answer student questions. It also feels much more engaging than just pointing at slides. In fact, the only thing displayed on the projector is Mike’s live screen from his laptop, displaying things like the work he’s doing in GNURadio Companion and other pieces of software.

If you have devices you’re interested in studying, you should bring them along with you. If time permits, Mike tries to work these devices into the analysis during the course.

Tools Used

• HackRF One (Received as part of the class)
• GNURadio
• Baudline
• inspectrum

Additional Resources

• Practical Signal Processing by Mark Owen
• Understanding Digital Signal Processing by Richard G. Lyons
• GNURadio Guided Tutorials

Opinions & Conclusion

This was a great class that I really enjoyed. However, I really wish there had been more emphasis on how you decode and interpret the unknown signals, such as discussion of common packet types over RF, any tools for signals analysis that could be built either in Python or in GNURadio. Perhaps he (or someone) could offer an advanced class that focuses on the signal analysis, interpretation, and “spoofing” portions of the problem of attacking RF-based systems.

If you’re interested in doing assessments of physical devices, or into radio at all, I highly recommend this course. Mike obviously really knows the material, and getting a HackRF One is a pretty nice bonus. Watching the videos on his website will help you prepare for the math, but will also result int a good portion of the content being duplicated in the course. I’m not disappointed that I did that, and I still feel that I more than made good use of the time in the course, but it is something to be aware of.

I’ve seen a lot of discussion of experience requirements and “entry-level” positions in the security industry lately. /r/netsecstudents and /r/asknetsec are full of threads discussing this topic, and I heard it being discussed at both BSidesLV and DEF CON this summer. The usual complaint is something along the lines of “all the positions want experience, so how am I supposed to get experience?” I’m going to take a stab at addressing this, and hope to at least provide some understanding.

I meant to write this post much closer to the end of Hacker Summer Camp, but to be honest, I’ve been completely swamped with getting back into the thick of things. However, I kept feeling like things were “unfinished”, so I thought I’d throw together at least a few thoughts from this year.

BSides Las Vegas

I can’t say much about BSides as a whole this year, as I spent the entire time Gold Teaming for Pros vs Joes CTF. (Gold Team is responsible for running the game infrastructure, scoreboard, etc.) It was a great experience to be on Gold Team, but I do miss having a team to support and educate. Overall, the CTF went fairly well, but there were a few bumps that I hope we can avoid next year.

BSides also announced that they are ending their free badges. In some ways, I’m disappointed, but I also understand the reasons they are doing this. Even though I’ve had a badge included with my participation in the PvJ CTF for years, I’ve also been a personal sponsor of BSidesLV for those years as well. I’m lucky enough to be well-employed in the industry that BSidesLV supports, and I want to support their mission. I hope others will do so as well, but I also want to try to find a way to support those who aren’t able to shell out for a badge. Once details are announced for badges next year, I’ll look for an opportunity to support passionate students in our community.

DEF CON 26

DEF CON 26 was an incredible event. I know there were some bumps and warts to it, but I had a great con. (Also, I think it’s the only conference I attend that I refer to simply as “con”.) The villages are my favorite part of DEF CON, and the villages were in rare form this year with the expansion.

This year was my first year speaking at DEF CON (as a village speaker) and I am incredibly humbled by the experience. To think that something I had done was seen as interesting enough for 150 or so attendees to choose to spend 45 minutes of their time listening to me really makes me feel like I’m making an impact. The audience was great, and thanks to the IoT village for having me. (Maybe one day I’ll get a DEF CON speaker badge to place on my wall of badges.)

I have hopes that next year, villages will have some way to divide their rooms or reduce noise for the presentations in their space. So many run another activity (a CTF, hands on activities, etc.) and the noise from that can be problematic when it comes to speakers in the same space. (I experienced this both as a speaker and as an attendee for the talks.)

I also hope that next year, DEF CON will have helped to work through the issues we had with Caesar’s security this year. A good friend of mine landed in hot water over a misunderstood tweet, and there were the obvious reports of “room checks” that were not going according to the established policy. (I’m not even a fan of the room checks, but rifling through guests belongings is completely unacceptable.)

Splitting across Las Vegas Boulevard was also not the best situation. I look forward to moving back to Paris/Bally’s and having Planet Hollywood join the con. (Plus, breakfast crepes!) Getting over to Flamingo was such an ordeal that I only went over there once, and it was a brief visit at that. The ICS village over there was really impressive, and I missed out on a chance to get a Car Hacking Village badge. Some of this was poor planning on my part, but also the sheer distance between the two conference areas made it anything but convenient.

Conclusion

I can’t wait until next year. I’ll begin my planning guide around the beginning of 2019 to try to provide support to those looking for travel information, and I have a feeling that DEF CON 27 will be an even stronger showing. Here’s to all the contributions of the hacker family!

Today I’m giving a talk in the IoT Village at DEF CON 26. Though not a “main stage” talk, this is my first opportunity to speak at DEF CON. I’m really excited, especially with how much I enjoy IoT hacking. My talk was inspired by the research that lead to CVE-2017-17704, but it’s not meant to be a vendor-shaming session. It’s meant to be a discussion of the difficulty of getting physical access control systems that have IP communications features right. It’s meant to show that the designs we use to build a secure system when you have a classic user interface don’t work the same way in the IoT world.

(If you’re at DEF CON, come check it out at 4:45PM on Friday, August 10 in the IoT Village.)

I’ve spent an unhealthy amount of time over the past 6 months or so participating in the craze that is #badgelife. This year, I built badges for my Security Research Group/CTF Team: Attacker Community. (Because community is important when you’re attacking things.) Like last year, all of my badges were designed, assembled, and programmed by me. There are 24 badges this year, each featuring 8 characters of 14-segment display goodness and bluetooth connectivity. I may not be one of the big names in #badgelife, but if you just make some badges for your friends, there’s a lot less pressure in case something comes up.