In July, the FireEye Labs Advanced Reverse Engineering (FLARE) team created and released the first FLARE On Challenge to the community. A total of 7,140 people participated and showed off their skills, and 226 people completed the challenge. Everyone who finished the challenge received a challenge coin to commemorate their success.

The coveted challenge coin

We are releasing the challenge solutions to help those who didn’t finish improve their skills. There are many different ways to complete each challenge, so we waited to see what solutions people devised. We found the following solutions posted online and recommend taking a look at these as well to see how the later challenges can be solved in different ways.

http://parsiya.net/blog/2014-10-07-my-adventure-with-fireeye-flare-challenge/

http://www.ghettoforensics.com/2014/09/a-walkthrough-for-flare-re-challenges.html

In this initial issue of the blog series, we focus on the first five challenges, which were easier. We hope that by starting with easier solutions, people who have never reversed before can still benefit. Below is a write up of how to solve the first five challenges, written as if we’d never seen them before. The goal of each challenge is to find a key in the form of an email address that allows you unlock the next challenge. The archive of challenges have been posted to the challenge website.

Stay tuned for Part 2 where we show two different and interesting ways of solving Challenge 6.

Challenge 1: Bob Doge

The first challenge starts out pretty easy. When we drop the binary into CFF Explorer (or equivalent PE tool), it informs us that we’re dealing with a PE 32-bit .NET Assembly, so we can run it in an x86 Windows VM and see what happens. A decode button appears to have two functions: transforming Bob Ross into Bob Doge, and converting the top label into some unprintable strings. We drop the binary into ILSpy (or equivalent .NET decompiler) to get an idea what this decode button is doing. The decompiled code is shown in the top of Figure 1.

Figure 1: Decode button code in ILSpy (top) and re-implemented in Python (bottom)

The button changes the image to Bob Doge, and encodes a resource string twice and sets the label text to the result. If we save out the resource that is being manipulated, we can play around with it. The Python code in the right side of Figure 1 is the decode button re-implement to help us figure out what we are dealing with. When this Python code is run, the following is printed out showing the solution to Challenge 1 as “Text 1” in the output.

Figure 2: Challenge 1 result

Challenge 2: Javascrap

The next challenge (to the bane of some of our players) is not a Windows PE file. Instead we have a version of the website www.flare-on.com. There has to be something special about this version of the website. So we look at page source of home.html. If we compare this version with the live challenge website, one line in particular stands out:

<?php include "img/flare-on.png" ?>

Why would a PNG image be loaded as a PHP script? When we open this image with an image viewer, the banner comes up so it is definitely an image. Since we know that the image is being loaded as a PHP script, we search for php inside of the image file and find the following:

