PAN LabyREnth CTF – Windows #6

Sample: 3968259859f056853fc7efd2b858b3fcf0d7147a9c7f40049e5c2e131718a1d7 (PW: infected)

file Ambrosius.exe
Ambrosius.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

In this challenge, you have to find the correct key to encrypt the flag. The flag is encrypted with RC4 and can be found in an encrypted form within the binary. Unfortunately I did not take many screenshots and I also destroyed my annotated version in IDA but I think my python code will most probably tell you everything you need.

The key is structured as follows:


The first four bytes are constant: “b00!”.
The 5th byte is the month returned by GetLocalTime + 0x2d.
The 6th byte is the day returned by GetLocalTime + 0x5e.
The 7th byte is the minute returned by GetLocalTime + 0x42.
The 8th byte is the major version return by GetVersion + 0x3f.
The 9th byte the minor version returned by GetVersion + 0x3f
The 10th byte is the status byte in the PEB (fs:[30]) if the process is being debugged or not.
The 11th byte is the value in ah returned by GetUserDefaultUILanguage.

With this information it is no problem to write a bruteforce script and crack the key. You just need to google a bit to find the restrictions in majorversion, minorversion, UserDefaultUILanguage.

For the majorversion, I chose the values {5, 6, 10}.
For the minorversion, I chose the values {0, 1, 2 ,3}.
For the UserDefaultUILanguage, I wrote a little helper script to filter out the possible languages.

I’ve downloaded all the possible local identifier from MSDN and looked for those who end with 0x00. Finally, I only had 6 possible identifiers.

While reversing the code, you could see that after decrypting, the first 3 bytes of the result are checked against the values ‘P’, ‘A’, and ‘N’ which makes sense since you are expecting a flag like the ones before starting with “PAN{“. This will also help for the bruteforce script to identify the correct key. For the script I implemented the RC4 from wikipedia.

Finally, here is the code. It will take a couple of minutes to crack the key.

Key: b00!9kLA@jf
3051382 Keys checked


This is also be the last write up since the challenge ended before I could solve Challenge 7 and since there are also a lot of write ups available I’m no longer motivated to solve #7 on my own.

Posted in Reverse Engineering | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #6

PAN LabyREnth CTF – Windows #5

Sample: f919ed81cd4b78fdff54f8f34ac10e07079814e2eaee08bb3fb4fc19c3301f26 (PW: infected)

file RGB.exe
RGB.exe: PE32 executable for MS Windows (GUI) Intel 80386 Mono/.Net assembly

Compared to the challenge before, this one was pretty easy. You need to adjust the controllers to the right value in order to get the key.


It’s again C# written code to you can decompile it easily. I used ILSpy to do so. Find the responsible function for the button click and voila, there you have a pretty suspicious if statement.


Since we just have to try 256*256*256 values, we can easily bruteforce for the correct values.



Posted in Reverse Engineering, Uncategorized | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #5

PAN LabyREnth CTF – Windows #4

Sample: 3dd0d247d51df1e9c8ae594089c82608792f6bbc376e102aee52ad7c1baa91ab (PW: infected)

file JugsOfBeer.exe
JugsOfBeer.exe: PE32+ executable for MS Windows (GUI) Mono/.Net assembly

This is a x64 Binary which is asking for a valid serial number.


So you need to find the function which is checking input. In order to find it, I always look for suspicious strings if applicable.



In IDA graph view, the function looks pretty confusing but you you just have to follow the paths and you will find a function which is responsible for the serial validation.


After finding the serial validation function you need to understand the algorithm. Here, the IDA decompiler helps a lot but for easier debugging I reimplemented the function in python to better understand what the algorithm does.

I could see that there are some values swapped around but I still did not have any idea whats going one. A got a hint by someone that I should check the challenge description. After googling I found out that the algorithm is a variant of the quite popular Three Jugs Problem. Maybe you remember the movie Die Hard 3 where John and Zeus were also facing this kind of problem 😉

After that, everything was quite clear and I could solve the problem via pen & paper. You basically have three containers with a size of 7, 13 and 19. The 7 and 13 size containers are  filled and the 19 size container is empty. What you need in the end is 10 in two containers (13 and 19).



After I wrote down the solution on paper I just had to run my python code and build a valid serial to fill the mask appropriately.




Posted in Reverse Engineering | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #4

PAN LabyREnth CTF – Windows #3

Sample: 57174eac6975871458d393301bbaa67e799e85ed66fefb912875152581eb2f79 (PW: infected)

file SquirtleChallenge.exe
SquirtleChallenge.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

Starting the sample, you will be prompted for a password.


So the next thing is to find out the password. After loading the file in IDA and searching for the string “Type the password:” you will quickly see what you need to type in.


After typing “incorrect” as a password you will also get a lot of hints what the code needs to  give you the flag. The guys from PAN even give you the URLs where to find additional information about the specific Anti-Debugging technique.


In the end you can either patch out the checks or step over via a debugging. If you’ve done everything right, a valid JPEG file “answer.jpg” will be dropped in the same directory as SquirtleChallenge.exe.


Decode the binary code:



Posted in Reverse Engineering | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #3

PAN LabyREnth CTF – Windows #2

Sample: 351ff406e49f28518315e99a87e5020ec031883c69c291f86b6abe99b2d7c4ef (PW: infected)

file BabbySay.exe
BabbySay.exe: PE32 executable for MS Windows (GUI) Intel 80386 Mono/.Net assembly

BabbySay.exe - ExeInfo

The second sample was a really funny one. Starting the file will show a keyboard and after hard thinking I came to the conclusion that I will most probably need to push the right buttons to reveal the flag ;-).

