Skip to content
krishnanv1990 edited this page Nov 22, 2016 · 17 revisions

https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-Slides.pdf

http://css.csail.mit.edu/6.858/2015/projects/je25365-ve25411.pdf

  • assembly instructions leading to general syscall invocation

  • mprotect - http://reverseengineering.stackexchange.com/questions/9336/can-mprotect-set-the-stack-itself-as-executable

  • finding gadgets

  • understanding of some gadget finding and rop payload generation tool

  • avoidance of null, space, newline and tab chars in rop payload

  • classification of gadgets

  • a proper python framework for disassembling a binary and obtaining instructions (distorm, for now).

  • getting absolute addresses of gadgets

  • do we need to go by general method or specific to mprotect

We will use the filebytes python module for parsing elfheader and capstone for disassembly. https://github.com/sashs/filebytes

Please look at the links below, and also at the proposed stack layout for our gadgets :-

https://software.intel.com/en-us/forums/virtualization-software-development/topic/499263 http://articles.manugarg.com/systemcallinlinux2_6.html

The disassembly of mprotect in gdb does not have an int x80 instruction. Rather it uses call DWORD PTR gs:0x10. If we have libc linked with our binary, then we can directly make use of the mprotect libc function. Otherwise we have to understand how to make use of a syscall gadget to invoke mprotect. And, it seems now there is a new syscall convention that does not use int 0x80, but uses the global descriptor table or something.

PROPOSED STACK LAYOUT

esp low ------------> high

| junk | shellcode | &mprotect | &(pop pop pop ret) | mp_arg1 | mp_arg2 | mp_arg3 | shellcode_addr |

mp_arg1 is the start address of the aligned memory. mp_arg2 is the length, and mp_arg3 is 0x7 (for RWX)

We have to ensure that shellcode starts at an aligned memory location or prepend it with a NOP sled.

If we can use libc, then it is straight-forward. Otherwise, we have to think about the syscall convention and find the necessary gadgets. mprotect syscall number is 0x7d. For syscalls, it seems the arguments are passed through registers (even for 32-bit). So if we are planning to use syscall gadget instead of mprotect function, then the above stack layout will not be valid.