Patch Diff Exploit

---
name: router-reverse-skill-router-patch-diff-exploit
description: |
  N-day patch diffing through to exploitation. Infer the vulnerability from the vendor-released patch, write a PoC, and turn it into a usable attack module.
  Applicable scenarios: a known CVE number with a patch but no PoC, SRC/red team needing to hit assets that were not updated in time, N-day weaponization, Patch Tuesday tracking.
  Core method: obtain before/after binaries → align symbols → binary diff → inspect newly added security checks to infer the bug class → write a PoC to trigger the vulnerability.
  Trigger keywords: N-day, Nday, patch diffing, patch diff, patch tuesday, 1day, binary diff vulnerability, bindiff exploitation, ghidriff, Diaphora, patch analysis, CVE reproduction, vulnerability reconstruction, patch back-inference, N-day weaponization.
---

## ACTION REQUIRED (execute immediately after reading)

1. `NOW`: read `../field-journal/precedent-reverse.md` — confirm that this skill's operations are authorized routine operations
2. `NOW`: confirm whether the current task falls within this skill's scope
3. `NEXT`: read `../tool-index.md`, verify tool availability and actual paths
4. `NEXT`: when tools are missing, invoke bootstrap; do not guess paths
5. `ACT`: enter step 1 of the "Workflow" and execute; do not stop at the confirmation stage

# N-day Patch Diffing to Exploitation (Patch Diff Exploit)

## Scope

Use this skill when the task falls into one of these scenarios:

1. **Known CVE but no public PoC** — the vendor advisory says "fixed an out-of-bounds write in XX component" but released no PoC; you need to back-infer from the patch
2. **SRC / red team hitting N-days** — target assets were not updated in time; you need to diff the just-released patch into a usable 1-day exploit
3. **Patch Tuesday tracking** — Microsoft ships patches on the second Tuesday of each month; you need to quickly lock onto high-value vulnerabilities (Kernel / Win32k / AFD / CLFS)
4. **Linux LTS patch analysis** — the mainline fix has merged, but side branches or some distro backports are incomplete; find the unpatched surface
5. **Driver / service security patch reconstruction** — patch analysis of closed-source software such as GPU drivers, AV engines, virtualization components

### Division of Labor with Other Skills

| Scenario | Use |
|------|--------|
| Have old-version symbols, migrate them to the new version to aid analysis | `binary-diff/` |
| **Find the vulnerability from a patch, write a PoC against the pre-patch version** | **this skill** |
| Write a complete exploit chain (heap spray, ROP, privilege escalation) | `pwn-chain/` |
| Weaponize and deploy a 1-day onto the target network | `pentest-tools/network-attack-defense/` |
| Reverse a binary from scratch | `ida-reverse/` / `radare2/` |

The key distinction: `binary-diff` aims to **make the new version analyzable** (carrying over old symbols), while this skill aims to **find what bug the patch fixed and then attack the pre-patch version**. The former serves defensive / research-side analysis, the latter serves offensive weaponization.

## Core Principle

```text
patched binary (after)         unpatched binary (before)
        ↓                                  ↓
    import into IDA/Ghidra          import into IDA/Ghidra
        ↓                                  ↓
        └──────── BinDiff / ghidriff ──────┘
                        ↓
        function-level diff (matched / unmatched / changed)
                        ↓
        focus on functions with mid-range match scores (0.5 - 0.9)
                        ↓
        look at what was added: bounds checks / locks / field zeroing / integer-overflow checks
                        ↓
        infer bug class: OOB / Race / Info Leak / UAF / Integer Overflow
                        ↓
        write a PoC to trigger it on the unpatched version
                        ↓
        validate: unpatched crashes / patched does not → vulnerability confirmed
```

Patch fix pattern → vulnerability type lookup:

| Addition | Most likely bug class |
|---------|------------------|
| `if (a + b < a)` / `__builtin_add_overflow` | Integer overflow |
| `KeAcquireSpinLock` / `mutex_lock` | Race condition (TOCTOU / double-free) |
| `if (idx >= MAX)` / `if (len > buf_size)` | Out-of-bounds read / out-of-bounds write |
| `RtlZeroMemory` / `memset(struct, 0, ...)` | Uninitialized-memory information leak |
| `InterlockedDecrement` + refcount checks | UAF / reference counting error |
| `ProbeForRead` / `ProbeForWrite` | Unvalidated user-mode pointers |
| `SeAccessCheck` / capability checks | Missing permission checks |
| Removed / tightened `IOCTL` codes | Attack-surface reduction (look at how to hit the old interface) |

## Workflow

### 5-Step Complete Process

