FLARE-ON Challenge – Part 1


This summer (2014) I had a go at FireEye’s FLARE-ON challenge. The challenge was a series of stages that you had to reverse engineer in order to get the answer to the next level. I found out about this from the IRC crowds, and they helpful enough to tell me what to look for and how the competition is structured – you’re looking for an email address. This is part one of the challenge, with (probably) the rest of write-ups to follow.

The Challenge

So, first things first. As you might have noticed already, file is one of my first go-to utilities and, with this in mind, behold:

flare-on/challenge_01 $ file Challenge1.exe
Challenge1.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

Oh dear. I have very little idea about .Net (or any M$ technologies for the matter), so this will be interesting. Strings?

This undated image released by Copyright Bob Ross Inc./The Joy of Painting, shows the late Bob Ross, host of the PBS series "The Joy of Painting." PBS said Thursday it's posted a video remix with clips from "The Joy of Painting" instructional series, featuring the late Bob Ross.

These look kind of interesting. Apparently .Net apps use resources, and these resources provide “data” (read serialized objects, images, strings, etc.) for the application to assist with localisation or other similar tasks (think Android resources), a pretty handy feature. The application seems to consist of a module that uses a combination of .Net Forms, images and buttons, but they are all obscurely named – XXXXXXXXXX. In this case our resource is probably an JPEG image (subtle hints : PictureBox, JFIF, Bitmap). At this point I am expecting a window with a button and an image, perhaps some text.

There is also a reference to the man – Bob Ross. Anyone else remember this guy? I used to watch him over lunch after school! I loved his paintings! He also provided the crowds with useful life philosophy:

Figure 1: Bob Ross being Bob Ross.
Figure 1: Bob Ross being Bob Ross.

Well said Bob, well said. Let’s move on to stage two of our analysis.

Analysis, Part Two

Given that it’s a .Net binary, we could attempt to decompile it (NB: decompile vs. disassemble, we are aiming high here) using ILSpy. This is a very handy utility that tries to reverse .Net binaries back to source code. But first, let’s run our binary, the solution might be simpler.

Figure 2: Main window of the application when we run the Challenge1.exe executable.
Figure 2: Main window of the application when we run the Challenge1.exe executable.

Spot-on on the prediction front. For those of you that didn’t get the reference, the patronising label over Bob was a phrase he used a lot. Easy? There’s a button that reads “DECODE!”. This seems a little too easy but we shall try it, after all this might be the idiot-test.

Figure 3: The button should read TROLL! rather than decode.
Figure 3: The button should read TROLL! rather than decode.

Two out of two on the prediction front so far, but still no e-mail. We’ve waited long enough, let’s decompile the application! The first thing we’ll see is a collection of everything that’s in the binary:

Figure 4: The main components of the application, as displayed by ILSpy.
Figure 4: The main components of the application, as displayed by ILSpy.


Remember .Net Resources? There’s a couple of interesting entities under declared as Resources in this binary; there’s an entity called dat_secret and another one called rev_challenge1.dat_secret.encode and then, under the XXXXXXXXXXXXX.Properties branch there’s a byte array that is called dat_secret. Let’s chase up on these. In order to see how these resources were being used, I started at the main and tried to see what code gets invoked. The main method doesn’t look too interesting, it just creates a Form object:

Figure 5: The application's main method.
Figure 5: The application’s main method.

An interesting sample of the Form object’s constructor is shown in Figure 6:

Figure 6: The Form1 class's constructor, partial display.
Figure 6: The Form1 class’s constructor, partial display.

The (partial) code shown of the constructor for Form1 does your standard thing and builds the GUI. Pay particular attention to the last line, which adds a click listener to the “DECODE!” button, and that listener is the function btnDecode_Click . The click listener’s code is very interesting, shown in Figure 7:

Figure 7: Click-listener code for the "DECODE!" button.
Figure 7: Click-listener code for the “DECODE!” button.

This is more like it! We’re on our way to get that address. In btnDecode_Click we can see three loops that do your typical string obfuscation in order to hide or otherwise transform strings through bitwise operations. In order to reveal our strings we could take a number of different approaches; one approach would be to understand what the code does and somehow reverse it. On the other hand, we could just copy-paste the code into a new file, feed it the obfuscated text and see if an email address comes out; let’s copy paste the code from Figure 7 into a C file, with some slight modifications (the handling of Strings for example in C#, C has no Strings):

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]){
    FILE *pFile= fopen(argv[1],"rb");
    int size = 31 ; // could get it from ftell
    unsigned char *dat_secret = malloc(sizeof(char)*size);
    unsigned char *text = malloc(sizeof(unsigned char)*size);
    for (int i = 0; i < size; i++){
        unsigned char b = dat_secret[i];
        text[i] = (b >> 4 | (b << 4 & 240)) ^ 41;
    unsigned char *text2 = malloc(sizeof(unsigned char)*size);
    for (int j = 0; j < size; j += 2){
        text2 [j]= text[j+1];
        text2 [j+1]= text[j];
    printf("%s\n", text2);
    unsigned char *text3 = malloc(sizeof(unsigned char)*size);
    for (int k = 0; k < size; k++){
        unsigned char arg_B6_0 = text2[k];
        text3 [k]= (unsigned char)(text2[k] ^ 102);
    printf("%s\n", text3);
    return 0 ;

And the result of this is:

flare-on/challenge_01 $ gcc --std=c99 -o decrypt.o decrypt.c
flare-on/challenge_01 $ ./decrypt.o sec.enc
   <nonsense - mainly what we see on the main window when we click the decode button>


Can everyone hear a sweet cha-ching sound? 3rmahg3rd.b0b.d0ge@flare-on.com looks like a valid email address, so let’s go ahead and talk to them! After sending an empty email (and waiting half an hour), I got the following response back:

 Well done! Looks like you kicked that one. I’ve attached the next challenge for your reversing pleasure. The password to this zip archive is “malware”.
We saw what looked like attacker activity to this site, can you figure out what the attackers changed?
Hopefully you’ll knock this one out too, Good luck!

Part 1 – The End

This is the end of part one! Although an easy one, this was a good warm-up. Stay tuned for Part 2 🙂


FLARE-ON Challenge – Part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s