19C0 AE 42 60 82 3C 3F 70 68 70 20 24 74 65 72 6D 73 .B`.<?php $terms

 19D0 3D 61 72 72 61 79 28 22 4D 22 2C 20 22 5A 22 2C =array("M", "Z",

 19E0 20 22 5D 22 2C 20 22 70 22 2C 20 22 5C 5C 22 2C "]", "p", "\\",

 19F0 20 22 77 22 2C 20 22 66 22 2C 20 22 31 22 2C 20 "w", "f", "1",

 1A00 22 76 22 2C 20 22 3C 22 2C 20 22 61 22 2C 20 22 "v", "<", "a", "

 1A10 51 22 2C 20 22 7A 22 2C 20 22 20 22 2C 20 22 73 Q", "z", " ", "s

...

Pulling this out of the image leaves us with:

<?php

 $terms=array("M", "Z", "]", "p", "\\", "w", "f", "1", "v",...

 $order=array(59, 71, 73, 13, 35, 10, 20, 81, 76, 10, 28, 63, 12,...

 $do_me="";

 for($i=0;$i<count($order);$i++)

 {

 $do_me=$do_me.$terms[$order[$i]];

}

 eval($do_me);

 ?>

So we have an array of characters, and then an array of indexes into the array of characters being used to build a string that gets evaluated. If we replace that eval with a call to echo, we can see the following strings in the display:

$_= 'aWYoaXNzZXQoJF9QT1NUWyJcOTdcNDlcNDlcNjhceDRGXDg0XDExNlx4Njh...

$__='JGNvZGU9YmFzZTY0X2RlY29kZSgkXyk7ZXZhbCgkY29kZSk7';

$___="\x62\141\x73\145\x36\64\x5f\144\x65\143\x6f\144\x65";

eval($___($__));

This reveals more obfuscation! Applying the same trick again results in the following lines of code:

$code=base64_decode($_);

eval($code);

So from this, we decide we should base64 decode the $_ string and, lo and behold, we have our key.

If(isset($_POST[\97\49\49\68\x4F\84\116\x68\97\x74\x74\x44\x4F\x54...

 {

 eval(base64_decode($_POST[“\97\49\x31\68\x4F\x54\116\104\x61\116...

 }

This is a string that is made out of mixing hexadecimal and ordinals. By writing a quick decoder for this conversion we get a11DOTthatDOTjava5crapATflareDASHonDOTcom. We then replace “DOT”, “AT”, and “DASH” with the corresponding character and get the key: a11.that.java5crap@flare-on.com.

Challenge 3: Shellolololol

Challenge 3 is an x86 PE file. We drop the binary into IDA Pro to see what it shows us:

push   eax

 call   __getmainargs

 add     esp, 14h

 mov     eax, [ebp+var_24]

 push   eax

 mov     eax, [ebp+var_20]

 push   eax

 mov     eax, [ebp+var_1C]

 push   eax

 call   sub_401000

 add     esp, 0Ch

 mov     [ebp+Code], eax

 mov     eax, [ebp+Code]

 push   eax

 call   exit

The function sub_401000 looks interesting to us since all of the other functions called before it have symbols associated with them, and 0×401000 is the beginning of the code section, commonly where the beginning of any user-written code exists.

push   ebp

 mov     ebp, esp

 sub     esp, 204h

 nop

 mov     eax, 0E8h

 mov     [ebp+var_201], al

 mov     eax, 0

 mov     [ebp+var_200], al

 mov     eax, 0

 mov     [ebp+var_1FF], al

 mov     eax, 0

 mov     [ebp+var_1FE], al

 mov     eax, 0

 mov     [ebp+var_1FD], al

 mov     eax, 8Bh

After just a cursory look, we see single bytes being moved onto the stack one at a time. After we get past all of the bytes being moved onto the stack, we see the following:

lea     eax, [ebp+var_201]

 call   eax

 mov     eax, 0

 jmp   $+5

The binary is calling the location of the first byte it moved onto the stack, so we’ll need to deal with a buffer of shellcode. At this point static analysis is much more work than dynamic, so we drop this into a debugger.

We set a breakpoint at the call eax above and let the code run to catch the program before it calls into the shellcode. Now we can dump the stack memory to a file and analyze it in IDA Pro as shown in Figure 3. All of the following analysis could be done in the debugger, but we decided to show the steps in IDA Pro.

Figure 3: 0×66 decoding loop

Figure 3 shows a loop decoding everything after the jmp instruction by XORing each byte with 0×66. We decided to write a script to do the decoding for us rather than running it and dumping it in the debugger again.

import idaapi

 loc = 0x1DA0

 for i in range(0x1DF):

 idaapi.patch_byte(loc+i, idaapi.get_byte(loc+i) ^ 0x66)

When we run this script we get the following decoded string:

00001DA0 aAndSoItBegins db 'and so it begins',0

Additional code that has also been decoded, showing another decoding loop:

00001DB0                 push   'su'

 00001DB5                 push   'ruas'

 00001DBA                 push   'apon'

 00001DBF                 mov     ebx, esp

00001DC1                 call   $+5

 00001DC6                mov     esi, [esp]

 00001DC9                add     esi, 2Dh ; '-'

 00001DCC                mov     ecx, esi

 00001DCE                add     ecx, 18Ch

 00001DD4                mov     eax, ebx

 00001DD6                add     eax, 0Ah

 00001DD9

 00001DD9 loc_1DD9:

 00001DD9                cmp     eax, ebx

 00001DDB                jnz     short loc_1DE2

 00001DDD                mov     ebx, esp

 00001DDF                add     ebx, 4

 00001DE2

 00001DE2 loc_1DE2:

 00001DE2                cmp     esi, ecx

 00001DE4                jz     short loc_1DEE

 00001DE6                mov     dl, [ebx]

 00001DE8                xor     [esi], dl

 00001DEA                 inc     ebx

 00001DEB                 inc     esi

 00001DEC                 jmp     short loc_1DD9

This time the encoding is a multi-byte XOR, so we write another script:

import idaapi

 loc = 0x1DF3

 key = “nopasaurus”

 for i in range(0x18C):

 idaapi.patch_byte(loc+i,idaapi.get_byte(loc+i)^ord(key[i%len(key)]))

Scripts like this are often needed when reversing malware to decode strings used by the program. After this script executes it seems we’ve gotten further because we have another string that has been decoded:

00001DF3 aGetReadyToGetN db 'get ready to get nop',27h,'ed so damn    hard in the paint

And following this we now have more code as shown in Figure 4.

Figure 4: GlOb decoding loop

What a surprise: another deccoding loop. By now, we’ve gotten pretty decent at writing these scripts, so here’s another one:

import idaapi

 loc = 0x1E47

 key = “bOlG”

 for i in range(0x138):

 idaapi.patch_byte(loc+i,idaapi.get_byte(loc+i)^ord(key[i%len(key)]))

After this one executes we have more code to look at. This is the last decoding step using the key of “omg is it almost over?!?” This time the script looks like:

import idaapi

 loc = 0x1EA9

 key = “omg is it almost over?!?”

 for i in range(0xD6):

 idaapi.patch_byte(loc+i,idaapi.get_byte(loc+i)^ord(key[i%len(key)]))

And we have our next key.

00001EA9 aSuch_5h3110101 db 'such.5h311010101@flare-on.com

We could have come to the same conclusion by stepping through the whole binary in a debugger. But we wanted to have a bit of fun in IDA Pro scripting!

Challenge 4: Sploitastic

Challenge 4 requires that we examine a PDF. Let’s see what happens when we open this in an unpatched version of Adobe Reader that is highly exploitable, like 9.0 as shown in Figure 5.

Figure 5: Malicious PDF

It looks like the malicious PDF popped open a message box, so we set a breakpoint on MessageBoxA and MessageBoxW. Figure 6 shows the arguments on the stack when this breakpoint hits.

Figure 6: MessageBoxA arguments

From the strings that are on the stack, we know that we are in the correct call to MessageBoxA. So if we trace back to the address that made this call, we find the following shellcode block:

00000000 E8 00 00 00 00 8B 14 24 81 72 0B 16 A3 FB 32 68 .......$.r....2h

 00000010 79 CE BE 32 81 72 17 AE 45 CF 48 68 C1 2B E1 2B y..2.r..E.Hh.+.+

 00000020 81 72 23 10 36 9F D2 68 71 44 FA FF 81 72 2F F7 .r#.6..hqD...r/.

 00000030 A9 A9 0C 68 84 E9 CF 60 81 72 3B BE 93 A9 43 68 ...h...`.r;...Ch

 00000040 D2 A3 98 37 81 72 47 82 8A 62 3B 68 EF A4 11 4B ...7.rG..b;h...K

 00000050 81 72 53 D6 47 C0 CC 68 BE 69 A4 FF 81 72 5F A3 .rS.G..h.i...r_.

 00000060 CA 54 31 68 D4 AB 65 52 8B CC 57 53 51 57 8B F1 .T1h..eR..WSQW..

 00000070 89 F7 83 C7 1E 39 FE 7D 0B 81 36 42 45 45 46 83 .....9.}..6BEEF.

 00000080 C6 04 EB F1 FF D0 68 65 73 73 01 8B DF 88 5C 24 ......hess....\$

 00000090 03 68 50 72 6F 63 68 45 78 69 74 54 FF 74 24 40 .hProchExitT.t$@

