How to Choose Projects That Advance Your Skills - From Endless Struggles to Endless Bugs

Introduction

There’s no shortage of new and exciting in our field. A Windows 0-day drops. A macOS fuzzer got open-sourced. Cutting-edge Chrome exploitation technique just got revealed. It’s like being a kid in a candy store—everything is vibrant, new, and tempting. I don’t know about you, but after reading something like this I immediately feel a rush to go and find new vulnerabilities in Windows, use the fuzzer, and learn the exploitation technique.

The problem is that I know nothing about Windows kernel, macOS and Chrome. That doesn’t look like a good background for Windows/macOS/Chrome 0-day project. Well, I know that now.

Feeling inspired is a fantastic start; it fuels real-world accomplishments. However, passion alone doesn’t guarantee results. It's easy to get lured into biting off more than we can chew. In fact, I started new projects only to fail countless times, just enough to almost stop trying. In this post, let’s explore how and why we fail when we get too ambitious for our own good and what we can do about that.

Struggles

My early career path was far from straightforward. More like a path I took home at 4 AM after partying all night. I devoured countless articles on reverse engineering, each filled with new tools and techniques. It seemed like authors effortlessly identified and exploited vulnerabilities, so I was thinking why can’t I do the same. One day, I felt ready to go from thoughts to action.

The article that gave me the final push was a post in /dev/ttys0 blog. The guy had a thing for D-Link and pwned it several times in a row. Since I had a similar model at home, I figured I’d follow his footsteps and snag my own 0-day.

Following the guide, I downloaded and unpacked my router’s firmware using Binwalk, revealing a full file system filled with binaries. I got a full file system with a lot of binaries. Next, found the CGI binary I needed to analyze and emulated it with Qemu. So far, so good. And then I loaded it into IDA. The architecture was MIPS, which I knew nothing about.

The only thing that I could recognize was function calls (they were marked by a different color). While the blog described the vulnerability in detail (unsanitized user input finally arriving in system()), I had no idea where to do from here. I also was able to see some structure in the assembly code, I was able to roughly understand which queries the binary handled, judging by the strings. Needless to say that I was pretty far from knowing what I was doing and was nowhere near the level of skill required to understand the code and look for bugs. Predictably, the project ended in failure.

Some time later I took a couple of reverse engineering lessons, I felt pumped up and ready to try again, but this time with different piece of software. But guess what? The same old story played out. It took a couple of another failed tries for me to even stop trying at all. It just felt like I wasn’t cut out for it and it just wasn’t meant to be.

Turnaround

Then, things took a turn when I found myself in an environment of seasoned reverse engineers. They were on a different level; I didn’t even have enough vocabulary to talk to them. Nevertheless, it got me inspired to give reverse engineering a try again.

This time around, I kept my ambitions in check. Instead of doing anything crazy like going for 0-days and except immediate result, I started with what I should have been doing: solving the simplest RE challenges I could find. I solved those until I got completely bored with them—a sign that I should move on. Right around then, a local antivirus company started a RE challenge, so I decided to participate.

That was something completely new to me as the challenges were all about Windows GUI crackmes, and I had zero experience in reverse engineering them. On the other hand, I had additional motivation since a lot of folks from my job were also competing and I didn’t want to land face-first in the mud.

In the first challenge, I used hardware breakpoints to track my inputs, which helped me find the WinAPI function the GUI form used to get text from user. Figuring this out was my first real win. This challenge made just a series of simple checks against user input, easy enough.

They ramped up the things with the second challenge. It interpreted inputs as hex characters, which were then processed through a system of 20 or 30 linear equations. I had to rewrite them from assembly to Python to put them into Z solver — a popular thing in CTFs those days.

The third and the final challenge remains unsolved for me still.

