Fixing Incorrect rdi Value in ROP Exploit: Understanding Stack Padding in Buffer Overflow

Learn why your ROP payload fails to set the correct rdi value due to stack padding and how adjusting your payload solves the issue in buffer overflow exploits.
---
This video is based on the question https://stackoverflow.com/q/79511517/ asked by the user 'Ian Burns' ( https://stackoverflow.com/u/22500215/ ) and on the answer https://stackoverflow.com/a/79511801/ provided by the user 'Jester' ( https://stackoverflow.com/u/547981/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Attack Lab Phase 4: rdi gets the wrong value despite correct assembly being put on stack

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to drop me a comment under this video.
---
Introduction

When working on Return Oriented Programming (ROP) exploits, particularly in buffer overflow attack labs, it's crucial to understand how the stack frame affects gadget execution. A common pitfall is that your payload appears correct but the target register (rdi in x86-64) contains unexpected values, causing the exploit to fail.

The Problem

You set up a ROP chain with gadgets that:

popq %rax

movq %rax, %rdi

Call the function touch2

Your payload looks similar to a working example, but instead of the expected cookie value passed through rdi, touch2 sees a random or incorrect value. Debugging with GDB shows:

The stack contains your gadgets and payload.

After calling, $rdi holds an unexpected value (like 0x1).

Root Cause: Stack Frame Padding

Examining the vulnerable function getbuf reveals:

[[See Video to Reveal this Text or Code Snippet]]

The function creates a stack frame of 5 qwords (each 8 bytes, total 40 bytes) by subtracting 0x28 from %rsp before calling gets.

When ret is executed, it adds 0x28 back to %rsp, consuming the first 5 qwords of your payload.

Because your payload only includes 3 qwords of padding before the first gadget, the initial gadgets are swallowed by stack pointer adjustments and never executed.

Consequence

The popq %rax gadget is skipped.

%rax retains the value set in the getbuf function (mov $0x1, %eax), which then gets moved to %rdi by your second gadget.

This triggers touch2(0x1) instead of the intended touch2(cookie).

Solution: Adjust Your Payload Padding

You need to match the padding to the stack frame size:

Add 5 qwords (40 bytes) of padding before your ROP gadgets.

The first 5 qwords will be discarded by the add $0x28, %rsp in getbuf, ensuring your gadgets align correctly with the return address.

Revised Payload Structure

[[See Video to Reveal this Text or Code Snippet]]

By increasing the padding to 5 qwords, your gadgets will execute properly, and %rdi will contain the intended cookie value.

Summary

Always analyze the vulnerable function's prologue and epilogue to understand stack adjustments.

Ensure your payload’s padding aligns with the saved frame size.

Incorrect padding leads to skipped gadgets and incorrect register values.

This adjustment will fix your ROP exploit, allowing %rdi to hold the correct value and calling touch2 successfully.