I am following the tutorial for ROP Primer, level0. 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:

(pyhton 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 which is outside from the mapped address space (according to gdb), si_addr in the above error message will contain this address. But id 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.

  • May be late to the party, but are you mprotect-ing the whole stack? The stack grows the "oppsite" way, so you need to mprotect the right part of the stack. Also the stack might be a different place when running in gdb versus outside. Run without and turn on core dumping, and load the dump in gdb afterwards. – Henrik Nordvik Apr 15 '17 at 6:20

Like any development process, bugs can be quite common and understanding them might not be so easy. That's why god invented 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.


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!)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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