ctf-pwn

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 81890607feb9 · 20 Oct 2026Report an issue or request a re-scan

• Publishercyberkaida GitHub userOwner of the repository this skill is read from
• Source foldercyberkaida/reverse-engineering-assistant/ReVa/skills/ctf-pwnThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict81890607feb9A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Solve CTF binary exploitation challenges by discovering and exploiting memory corruption vulnerabilities to read flags. Use for buffer overflows, format strings, heap exploits, ROP challenges, or any pwn/exploitation…

---
name: ctf-pwn
description: Solve CTF binary exploitation challenges by discovering and exploiting memory corruption vulnerabilities to read flags. Use for buffer overflows, format strings, heap exploits, ROP challenges, or any pwn/exploitation task.
---

# CTF Binary Exploitation (Pwn)

## Purpose

You are a CTF binary exploitation specialist. Your goal is to **discover memory corruption vulnerabilities** and **exploit them to read flags** through systematic vulnerability analysis and creative exploitation thinking.

This is a **generic exploitation framework** - adapt these concepts to any vulnerability type you encounter. Focus on understanding **why** memory corruption happens and **how** to manipulate it, not just recognizing specific bug classes.

## Conceptual Framework

### The Exploitation Mindset

**Think in three layers:**

1. **Data Flow Layer**: Where does attacker-controlled data go?
   - Input sources: stdin, network, files, environment, arguments
   - Data destinations: stack buffers, heap allocations, global variables
   - Transformations: parsing, copying, formatting, decoding

2. **Memory Safety Layer**: What assumptions does the program make?
   - Buffer boundaries: Fixed-size arrays, allocation sizes
   - Type safety: Integer types, pointer validity, structure layouts
   - Control flow integrity: Return addresses, function pointers, vtables

3. **Exploitation Layer**: How can we violate trust boundaries?
   - Memory writes: Overwrite critical data (return addresses, function pointers, flags)
   - Memory reads: Leak information (addresses, canaries, pointer values)
   - Control flow hijacking: Redirect execution to attacker-controlled locations
   - Logic manipulation: Change program state to skip checks or trigger unintended paths

### Core Question Sequence

For every CTF pwn challenge, ask these questions **in order**:

1. **What data do I control?**
   - Function parameters, user input, file contents, environment variables
   - How much data? What format? Any restrictions (printable chars, null bytes)?

2. **Where does my data go in memory?**
   - Stack buffers? Heap allocations? Global variables?
   - What's the size of the destination? Is it checked?

3. **What interesting data is nearby in memory?**
   - Return addresses (stack)
   - Function pointers (heap, GOT/PLT, vtables)
   - Security flags or permission variables
   - Other buffers (to leak or corrupt)

4. **What happens if I send more data than expected?**
   - Buffer overflow: Overwrite adjacent memory
   - Identify what gets overwritten (use pattern generation)
   - Determine offset to critical data

5. **What can I overwrite to change program behavior?**
   - Return address → redirect execution on function return
   - Function pointer → redirect execution on indirect call
   - GOT/PLT entry → redirect library function calls
   - Variable value → bypass checks, unlock features

6. **Where can I redirect execution?**
   - Existing code: system(), exec(), one_gadget
   - Leaked addresses: libc functions
   - Injected code: shellcode (if DEP/NX disabled)
   - ROP chains: reuse existing code fragments

7. **How do I read the flag?**
   - Direct: Call system("/bin/cat flag.txt") or open()/read()/write()
   - Shell: Call system("/bin/sh") and interact
   - Leak: Read flag into buffer, leak buffer contents

## Core Methodologies

### Vulnerability Discovery

**Unsafe API Pattern Recognition:**

Identify dangerous functions that don't enforce bounds:
- **Unbounded copies**: strcpy, strcat, sprintf, gets
- **Underspecified bounds**: read(), recv(), scanf("%s"), strncpy (no null termination)
- **Format string bugs**: printf(user_input), fprintf(fp, user_input)
- **Integer overflows**: malloc(user_size), buffer[user_index], length calculations

**Investigation strategy:**
1. `get-symbols` includeExternal=true → Find unsafe API imports
2. `find-cross-references` to unsafe functions → Locate usage points
3. `get-decompilation` with includeContext=true → Analyze calling context
4. Trace data flow from input to unsafe operation

**Stack Layout Analysis:**

Understand memory organization:
```
High addresses
├── Function arguments
├── Return address         ← Critical target for overflow
├── Saved frame pointer
├── Local variables        ← Vulnerable buffers here
├── Compiler canaries      ← Stack protection (if enabled)
└── Padding/alignment
Low addresses
```

**Investigation strategy:**
1. `get-decompilation` of vulnerable function → See local variable layout
2. Estimate offsets: buffer → saved registers → return address
3. `set-bookmark` type="Analysis" category="Vulnerability" at overflow site
4. `set-decompilation-comment` documenting buffer size and adjacent targets

**Heap Exploitation Patterns:**

Heap vulnerabilities differ from stack:
- **Use-after-free**: Access freed memory (dangling pointers)
- **Double-free**: Free same memory twice (corrupt allocator metadata)
- **Heap overflow**: Overflow into adjacent heap chunk (overwrite metadata/data)
- **Type confusion**: Use object as wrong type after reallocation

**Investigation strategy:**
1. `search-decompilation` pattern="(malloc|free|realloc)" → Find heap operations
2. Trace pointer lifecycle: allocation → use → free
3. Look for dangling pointer usage after free
4. Identify adjacent allocations (overflow targets)

### Memory Layout Understanding

**Address Space Discovery:**

Map the binary's memory:
1. `get-memory-blocks` → See sections (.text, .data, .bss, heap, stack)
2. Note executable sections (shellcode candidates if NX disabled)
3. Note writable sections (data corruption targets)
4. Identify ASLR status (addresses randomized each run?)

**Offsets and Distances:**

Calculate critical distances:
- Buffer to return address: For stack overflow payload sizing
- GOT to PLT: For GOT overwrite attacks
- Heap chunk to chunk: For heap overflow targeting
- libc base to useful functions: For address calculation after leak

**Investigation strategy:**
1. `get-d

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/cyberkaida/reverse-engineering-assistant
git -C reverse-engineering-assistant checkout 81890607feb9

Works in

1. 2026-10-20
   ✓SAFE B 89 / 100

   first audit · source 81890607feb9

Questions about ctf-pwn

• github.com/cyberkaida/reverse-engineering-assistant/tree/main/Re — the audited source at commit 81890607feb9 and every finding aboveObserved · 20 Oct 2026

Spotted something wrong? Report a correction · Methodology