Performing Return-Oriented Programming

When to Use

• During authorized exploitation when you control the saved return address (via stack overflow, write-what-where, etc.) but NX/DEP prevents executing injected shellcode on the stack.
• When you need to call an existing function (system, execve, mprotect) or invoke a syscall with attacker-chosen arguments by chaining small ...; ret gadgets.
• When choosing between ret2libc (call a libc function), ret2syscall (raw sys_execve, common in static binaries), ret2dlresolve, SROP (when gadgets are scarce), or stack pivoting (off-by-one / short overflows).
• On ARM64 targets where ret jumps to x30 and instructions cannot be entered mid-instruction, requiring JOP or pivot-based approaches.

Critical: Concepts/Steps Most Often Missed

• 16-byte stack alignment on x86-64. The SysV ABI requires RSP be 16-byte aligned at a call. libc functions use SSE (movaps) and will SIGSEGV if misaligned. If system() crashes inside libc, insert a bare ret gadget before it to realign. This is the single most common reason a "correct" chain crashes.
• Argument passing differs by arch/ABI. x86 cdecl pushes args on the stack (right-to-left); x86-64 SysV uses RDI, RSI, RDX, RCX, R8, R9; Windows x64 uses RCX, RDX, R8, R9. You need pop rdi; ret-style gadgets to load registers, not just stack values.
• The function needs a return slot. After system you must place a return address (e.g. exit) or the chain crashes on system's own return. CTFs often get away with garbage, real targets do not.
• ARM64 entry-point pitfall. When jumping to a function via ROP on ARM64, jump to the function's second instruction to avoid re-storing the stack pointer and looping forever.
• NUL bytes and bad chars in gadget addresses. A pop rdi; ret gadget at 0x400686 is fine, but addresses with NULs break string-copy overflows. Pick alternate gadgets or use ret2dlresolve/SROP.