WARMING UP on STACK - Part I
In our
last post
we talked about a
challenge
set up by gera from Core Security. Since these challenges make up a good training ground for further real world exploit situations I decided to give a shot at them now that my schedule got a little softer.
We will start from the ground up and cover levels #1 to #3 from the "Warming up on Stack" section which, as the name implies, are just a warmup. To get the job done, we needed a linux distribution that doesn't include any security filters such as ASLR or Non-executable stack or the PaX patch; in my case, I chose to use SUSE 9.3 inside a virtual machine. Completenting our toolset we will use the usual set; gdb, python and a terminal (Hello, Konsole :-).
First, let's take a look at the challenges source code:
Once we hit the breakpoint we analyze the stack:
This is where the fun begins. You can see where our garbage A's begin and where our
cookie
%span{:style => "font-weight: bold; color: #990000;"} ebpand
are so, all that's left is a little hex math.
ebp
is at
0xbffff118,
the cookie at
0xbffff10cand
our buffer starts at
0xbffff0b0,
thats
92
bytes from our buffer till the cookie(which at the same time is 12 bytes minus ebp, as the cmp instruction shows). Therefore we have all we need, the offset and the value of the cookie. All that's left to do is just injecting those values in our buffer, and that's were python comes to play. We can build our string with python and then pipe the result to our program like this:
The first three levels covered in this post are just little variants of each other where the only difference is the value of the cookie. This is no match for python which handles hex values just as fine, congratulating us with a gentle
"you win!".
Now this is it for today, The 4th and 5th levels are a bit different because they deal with carriage return and new line values in the cookie (0x0d and 0x0a, respectively) and thus, require a different approach. I hope you enjoyed this as much as I did solving them. Keep adding NOPs! :-)
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);
if (cookie == 0x41424344)
printf("you win!\n");
}
Nothing strange in here, a simple C program that uses libc's very own gets() function to receive some input from stdin. If we take a look at the disassembled code we notice that all it takes to get into the
good-boy
is to succeed in the hardcoded comparison against the
0x41424344
cookie, no news after the C source. So let's setup a breakpoint at the comparison and take a look at the stack layout.
Once we hit the breakpoint we analyze the stack:
This is where the fun begins. You can see where our garbage A's begin and where our
cookie
%span{:style => "font-weight: bold; color: #990000;"} ebpand
are so, all that's left is a little hex math.
ebp
is at
0xbffff118,
the cookie at
0xbffff10cand
our buffer starts at
0xbffff0b0,
thats
92
bytes from our buffer till the cookie(which at the same time is 12 bytes minus ebp, as the cmp instruction shows). Therefore we have all we need, the offset and the value of the cookie. All that's left to do is just injecting those values in our buffer, and that's were python comes to play. We can build our string with python and then pipe the result to our program like this:
The first three levels covered in this post are just little variants of each other where the only difference is the value of the cookie. This is no match for python which handles hex values just as fine, congratulating us with a gentle
"you win!".
Now this is it for today, The 4th and 5th levels are a bit different because they deal with carriage return and new line values in the cookie (0x0d and 0x0a, respectively) and thus, require a different approach. I hope you enjoyed this as much as I did solving them. Keep adding NOPs! :-)