Exploit Development Guidance

Exploit Development Guidance

Auto-loads: When developing exploits or analyzing exploitation feasibility

Token cost: ~600 tokens

Purpose: Verify constraints before attempting techniques, avoid wasted effort

Core Principle

Verify constraints BEFORE attempting any exploit technique.

Many hours can be wasted attempting techniques that are architecturally impossible. Check constraints first, then choose appropriate techniques.

Using RAPTOR's Mitigation Analysis

Run mitigation analysis FIRST. Check the output for:

TECHNIQUE VIABILITY
----------------------------------------
  BLOCKED (don't waste time on these):
    ✗ strcpy multi-gadget ROP
    ✗ strcpy ret2libc chain (pop_rdi + bin_sh + system)

  VIABLE (focus here):
    ✓ format string %n writes
    ✓ partial overwrite
    ✓ single gadget redirect (one_gadget)

Key fields in analysis result:

• result['input_handlers'] - Detected input functions (strcpy, fgets, etc.)
• result['constraints']['blocked_techniques'] - Don't waste time on these
• result['constraints']['viable_techniques'] - Focus here
• result['constraints']['input_handler'] - Which handler drove the constraints

Constraint Checklist

1. Bad Bytes

What bytes cannot appear in the payload?

2. Architecture

x86_64 null byte pitfall: Userland addresses are 0x00007fff... format. In little-endian memory: 78 56 34 12 ff 7f 00 00. The null bytes are at offsets 6-7. String functions copy low bytes first, then stop at null - so only 6 bytes of an address can be written via strcpy.

3. Protections

4. Primitives Needed

Vulnerability Class Quick Reference

Format String

• Read: %p leaks stack values, %s reads from pointer on stack
• Write: %n writes byte count to address on stack
• Bypass null bytes: Write address using multiple %hhn (one byte each)
• Key insight: Format string CAN write null bytes; strcpy overflow CANNOT

Stack Buffer Overflow

• With NX: ROP chain, ret2libc
• Without NX: Shellcode on stack, jump to it
• With canary: Leak canary first (format string, separate bug)
• x86_64 + strcpy: Can only write ONE gadget address (null byte issue)

Heap Exploitation

• tcache (glibc 2.26+): tcache poisoning, double-free
• fastbin: Fastbin dup, House of Spirit
• Unsorted bin: Unsorted bin attack, House of Orange
• Key: Know your glibc version - techniques vary significantly

Use-After-Free

• Object replacement: Allocate controlled data in freed slot
• Vtable hijack: Replace C++ vtable pointer
• Function pointer: Overwrite function pointer in struct

When Technique A is Blocked

IMPORTANT: Full RELRO typically blocks BOTH GOT AND .fini_array (standard linker scripts place both in the RELRO segment). Do NOT suggest .fini_array when Full RELRO is enabled.

Testing Methodology

1. Verify assumptions: Use GDB/pwndbg to check actual memory layout
2. Test constraints empirically: Send payload with suspect bytes, observe behavior
3. Check versions: ldd --version for glibc, actual offsets vary by version
4. Iterate: Exploit development is rarely first-try; debug and refine

Common Mistakes

1. Assuming technique works without checking constraints
2. Forgetting endianness when constructing addresses
3. Not accounting for stack alignment requirements (x86_64: 16-byte before call)
4. Using offsets from wrong libc/binary version
5. Overlooking simpler alternatives when complex technique is blocked