Skip to content
Back to skills

Exploit Memory Corruption

ASecurity

Turn a memory-corruption bug in a native binary into code execution — stack overflows, format strings, and ROP against modern mitigations. Load when you control input to a compiled program and it crashes or misbehaves: a network daemon, a thick client, a setuid/SUID helper, or extracted firmware. Signals: segfault on long/`%n` input, a crash with control of a register, no source, checksec output, "exploit this binary/service".

  • 20 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 22, 2026
ai-agentsgoc++shelldatabase

Works with

  • cli

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add NoorQureshi/SploitAgent --skill exploit-memory-corruption --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Exploit Memory Corruption?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Exploit Memory Corruption
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/noorqureshi-exploit-memory-corruption/badge)](https://www.skillsdirectory.com/skills/noorqureshi-exploit-memory-corruption)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: exploit-memory-corruption
description: >
  Turn a memory-corruption bug in a native binary into code execution — stack overflows, format
  strings, and ROP against modern mitigations. Load when you control input to a compiled program and
  it crashes or misbehaves: a network daemon, a thick client, a setuid/SUID helper, or extracted
  firmware. Signals: segfault on long/`%n` input, a crash with control of a register, no source,
  checksec output, "exploit this binary/service".
domain: exploit-dev
type: technique
stability: learning
modes: [pentest]
severity: critical
mitre: [T1203]
cwe: [CWE-121, CWE-134, CWE-787, CWE-416]
tools: [pwntools, gdb-gef, ropgadget, ropper, one_gadget]
schema_version: 1
---

# Memory-corruption exploitation

## When it applies
You have a native binary or service on an authorized target that mishandles your input — a
network-facing daemon, a thick-client, a setuid helper found during `privesc`, or a binary carved
from firmware (`reverse-eng-firmware`). `reverse-eng-binary-triage` located the bug; this skill turns
that crash into controlled execution. Pentest-only — this is destructive and can crash the service.

## Why it works
C/C++ has no memory safety: writing past a buffer overwrites saved return addresses and pointers, and
a user-controlled format string reads/writes arbitrary memory. Redirect execution to your code or to
existing code (ROP) and the process does your bidding. Modern mitigations (NX, ASLR, PIE, stack
canaries) don't remove the bug — they shape the technique.

## Method
1. **Check protections first** — `checksec ./bin` (or `pwntools`): NX, PIE, RELRO, canary. This
   decides everything. No canary + NX → ROP; PIE → you need a leak; no PIE, no NX → maybe shellcode.
2. **Find the offset** — send a cyclic pattern (`cyclic 200` / pattern_create), crash it under
   `gdb`+GEF/pwndbg, read the value in `$rip`/`$eip`, and `cyclic -l <value>` for the exact offset to
   the saved return address.
3. **Pick the primitive by protections:**
   - **ret2win** — a target function already in the binary; overwrite the return address with it.
   - **ret2libc / ROP** — with NX, chain gadgets: leak a libc address (call `puts(puts@got)` via the
     PLT), compute the libc base, return to `system("/bin/sh")` or a `one_gadget`. Build gadgets with
     `ROPgadget`/`ropper`, the chain with `pwntools` `ROP()`.
   - **Format string** (`printf(user)`) — leak stack/canary/PIE base with `%p`, then do arbitrary
     writes with `%n` (GOT overwrite → redirect a call to `system`). `fmtstr_payload` automates it.
4. **Defeat mitigations with leaks** — ASLR/PIE need a leaked address (from a format string or an
   info-leak bug) to rebase; a stack canary must be leaked (or brute-forced byte-by-byte on a forking
   server) and replayed in your overflow so the check passes.
5. **Build it with pwntools** — a repeatable script: `process()`/`remote()`, `recvuntil`, pack with
   `p64()`, stage the leak, then send the final chain; iterate locally, then fire at the target.
6. **Land a shell** — reuse `payloads-reverse-shells` for what to run once you have execution.

## Gotchas
- **Match the exact libc** — remote exploitation fails on the wrong libc version/offsets; identify it
  (leaked addresses → a libc-database lookup) before computing `system`/`one_gadget`.
- **Bad bytes** — `\x00`, `\x0a`, `\x20` can truncate input depending on the read function; check and
  avoid them in addresses/payload.
- **Local works, remote doesn't** — environment/stack alignment differs; the `movaps` alignment crash
  before `system` is fixed by an extra `ret` gadget.
- **This crashes the target** — it's inherently disruptive; only on authorized pentest targets, never
  a live bug-bounty production service, and note the risk in the RoE.

## Verify success
Reliable control of execution demonstrated on the target — a returned shell, a run command, or a
controlled `$rip` with a working ROP chain — reproducible from your pwntools script.

## References
pwntools docs & tutorials; `checksec`; GEF/pwndbg; ROPgadget/ropper; `one_gadget`; libc-database.
Find the bug with `reverse-eng-binary-triage`; shell payloads in `payloads-reverse-shells`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…