> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/HackTricks-wiki/hacktricks/llms.txt
> Use this file to discover all available pages before exploring further.

# Binary Exploitation Overview

> Introduction to binary exploitation techniques, common memory protections, and the methodology used to find and exploit vulnerabilities in compiled programs.

Binary exploitation covers the craft of finding and abusing memory-corruption vulnerabilities in compiled programs to redirect execution, leak data, or gain arbitrary code execution. This section walks through the most important primitives and protections you will encounter.

## What is binary exploitation?

When a program mishandles memory — reads or writes past the end of a buffer, uses freed memory, or misinterprets attacker-controlled data — an attacker may be able to overwrite sensitive structures such as return addresses, function pointers, or heap metadata to redirect execution flow.

The core goal is almost always the same: **control the instruction pointer** (EIP/RIP on x86, LR/PC on ARM) so arbitrary code runs in the context of the target process.

## Key vulnerability classes

<CardGroup cols={2}>
  <Card title="Stack Overflow" icon="layer-group" href="/binary-exploitation/stack-overflow">
    Writing past the end of a stack buffer, overwriting the saved return address and achieving control flow hijacking.
  </Card>

  <Card title="Return-Oriented Programming" icon="arrow-right-arrow-left" href="/binary-exploitation/return-oriented-programming">
    Chaining existing code gadgets to build arbitrary computation without injecting new code.
  </Card>

  <Card title="Heap Exploitation" icon="database" href="/binary-exploitation/heap-exploitation">
    Abusing allocator internals — use-after-free, double-free, and bin attacks — to redirect execution or corrupt data.
  </Card>

  <Card title="Format String" icon="code" href="/binary-exploitation/stack-overflow">
    Exploiting unchecked `printf`-family calls to read from or write to arbitrary memory addresses. See stack-based techniques for exploitation primitives.
  </Card>
</CardGroup>

## Common binary protections

Modern toolchains and operating systems ship several mitigations. Understanding them is prerequisite to defeating them.

<AccordionGroup>
  <Accordion title="Stack Canaries">
    A randomised value placed between the local variables and the saved return address. Before the function returns, the runtime checks that the canary is intact. Any linear stack overflow that overwrites the return address will corrupt the canary and trigger an abort.

    **Bypasses**: information leak to read the canary, bruteforcing in forking servers (one byte at a time), or exploits that skip the canary entirely (e.g., format strings targeting the return address directly).
  </Accordion>

  <Accordion title="ASLR — Address Space Layout Randomisation">
    The OS randomises the base addresses of the stack, heap, and shared libraries on each execution. Without knowing where code lives an attacker cannot hardcode gadget addresses.

    **Bypasses**: information leaks (format strings, partial overwrites), brute force (32-bit), or targets with ASLR disabled.
  </Accordion>

  <Accordion title="NX / DEP — Non-Executable Stack">
    Pages are marked either writable or executable but not both. Shellcode placed on the stack cannot be directly executed.

    **Bypass**: Return-Oriented Programming (ROP) — reuse existing executable code.
  </Accordion>

  <Accordion title="PIE — Position Independent Executable">
    The main binary itself is loaded at a randomised base address (like a shared library), extending ASLR to the executable's own code and GOT.

    **Bypasses**: information leak of a code pointer, partial overwrites using only the low bytes of an address.
  </Accordion>

  <Accordion title="RELRO — Relocation Read-Only">
    Full RELRO makes the GOT (Global Offset Table) read-only after dynamic linking, preventing overwrite attacks that redirect PLT calls.

    Partial RELRO only protects some segments; full RELRO is the stronger form.
  </Accordion>
</AccordionGroup>

## Enabling core dumps for debugging

When developing or analysing an exploit, core files capture the exact memory state of a crashed process.

```bash theme={null}
# Allow unlimited core dump size for the current session
ulimit -c unlimited

# Analyse a core file with GDB
gdb /path/to/binary /path/to/core_file
```

For a persistent setting, add the following to `/etc/security/limits.conf`:

```text theme={null}
* soft core unlimited
```

## Exploit development workflow

<Steps>
  <Step title="Identify the vulnerability">
    Fuzz the target, review source code, or reverse engineer to find where user input can overflow a buffer, trigger a use-after-free, or cause another memory error.
  </Step>

  <Step title="Determine what you control">
    Work out which registers or memory locations you can influence and to what extent. A De Bruijn sequence (cyclic pattern) is the standard way to measure the exact offset to the return address.
  </Step>

  <Step title="Audit protections">
    Run `checksec` on the binary to enumerate enabled mitigations.

    ```bash theme={null}
    checksec --file=./target
    ```
  </Step>

  <Step title="Plan a bypass chain">
    Select the appropriate technique for the protection set: ROP for NX, info-leak for ASLR/PIE, heap grooming for canary bypass in forking servers, and so on.
  </Step>

  <Step title="Write and iterate the exploit">
    Use `pwntools` to automate interaction, build ROP chains, and pack addresses. Test locally then adapt for the remote target.
  </Step>
</Steps>

## Essential tools

| Tool                     | Purpose                                                                         |
| ------------------------ | ------------------------------------------------------------------------------- |
| `pwntools`               | Python exploit-development framework — packing, ROP, process/socket interaction |
| `GDB` + `GEF` / `pwndbg` | Dynamic analysis with heap visualisation and pattern generation                 |
| `ROPgadget` / `ropper`   | Static gadget search in ELF binaries and libraries                              |
| `checksec`               | Enumerate binary protections                                                    |
| `ltrace` / `strace`      | Trace library and system calls at runtime                                       |
| Ghidra / IDA             | Reverse engineering and static analysis                                         |

<Note>
  All the techniques in this section assume a Linux/ELF target unless stated otherwise. Windows exploitation (SEH overflows, WoW64, kernel) is covered under the platform-specific pages.
</Note>