Took me way too long to finally getting around to publishing this post, but here it is.
Last fall, FireEye announced their 3rd annual Flare-On challenge. It's sort of a recruiting thing for them, I think -- if you solve all the challenges (and especially if you solve them quickly), sounds like you might get an interview/job offer -- after all, "The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team".1
Shortly after the contest was over, FireEye published solutions for all the challenges. As you can see, the solution for Challenge 1 is not particularly complex, at least so far as CTF challenges go... but, it does require you, the reverse-engineer, to actually understand what the
challenge1.exe2 program is actually doing.
At the time, I was particularly interested in Angr, a symbolic execution and binary analysis framework. Having spent a lot of time reversing binaries and manually figuring out how to get from program entry points to interesting places in the program, the idea that you can tell Angr "figure out the conditions that get me from here to there" seems both intriguing and appealing.3 If you open
challenge1.exe in IDA, you'll see that it's a great candidate for Angr -- a short
main() function, with two possible outcomes ("Correct!", or "Wrong password"). So let's just tell Angr to get us executing down the "Correct" path, right? And then print out the relevant condition/s that got us there!4
Here's the reasonably-heavily commented solution:
It takes about 15 minutes to solve on an i7-6700HQ. If you have any suggestions for efficiency improvements, I'm all ears.
I did use Angr in a Sandstorm iPython/Jupyter notebook to help prototype the solution, which was pretty nice. I haven't updated that Sandstorm package since that post... I should do that. >_>
Something to keep in mind as this fall rolls around, if you're looking for a job. ↩
You can download all the challenge binaries here: http://flare-on.com/files/Flare-On3_Challenges.zip ↩
Of course there is a great deal of value in spending time doing this manually -- you'll learn a lot about how programs and computers work! But after a while, you will probably start to wonder if any parts of that problem solving process can be automated/abstracted... ↩
Sounds maybe sorta easy, right? But really, at least in this case, we're just choosing to invest brain cycles in understanding how Angr works, instead of the similar amount of brain cycles it would take to understand the program's actual password encoding algorithm... but I think this is a worthwhile investment. :) ↩