Description: Welcome to Part 7 of the Buffer Overflow Primer. If you have not already done so, please start this series by viewing Part 1. The Buffer Overflow Primer requires that you know at least some basic Assembly Language. I have created a series of Assembly Language video tutorials for Hackers here, for those not familiar with the language. <br><br>In this video we will do a buffer overflow exploitation demo using HackYou.c and ExploitMe.c . We will first execute HackYou.c to inject the shellcode into the environment variable EGG. Then, we will invoke ExploitMe.c with the $EGG input. This will cause the stack to be over written by the $EGG environment variable and plant our shellcode on the stack, and replace the RET address to point to our shellcode. Now, when main() returns, our shellcode is called. As expected the shellcode runs and spawns a shell :) It is important to note that in this video there are no protection mechanisms for the stack such as NX, ASLR etc. We will deal with how to exploit the stack in presence of these protections in later videos. <br><br><br><br><br><br> <style type="text/css"> body { background: #FFF; } </style> </div>
Tags: tools ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.
You're the best! =D
I forgot to ask you something. Why does this don't work on ubuntu 9.10? That's because the ubuntu manage the stack diferently than slackware? Because i tried to execute the programs desabling the SSP, but it still didn't work.
I'd have to probably check what mitigations that specific version of Ubuntu ships by default but it could be anything - DEP, ASLR, Stack Cookies etc. In some circumstances, some or all of these protections can be bypassed.
Have a look at the Exploit Research Megaprimer in progress. I will be covering these topics in more depth there.
Brilliant. Looking forward to finishing this series tomorrow.
Many thanks.
Hi Vivek, and Hi to everybody.
First of all I really want to tank you for your video, I'm studing it and they are really of good quality.
I've tried out your example.
First time it didn't work because I had a protection in my BackTrac Compiler. Thanks to s0ttle at the link : http://www.smashthestack.org/viewtopic.php?id=388
I discovered I had a Stack Smashting Protection (SSP) / ProPolice, so I disablet it.
Still doesn't work.
It seems the layout of my stack is different then the stack in your stack.
I've watched other your video in exploitation and I saw you usually put the payload (shellcode) after the return address and not before.
It seems to me that putting the payload before the return address is going to make things a bit more difficult then putting it after.
Could you tell me why you choosed to put the payload before the ret address, so I can understand what is the purpose of this?
Thanks again
Escube
thank you for the tutorial, it was really excellent.
Thanks you very much.
So to find the return address, you just sued the top of the stack? You surely can not always do this, so how would you work out the return address otherwise?
By the way, amazing video series and the assembly series primer, I had a lot of trouble getting the stack for a long time and now thanks to you I do, many many thanks and please do continue.
Once again, thank you for the time and effort you've taken to share your knowledge.
The ambient background noises on the different series are interesting :) I've heard water dripping, gunshots, birds calling and I believe some frogs. I picture you in a hut in the middle of a jungle somewhere :)
I am having some problems getting this to work. As you can see below, I have gotten ret to point back to esp:
# after injection
(gdb) x/24xw $esp
0xbffff410: 0xbffff418 0xbffff68f 0x6850c031 0x68732f6e
0xbffff420: 0x622f2f68 0x99e38969 0xe1895352 0x80cd0bb0
0xbffff430: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff440: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff450: 0x90909090 0x90909090 0x90909090 0x90909090
0xbffff460: 0x90909090 0x90909090 0x90909090 0xbffff410 # points back to shell code
# Is there a problem with ebp being overwritten?
# Is there a protection mechanism going on or am I just doing it wrong?
(gdb) x/1xw $ebp
0xbffff468: 0x90909090
(gdb) s
11 }
(gdb) s
Cannot access memory at address 0x90909094
Thanks for the video by the way. Even though I haven't gotten it working, I feel like I understand the concepts a lot better.
@t0ph4tter same error, did u find a fix??
thank you, I failed because security cookies...Now I'm figuring out what it is!!
but in your computer situation, I can handle it!
same problem as Patcher and t0ph4tter pls somebody explain to us what is the problem
@Wilson & @t0ph4tter: I had the same problem on ubuntu 11.04, I don't know why but when you disassemble main@ExploitMe, the 3rd instruction subtracts 0x5c from %esp instead of the 0x50 that is shown on the video. So, when you overwrite the return address to __libc_start_main, you have to check in which part of the stack begins exactly the shellcode, in my case it was %esp+12. Hope it helps. Excellent material, Vivek, thanks a lot.
@orrala This is what I did, but as t0ph4tter, Patcher and Wilson I've exactly the same error with this in my stack (shellcode included):
(gdb) x /25wx $esp
0xffffd5b0: 0xffffd5b8 0xffffd89e 0x6850c031 0x68732f6e
0xffffd5c0: 0x622f2f68 0x99e38969 0xe1895352 0x80cd0bb0
0xffffd5d0: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd5e0: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd5f0: 0x90909090 0x90909090 0x90909090 0x90909090
0xffffd600: 0x90909090 0x90909090 0x90909090 0xffffd5b8
0xffffd610: 0x00000000
(gdb) x /1wx 0xffffd5b8
0xffffd5b8: 0x6850c031
So, as you can see the value in 0xffffd5b8 is the begining of my shellcode and it's the place where the ret value is overwritten. Please we need some help Vivek. Anyway your videos are so amazing, I recommended them to all of my colleagues who are seeking for comp security knowledge. Thanks a lot Vivek!
Damnit. I'm having the same problem - Cannot access memory address 0x90909094.
I'm not sure what else to do. I've tried numerous things. I see that in his example, the first address in ESP is pointing to his shellcode. However, mine is pointing to a completely different address. Perhaps this first address is where this error is being generated from? I'm so lost on this one simple step, and I cannot and will not proceed with the next video until I get this taken care of.
everyone who's having the same problems as t0ph4atter...
I had this same error when i set breakpoints in gdb using the syntax
>>break *main+35
however, if i just fired up ExploitMe in gdb and did
>>run $EGG
I would generate a shell as expected. not sure why adding breakpoints in main prevents you from creating a shell properly, but thats my experience with it. hope this helps
I keep getting a Segmentation Fault when I run ./ExploitMe. It seems to compile okay but will not run. No problem running the ./HackMe program. I will have to give this some thought.
I had the same problems as the previous posters and found that the memory location of the stack changes when I use gdb. Adding the line
printf("%p\n", buffer);
to ExploitMe.c gave me the correct memory location for the buffer. In my case it was 0xffffd198.