Examining this in IDA shows the following:

00000359         call   $+5

 0000035E         mov     edx, [esp]

 00000361         xor     dword ptr [edx+0Bh], 32FBA316h

 00000368        push   32BECE79h

 0000036D         xor     dword ptr [edx+17h], 48CF45AEh

 00000374         push   2BE12BC1h

 00000379         xor     dword ptr [edx+23h], 0D29F3610h

 00000380         push   0FFFA4471h

 00000385         xor     dword ptr [edx+2Fh], 0CA9A9F7h

 0000038C         push   60CFE984h

 00000391         xor     dword ptr [edx+3Bh], 43A993BEh

 00000398         push   3798A3D2h

 0000039D         xor     dword ptr [edx+47h], 3B628A82h

 000003A4         push   4B11A4EFh

 000003A9         xor     dword ptr [edx+53h], 0CCC047D6h

 000003B0         push   0FFA469BEh

 000003B5         xor     dword ptr [edx+5Fh], 3154CAA3h

 000003BC         push   5265ABD4h

 000003C1         mov     ecx, esp

 000003C3         push   edi

 000003C4         push   ebx

 000003C5        push   ecx

 000003C6         push   edi

So it looks like we have strings that are being encoded on the stack in some way. Since our breakpoint hit after this code has already run, we can go back and force the debugger to execute this code again to see what is revealed on the stack.

