How to Design Your Way Through a Hacking Competition

How to Design Your Way Through a Hacking Competition

As opposed to hacking your way through a design competition
Rob Rehrig
Derek Olson
Raina Wellman
read time:

You’ve infiltrated the other team’s base, found the hidden flag, and are anxiously navigating back to safety in order to score. For many people, this might bring back adolescent memories of playing capture the flag with their neighbors; for the two of us, this was what it felt like to compete in Thotcon, a two-day hacking conference. Instead of running around in someone's backyard, we were gunning for flags over wireless connections, hacking into devices, and deciphering puzzles.

In the hacking world, capture the flag (CTF) describes a competition that requires participants to complete challenges that vary in topic (hardware, software, social engineering, cryptography, etc.) and complexity to—you guessed it—capture digital flags. Not only does winning these competitions mean bragging rights and great prizes, it’s also a great way to learn and teach new skills while working with others in the community.

To prepare for the competition, we doubled down on the design thinking process we rely on in our work: We built a multidisciplinary team so we had a wealth of resources on our side, and we relied on rapid prototyping to create tools that helped us solve puzzles. Here are our best tips for getting through a challenge like this one, borrowed and modified from the best practices and processes of design thinking.

Assemble a dream team

CTF challenges are usually designed to push the bounds of competitors’ knowledge and abilities, and this one was no different. When we were preparing, we knew we’d need a team that could handle embedded systems and hardware as well as web and networking. Luckily, between the two of us, we have those covered, but we also teamed up with friends at the conference with specialties in cryptography, wireless hacking, and other skills to round out our abilities.

As we thought about the types of challenges we might face, we broke down the kinds of skills we'd need and assigned them among the team. Once the challenge kicked off, we huddled to share ideas and make sure that none of the teammates got stumped on their pieces of the challenge. Even though assigning roles to work efficiently is really important, you can’t get through a challenge without leaning on one another.

Adopt a beginner’s mindset

When you go into a challenge like this, you often face things you’ve never seen before, like long strings of garbled text that make absolutely no sense at first glance; hardware that is completely new to you; antiquated and obscure software that you need to exploit somehow.

It’s daunting, but it’s not so different from taking on a design challenge. When you rely on the methods and processes of design thinking to find an unknown solution to a complex problem, you don’t know what you’re trying to build until you figure it out. CTFs work much the same way. And to succeed at them, we rely on the same methods we use to create a new product or service, or solve an engineering problem: we adopt a beginner’s mindset. When we start a project, we take significant time researching the client, the industry, and of course, the users. When we sign up for a challenge, we start working to learn as much as we can in advance, thinking about the creators and what kind of challenge they might be looking to hand us. Having little to no idea about what we’ll encounter once the challenge starts, we do our best to prepare.

Build, test, fail… repeat!

Seldom do we participate in a CTF without having to develop custom tools on the fly, like software scripts for cracking cryptography or custom hardware for probing and manipulating physical challenges. Given our time constraints, we have to slap these tools together, focusing on scrappy versions that will last just long enough to help us solve the challenge and find the flag. CTFs tend to last only a couple of days, so time is a valuable resource. It usually doesn’t matter how well a tool is designed, as long as it can be made quickly and help get us closer to the flag.

It’s a strategy straight out of the design thinking playbook. When designers are coming up with a new solution to a problem, we don’t always have time to take one idea from concept to completion. We work on many solutions in tandem, figure out which ideas are going to fail fast, then advance the others forward (or come up with totally new concepts). The tools we develop during hacking CTFs are no different. It’s a cycle of quick development, testing, and processing the feedback in order to inch closer to a solution.

Get out of your head

These challenges are called challenges for a reason. At this point, the two of us have been around the CTF block before—and yet we still get stuck and fail spectacularly.

This time, for example, we ran into an issue with listening to an audio clip that played from our ID badges. We couldn’t make out what was coming out of the tiny speaker, so we started thinking about ways to rip the firmware off the badge and download the file it was playing. That was going to take hours (if not longer), but Rob suggested we just needed a better speaker. We were thinking way too technically—we didn’t need to rip the file, we just needed to hear it better.

By articulating the simplest problem and searching for the simplest solution, we were able to move forward much faster than if we had tried to solve the problem in a much more “correct” way. It’s about knowing when to take a step back and allowing yourself to be curious about other possibilities.

Just like with our other work, failure is part of the process. Sometimes your seemingly perfect solution fails in testing, or your prototype isn’t what a client wanted. You get sent back to sketch out new ideas and start again. After our momentary fiasco with the ID badge speaker, we got the message from the audio file, moved forward to the next challenge, on and on, until we won!

Enjoy sweet, sweet victory

By pulling from our IDEO skills, and with support from some new friends, we ended up winning our first hacking CTF at this competition. We’ve since gone on to compete in other hacking competitions around the country, including winning DarkNet at the notorious DEFCON, thanks to our experience in things like breaking out of handcuffs and having a basic proficiency in Vulcan. (Yes, knowing the fictional language from Stark Trek was an actual part of the competition). Part of the challenge even involved cracking codes to gain access to a secret party—super cool.

If you can’t tell, we’re huge fans of the way CTFs push us to think quickly, pivot fast, and challenge our expectations. And Rob is such a fan that he’ll be heading back to Thotcon this year as an organizer. That's handy for the rest of us, because even though he won’t be sharing any hints as to what’s coming, we already know the way he thinks. We're ready to hit step number two, thinking about the kinds of challenges he might be all too excited to throw at us.

No items found.
No items found.
Rob Rehrig
Hardware hacker by day, design deliriant by night—Rob Rehrig is an electrical engineer at IDEO with a passion for human-computer interaction, music, and rapid prototyping.
Derek Olson
Ideo Alum
Derek is a software designer at IDEO. With a background in art, music, and electronics, he lives for design challenges that straddle the line between technology and creativity.
Raina Wellman
Raina is a communication design intern at IDEO's Chicago studio. When creative thinking and diverse fields of study come together, she believes we have the power to make a lasting positive impact.
No items found.