After my last post on disassembling control flow structures, a colleague of mine mentioned that I should participate in the 2016 FLARE On challenge next year. Due to work and life obligations I have not had the opportunity to partake in the previous 2 contests but I figured now would be a good time to get some practice in and prepare for 2016. I am by no means an expert and this is very much a learning exercise for me, one that I intend to document and share. I'll be doing a series of posts (when I find time) over the next few months documenting my progress.
The FLARE On contest is an annual capture-the-flag style reverse engineering competition from FireEye. If you'd like to follow along you can download the materials here. Each challenge involves assessing a sample with the sole intent of finding a key (an e-mail address).
The first file is a self-extracting zip and will dump an executable into a specified directory with the name "i_am_happy_you_are_to_playing_the_flareon_challenge.exe". It's a long and oddly named file. I'll assume the intentional grammatical deficiencies are for comedic purposes and don't have any greater significance, for now :)
Before executing this file lets check out the import table to get an idea of what it does. It's only 2KB in size so it is clearly a small application with very limited functionality.
When we run the file this hypothesis is confirmed. The application prints two strings, prompts the user for input, checks if it is the correct value, and then prints a string depending on whether the user input the secret key. I tried entering a variety of answers that included special characters and lengthy input but could not generate an alternate error message.
bit-wise XOR operation is then performed against the AL register and the hex value '7D'. The result is then compared to a value stored at the memory offset of variable 'byte_402140'. If the values do not match then we get the error message. However, if the value does match then ECX is incremented and the XOR comparison occurs again. It iterates through this loop 0x18 times. In decimal this is 24 loops, which interestingly is the length of the mutated character we noted earlier. The memory offset referenced by variable 'byte_402140' is the location of this suspicious string as well.
At this point there is enough evidence indicating that the mutated characters are in fact the secret key. I thought about writing a program to XOR each byte at that offset by 0x7D but got lazy and used the Python interpreter.
Once you have computed each value, assemble the string and convert the hexadecimal values to ASCII.
Well that certainly looks like an email address. Sure enough, when we enter this as our key value it is successful.
Ta-da! This first challenge was fairly straightforward and didn't take long at all but I assume the difficulty level will ramp up quite quickly.