The file in question is tucked away in the "/SECRET" directory in the root directory. This time, I decided it might be easier if I place the file on my Kali VM so I could diagnose the problem easier. I loaded the file in gdb and quickly found the spot EIP was overwritten using "pattern arg 300" and "pattern search" respectively.
I see EIP is overwritten 171 bytes in, so I send a new string to confirm my control over EIP.
So far so good. However, here it's important to note ASLR is turned off within gdb, though once I load up the final exploit outside of the debugger, it will be enabled. I also see ESP contains the NOPs I sent in my python script. Now I'm ready to create a python script that will brute force the program aiming for the correct address with my "/bin/sh" shellcode. I chose "0xbffff2ea" just to be "safe." Also, while reading up on ASLR exploitation, I learned a larger NOP sled is ideal in this case. Basically, by creating a large NOP sled, you increase your chances of hitting your shellcode. Since ESP allows me to create a large NOP sled, I'm going to take advantage of it to make a more reliable exploit. I chose 32,000 NOPs which produced fairly consistent results.
So after running 1258 times, the exploit worked and I get a shell. With my PoC, I decide to switch to the "Lord Of The Root" VM and continue my work there. I send the same python script through gdb and take note of the ESP address.
Now that I have a sample ESP address, I create a quick python script to automate the exploitation process. It should be noted that I chose an address slightly after ESP once again to be safe (0xbffff640 instead of 0xbffff620). It automatically finds the correct door since there is a script that runs every few minutes that changes the correct file location.
After running nearly 3000 times, a shell finally drops with root privileges.
This was a tough challenge for me as I've never attempted to bypass ASLR before, so I learned some new concepts that should aid in my future exploitation of buffer overflows.