PT0-002 Practice Question: A penetration tester is writing a return-oriented…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The library must be loaded at a fixed address

  Why this is correct

  A ROP chain requires the attacker to hardcode the addresses of gadgets, which are sequences of instructions ending in `ret`. If the target library (such as libc) is loaded at a predictable, fixed base address because ASLR is disabled for that library, the attacker can compute the exact runtime addresses of those gadgets in advance. This makes the exploit reliable across reboots and processes, even if the main executable's own ASLR is enabled, because the chain never needs to reference the main binary's addresses.

• ✗

  The stack must be executable

  Why it's wrong here

  ROP is specifically a defense against Data Execution Prevention (DEP), also known as NX, which marks the stack as non-executable. If the stack were executable, the attacker could simply place shellcode on the stack and jump to it, eliminating the need for ROP entirely. ROP instead dereferences return addresses already on the stack, causing the CPU to `ret` into existing code within executable memory regions, while the stack itself remains non-executable throughout the exploit.

• ✗

  The binary must be compiled with stack canaries

  Why it's wrong here

  Stack canaries are a compile-time defense against stack buffer overflows, placing a random value between the buffer and the saved return address. They do not prevent ROP execution; they only attempt to detect the overflow before the function returns. An attacker can bypass canaries by leaking the canary value through another vulnerability, or by targeting a buffer that is not directly adjacent to a canary, so the presence of canaries is irrelevant to whether ROP can be executed.

• ✗

  The exploit must bypass ASLR for the main binary

  Why it's wrong here

  The ROP chain relies on gadget addresses in the library, not in the main binary. If the library is loaded at a fixed, non-ASLR base, those gadget addresses are stable regardless of whether the main executable uses ASLR. The main binary's ASLR would only randomize its own text, data, and stack regions, none of which are used as return-to-program destinations in the chain, so bypassing the main binary's ASLR is not a requirement.