ROP利用：向.data段写入触发SIGSEGV问题求助

Let's walk through why you're hitting that SIGSEGV and how to fix it step by step.

Common Causes & Fixes #

1. Target Memory Page Doesn't Have Write Permissions #

The most likely culprit is that the page containing 0x0000201c isn't marked as writable. Even though .data is supposed to be writable by default, sometimes memory mappings can have unexpected permissions (e.g., stripped binaries, custom linker configurations, or misconfigured segment flags).

How to verify:

• Run your vulnerable program, then check its memory mappings with:

  cat /proc/$(pidof your_vulnerable_program)/maps
  

• Locate the line that includes 0x201c. The second column shows the page permissions—you need to see rw- (read-write, no execute) or rwx. If it's r-- (read-only), that’s exactly why the write operation is failing.

Fix:

• Switch to a guaranteed writable memory region instead. The stack is almost always writable (look for the line labeled [stack] in the maps output) or the .bss segment (designed for uninitialized writable data, usually adjacent to .data). Adjust your ROP chain to calculate the address of one of these regions instead.

2. Your EAX Calculation Isn’t Actually Resulting in 0x201c #

Even though your math checks out on paper, it’s easy to have a mistake in gadget execution order or unintended register modifications during runtime.

How to verify:

• Use GDB to step through your ROP chain one gadget at a time:
  1. Set a breakpoint on the first gadget (xor eax, eax):

     b *0x<address_of_xor_eax_eax>
     

  2. Run the program and trigger the vulnerability.
  3. After each gadget executes, check the value of EAX with:

     info registers eax
     

• Confirm each step matches your expected value:
  • After xor eax, eax: eax = 0x0
  • After add eax, 0xd: eax = 0xd
  • After mov ah, 0x13: eax = 0x130d
  • After add ah, al: eax = 0x200d (since 0x13 + 0xd = 0x20)
  • After add eax, 0xf: eax = 0x201c

Fix:

• If any step doesn’t match, double-check that you’re using the correct gadget addresses. Sometimes gadgets can look similar but have subtle differences (e.g., an extra push/pop that modifies another register, or a typo in the gadget offset).

3. PIE/ASLR Is Confusing Absolute vs. Relative Addresses #

Wait, you mentioned <__data_start> is at 0x201c—is that an absolute address or a relative offset? If your binary is compiled with Position-Independent Executable (PIE) enabled, the base address of the binary is randomized at runtime, so 0x201c would be an offset from the base, not the absolute address.

How to verify:

• Check if your binary is PIE-enabled with:

  file your_vulnerable_program
  

• If the output includes "PIE", then you need to calculate the absolute .data address by adding the randomized base address (from /proc/[pid]/maps) to the offset 0x201c.

Fix:

• If PIE is enabled, adjust your ROP chain to first leak the binary’s base address (e.g., via a GOT entry leak) before calculating the absolute .data address.

Quick Debugging Tip #

When the SIGSEGV triggers, check the error code in GDB to get more context:

info signal SIGSEGV

• Error code 0x2 means you tried to write to read-only memory (confirms a permission issue).
• Error code 0x4 means the target address doesn’t exist at all (confirms an address calculation mistake).

内容的提问来源于stack exchange，提问作者Luigi