Reverse Engineering Patch Tuesday

Reverse Engineering Patch Tuesday

Speakers: John McIntosh, Security Researcher, Clearseclabs

Conference: REcon 2025

YouTube: https://www.youtube.com/watch?v=9LJdIgof9jA

Overview

Every month, Microsoft releases a batch of security updates on Patch Tuesday — and every month, the security community is left squinting at a list of CVE identifiers with partial, incomplete, or entirely misleading descriptions. A CVE entry might tell you a vulnerability lives somewhere in the Windows networking stack; it will not tell you which binary was modified, what function was changed, or whether the fix represents a trivially reachable code path or a near-impossible exploit prerequisite. John McIntosh, founder of Clearseclabs, calls this the "blurry picture" problem.

This talk presents McIntosh's methodology and toolchain for reverse engineering Patch Tuesday itself — automatically correlating CVE identifiers to specific updated binaries, diffing those binaries at the function level, and producing what he calls "binary truth": a precise, auditable account of what actually changed in a given month's updates. The approach combines his open-source command-line diffing tool gdriff (also rendered as "gedriff" or "gedrrith" in the talk), the community-maintained Windbindex binary database, and a custom CVE-to-binary correlation algorithm built in Python with pandas and Jupyter notebooks.

The talk also covers the fascinating historical origin of patch diffing: the MS Blaster worm of 2003, which was itself born from a patch diff of Microsoft's RPC vulnerability bulletin — meaning Patch Tuesday was created, in part, as a response to a patch diff.

Background

▶ Watch: Patch diffing methodology: scoping reverse engineering effort (0:08)

Microsoft's Security Response Center publishes approximately 70 CVEs per month via its Security Update Guide. Each CVE entry provides some metadata — CVSS score, attack vector, impact type, and increasingly a CWE classification (a welcome 2024 addition that tells researchers the vulnerability class). But there is no direct, machine-readable mapping from a CVE to the specific Windows binary or function that was patched.

The community has developed partial answers. ZDI publishes monthly Patch Tuesday summary blog posts. Individual researchers post detailed write-ups on selected CVEs. But these are reactive, manual, and incomplete. For any organization trying to understand its actual risk posture from a given patch release, or for any researcher trying to locate a bug-class to study, the gap between "Microsoft fixed this" and "here is the precise code change" remains wide.

Patch diffing — comparing pre-patch and post-patch binaries to identify what changed — is the established technique for closing this gap. The insight of this talk is that the entire process can be automated at scale: download all relevant binaries, diff them programmatically, correlate CVE metadata to the resulting changes, and produce a monthly "Patch Tuesday biography" with one click.

The historical backdrop is important. Patch Tuesday itself was created in October 2003 as a response to a chaotic patching environment — exemplified by the MS Blaster worm, which propagated across over a million (some accounts say 10 million) machines via a buffer overflow in the Windows RPC service. The original Blaster worm was engineered by the hacking collective Xfocus after they patch-diffed Microsoft's security bulletin MS03-026, found the exact function affected (GetPathForServer), and published the full technical details nine days after the patch was released. The worm appeared 17 days later. Patch Tuesday was Microsoft's structural response to the chaos that followed — meaning the entire monthly patching cadence was born from a patch diff.

Key Findings

▶ Watch: Key technique: patch diffing to focus RE on changed code (12:12)

CVE-to-Binary Correlation Is Automatable

The fundamental challenge of patch diffing at scale is the absence of a direct CVE-to-binary mapping. McIntosh's approach is probabilistic: every Patch Tuesday, hundreds of binaries are updated, but only the subset with changed build numbers need consideration. Using MSRC catalog data (including binary names, descriptions, and KB update metadata), combined with natural language correlation on CVE descriptions, he is able to narrow the candidate binaries from roughly 1,000 per Patch Tuesday down to 3–4 per CVE — a 60–70% mapping accuracy across the CVEs he tested.

Modern Patch Diffing: 30,000 Functions to 1–2

