K17 CTF 2013 – Reverse Engineering Challenges Writeup

This blogpost contains the writeup of how I solved the reverse engineering challenges for the K17 CTF 2013 event ran by UNSW. I’ve written a page about this CTF event in my CTF Event page, here.

Reverse Engineering / Crypto – Rope

I ran the binary file, Rope, given to the teams by the organizes and nothing happened, immediately I opened the binary in IDA Pro and noticed straight this was going to be a simple reverse engineering challenge.

Screenshot from 2013-09-29 14:22:27

The reason why I knew this was going to be a simple solution was because when IDA had finished analyzing the binary I could see that the main function runs through some instructions until it hits a “JZ” instruction which if the Z Flag is set to 0 the execution flow jumps to the bottom instructions and the binary closes. With this information I knew all I had to do was manually change the Z Flag to “1″ so the binary doesn’t take the jump and then I’ll be able to see the flag. I set the breakpoint on the “JZ” instruction as well as a few breakpoints on the next couple of instructions after the jump is not taken so I would be able to view the difference it makes to the binary execution.

Screenshot from 2013-09-29 14:29:51

Once the breakpoints had been set I ran the binary hitting the first breakpoint on the “JZ” instruction and modified the Z Flag, then continued the executing the next few instructions until right before binary closes and examine the hex data of the binary which is where I found the flag, “Thekeyis:1KsRezs4u8ksj6T26DMgvjjNsLjMmcH69s“. See what did I say, it was actually a very simple solution.

Reverse Engineering / Crypto – The controller

In the next reversing challenge we were given a binary called thecontroller.

Screenshot from 2013-09-29 14:56:54

From the above screenshot you can see the output from when I ran the binary as well as the several times of the “strings” command on the file. When I ran the binary I was given a prompt to enter some input which appears to be checked against a value within the binary to become authenticated. I also used the strings command to search the binary for strings containing “flag” or “key” could potentially identified the answer for this question, this was not the case.

The output from the strings command on the binary when grepping for key search of “flag” returned the string “thisistotallytheflag”. I attempted to submit that string but was given a incorrect flag message on submission, turns out it wasn’t actually the flag and this challenge was actually going to take a bit more work. So I decided time to break out IDA Pro again and have a look at the binary.

Screenshot from 2013-09-29 15:08:32

From the above screenshot I’ve placed two breakpoints on two instructions inside the main() function of thecontroller binary. The first instruction calls a new function called auth(), which is used by the binary to check input of the user to authenticate the user. If the authentication is correct the binary moves passed the “JZ” instruction and displays a message saying authentication was successful, if not successful when the flow of execution reaches the “JZ” instruction the Z flag would be set to “0″ and the jump is taken instead. After examining the main() it was time to have a look at the auth() function of the binary to see what happens inside the function when it is called and in turn executed.

Screenshot from 2013-09-29 16:11:59

So the string I found earlier “thisistotallytheflag” turns out to be overwritten by the real flag and if the user’s input actually matches the correct flag, the user becomes authenticated. I placed a breakpoint on the flag and began executing the problem and watched as this string was overwritten by the correct flag.

Screenshot from 2013-09-29 16:05:50

I was able to reverse engineer the binary to find the correct flag which was “BRAINS!AREPRETTYNEAT“.

Edit:

After the event, a judge has approached our team and informed that the string is being passed through a ceasar cipher which is used to de-obfuscates the string into the flag and not actually overwrites the string “thisistotallytheflag”, I’ve added the code for the ceasar cipher below.


loc_80484CC:
mov     eax, [ebp+var_C]
add     eax, 804A035h
movzx   eax, byte ptr [eax]
mov     edx, eax
mov     eax, [ebp+var_C]
add     eax, 804A020h
movzx   eax, byte ptr [eax]
mov     ecx, edx
sub     cl, al
mov     eax, ecx
mov     edx, [ebp+var_C]
add     edx, 804A035h
mov     [edx], al
add     [ebp+var_C], 1

Looking at the screenshot in IDA Pro of the auth(), the binary runs through the ceasar cipher and then compares the current string to the flag string and if correct, the binary does not take the jump into the ceasar cipher as shown in the code before and displays the correct flag instead of the “thisistotallytheflag” string and then finishes the auth() and returns back to the main() and grants the user authentication to the binary.


cmp     [ebp+var_C], 13h
jle     short loc_80484CC
mov     eax, offset flag ; "BRAINS!AREPRETTYNEAT"

About these ads

2 responses to “K17 CTF 2013 – Reverse Engineering Challenges Writeup

  1. Pingback: UNSW K17 – Networx | HackoGram | Tech with Beats

  2. re rope: `cat` and `objdump` would’ve given you the flag as well, as it was simply a string in the ELF binary. It was a UTF-32 LE string however, so a normal `strings` wouldn’t work.

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