Try the challenge thoroughly before reading the write-up. Otherwise, it's your loss.
Recap of previous level.
The recap of the previous level is the same as my solution in this post.
The story of this level tells us that this is the first hard challenge which will decide whether we are a just a kiddy or a true hacker. Challenge accepted!
So, the challenge binary has an interface like the pokemon game boy games I used to play before.
Examinig the source code, I realized that there was a buffer overflow vulnerability in the game_loop() function in the input
Also, if we wish to exploit this vulnerability, we’ll have to return from the game_loop() function. Therefore, buffer should be ‘4’. I decided that I’ll place my shellcode (
\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80) in the buffer, and then try to jump to it.
However the shellcode always kept segfaulting on me. I realized much much later that it was being mangled. This was because the stack pointer was near the shellcode, and our shellcode was utilizing the stack itself. So basically, the later instructions (unfortunately, just the last interrupt!) of the shellcode were being overwritten by the variables that the shellcode itself wanted to store on the stack.
However, I did have a few bytes (4) that I could utilize to prevent this. So, I filled the initial part of the shellcode with four
\x58 which correspond to the
pop eax instruction. I was thus able to move the stack pointer away from the shellcode itself so that it didn’t get mangled.
The biggest hurdle of the challenge however was figuring out the address to which I needed to jump to in order to execute the shellcode. Since ther wasn’t any space for a NOP sled. I was able to work out the exploit on my system both inside and outside gdb (by attaching it to the process).
However, I had used pwntools (which isn’t available on the gracker system) and I had attached gdb to the process (which too has been disabled on the gracker system). I was able to run the exploit from inside gdb though, however in order to read the flag, I needed to have level11 permissions which were not possible from inside gdb. So, I tried to make up for the difference in the addresses between inside gdb and outside it by accounting for the environment variables. This stackoverflow question has explained it well. However, nothing worked for me. Not manually hardcoding the address after accounting for the difference, or the wrapper script provided in that answer. You have to remember that I had to be exact to the byte of the address! Even if I was on byte on either side, it would segfault.
So, I figured there was nothing to it but to bruteforce. I used the address inside gdb (after removing the env vars) as the reference and kept progressing further byte by byte using a python script (it was painful without the elegant pwntools) till I hit the correct address.
I struck gold at the offset 511 => address
0xffffdc11. I then modified the script to read the password from
And Voila! I got the password to the next level. I am not revealing the password here so that the readers try the challenge on their own.