Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just trying to get the assembler instructions for <__execve> of the code below because i want to build the shell spawn opcode list:

#include <stdio.h>
int main()
     char *happy[2];
     happy[0] = "/bin/sh";
     happy[1] = NULL;
     execve (happy[0], happy, NULL);

Objdump gives me this :

8053a20:    53                      push   %ebx
8053a21:    8b 54 24 10             mov    0x10(%esp),%edx
8053a25:    8b 4c 24 0c             mov    0xc(%esp),%ecx
8053a29:    8b 5c 24 08             mov    0x8(%esp),%ebx
8053a2d:    b8 0b 00 00 00          mov    $0xb,%eax
8053a32:    ff 15 a4 d5 0e 08       call   *0x80ed5a4
8053a38:    3d 00 f0 ff ff          cmp    $0xfffff000,%eax
8053a3d:    77 02                   ja     8053a41 <__execve+0x21>
8053a3f:    5b                      pop    %ebx
8053a40:    c3                      ret    
8053a41:    c7 c2 e8 ff ff ff       mov    $0xffffffe8,%edx
8053a47:    f7 d8                   neg    %eax
8053a49:    65 8b 0d 00 00 00 00    mov    %gs:0x0,%ecx
8053a50:    89 04 11                mov    %eax,(%ecx,%edx,1)
8053a53:    83 c8 ff                or     $0xffffffff,%eax
8053a56:    5b                      pop    %ebx
8053a57:    c3                      ret    
8053a58:    90                      nop
8053a59:    90                      nop
8053a5a:    90                      nop

From several texts I've read there was supposed to be a int 0x80 somewhere in the above output. Why isn't there one?

Are there any major changes in the 3.2 kernel concerning how syscalls work that might affect the algorithms of shellcode building (specific register loads, etc) which are presented in books written 3-4 years ago? The above dump looks very different from the output presented in the "Shellcoders Handbook" or "Smash the Stack"


share|improve this question
Some of the work is done in call *0x80ed5a4. Have you looked at the code of that function? – Gilles Jan 20 '13 at 14:25
Hello! I have and no hint of "int 0x80" there! Also I've grep-ed the whole objdump output for the binary file (compiled with the -static flag) and no hint of SYSENTER or SYSCALL either. – kawa Jan 20 '13 at 15:00
up vote 2 down vote accepted

Interrupts have substantial performance overheads, linux has moved to syscall/sysenter on x86 where supported. The VDSO pseudo-dll "" (which ldd will show) makes the platform-specific fastest call, you can read more here:

Code that uses 0x80 will continue to work, though current glibc versions won't use that method on modern x86 platforms and linux kernels.

share|improve this answer
Thanks a lot! That's what I needed to know , i.e. , if I could still use the old int 0x80 shellcodes evem on newer kernels. Thank you! – kawa Jan 20 '13 at 15:08
so old shellcode will work on my 3.2 kernel if i compile the binary with the -fno-stack-protector and -z execstack flags; just tested it – kawa Jan 20 '13 at 17:28

When writing C code and calling a "system call function" like execve(), you do not actually jump into the kernel directly; you call a function in the standard C library, which does the jump into the kernel (the int 0x80). This way, the C compiler does not have to know anything about the kernel calling convention, and this allows for changes over time (e.g. replacing a system call with a better one, with a distinct API: the libc must be altered, not the applications).

To do a direct system call, you have to resort to writing assembly yourself. You may want to have a look at the libc source code for guidance.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.