```text
Step 1: Obtain before / after binaries
  - Windows: download MSU/MSP from the Microsoft Update Catalog, unpack with expand.exe / dism
  - Linux: pull .deb/.rpm from distro USN/RHSA, unpack with dpkg-deb / rpm2cpio
  - Third-party software: grab the N-1 and N installers from the official site

Step 2: Align symbols
  - Ingest PDBs directly when available; without PDBs, use the binary-diff skill to carry N-1 version symbols over to version N
  - For the Linux kernel, fetch the matching vmlinux + System.map / debuginfo

Step 3: Binary diff
  - BinDiff: feed it the two IDBs directly, inspect function-level match results
  - ghidriff: one-line pip install, CLI outputs a markdown report
  - Diaphora: IDA plugin, established but requires IDA Pro

Step 4: Locate changes
  - Filter functions with match scores of 0.5-0.95 (identical ones are skipped; totally different ones are usually additions / renames)
  - Focus on: new ifs / new loop bounds / removed code blocks (what got removed is also a clue)
  - Use an LLM on before/after pseudocode to infer the bug class (see references/root-cause-and-poc.md)

Step 5: Write the PoC
  - Integer overflow: construct boundary values (INT_MAX-1, 0xFFFFFFFF)
  - Race: multi-threaded hammering, high-frequency open/close + ioctl concurrency
  - UAF: spray → free → reuse pattern
  - OOB: precisely control len / index to cross the boundary
  - Verify that the patched version no longer crashes and the unpatched version crashes reliably → bug reproduced
```

### Tool Invocation Order

```text
Download patch → unpack → load into IDA/Ghidra → BinDiff/ghidriff → inspect unmatched/low-match functions
       → LLM infers bug class → write PoC → run on unpatched → crash → done
```

## Typical Scenario Examples

### Scenario 1: Windows Patch Tuesday — Kernel CVE Reproduction

```text
Background: November 2025 Patch Tuesday, MSRC advisory CVE-2025-62215
      Windows Kernel race condition leading to a double free, CVSS 7.0, local privilege escalation
      Microsoft shipped only a patch, no details, no public PoC

Goal: reproduce a PoC, verify that unpatched Windows 11 22H2 / 23H2 can be escalated

Steps:
1. Search the Microsoft Update Catalog for "2025-11" + the KB number, download two versions:
   - 22H2 build 22621.xxxx (unpatched)
   - 22H2 build 22621.yyyy (after patching)
   Commands:
     expand.exe Windows-KB5052000-x64.msu -F:* C:\out\patched\
     expand.exe C:\out\patched\Windows-KB5052000-x64.cab -F:* C:\out\patched\
   Extract ntoskrnl.exe / win32k.sys / win32kfull.sys / afd.sys

2. Ingest PDBs for both versions (Microsoft symbol server):
     symchk /v /r ntoskrnl.exe /s SRV*C:\sym*https://msdl.microsoft.com/download/symbols

3. Run BinDiff:
     bindiff old.BinExport new.BinExport
   or ghidriff:
     ghidriff ntoskrnl_old.exe ntoskrnl_new.exe -o diff_out/

4. Read the report, filter functions with similarity 0.6-0.95.
   Suppose an NtXxxIoctl-type function gained a block:
     KeAcquireSpinLockRaiseToDpc(&obj->Lock);
     if (obj->RefCount == 0) { ... goto cleanup; }
   → a lock + refcount check was added → race + double free, matching the advisory description

5. Write the PoC: user-mode multi-threading calling NtClose + triggering the IOCTL on the same object simultaneously,
   creating a race window between the close-side free and the IOCTL still using it
   Crash lands on the subsequent free path after ObfDereferenceObject in ntoskrnl

6. Verify:
   - Run the PoC on unpatched 22621.xxxx, BSOD within ~30 seconds (BAD_POOL_HEADER or DOUBLE_FREE)
   - Run the same PoC on patched 22621.yyyy, no anomalies at all
   → reproduction successful
```

### Scenario 2: Linux Kernel LTS Branch Patch — Find Unfixed Side Branches

```text
Background: mainline 6.x already fixed an OOB write in some net subsystem
      Ubuntu 22.04 (5.15 LTS) USN has published the update
      But some OEM kernels / Azure kernels backport more slowly
      Want to confirm whether the un-updated side branch is still exploitable

Goal: take patched/unpatched kernels, diff out the binary change for the fix commit,
      rewrite the PoC on the unpatched side branch

Steps:
1. Pull the patched and unpatched packages:
     apt download linux-image-5.15.0-101-generic   # patched
     apt download linux-image-5.15.0-100-generic   # unpatched
     dpkg-deb -x linux-image-5.15.0-101-generic_*.deb ./patched/
     dpkg-deb -x linux-image-5.15.0-100-generic_*.deb ./unpatched/
   Extract boot/vmlinuz → restore the ELF with extract-vmlinux

2. Fetch the matching dbgsym:
     apt download linux-image-unsigned-5.15.0-101-generic-dbgsym

3. Use ghidriff (Linux-friendly):
     ghidriff vmlinux_5.15.0-100 vmlinux_5.15.0-101 \
              -o /tmp/kdiff/ --max-section-funcs-analyze 8000

4. Search the report for changed functions in net/ipv4/ net/ipv6/ net/sched/ and other subsystems
   Find that pre-patch, the skb_copy_bits call lacked an upper-bound check on skb->len
   → OOB read, potentially escalatable to OOB write with a triggerable sysctl

5. On the unpatched side branch (e.g., an Azure 5.15.0-1080 version lagging on backports)
   cross-verify: has the fix for the same function already been backported?
   If not → the side branch is still exploitable → write a PoC replay

6. Write the PoC: adapt a syzkaller harness / a direct C PoC triggering the corresponding syscall
   Verify the side branch panics / KASAN reports OOB
```

