How reverse-skill Handles N‑day and Patch Tuesday Vulnerabilities: The 5‑Step Workflow

reverse-skill treats N‑day (Patch Tuesday) vulnerabilities as a dedicated patch‑diff‑exploit skill that acquires before/after binaries, performs symbol alignment and binary diffing, and produces a weaponized proof‑of‑concept through a rigorous five‑step process.

The zhaoxuya520/reverse-skill repository automates the analysis of publicly patched security flaws—commonly triggered by keywords like "N‑day", "patch diff", or "CVE reproduction" in task routing. When the routing engine detects these terms in skills/config/routing.json, it delegates execution to the patch-diff-exploit skill located at skills/patch-diff-exploit/SKILL.md.

Routing and Architectural Entry Points

The framework routes N‑day tasks through a dedicated entry in the master routing matrix. According to skills/MASTER-ROUTING.md and the routing configuration in skills/config/routing.json, the condition "Patch‑diff / N‑day" maps directly to the skills/patch-diff-exploit/ directory. Upon trigger, the framework loads SKILL.md as the execution blueprint, which defines the end‑to‑end workflow for converting patch differences into working exploits.

The core architectural principle relies on binary differential analysis: the skill requires both a patched (after) binary and an unpatched (before) binary. By aligning symbols—using PDB files on Windows or the binary-diff skill on Linux—and running a structural diff, the system isolates modified functions and maps them to specific bug classes.

The 5-Step Patch-Diff-Exploit Workflow

The canonical workflow is documented in skills/patch-diff-exploit/SKILL.md and expanded in skills/patch-diff-exploit/references/patch-tuesday-workflow.md. Each step moves from artifact acquisition to verified weaponization.

Step 1: Obtain Before and After Binaries

The process begins with acquiring both versions of the target binary. For Windows Patch Tuesday updates, the skill downloads MSU/MSP files from the Microsoft Update Catalog and unpacks them using expand.exe or dism. For Linux distributions, the workflow fetches specific package versions (.deb or .rpm) and unpacks them with dpkg-deb or rpm2cpio.

# Windows: Download and unpack the MSU patch

wget "https://download.microsoft.com/download/KBXXXXX/Windows10.0-KBXXXXX-x64.msu" -OutFile "KBXXXXX.msu"
expand.exe KBXXXXX.msu -F:* C:\patch\raw\

# Linux: Fetch patched and unpatched kernel 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/

Step 2: Align Symbols

With both binaries extracted, the workflow aligns debug symbols to ensure accurate function mapping. On Windows, this involves pulling PDBs from the Microsoft Symbol Server using symchk. On Linux, the process retrieves matching vmlinux, System.map, and debuginfo packages. If symbols are missing for the patched version, the binary-diff skill migrates symbol tables from the unpatched binary.

# Pull symbols from Microsoft Symbol Server

symchk /v /r C:\patch\raw\ntoskrnl.exe /s SRV*C:\sym*https://msdl.microsoft.com/download/symbols

Step 3: Perform Binary Diff

The skill executes a differential analysis using specialized engines such as BinDiff, ghidriff, or Diaphora. These tools generate function‑level match scores and identify changed, added, or removed functions between the two binaries.

# Using ghidriff for headless comparison

ghidriff unpatched/vmlinux unpatched/vmlinux patched/vmlinux -o diff_report/

The output—typically a markdown‑formatted report in diff_report/—provides the structural changes required for root cause analysis.

Step 4: Locate Changes and Infer Bug Class

Analysts filter the diff results for functions with match scores between 0.5 and 0.95, indicating significant but not total modification. The workflow focuses on newly added conditionals, loop modifications, or removed safety checks. Using the templates in skills/patch-diff-exploit/references/root-cause-and-poc.md, the analyst (optionally assisted by an LLM) maps observed changes to bug classes—for example, recognizing patterns like if (a+b<a) as integer overflow indicators or identifying missing locks as race conditions.

Step 5: Write and Verify the PoC

The final step generates a proof‑of‑concept aligned with the inferred bug class. The skill produces specific payloads for integer overflows, use‑after‑free (UAF) sprays, race‑condition hammers, or out‑of‑bounds (OOB) accesses. Verification requires running the PoC against the unpatched binary (expecting a crash) and the patched binary (expecting stable execution).

# Conceptual verification script structure

# Run against unpatched binary -> CRASH (vulnerability confirmed)

# Run against patched binary -> NO CRASH (patch effective)

Legal Guardrails and Compliance

The patch-diff-exploit skill enforces strict authorization boundaries defined in RULES.md and RULES_zh.md. Weaponization is permitted only within authorized scopes including Security Researcher Programs (SRC), bug bounty environments, owned labs, or CTF competitions. The skill explicitly prohibits exploitation of unpatched systems outside these boundaries, ensuring compliance with responsible disclosure practices.

Integration with Downstream Skills

Upon successful PoC generation, the output flows to complementary skills within the reverse‑skill ecosystem. The framework can pass results to pwn-chain/ for full exploit chain development, to pentest-tools/network-attack-defense/ for weaponization, or to attack-chain/ to embed the N‑day exploit into broader adversary simulation paths, as documented in the routing context of skills/patch-diff-exploit/SKILL.md.

Summary

• Routing: N‑day tasks trigger via skills/config/routing.json and execute through skills/patch-diff-exploit/SKILL.md.
• Acquisition: Windows binaries unpack via expand.exe; Linux binaries extract via dpkg-deb or rpm2cpio.
• Analysis: Symbol alignment precedes binary diffing with BinDiff, ghidriff, or Diaphora.
• Inference: Changed functions (match scores 0.5‑0.95) map to bug classes using root-cause-and-poc.md templates.
• Verification: PoCs must crash unpatched binaries and remain stable against patched versions.
• Compliance: Execution restricted to authorized scopes per RULES.md.

Frequently Asked Questions

What triggers the patch-diff-exploit skill in reverse-skill?

The routing engine activates the skill when task descriptions contain keywords such as "N‑day", "patch diff", "Patch Tuesday", or "CVE reproduction". These terms are mapped in skills/config/routing.json to the skills/patch-diff-exploit/ directory.

Which binary diffing tools does reverse-skill support?

The workflow supports BinDiff, ghidriff, and Diaphora for generating function‑level match scores. The choice of tool depends on the target platform and analyst preference, with ghidriff providing headless automation suitable for CI/CD pipelines.

How does reverse-skill handle symbol resolution for patched Windows binaries?

When PDB files are not immediately available for patched Windows binaries, the skill uses the binary-diff utility to migrate symbols from the unpatched version. Alternatively, it leverages symchk to retrieve symbols directly from the Microsoft Symbol Server.

Can the patch-diff-exploit skill be used for live production testing?

No. According to RULES.md, the skill restricts weaponization to authorized environments only—specifically SRC programs, bug bounty scopes, privately owned laboratories, and CTF competitions. Testing against production systems without explicit authorization violates the framework's legal guardrails.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}