For CVE-2024-26984 (Windows kernel privilege escalation, integer overflow), McIntosh demonstrates diffing the full ntoskrnl.exe — an 11 MB binary with approximately 30,000 functions. Using gdriff against the pre- and post-patch versions, the diff identifies zero deleted functions, zero added functions, and exactly two modified functions. The root cause is immediately visible: RTL_ULONG_MULTIPLY and similar safe-integer math wrappers were added to protect input parameters passed to a ReallocFunction call, preventing the integer overflow.

High-CVSS Scores Do Not Always Mean High Exploitability

CVE-2024-38063, a TCP/IP vulnerability (tcpip.sys) with a CVSS score of 9.8, generated significant community "CVE hype" suggesting a wormable vulnerability. McIntosh's patch diff located the changed function as IPv6ProcessOptions, showing the removal of one method and the substitution of another. While this confirmed the vulnerability was in IPv6 option processing, the diff alone could not confirm wormability — but it provided the precise starting point for targeted debugging, cutting the investigation surface from the entire TCP/IP stack down to one function.

The MS Blaster Diff, Reproduced After 20 Years

McIntosh reproduces the original 2003 Xfocus patch diff using modern tooling. Starting from a clean Windows XP installation and the MS03-026 patch (recovered from the Internet Archive and a random FTP server), he installs the patch, reads the PendingFileRenameOperations registry key to identify updated binaries, extracts the pre- and post-patch binaries, and runs them through Ghidra. The vulnerable function GetPathForServer is identified. The bug: a buffer of 32 bytes was allocated for a machine name that could be up to 256 Unicode characters (512 bytes), a classic stack buffer overflow. The fix: changing the buffer size to match the maximum input. This is the exact diff Xfocus published in their 2003 report, reproduced to the letter 20 years later.

Technical Deep Dive

▶ Watch: Tracing from patch diff to vulnerable code path (15:39)

The Toolchain

gdriff / gedriff (open source): McIntosh's command-line binary diffing tool, built on top of Ghidra. It takes two binaries as input and outputs a structured diff (markdown and JSON) showing deleted, added, and modified functions along with their changed subcomponents. It can process large binaries like ntoskrnl.exe in parallel.

Windbindex: A community-maintained catalog (attributed to the handle m417z) that indexes all Microsoft Windows binary versions over time and provides direct download links to the binaries from Microsoft's own symbol servers. Microsoft hosts these for legitimate debugging purposes. Windbindex makes them queryable and automatable.

win-bindiff (not yet open-sourced): McIntosh's automation layer that combines gdriff with Windbindex and the CVE correlation algorithm. It:

1. Reads the current month's MSRC catalog and KB update data
2. Identifies all binaries with updated build numbers
3. Downloads pre- and post-patch versions from Windbindex/Microsoft
4. Runs gdriff on each pair in parallel
5. Correlates CVE metadata to binary names and descriptions using pandas dataframes
6. Outputs a structured markdown report — the "Patch Tuesday binography" — with per-CVE tables linking to the actual function diffs

CVE Markdown Charts (open source): An earlier tool that scrapes MSRC data and generates vulnerability-type trend charts. Used by McIntosh to build intuition about which vulnerability classes are most prevalent in Patch Tuesday updates.

The CVE Matching Algorithm

The algorithm is described candidly as heuristic rather than precise. The steps:

1. Pull the full MSRC catalog for the month — ~70 CVEs, each with a KB update reference and some text description
2. From the KB update manifest, enumerate all binaries with a new build number — typically 100–200 per month
3. Correlate CVE descriptions to binary names/descriptions using string matching (binary name, description fields) and filter out generic matches (e.g., CVEs described only as "Microsoft Windows" without a component name)
4. For each CVE, produce a ranked list of candidate binaries
5. Diff each candidate and flag the functions with the most significant changes
6. Coverage hovers around 60–70% of CVEs having at least one correctly matched binary

The output is a per-month "Patch Tuesday binography" — a document (or GitHub-hosted markdown file) that maps each CVE to a binary and links directly to the gdriff output showing which functions changed.

Binary Biography Concept

McIntosh introduced the concept of a binary biography at Black Hat the previous year: telling the complete story of a single binary's changes over time by running win-bindiff across all historical versions indexed in Windbindex. This is the per-binary analog of the per-month Patch Tuesday binography.

