K17 CTF 2013 Reverse Engineering Challenges Writeup
A solution guide for challenges released during a past CTF event
This blogpost contains the writeup of how I solved the reverse engineering challenges for the K17 CTF 2013 event ran by UNSW.
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.
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.
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.
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.
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.
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.
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"
