Finding a place to inject shellcode

Question

I am following the tutorial for ROP Primer, level 0. The tutorial sets the memory at the beginning of [vdso] writeable and executable and copies the shellcode there.

I do not know why, but it seems that mprotect fails for me:

(python exp.py; cat) | strace ./level0
...
mprotect(0xb7fff000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xa7fff804} ---
+++ killed by SIGSEGV +++

I changed the target address to 0x8048000 (got with vmmap in gdb-peda). Now mprotect does not return -1, but I still receive SIGSEGV:

(pyhton exp.py; cat) | strace ./level0
...
mprotect(0x8048000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x88048804} ---
+++ killed by SIGSEGV +++

I have examined memory addresses, the single difference from the tutorial was that the shellcode ended up at 0xbfff764 instead of 0xbfff754, and I adjusted the python script accordingly.

I do not understand why I am getting these errors, especially because I am using a downloaded virtual machine. How can I get the shellcode run?

UPDATE: I do not know if it has anything to do with the problem, but if I set a target address for mprotect (and later I expect eip to point there too) to an address that is outside from the mapped address space (according to gdb), si_addr in the above error message will contain this address. But if the address belongs to the program's address space, si_addr will be different (and probably invalid), like above.

And if I execute it in gdb the region is set properly executable, and even the shellcode is executed.

Answer 1

I'm not sure if this will help, but, if you're ever unsure whether or not shellcode is trying to run, try setting your shellcode to either "\xeb\xfe" (jmp -2) or "\xcc" / "\xcd\x03" (both are int 0x03).

In the first case, the program will hang till it receives a signal (like, you kill it). In the latter cases, the program will die with a debug / tracepoint. That makes it really obvious whether or not it's working (it also works super well against remote servers, assuming an infinite loop will automatically get killed, to verify whether or not your code is actually running!)

Answer 2

Like any development process, bugs can be quite common and understanding them might not be so easy. That's why god created debugging. You should run your exercise program under a debugger and follow through the exploitation process in order to find out what and where things go sideways.

Without any additional information it's quite hard to guess what's the issue there. I suggest you post your conclusions of debugging the exploit and we can further answer your question.