I'm learning exploitation, and I downloaded some execve("/bin/sh") shellcode from exploit-db to use it in simple buffer overflow example. When I execute the program I am getting segmentation fault. I'm running this on kali linux in vmware.

Here is code:


const char sc[] = \

void main()
         printf("Shellcode Length: %d\n", strlen(sc));

Here is how it is compiled:

gcc -z execstack -fno-stack-protector shell.c -o shell
  1. May it be caused by running it on vmware?
  2. Is it possible that there is something wrong with shellcode but I am getting SIGSEGV instead of SIGILL?
  3. Is there something wrong in the way that I execute code in this C program?
  • The shellcode you posted is the one found here. This shellcode targets ARM machines, is your kali linux running on an ARM machine?
    – game0ver
    Dec 5, 2018 at 22:46
  • No, it is x86. But then why I am getting SIGSEGV, and not SIGILL?
    – user192960
    Dec 5, 2018 at 22:52
  • Why you get SIGSEGV instead of SIGILL is a very interesting question and I guess it has to do with linux internals. I found this post that seems to be relevant, but I think the best thing you can do is to ask a new question regarding that and hopefully someone with more knowledge will answer :)
    – game0ver
    Dec 5, 2018 at 23:11
  • 1
    @game0ver I doubt it has to do with Linux internals. A general protection fault, #GP(0), occurs both on Linux and Windows. The only difference is how they are handled, with Linux raising a POSIX signal.
    – forest
    Dec 10, 2018 at 9:34

1 Answer 1


You are executing ARM machine code on an x86 machine. Of course it won't work. If it is giving SIGSEGV (which happens when a general protection fault, #GP(0), is raised) instead of SIGILL (which happens when an illegal or unknown instruction is found) despite being compiled for a different architecture, then the first few bytes of the ARM shellcode must have been interpreted as legal x86 machine code. The x86 ISA is extremely complicated, and any random assortment of bytes has a non-negligible chance of being technically valid x86. While it may have been decoded correctly, it does something totally unintended, which just so happens to trigger a general protection fault before anything that can't be interpreted as valid x86 is reached.

You must log in to answer this question.