2

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"

Thanks!

3

Interrupts have substantial performance overheads, linux has moved to syscall/sysenter on x86 where supported. The VDSO pseudo-dll "linux-gate.so" (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.

  • 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
  • 1
    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
  • vDSO is specific to only certain syscalls. It is not used automatically for all syscalls. E.g. if you want to use gettimeofday(), you have the option of using the vDSO version for performance, but if you are using open(), you can't even ask the vDSO to do it for you. – forest Dec 31 '17 at 1:59
  • @forest: yes and no, its user-space implementation of optimised functions is limited as you describe. x86 glibc systems (not x86_64) will also use the __kernel_vsyscall trampoline function in the vDSO to wrap up the complexities of how to trap and sysenter housekeeping. This is a long, but very useful reference (for both 32- and 64-bit x86): blog.packagecloud.io/eng/2016/04/05/… – mr.spuratic Jan 2 '18 at 18:13
  • OK that makes sense. I am only familiar with x86_64 (where the much simpler syscall instruction is used). – forest Jan 3 '18 at 2:23
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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