This year it was once again time for the most highly anticipated reverse engineering event of the year (for me anyway!), Flare-On!
For those who don’t know, Flare-On is an annual jeopardy style reverse engineering event organized by FireEye. The event runs for 6 weeks and comprises of around 8-12 binary challenges that reflect the actual real world challenges the fireeye teams face on a day to day basis. This year we got 11 challenges ranging from a simple python crackme to a fully fledged piece of malware based on gozi.
As I’ve attempted to complete Flare-On the previous 2 years, and failing, I knew the immense difficulty of the road ahead. Starting out fresh on day 1 I finished the first 3 challenges, after which I kept completing about 1 or 2 challenges a day for the coming week up until
crackstaller (challenge 9). This is where I felt like the more experienced reverse engineers were going to be seperated from the beginners and is also around the point where I had to give up during the previous 2 editions. However, this year I cruised through the challenge with relative ease. The challenge involved a driver component and a lot of COM (blergh :( ) functionality, requiring you to bring together analysing and interacting with com objects from c as well as understanding driver callbacks to create the final solution. While this took 2 days, it was still relatively easy compared with what was ahead.
NOTE: working full-time as a reverse engineer while attempting to finish a grueling reverse engineering ctf is not a good idea.. But I digress.
Having arrived at challenge 10 after about a week and a half of working on challenges after work and completely disregarding my wife, I felt the need to take a break slowly creeping in. Knowing the time was limited and being absolutely set on finishing this year I decided to start on the 10th challenge anyway. The 10th challenge’s name was
break which was meant to be a hint for what the challenge was about, but at the same time it was also a very good indicator for what would happen to your mental state after working on the challenge. This challenge was so daunting it almost broke me to the point of abandoning flare-on entirely! (How did the first place finisher finish this in just a few hours?! hax!)
The challenge was a linux binary that obfuscated its functionality by debugging itself while at the same time also debugging itself, I know right.. Putting triggers on debug events while also debugging another process, the entire thing was made to jump to seemingly completely random places after each little event. Abusing forced null dereferences and implicit syscalls to trigger debug events and resolving text that would then be used inside of another debug event inside of the debugged process of the child of the current process before returning back to the parent process. Stuff like that, fun stuff..
For the challenge I used a tool to catch which debug events were triggered during execution to analyse the expected control flow. Thinking this was the entire scope of the challenge and setting expectations on when this would be over was the thing that almost made me quit. This turned out to be only the very first step in what ended up being a challenge that severely overstayed its welcome by, again and again, popping up with more pieces to the final puzzle. Each of these pieces requiring very intricate knowledge of an entire spectrum of linux or low level tech. Eventually clearing the challenge after continuously banging my head against it in the hours after work for a week, I was elated and exhausted. The
break challenge did end up forcing me to take a break. Kind of ironic if you think about it…
After a little more than 3 of the 6 weeks having passed and having taking a break for 1 of them, I got back at it with renewed motivation. Once agiain severely underestimating the challenge ahead. The final challenge, called
rabbithole, took the full remaining time to finish (having work during the week and not being robot enough to be able to devote every single remaining minute to it). The challenge was a forked and edited version of a leaked version of Gozi. The original was available on github, but it was hardly of any use as relating logic from the binary to the source code was hardly ever useful or possible. The process did many things such as injecting itself into other processes, spawning 4 other processes of itself, hiding in the registry, etc. You also weren’t given a binary to start, but an NTUSER.dat registry hive that was supposedly recovered from an infected pc. Most of its state and logic was taken from a multitude of encrypted registry entries that were generated and edited throughout the process’ logic.
What really made the challenge difficult was the fact that the goal wasn’t very clear. Somehow the process was going to extract a file from the pc which contained the flag, however this file was actually contained in the registry with no indication that it was in fact the flag file. So Having used 1 week to really understand the malware and knowing where and how the communications took place, it took another 2 to actually find the 1 correct file in the correct execution flow to decrypt. Finding the correct file on the 2nd to last day caused a huge sigh of relief followed by excitement. Being able to insert the last flag into the system and being greeted by a form that requests the details to where to send the prize to was amazing.
After waiting for 2 months, the tangible evidence of what I think is my biggest achievement yet arrived in the mail:
This challenge did not only teach me a lot of new techniques, tools and functionalities, it also greatly increased the amount of setbacks I can handle working under time pressure and handling the stress of doing this next to a full-time job and heading a family.
The fact that the final report about this year’s challenge by fireeye stated that this was the hardest one thus far, makes the victory feel that much greater :)