But competing alongside veterans who had years of experience under their belts, I realized two things. First, it was extremely rewarding to finally play on the same field with them. The second, I understood just how much I was lagging behind—they were days ahead of me, solving challenges as easy as I was breathing. Still, it was cool to get a bit closer to speaking the same language with them and to see how their approach was different from mine. I finally felt like I had grown.

Finding My Niche

Another thing was happening at the same time. Long story short, there was a lack of pentesting tasks and plenty of RE tasks. Having always dreamt of RE, I decided to give it a shot. On the next project, I made sure to first complete my usual pentesting tasks and then picked up with the smallest possible RE task. In fact, it was so insignificant that nobody would notice if it wasn’t done—an opposite of a project-critical task. In other words, a perfect starting task for someone in my position.

The task was to find out how the software we were auditing stored passwords. The software was a Windows GUI application — the type of software I had just gotten plenty (by my standards at the time) of experience with.

Using hardware breakpoints—my usual technique at the time—I found the place in the code responsible for checking passwords. And with a little help from my more experienced colleague, I managed debug and reverse engineer the encryption algorithm. A huge win for me at the time. It didn’t even make it into the final report — that’s how insignificant this was for us at the time. But at least the ice was broken. I knew it, and my team knew it.

I continued this chain of small tasks. On the next project, I chose the worst and most outdated, off-the-market controller to reverse. Eventually, I teamed up on a serious task with an experienced colleague. We could make a whole lot on that project, and I’m proud to say that I helped him as much as he helped me. We found over 10 bugs, including a memory overwrite leading to RCE. Hell, we even came up with a way to exploit it and make the controller blink. All without any debugging, pure static analysis.

After nailing that project, I had enough confidence in myself, and my boss — in me, so I could take on any crucial task on my own.

Final Reflections

Picking the right tasks, ones that match what you're into and what you're good at, is one of the most important skills we can have. Don't expect to stumble upon a zero-day vulnerability right off the bat. It’s also important to distinguish your interest, enthusiasm, and motivation from overconfidence. There’s a fine line.

Let’s compare two perspectives:

1. Imagine someone excited by the latest vulnerability in macOS. They immediately want to do the same and fuzz macOS kernel extensions (aka drivers) to find a 0day. The plan is to just use the blogpost they read as a guideline and to apply it to a different kext.
2. Another person is also excited. This person might start by diving into the macOS internals, learning from previous research, understanding attack surface, analyzing targeted kexts and reviewing existing fuzzers to select the best option.

Clearly, the second person is more likely to succeed. They understand the task’s complexity, the challenges that come with it and what’s needed to be done for a successful research project. What is crucial is that they understand what they know and what they don’t.

While enthusiasm is a great start, it needs to be paired with realistic goals. From what I’ve seen, the best task is the one you know how to solve 70% of. It's challenging enough to strike the balance between confidence and the excitement of the unknown. 90% is probably time to automate some of that stuff or move on. 50% zone is a gamble — you might pull it off, or you might crash and burn. And lower than that is closer to learning basics of the topic than a full fledged project. Choosing such task as a project has a low chance of success.

And I’m not saying that failing is the end of the world, but failing without learning anything is. For me, a lot of times it was like playing a videogame without saves: you die - you have to repeat it from the start. As a result, I got somewhat good in the early stage, but still had no idea what to do next.

And let’s go back to our example above. Let's say the first person fails the task. They might just shrug it off, because there’s just no plan to begin with, not enough data and knowledge to understand what went wrong. But the second person? They might look back, figure out what was off, e.g. the chosen kext wasn’t good for fuzzing or there wasn’t enough knowledge base to successfully implement a certain part of the plan. So they can work on their strategy, on their knowledge and adjust for next time.

So, while I’m all for keeping that optimism high, just suggesting to channel it wisely. Make sure it’s guiding you towards challenges that are just right—not too easy, not impossible, but just right to push your boundaries and grow your skills.

This were some stories from my side. If you also have a story about overcoming challenges in your career, I’d love to read it!