c - Stack-based overflow code from Hacking: The Art of Exploitation -

this might related this, i'm not sure if it's in same boat.

so i've been re-reading hacking: art of exploitation , have question of c code in book, doesn't quite make sense me:

let's assume we're in ~2000 , don't have stack cookies , aslr (maybe do, hasn't been implemented or isn't widespread), or other type of protection have now-a-days.

he shows piece of code exploit simple stack-based overflow:

#include <stdlib.h>  char shellcode[] = "..." // omitted  unsigned long sp(void)  { __asm__("movl %esp, %eax); }  int main(int argc, char *argv[]) { int i, offset; long esp, ret, *addr_ptr; char *buffer, *ptr;  offset = 0; esp = sp(); ret = esp - offset;  // bunch of printfs here...  buffer = malloc(600);  ptr = buffer; addr_ptr = (long *) ptr; for(i = 0; < 600; i+=4) { *(addr_ptr++) = ret; }  for(i = 0; < 200; i++) { buffer[i] = '\x90'; }  ptr = buffer + 200; for(i = 0; < strlen(shellcode); i++) { *(ptr++) = shellcode[i]; }  buffer[600-1] = 0;  execl("./vuln", "vuln", buffer, 0);  free(buffer);  return 0; } 

so wants take address of esp , overwrite saved eip address, processor jump nop sled in memory , execute shellcode in stack.

what not understand, how can use particular esp value gets sp() @ current time calls it.

from understand, stack looks "something" this:

... saved ebp <-- execl saved eip "./vuln" "vuln" buffer 0 *ptr <-- sp() returns address? *buffer *addr_ptr ret esp offset saved ebp <-- main saved eip argc argv ... 

since calls (i know it's function pointer, guess not entirely accurate wording?) sp() in exploit, shouldn't give him bad esp address? matter, don't see how can use technique here, because never esp points top of buffer inside vuln program.

thanks.

i don't see how can use technique here, because never esp points top of buffer inside vuln program.

i haven't read of book, think i've figured out. here's *buffer looks like:

nop sled | shellcode | address of buffer in exploit's stack frame 

when vuln strcpy() on buffer own stack, fails check bounds , overwrites own eip address of start of buffer in exploit's stack frame, or @ least close (hence nop sled). the nop sled , shellcode copied vuln's stack frame incidental; that's not run from. it's critical sled , shellcode smaller how big vuln expects buffer be, otherwise saved eip overwritten shellcode rather address of buffer.

then, when whatever portion of vuln uses strcpy() on buffer returns, goes nop sled , executes shellcode.

the important point buffer read twice, in 2 different places.

edit: disregard that, confused myself (though accept!). not confuse too, why i'm writing edit. vulnerable program in completely different virtual memory space since run operating system in separate process (or same process new image? whatever). there'd no way vuln access exploit's stack or heap.

the esp trickery must way guess nop sled in copied buffer ends in vuln's stack. expect larger offset 0 since exploit's stack quite small compared vuln's.

that said, i'm pretty sure there still 2 copies of shellcode in vuln (otherwise, strcpy() from?). offset of 0, perhaps running shellcode stored in argv[]...?!? in case, you'd still have situation address in 1 buffer points nop sled in buffer, in original answer. i've been wrong before though, let me know if makes no sense.