BabbySay - Keyboard


Since we have a C# sample here, we can decompile the code to see what’s going on.
I used .NET Reflector to decompile it. After digging around you will spot the function which is responsible for the actions taken on each button click.

BabbySay - clickHandler

Just read the bunch of if statements to understand which buttons must be pressed in which order and after you’ve done it, the flag will show up.


Posted in Reverse Engineering | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #2

PAN LabyREnth CTF – Windows #1

Sample: 61921d13ef1be2285301fceafa6ecd3d0a01d45f71fe620149975d63e92d3612 (PW: infected)

file AntiD.exe
AntiD.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit

The file is packed with UPX but unfortunately, it cannot be unpacked the easy way with UPX.

AntiD.exe ExeInfo

You must unpack it manually. However, there are thousands of tutorial which explain doing this so I will not explain it again here.

After unpacking the file (you can download the unpacked version here: AntiD_Dump PW: infected) you can load it into IDA and start looking for suspicious or interesting stuff. I always start with the “Strings Window”.


The strings “Figure the key out:” or “Well done! A+! You get a gold star!\n” look very interesting. Following those strings will bring you to the function which is doing the check against your input.


I already annotated the called function before the branch to “checkKey” because it’s quite obvious what’s going on here.

Digging deeper into the function, you will see a lot of hex values assigned to variables.


These hex values concatenated will most probably be the solution. The rest is simple reversing. For the sake of simplicity, here is the annotated decompiled version of the “checkKey” function.


You can see that there are some Anti-Debugging features in place. You can just change the specific flags to avoid getting hit by one of these features or patch them out. During debugging I thought the latter would be easier so I patched everything out.

After understanding the logic of this code, I wrote a simple python script to reverse the hex values.

Running the script will display the key for the next round:


Posted in Reverse Engineering | Tagged , | Comments Off on PAN LabyREnth CTF – Windows #1

How to set up a BinaryPig Multi-Node Cluster

Based on my BinaryPig Single-Node cluster tutorial, I’ll now explain how to set up a Multi-Node cluster. It’s necessary that your Single-Node cluster is running properly. I changed the username to “hadoop” to avoid confusions but you can keep the “master” username.

For the Multi-Node setup, you will just need to clone your Single-Node VM and change a couple of configuration files.

Change /etc/hosts on master and slave:

Make sure that you’re able to ssh (without password) from master to slave and vice versa.
Change /usr/local/hadoop-1.2.1/conf/core-site.xml on the master and the slave:

Change /usr/local/hadoop-1.2.1/conf/mapred-site.xml on the master and the slave:

Change /usr/local/hadoop-1.2.1/conf/masters and /usr/local/hadoop-1.2.1/conf/slaves on the master as well as on the slave:

That’s pretty much it. Just format the namenode one more time and everything should be fine:

Start hadoop with After starting you should be able to run pig on the master or the slave:

The script from binarypig should look like as follows:

The job “strings.pig” will now be executed one the slave which is basically also a single node setup but you can easily add more slaves if you want to.