Figure 7: Breakpoint to reveal the key

And there it is in Figure 7 as referenced by ESP. So we’ve found the next key.

Challenge 5: 5get_it

Challenge 5 is a Windows PE DLL, so we drop it into IDA Pro and started jumping around the functions to see if anything interesting pops out. After bouncing around a bit, we stumble upon this huge function starting at 0×10001240. This function takes no arguments and appears to build a giant stack string. Since it takes no arguments, we tried setting eip to the entry of the function in a debugger and running it, which reveals the image shown in Figure 8.

Figure 8: Challenge 5 message box

Interesting, but it doesn’t seem to contain the key. Checking the cross references to this function leads us to the function shown in Figure 9.

Figure 9: Subroutine that calls the message box function

That doesn’t tell us much by itself. We see this function checks a global variable to determine whether to open a MessageBox, and then the letter “m” is returned. Cross references to this function show a function whose graph is shown in Figure 10.

Figure 10: “if” statement control function

This function is huge and contains some sort of if/else statement. At the top of it we see the following bit of code.

10009ECD         movsx   edx, [ebp+var_4]

 10009ED1         cmp     edx, 0DEh

 10009ED7         jg     loc_1000A3A4

 10009EDD       movsx   eax, [ebp+var_4]

 10009EE1         push   eax

 10009EE2         call   ds:GetAsyncKeyState

 10009EE8         movsx   ecx, ax

 10009EEB         cmp     ecx, 0FFFF8001h

 10009EF1         jnz     loc_1000A39F

An if/else statement based on GetAsyncKeyState sounds like we are dealing with a keylogger. It appears that pressing the “m” key causes a specific global variable to be set, which later causes the program to pop up a message box. So what is this global variable, dword_100194FC, and what sets it? Cross references to this are shown in Figure 11.

Figure 11: Cross references to dword_100184FC

The global variable is initialized to zero, and then some other function sets it to one. The function that sets it is sub_10009B60 and is shown in Figure 12.

Figure 12: “o” keystroke function

This appears to be the function that handles the keystrokes for the “o” key. The last condition checks if dword_100194F8 is set, and if so then set dword_100194FC to 1. Those global variables are in sequence, so from here we play on a hunch and look at the memory addresses of the global variables and start naming them as follows:

As we start doing this, a pattern starts to emerge:

We notice that the pattern “dotcom” emerge so we can do this for the rest of the global variables (which are a series of global variables controlling a state machine based on key strokes) and we get the final key: l0gging.Ur.5tr0ke5@flare-on.com.