Challenge: here

This level was pretty much the same code as the previous level, except we no longer have ASLR turned off and the address leak of our buffer is no longer available to us:

printf("[debug] buffer is at 0x%08x :-)\n", buffer); :D

While we really did not need this in the first challenge, because we could have used a dynamic debugger such as gdb to see where our buffer was in memory.

We do however, still have an executable stack. This tells us that we can still run our shellcode making our payload pretty similar to what it was in the previous level.

It would be really nice to be able to get the eip register to point to our shellcode… let’s checkout what happens right before the function fix_path returns using gdb.

We start out by sshing into the fusion vm and startup gdb as root:

[~]$ ssh fusion@<ip address of fusion vm>
fusion@172.16.76.131's password: 
fusion@fusion:~$ sudo gdb
(gdb) 

Making a little python script that uses sockets to establish a connection to the fusion vm on the same port that the level01 program is listening on (20001) we can run the program and then attach to the child process on the fusion vm:

(gdb) shell pgrep level01