862 Exploit Guidance Ac8d69a7

# 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?

| Input Handler | Bad Bytes | Notes |
|---------------|-----------|-------|
| strcpy, strcat, sprintf | `0x00` | Null terminates |
| fgets, gets | `0x00`, `0x0a` | Null and newline |
| scanf %s | `0x00`, `0x09-0x0d`, `0x20` | Null and whitespace |
| read, recv | None (binary safe) | Length-limited only |

### 2. Architecture
| Property | x86 (32-bit) | x86_64 (64-bit) | ARM | ARM64 |
|----------|--------------|-----------------|-----|-------|
| Pointer size | 4 bytes | 8 bytes | 4 bytes | 8 bytes |
| Endianness | Little | Little | Usually little | Usually little |
| Stack growth | Down | Down | Down | Down |
| Calling convention | Stack args | RDI, RSI, RDX, RCX, R8, R9 | R0-R3 | X0-X7 |
| Address null bytes | Rare | Always (bytes 6-7) | Varies | Common |

**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
| Protection | Impact | Bypass |
|------------|--------|--------|
| NX | No shellcode on stack/heap | ROP, ret2libc |
| ASLR | Randomized addresses | Info leak, partial overwrite, brute force |
| PIE | Randomized binary base | Info leak for binary addresses |
| Stack canary | Detects stack overflow | Leak canary, format string, or skip it |
| Full RELRO | GOT read-only | Target other writable areas |
| Partial RELRO | GOT writable | Overwrite GOT entries |

### 4. Primitives Needed
| Primitive | Description | Common Sources |
|-----------|-------------|----------------|
| Arbitrary write | Write controlled value to controlled address | Format string %n, heap overflow |
| Arbitrary read | Read from controlled address | Format string %s, OOB read |
| Info leak | Disclose addresses/canary | Format string %p, uninitialized memory |
| Control RIP | Redirect execution | Stack overflow, GOT overwrite, vtable |

---

## 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

| Blocked | Try Instead |
|---------|-------------|
| Multi-gadget ROP (null bytes) | Format string %n writes, partial overwrite, one-gadget |
| GOT overwrite (Full RELRO) | Stack return address, __exit_funcs (needs PTR_DEMANGLE bypass) |
| Stack shellcode (NX) | ROP, ret2libc, mprotect to make region executable |
| Direct address (ASLR/PIE) | Leak addresses first, partial overwrite, brute force |
| Large payload (length limit) | Staged payload, reuse existing code |

**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