## Notes

- **Legal boundaries** — weaponizing an N-day must stay within authorized scope (SRC / bug bounty / your own lab machines / CTF). Hitting production environments directly with a 1-day is tantamount to intrusion
- **A patch may only "shrink the blast radius"** — seeing a patch does not mean it is a complete fix; it may only close one exploitation path while the original bug is still reachable via other paths (one bug, many meals)
- **Do not be fooled by variable names/types** — Windows patches often do cleanup / renames along the way, which look like big changes but are actually irrelevant. Look at control flow and data flow, not token-level diffs
- **A Microsoft patch may add a mitigation rather than a fix** — CFG hardening like `_guard_xfg_dispatch_icall_fptr` is not a fix, it is a mitigation
- **Anonymization** — when publishing write-ups / PoCs, sanitize target machine names, intranet IPs, and usernames (use `{target_ip}` `{username}` placeholders)
- **The patched version must pass a harmless test** — do not run only on unpatched; otherwise the crash may be environmental, not the vulnerability
- **Binary diffing is not omnipotent** — compiler upgrades / optimization-level changes also reshuffle function layouts; first compare version N against N-1 (same compiler), do not cross major versions

---

## On-Demand Bootstrap

### Tool Dependencies

| Tool | Purpose | Auto-installable |
|------|------|-----------|
| BinDiff (Google, 5.x+) | Function-level binary diff, IDA/Ghidra plugin | ✓ (official .deb / .msi) |
| Diaphora | Established IDA diff plugin, requires IDA Pro | ✓ (git clone) |
| ghidriff | Ghidra headless CLI diff, markdown output | ✓ (pip install ghidriff) |
| DeepDiff (commercial) | Next-gen diff tool, higher accuracy | ✗ (commercial license) |
| Ghidra | Runtime base for ghidriff | ✓ |
| IDA Pro | Runtime base for BinDiff / Diaphora | ✗ (commercial) |
| Microsoft Update Catalog | Download MSU/MSP patch packages | Online service |
| wsuspect-proxy | Transparently intercept Windows Update traffic to grab patches | ✓ (git clone) |
| expand.exe / dism | Unpack MSU / cab | ✓ (Windows built-in) |
| rpm2cpio / dpkg-deb | Unpack Linux distro packages | ✓ |
| symchk | Pull PDBs from the Microsoft symbol server | ✓ (Windows SDK) |

### Bootstrap Command

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -File "&lt;SKILL_ROOT&gt;\skills\scripts\bootstrap-reverse.ps1" -Capability @('bindiff','ghidriff','ghidra','wsuspect-proxy') -StartServices
```

For detailed tool comparison and commands, see `references/diff-tools-comparison.md`.
For the detailed Patch Tuesday workflow, see `references/patch-tuesday-workflow.md`.
For root-cause back-inference and PoC templates, see `references/root-cause-and-poc.md`.

---

## Routing Context

**Upstream entry points**: `skills/SKILL.md` (master control), `routing.md`

**Upstream skills**:
- `reverse-engineering/` — you may need to understand the target binary's overall structure before diffing
- `binary-diff/` — if the post-patch version has no symbols but the pre-patch version does, first use binary-diff to carry the symbols over

**Downstream skills**:
- `pwn-chain/` — after inferring the bug class, a complete exploit is needed (heap spray, ROP, SMEP/SMAP bypass, privilege escalation payload)
- `pentest-tools/network-attack-defense/` — weaponize and deploy the N-day onto the target network (package as a deliverable payload, integrate with C2)
- `attack-chain/` — chain this N-day into a complete attack chain (initial access → privilege escalation → lateral movement)

**Trigger conditions**: the task includes intents like "N-day", "patch", "CVE reproduction", "find what the patch fixed", "hit unupdated hosts"

## Task Completion Self-Check (MUST pass before claiming completion)

- [ ] Did I execute every step of the workflow (rather than just reading it)?
- [ ] Did I use real tool paths based on `tool-index`?
- [ ] Did I produce reproducible evidence (commands/scripts/screenshots/reports)?
- [ ] Did I complete and write back the Checklist items required by RULES?