1. ive written some assembly shellcode to do something simple things, e.g write to stdout.. only problem is I dont know how to correctly use the stack to reference adresses (e.g adress of string start)
   

   like if i did
   

             pushl  $0x8798 # random 4 byte string          pushl  $0x7776 # random 4 byte string          xorl   %ebx , %ebx          movb   $8 , %bl # store length of string in ebx

   
   

   am i correct to store the string length in the low byte of ebx (assuming x86)?

   
   

   Also how would i go about storing the string adress (i know i have to use ebp but im not sure whether to use leal or movl).

   
   
2. if i make a simple program
   

             char buff[4];          strcpy(buff,"ABCDEFGH");

   
   

   and look at the base pointer in gdb it isnt changed, whereas using a for loop until i find a null byte does alter the base pointer.

   
   

genjix@linux:~/media/programming/c++/TEST> ./a.out aaaaaaaaaaaaaaaa bpool = (aaaaaaaaaaaaaaaa)bank = (b)genjix@linux:~/media/programming/c++/TEST> ./a.out aaaaaaaaaaaaaaaaa bpool = (aaaaaaaaaaaaaaaaa)bank = (b)Segmentation fault

... it seems the compiler isnt aligning the 2 strings next to each other in memory.

I wondering what the moderators would have to say about this thread, given that this knowledge would really only be used for bad purposes.

How do we know people here aren't helping you create a new virus?!

i can easily make linux viruses, this is a buffer overflows.

1. Thats as silly as saying, im not going to let you go boxing because you could be using that knowledge to hurt people.
   
2. How do you know im not using it to speed up memory access and tighten code in my game?
   
3. Who has a right to deny me my knowledge, if I'm not explicitly causing anyone harm?
   

I am just interested, don't tell me these sort of things don't interest you (or anyone else for that matter).

iMalc: I had to study buffer overflows (and the implementation) in cryptography and security course I took at uni. Buffer overflow is the number one cause of vulnerabilities. Genjix might as well be intrested in hardening the linux kernel against buffer overflow attacks. And I guess moderators have already seen this thread... and the info one gains from this thread hardly allows one to write a real life exploit. There is many _much better_ information sources from black hats than this.

But what comes to me, this is the last public post I send to this thread (this thread hardly relates to game programming (or it might relate to copy protection, not like though))... private messages still work.

Genjix:

Pool gets allocated to the stack before the bank. So if you overflow the pool it just writes over the stored basepointer and ret address and so on. If you reverse the order of the strings it works as you suppose to:


gcc v2.c -o v2; ./v2 imWayTooLongString ButImNot
pool = (imWaButImNot)
bank = (ButImNot)

There is some alignment issues, true. If you use debugger to check starting addresses of pool and/or bank and compare it to the ebp (address of stored ebp) you notice that the difference changes if you use different optimizations (-Os, -O2, -O0).

Few answers to your previous questions:

You don't usually need the ebp in shellcode. But if you use the technique where you call some libc function directly, you will need to have sane stack frame (function may have local vars). So how is ebp related to this. After you enter a function, ebp points to address where the stack "ends" and local vars start (remember that stack grows towards address 0). That address contains the stored ebp. When you leave the function stack frame is recovered by leave instruction (or mov esp,ebp and pop ebp). This is only if you have frame pointer. If you have compiled your prog without frame pointer the compiler takes care of the esp register. But still the basepointer is used to address the arguments and possibly local vars.

So the bottom line is.. your shellcode most probably does _not_ need basepointer and you should only worry about the return address (which is just above the stored basepointer).

And basepointer (the ebp register) should not change if you just overwrite the stored basepointer (in memory). It changes at the point where you leave the function (pop ebp).

ok, thank you very much for your help. There are still a few things I don't understand, but I want to look these up myself. Thanks again.