PT0-002 Practice Question: A penetration tester is attempting to exploit a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Inject shellcode into the buffer and redirect execution to it

  Why it's wrong here

  Injecting raw shellcode into the buffer and overwriting the return address to point directly at that buffer fails because Data Execution Prevention (DEP/NX) marks the stack and heap as non-executable memory regions. When the CPU attempts to fetch an instruction from a non-executable page, a hardware exception (STATUS_ACCESS_VIOLATION on Windows, SIGSEGV on Linux) is raised, terminating the process. Even though the shellcode resides at a predictable address and the overflow succeeds, the processor refuses to execute it, making this technique ineffective in a DEP-enabled environment.

• ✗

  Use a ROP chain to call mprotect() to make the stack executable, then jump to shellcode

  Why it's wrong here

  Since ASLR is disabled, the attacker can use a Ret2Libc attack to jump directly to existing library functions like system() without needing to modify memory permissions. Using mprotect() to bypass DEP via ROP chains is required only when the attacker must execute custom shellcode residing on the stack or heap. In this scenario, bypassing DEP by making memory executable adds unnecessary complexity when direct function calls are possible due to known static addresses.

• ✓

  Perform a return-to-libc attack to call system("/bin/sh")

  Why this is correct

  A return-to-libc (ret2libc) attack is correct because it bypasses DEP by reusing existing executable code from the C standard library instead of injecting instructions. Since ASLR is disabled, the base address of libc and the offset of the system() function are known, so the attacker can overwrite the saved return address with the address of system() and place a pointer to the string "/bin/sh" at the appropriate stack position to be interpreted as system()'s argument. This causes the process to call system("/bin/sh") directly from executable memory, completely avoiding the non-executable stack while achieving arbitrary command execution.

• ✗

  Use a heap spray to place shellcode at a known address and then trigger the overflow

  Why it's wrong here

  A heap spray does not address Data Execution Prevention (DEP); it is primarily a technique to defeat Address Space Layout Randomization (ASLR) by filling large portions of the heap with a NOP sled and shellcode, increasing the chance that a jump lands somewhere in the sled. Even if a predictable address is achieved, DEP still marks the heap as non-executable, so any attempt to execute the sprayed shellcode will trigger the same hardware exception as stack injection. Unless the heap is explicitly mapped with executable permissions, which modern systems do not do, heap spraying remains useless against DEP alone and is therefore the wrong choice here.