Posted in Malware Analysis | Tagged , | Comments Off on How to set up a BinaryPig Multi-Node Cluster

Flare-On 2015 #5

First we’ll check the PCAP to see what’s going on. We can see that there are a couple of HTTP packets so let’s filter for http:

We can see that the last 4 bytes of each packet must be some sort of key. If we concatenate all the 4byte values of each packet we’ll get the following string:

This must be a base64 string but if we’re trying to decode it, we’ll just get some strange binary stuff. So let’s have a look on IDA. Since we know that this binary is sending HTTP requests, we’re searching for specific function calls e.g. InternetOpen, HttpSendRequest, or HttpOpenRequest in the Import tab of IDA:

Let’s track back the function and we’ll see that most of these functions will be called in the function sub_401000. Checking the cross reference, we’ll find out that there is only one call of sub_4010000:

So we need to check what’s going on before this function call. The first interesting function call is “ReadFile”. If we scroll up a little bit higher, we’ll find out that this binary is trying to read a file “key.txt”. The function at 4011A0 (renamed to checkKey in the screenshot) is reading the content of “key.txt” and just adding each byte of the input to the respective byte of the string “flarebearstare”:

The encoding routine can be found at 4011E7 (renamed to obfuscation, that was my first thought ;-)). I did not get it that this was just a Base64 encoding algorithm with a different alphabet so I wrote a dirty-ass python script to reverse the whole stuff (omg!):

Anyways, it worked quite good. The output is:

If any python pro will ever read this blog. Please forgive me!

Posted in Reverse Engineering | Tagged | Comments Off on Flare-On 2015 #5

Flare-On 2015 #4

Ok let’s start the sample first:

Well, 2 +2 = 4, that’s right. Let’s have a look on the Imports:

That’s not very much. Maybe it’s packed!? Let’s check it with ExeinfoPe:

Seems to be packed with UPX. This should be easy to unpack. Let’s try it with UPX itself:

Let’s start it again:

Hm, it does not even start so will also have no chance to debug in Olly because it will crash before I can step through the code. Something must went wrong with the unpacking. We’ll try to unpack it manually. We’ll use a WinXP VM since Win7 and Win8 does not work for some reason. There are a lot of really good tutorials how to unpack UPX manually so i’ll skip all the details here.

Olly will wait on the EP B440:

Step over the PUSHAD instruction and “Follow Dump” the ESP register:

Memory Breakpoint “On Access” at 12FFA4:

Let’s run the binary. It will stop at the Memory Breakpoint you set. Scroll down a little bit and you will identify a far jump (0x40b61A) and a lot of crap code below.

Set a breakpoint at the jump:

Run until the JMP and step over it. You will land at the OEP of this binary (0x403A8A):

Dump the process with OllyDump:

Press dump and save the file. Don’t quit Olly because we’ll need to fix the imports first. Start Import REConstructor and fix the IAT:

Type in the OEP which is 3A8A (see the screen above) and press IAT AutoSearch:

As Import ReConstructor tells us, we press Get Imports and finally “Fix Dump” to save the file.

Now we’re trying to start the unpacked sample again:

Looks good. Now we can try to run it in OllyDbg. I’ll skip again all the try and error and just show my breakpoints:

The last breakpoint is the one where the magic happens but just see youself:


Did I already mention that writing blog posts is a shitload of work?


Posted in Reverse Engineering | Tagged | Comments Off on Flare-On 2015 #4

Flare-On 2015 #3

Starting the executable will result in a very nice picture but no real hint to start with.

We can see that the file size of that executable is unsually big. Anyways, we’re doing some basic stuff like strings and let’s see what we can find:

Based on the output we can assume that this file must be written in python and be converted into an executable with PyInstaller or py2exe. In order to extract the python code I used which can be downloaded here (I also used some other tools but none of those really worked except

The following command will extract all the python stuff from the executable.

The result looks like as follows:

We’re looking for something suspicious here:

The file “elfie” seems to be just ASCII text. Let’s have a look on that:

That’s quite a lot of concatenated base64 strings. Just build the complete string and decode the string. I just used PyCharm and copied all the obfuscation code into a python script to decode it. After decoding you will find a lot of crappy python code and if you scroll down you will notice something which kinda looks like an email address.

Just reverse it and you’ll have the solution for challenge #3.

Elfie <3

Posted in Reverse Engineering | Tagged | Comments Off on Flare-On 2015 #3