Assembly works, but shellcode does not

Question

I have a x64 processor and I'm looking into shellcode.
I have the following code:

section .text
  global _start

_start:
   push rax
   mov rbx, 0x68732f6e69622f2f
   shr rbx, 0x8
   push rbx
   mov rdi, rsp
   ;mov rdi, com

   mov al, 59
   syscall

When compiled with the foolowing command:

nasm -g -f elf64 execve.asm

And linked with:

ld execve.o -o execve

It runs fine. It opens a shell. If i get the shellcode from it:

"\x50\x48\xbb\x2f\x2f\x62\x69\x2f\x73\x68\x48\xc1\xeb\x08\x53\x48\x89\xe7\xb0\x3b\x0f\x05"

And use this C program:

int main(void)
{
    const char shellcode[] = "\x50\x48\xbb\x2f\x2f\x62\x69\x2f\x73\x68\x48\xc1\xeb\x08\x53\x48\x89\xe7\xb0\x3b\x0f\x05";

    (*(void (*)()) shellcode)();

    return 0;

} Compile it:

gcc -fno-stack-protector -z execstack -o ex2 ex.c

If run it returns a segmentation fault, but it should execute a shell. Why? Help is appreciated!

Have you checked that the `shellcode` array and its contents is actually put into the code segment, making it executable? — Some programmer dude, Sep 17 '17 at 16:57
I would guess because the memory doesn't have execute permission. — Steve, Sep 17 '17 at 16:58
Thanks for the replyes. I guess it has the permission to execute it as it was compiled with gcc -fno-stack-protector -z execstack -o ex2 ex.c — Ervin, Sep 17 '17 at 17:25
@fuz, that is unlikely to work because he hasn't made the data segment be executable, only the stack. — prl, Sep 17 '17 at 17:37
@prl can You tell me how to enable the stack to be executable? — Ervin, Sep 17 '17 at 17:38
gcc --version: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 — Ervin, Sep 17 '17 at 17:39
you can run `execstack -q ex2` to check that the executable is marked as requiring an executable stack. It should print `X`. — prl, Sep 17 '17 at 17:44
What is your problem? You invoke undefined behaviour and that's what you get. — too honest for this site, Sep 17 '17 at 19:17
Is there some reason to load rbx with "//bin/sh" and then shift right, discarding the extra leading '/'? — prl, Sep 17 '17 at 19:22

Petr Skocik · Accepted Answer · 2017-09-17T19:09:05.183

Your standalone assembly depends on registers rsi and rdx being zeroed. (As you can see from http://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64/ sys_execve takes three arguments through registers rdi, rsi, and rdx, and Linux will also accept it if rdi is a correct filename and rsi and rdx are zero).

This may be the case when the program starts, but it's not when you run the instructions from within the middle of a program.

Consequently if rsi, and rdx have garbage in them, the syscall will fail and the instruction stream will continue executing the garbage bytes it'll find after the syscall instruction, eventually leading to a crash (this is indeed, what's happening in your case, as you can see if you run the program through gdb)

The simplest way to make the syscall succeed is by zeroing out 2nd and the third argument:

section .text
  global _start

_start:
   xor rax, rax
   xor rsi, rsi ; zero 2nd argument
   xor rdx, rdx ; zero 3rd argument
   push rax
   mov rbx, 0x68732f6e69622f2f
   shr rbx, 0x8
   push rbx
   mov rdi, rsp

   mov al, 59
   syscall

Corresponding C code:

int main(void)
{
 char shellcode[] =

"\x48\x31\xc0\x48\x31\xd2\x48\x31\xf6\x50\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68\x48\xc1\xeb\x08\x53\x48\x89\xe7\xb0\x3b\x0f\x05"
;
    ((void (*)()) shellcode)();
    return 0;
}

Thank You for the help! I will dive into it deeper to figure out the problem with my code. — Ervin, Sep 17 '17 at 18:38
@PSk, It looks like this code is assuming that rax is 0? (It is used to push the null terminator for argv.) — prl, Sep 17 '17 at 18:42
@prl yup, it did. I changed it, though. Now I'm zeroing it explicitly and I'm also zeroing the 2nd and 3rd argument to execve, while keeping the rest of the code the same. That should replicate the conditions at the start of a process, which caused the standalone example to succeed unlike C example that embedded it. — Petr Skocik, Sep 17 '17 at 19:13
@PSkocik It is a really good explanation. I like it. Thank You for the help once again. — Ervin, Sep 18 '17 at 05:22

score 0 · Answer 2 · answered Sep 17 '17 at 18:08

0

You left out the \x6e.

This causes segv because the exec fails and there isn't a return after the syscall.

answered Sep 17 '17 at 18:08

prl

11,716
2
13
31

1

Adding the missing 6e doesn't fix the problem, though. – Petr Skocik Sep 17 '17 at 18:14
Yeah, I just reported the first error I found. Not surprising there are others. – prl Sep 17 '17 at 18:35
Thank You for the help. I did not know that i should add 6e to the end, but suprisingly it failed with the same error. It looks like the problem is in te execve call, and that is cousing the error, not the end of instructions. – Ervin Sep 17 '17 at 18:40
1

There are 3 problems: 1) the path "/bin/sh" is "/bi/sh"; 2) rsi and rdx are not initialized before the syscall; 3) there is no return after the syscall (so it causes segv when the execv fails). – prl Sep 17 '17 at 18:44
@prl The path is correct. – Petr Skocik Sep 17 '17 at 19:14
@PSk, in the original question, it is `\x2f\x2f\x62\x69\x2f\x73\x68`. – prl Sep 17 '17 at 19:19

Assembly works, but shellcode does not

2 Answers2