Walkthrough of my Regime entry-level CTF challenge

Regime walkthrough

Summary

This was the 2nd reverse engineering challenge I wrote and was meant to be an entry-level one for ENUSEC's "Le Tour Du Hack", and was worth 150 points. A file named login was given to the contestant. It had four solves in total.

I'll be using gdb-peda and IDA free in this writeup. They're both free.

Jumping in..

If we run the UNIX utility file on the binary we get this return:

login: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

We can now see its not stripped, meaning we'll have meaningful symbols within the binary we can relate to and that its 32 bit. Running the binary gave us a prompt where we'd have to input a password.

Ok, we can now conclude that it's comparing our input (a string), to another input within the binary. We can assume its using strcmp, or strncmp (the safer version of strcmp). Lets take a look at it in IDA.

Looking at it in IDA, we can see a subroutine called login_show_splashscreen. Lets check it out.

Oh, ok. It's just showing the console stuff. We can ignore this. If we go down to where we're recieving input, this is where the password is compared so we're interested more in this logic than anything else. We can see fgets is called, this is obviously being used to gather input from stdin (your console). Ok, now we see login_check_password, we're passing eax to this method which is obviously the password. We can see that theres a "Welcome" message too if the password is correct, great! Lets go check this out!

Lets look at login_check_password. At the start of login_check_password it seems to be deriving different bytes from 0xDEADBABE. If we then look to another node, we can see these are referenced in some type of XOR loop where the length of our input is used (we can see a call to strlen, in x86 the result of a call will be placed in eax). Ok, so basically its now unlocking the encrypted password.

We can just ignore this routine though, its irrelevant. The strncmp we can see has to see the "cleartext" (decrypted) password some time, right? We can see theres a call to strncmp, this is obviously comparing OUR password with the DECRYPTED password.

Lets open the binary in gdb and put a breakpoint on strncmp, this way we can see whats being passed to it. Run gdb login to open it in gdb. Now, we'll proceed to put a breakpooint on strncmp. A breakpoint is when the debugger will pause execution at a certain point. We want to stop at where our password is compared, so break strncmp or b strncmp. b is an alias for break in gdb.

Now type run or r. This will start the program. Once its loaded, input a dummy password. We should then break on strncmp where our input is compared.

We've input dummy_pw in this example, we can now see that its hit the breakpoint and gdb-peda has shown us the stack. In x86 with GCC, by default all of the parameters are pushed onto the stack for libc functions (C functions) unless another calling convention is used. We can see that the second parameter on the stack:

0008| 0xffffced4 --> 0xffffcefc ("enusec{lemmein}")

is here, we could also access this in GDB by printing (simply print) the location of $esp + 8 where the breakpoint is sat. Our password we input is at $esp + 4, as sizeof(WORD) in x86 is 4 - hence all addresses are 4 bytes wide (32 bits). We could also just simply do: x/s *0xffffced4 as we can see that 0xffffced4 is the address of the second parameter.

tl;dr

gdb login
b strncmp
r
# enusec{lemmein}