> 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/01.-basics.md).

# Binary Exploitation — The Basics

> A beginner-friendly guide to understanding the core concepts before you write a single exploit.

## 📌 What Even Is Binary Exploitation?

When developers write code (usually in C or C++), it gets **compiled** into a binary — a raw executable file that the computer runs directly. Binary exploitation is the art of **finding bugs in these programs and abusing them** to make the program do something it wasn't supposed to do — like give you a shell, leak a secret, or crash in a controlled way.

Think of it like this: the developer built a house (the program), and you're looking for an unlocked window or a loose floorboard (a vulnerability) to get inside.

## 🗺️ The Memory Layout — Where Does Everything Live?

When a program runs, the operating system gives it a chunk of memory. That memory is divided into sections:

```
High addresses  ┌──────────────────┐
                │      Stack       │  ← Function calls, local variables
                │        ↓        │
                │                  │
                │        ↑        │
                │       Heap       │  ← Dynamic memory (malloc, new)
                ├──────────────────┤
                │       BSS        │  ← Uninitialized global variables
                ├──────────────────┤
                │      Data        │  ← Initialized global variables
                ├──────────────────┤
Low addresses   │      Text        │  ← The actual program code
                └──────────────────┘
```

### The Stack

The stack is the most important section to understand for beginners. It works like a stack of plates — **Last In, First Out (LIFO)**.

Every time a function is called, the program **pushes** a "stack frame" onto the stack containing:

* **Local variables** (things declared inside a function)
* The **return address** (where to go back after the function finishes)
* The **saved base pointer** (a bookmark to the previous frame)

When the function ends, the frame is **popped** off and control returns to the caller.

## 📐 What Is an Offset?

An **offset** is just a **distance in bytes** from one point in memory to another.

### Simple Analogy

Imagine a street with houses numbered 0, 1, 2, 3... If you're standing at house 10 and want to reach house 14, the offset is **4**.

### In Exploitation

Say you have a buffer (a chunk of memory) that starts at address `0x7fff1000`, and the return address is stored at `0x7fff1020`.

```
0x7fff1000  [ buffer starts here         ]
0x7fff1010  [                            ]
0x7fff1020  [ return address lives here  ]
```

The **offset from the buffer to the return address** is:

```
0x7fff1020 - 0x7fff1000 = 0x20 = 32 bytes
```

So you'd need to write **32 bytes of junk** before your payload reaches the return address.

### Finding the Offset in Practice

Tools like `pwndbg` + `cyclic` (from pwntools) help find offsets automatically:

```bash
# Generate a cyclic pattern
cyclic 100

# Run the program, let it crash, then check which part of the pattern landed in the return address
cyclic -l <value_in_rip>
```

## 📦 What Is a Buffer?

A **buffer** is just a **fixed-size chunk of memory** reserved to hold data — like an array.

```c
char name[64];  // A buffer that holds 64 bytes
```

The problem? If you try to put MORE than 64 bytes into it and the programmer didn't check, those extra bytes **overflow** into adjacent memory. That's called a **Buffer Overflow** — one of the most classic bugs in binary exploitation.

## 🔤 What Is a String (in binary context)?

In C, a string is just **a sequence of bytes in memory ending with a null byte** (`\x00`). There is no special "string type" — it's just bytes.

```
"Hello" in memory looks like:
48 65 6c 6c 6f 00
H  e  l  l  o  \0
```

### Why Does This Matter?

Many vulnerable functions in C (like `gets`, `strcpy`, `scanf`) **don't check how long the input is**. They just keep reading bytes until they hit a newline or null byte — meaning you can feed them way more data than the buffer can hold.

```c
char buf[32];
gets(buf);       // ← DANGEROUS: reads until newline, no length check
```

## 🏠 What Are Registers?

Registers are **tiny, super-fast storage locations inside the CPU** itself. On a 64-bit system (x86-64), the key ones to know are:

| Register            | Purpose                                                                    |
| ------------------- | -------------------------------------------------------------------------- |
| `rsp`               | Stack pointer — points to the TOP of the stack                             |
| `rbp`               | Base pointer — points to the BOTTOM of the current stack frame             |
| `rip`               | Instruction pointer — holds the address of the NEXT instruction to execute |
| `rax`               | Return value register                                                      |
| `rdi`, `rsi`, `rdx` | First, second, third function arguments                                    |

### The Golden Register: `rip`

If you can **control `rip`**, you control where the program goes next. That's the core goal of most binary exploits — overwrite the return address (which gets loaded into `rip`) to redirect execution.

## 🛡️ Common Protections (and What They Do)

Modern systems have defenses that make exploitation harder. You'll encounter these constantly:

### 1. ASLR — Address Space Layout Randomization

**What it does:** Randomizes the base addresses of the stack, heap, and libraries every time the program runs.

**Why it matters:** You can't hardcode an address in your exploit because it changes each run.

**Bypass idea:** Leak an address at runtime, then calculate where everything else is.

```bash
# Check if ASLR is on
cat /proc/sys/kernel/randomize_va_space
# 0 = off, 2 = full ASLR
```

### 2. NX / DEP — Non-Executable Stack

**What it does:** Marks the stack as non-executable, so you can't just inject shellcode and run it.