Practical Workflow: CVE-2024-38063 Example

1. MSRC entry shows tcpip.sys, CVSS 9.8 — community hype suggests wormable
2. win-bindiff identifies tcpip.sys as the candidate binary, downloads pre- and post-patch versions
3. gdriff diff identifies IPv6ProcessOptions as the modified function
4. Function-level diff shows removal and substitution of IPv6 option handling logic
5. Call graph analysis from the modified function maps the reachable code paths to the external network surface
6. Researchers can now focus debugging and PoC development on exactly this function rather than scanning the entire TCP/IP stack

Demo / Proof of Concept

▶ Watch: Automation tools: open-sourced patch analysis pipeline (26:03)

McIntosh runs a live demo of win-bindiff processing June's Patch Tuesday updates. The tool:

• Hits the Windbindex server to download all updated binaries for the month
• Processes them through Ghidra/gdriff in parallel (the terminal output is command-line only, not visually exciting, but the end result is a structured report)
• Produces a GitHub-hosted markdown document with a table of CVEs, each linked to a binary diff

He navigates through the output live, clicking through CVE entries to show how each one maps to a binary and then to specific changed functions. The process takes the audience from a raw CVE list to clickable function-level diffs in a single automated pipeline.

He also replays the MS03-026 Blaster diff as a historical demonstration, showing the vulnerable GetPathForServer function in Ghidra and the precise buffer size change that both caused the vulnerability and, once patched, led to the birth of Patch Tuesday itself.

Defensive Implications

▶ Watch: Practical workflow: identifying patched binaries at scale (29:32)

For vulnerability researchers: The gdriff tool is open source and immediately usable for any binary diff workflow. The full win-bindiff automation is not yet released, but the methodology is fully described and reproducible with the publicly available tools (gdriff + Windbindex + Python/pandas).

For defenders and patch prioritization teams: The Patch Tuesday binography provides a faster and more accurate basis for risk assessment than CVSS scores alone. A CVE with a 9.8 CVSS and a single-function diff in a rarely-reached code path is materially different from a CVE with a 7.5 CVSS and a diff in a universally-called kernel function. Binary truth lets defenders make that distinction without waiting for third-party blog posts.

For red teamers and bug hunters: Each month's Patch Tuesday is, as McIntosh describes, "a fresh scoped reverse engineering problem." Using CVEs as north stars to point toward modified functions is an efficient entry point for learning vulnerability classes and understanding modern Windows internals.

For organizations assessing exposure from specific CVEs: The workflow — MSRC metadata → binary identification → gdriff diff → call graph analysis — answers the question "is this actually reachable in my environment?" with direct binary evidence rather than vendor descriptions.

Key Takeaways

• Patch Tuesday can be automated end-to-end: From the CVE list to function-level diffs, the entire pipeline can run without manual binary identification or manual diff setup, thanks to Windbindex and gdriff.
• Patch diffing originated in 2003 with MS Blaster: The Xfocus group patch-diffed MS03-026, built the Blaster worm, and indirectly caused Microsoft to create the Patch Tuesday cadence — meaning Patch Tuesday is literally a child of patch diffing.
• CVSS score ≠ exploitability: High-scoring CVEs like CVE-2024-38063 (CVSS 9.8) may have limited practical reach once you see the actual code change; the diff provides "binary truth" that no metadata can substitute for.
• gdriff is the enabling technology: The open-source command-line diffing tool McIntosh built on top of Ghidra is the core engine that makes everything else possible — download it, use it.
• CWE data from MSRC is a multiplier: Microsoft's 2024 adoption of CWE tagging for CVEs gives researchers the vulnerability class before they even open a diff, dramatically scoping the analysis.

About the Speaker

John McIntosh is a security researcher and founder of Clearseclabs, a one-person research firm. He is an open-source developer, blogger, and occasional trainer who focuses on vulnerability research, binary analysis, and Windows internals. He presented win-bindiff at Black Hat and has published tooling including gdriff and CVE Markdown Charts on GitHub. He can be found on social media at the handle ClearBlueJar.