# Router Reverse Skill Router Patch Diff Exploit > 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. - Skill: `netvar1337/router-reverse-skill-router-patch-diff-exploit` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add netvar1337/router-reverse-skill-router-patch-diff-exploit` - Raw SKILL.md: https://api.skillmd.com/api/skills/netvar1337/router-reverse-skill-router-patch-diff-exploit/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: netvar1337 (https://skillmd.com/u/netvar1337) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/netvar1337/router-reverse-skill-router-patch-diff-exploit --- ## 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 "<SKILL_ROOT>\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?