**Why it matters:** Classic "put shellcode in the buffer and jump to it" doesn't work.

**Bypass idea:** ROP (Return-Oriented Programming) — chain existing code already in the binary.

```bash
# Check with checksec
checksec --file=./vuln_program
```

### 3. Stack Canary

**What it does:** Places a secret random value between local variables and the return address. Before returning, the program checks if this value was changed.

**Why it matters:** A basic buffer overflow that overwrites the return address will also overwrite the canary, and the program will detect it and abort.

**Bypass idea:** Leak the canary value first, then include it correctly in your payload.

### 4. PIE — Position Independent Executable

**What it does:** Similar to ASLR but for the binary itself — the binary's own code is loaded at a random base address.

**Bypass idea:** Same as ASLR — leak a pointer from the binary, calculate the base.

***

## 🔢 Number Systems You Need to Know

Binary exploitation lives in **hex (base 16)**. Get comfortable with it.

| Decimal | Hex   | Binary      |
| ------- | ----- | ----------- |
| 0       | 0x00  | 0000 0000   |
| 10      | 0x0A  | 0000 1010   |
| 255     | 0xFF  | 1111 1111   |
| 256     | 0x100 | 1 0000 0000 |

### Endianness — The Byte Order Thing

On x86/x64 (most modern systems), values are stored in **little-endian** format — the **least significant byte comes first** in memory.

```
The value 0xdeadbeef stored in memory looks like:
ef be ad de
```

This matters when you're crafting payloads with addresses!

```python
# In pwntools, p64() handles this for you
from pwn import *
p64(0xdeadbeef)  # → b'\xef\xbe\xad\xde\x00\x00\x00\x00'
```

***

## 🧰 Essential Tools for Beginners

| Tool                | What It Does                                                    |
| ------------------- | --------------------------------------------------------------- |
| `gdb` + `pwndbg`    | Debugger — step through a program, inspect memory and registers |
| `pwntools`          | Python library for writing exploits                             |
| `checksec`          | Shows what protections a binary has                             |
| `file`              | Tells you the architecture and type of a binary                 |
| `strings`           | Extracts readable strings from a binary                         |
| `objdump`           | Disassembles a binary                                           |
| `readelf`           | Shows ELF binary structure info                                 |
| `ltrace` / `strace` | Traces library/system calls the program makes                   |

### Quick Start Commands

```bash
# What kind of binary is this?
file ./challenge

# What protections does it have?
checksec --file=./challenge

# Open in gdb with pwndbg
gdb ./challenge

# Inside gdb:
(gdb) run              # run the program
(gdb) info registers   # see all registers
(gdb) x/20gx $rsp      # examine 20 values on the stack
(gdb) disassemble main # disassemble the main function
```

## 📏 What Is a Payload?

A **payload** is the crafted input you send to the vulnerable program. It's usually made of:

1. **Padding** — junk bytes to fill up the buffer and reach the target (like a return address)
2. **The actual exploit data** — an address to jump to, shellcode, ROP chain, etc.

```
[  AAAAAAAAAA...AAA  ][  address_to_jump_to  ]
      padding               overwrite
   (fills the buffer)    (controls rip/eip)
```

In pwntools:

```python
from pwn import *

padding = b"A" * 40          # 40 bytes to reach return address
target  = p64(0x401234)      # address we want to jump to (little-endian)
payload = padding + target

p = process("./vuln")
p.sendline(payload)
p.interactive()
```

***

## 🗂️ Vulnerability Types — Quick Overview

| Vulnerability         | One-Line Description                                                 |
| --------------------- | -------------------------------------------------------------------- |
| **Buffer Overflow**   | Writing more data than a buffer can hold                             |
| **Format String**     | Abusing `printf`-style functions with user-controlled format strings |
| **Use After Free**    | Using a heap pointer after the memory it pointed to was freed        |
| **Integer Overflow**  | Math that wraps around and produces unexpected values                |
| **Command Injection** | Injecting shell commands through unsanitized input (see Part 2)      |
| **Off-by-One**        | Overwriting exactly one extra byte — often enough to hijack control  |

***

## 🧭 The General Exploit Workflow

```
1. Run the binary — understand what it does
         ↓
2. checksec — see what protections are enabled
         ↓
3. Find the vulnerability — static analysis (Ghidra/objdump) or fuzzing
         ↓
4. Figure out the offset — how many bytes to reach the target
         ↓
5. Find your primitive — shellcode? ROP chain? libc leak?
         ↓
6. Write the exploit in pwntools
         ↓
7. Test locally → adjust → test on remote
```

***

## 📚 Recommended Learning Path

1. **Learn C basics** — pointers, arrays, memory allocation
2. **Learn x86-64 assembly** — just enough to read disassembly
3. **Play with GDB** — get comfortable pausing and inspecting programs
4. **Do intro CTF challenges** — pwn.college, picoCTF, CTFlearn
5. **Read** — "Hacking: The Art of Exploitation" by Jon Erickson

***

> 💡 **Remember:** Binary exploitation is about *understanding*, not memorizing. Every time you're confused, open GDB and look at the actual memory. The answers are always there.


---

# 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/01.-basics.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.