Solving the 2015 FLARE On RE Contest - Challenge #1

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).

Challenge #1
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.

Pretty standard stuff here, no notable cryptography or networking related libraries. This binary appears setup to take some input and that's about all.

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.

At this point I elected to fire up IDA and take a peek at the disassembled routines. Before analyzing the main function though, lets review the raw hex and look for some of the strings that we observed during interactive program execution.

My first observation here is that after the 'You are failure' string we see  24 characters that appear mutated and are followed by some null values. Let's keep this in mind and take a peak at the application entry point.

Our application is initialized and GetStdHandle is called. This function retrieves a handle to the specified standard device (standard input, standard output, standard error). User input is taken and written to the memory offset for variable 'byte_402158'. Now we enter the core logic of the application.

The first routine takes the first low order byte (x86 is little-endian and the AL register is 8 bits) from the ECX register and moves it into AL. A 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.