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"


closed as off-topic by Kusalananda, phk, Jeff Schaller, GAD3R, a CVn May 19 '17 at 20:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question has been posted on multiple sites. Cross-posting is strongly discouraged; see the help center and community FAQ for more information." – Kusalananda, phk, Jeff Schaller, GAD3R, a CVn


The syscall implementatin is hardware dependent (heavily) - see wikipedia article on syscalls and the article on kerneltrap. On modern x86 it seems int 0x80 has been abandoned in favour of the newer SYSENTER et al some time ago.

For me __execve looks like this:

000000000040f7c0 <__execve>:
  40f7c0:    b8 3b 00 00 00          mov    $0x3b,%eax
  40f7c5:    0f 05                   syscall 
  40f7c7:    48 3d 00 f0 ff ff       cmp    $0xfffffffffffff000,%rax
  40f7cd:    77 02                   ja     40f7d1 <__execve+0x11>
  40f7cf:    f3 c3                   repz retq 
  40f7d1:    48 c7 c2 c0 ff ff ff    mov    $0xffffffffffffffc0,%rdx
  40f7d8:    f7 d8                   neg    %eax
  40f7da:    64 89 02                mov    %eax,%fs:(%rdx)
  40f7dd:    48 83 c8 ff             or     $0xffffffffffffffff,%rax
  40f7e1:    c3                      retq   
  40f7e2:    66 90                   xchg   %ax,%ax
  40f7e4:    66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40f7eb:    00 00 00 
  40f7ee:    66 90                   xchg   %ax,%ax

Note the syscall at the beginning. The exact form of the function depends on compilation flags and the architecture for which the code is compiled - see gcc's options -mtune and -march.

EDIT: Additional interesting links:

  • Thanks for the answer! So, what you're saying is that compiling code with system calls on later kernels (post 2.6) will build machine code with SYSCALL or SYSENTER opcodes instead of the old 0x80 interrupt. Does that mean that a shellcode designed to work with 0x80 interrupt will fail on these later kernels? I'm asking this question because I have tried a shellcode, that used the old method, which is supposed to spawn a shell and I get a segmentation fail core dump error and I want to know what is the cause (bad design or intx80 not working anymore). Thanks! – kawa Jan 20 '13 at 14:25
  • I'm neither really sure what it means nor what are you trying to achieve. In the end you probably want to code it in assembly anyway, since linking with libc is rather an overkill in this case. Anyway, if kernel stopped using int 0x80, I would expect the interrupt vector to be intentionally initialized to 0x0 which would cause NULL-ptr dereference aka segfault. However I would still expect it to support it to some extent at least - the ultimate answer is in the kernel sources and in running the program in debugger. Also check newly added link in the answer. – peterph Jan 20 '13 at 21:36

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