Lab 03 — Security Patch and Variant Analyzer

Difficulty: 4/5 | Runs locally: yes

Pairs with the Phase 08 WARMUP Chapters 10–11 (variant analysis, reverse engineering and patch diffing) and the HITCHHIKERS-GUIDE ("Patch Review Questions").

Why This Lab Exists (Purpose & Goal)

When you find or fix one bug, the same mistake almost always exists elsewhere — the developer who made it once made it in sibling code, and the codebase likely repeats the anti-pattern. Fixing only the instance you found, while three variants remain exploitable, is a partial fix an attacker simply pivots around. The goal of this lab is to build the analyzer that turns a single fix into a class-closing fix: it reads a patch, identifies what security property it added, and generates a variant checklist for sibling parsers and alternate call paths.

The Concept, In the Weeds

The analyzer reasons about a patch the way an elite security team (e.g. Google Project Zero) does:

  • What did the patch actually add? Bounds validation? Checked arithmetic? Duplicate-field rejection? Exact consumption? A regression test? Each of these maps to a Phase 01 invariant. A patch that adds len > remaining tells you the bug was an OOB read; a patch that adds an overflow check tells you the bug was integer-multiply-before-allocate.
  • Abstract the bug into a pattern, then hunt for it. Once you know the property the patch added, you search the codebase for every place that property is missing — sibling parsers, alternate call paths, the same idiom copy-pasted elsewhere. This is variant analysis, and it is the highest- leverage activity in vulnerability research: one finding becomes a patch that closes a category.
  • Patch diffing is dual-use. The same analysis that lets you close variants lets an attacker understand an undisclosed bug from a public fix ("1-day" analysis) — which is why disclosure timing matters, and why you do this analysis without publishing weaponizable detail before users patch.
  • Was the patch even complete? A patch that fixes the reported instance but misses siblings is an incomplete fix — exactly the gap variant analysis catches, including in vendors' patches.

Why This Matters for Protecting the Company

When the company patches a vulnerability — in its own code or by understanding a dependency's fix — the question that determines whether the patch actually closed the risk is "did we fix all the variants?" Variant analysis is how a security team converts each incident into durable, class-level protection instead of an endless game of whack-a-mole. It is also how you assess a third-party patch ("which versions are affected, and did the vendor fix everything?") to plan backports and write detections. A team that does variant analysis gets steadily safer with each bug; one that fixes only instances stays perpetually exposed to the next pivot.

Build It

Given before/after code metadata, identify whether a patch adds bounds validation, checked arithmetic, duplicate-field rejection, exact consumption, and regression tests. Generate a variant checklist for sibling parsers and alternate call paths.

LAB_MODULE=solution pytest -q

Validation — What You Should Be Able to Do Now

  • Read a patch and identify the security property it added (and therefore the bug it fixed).
  • Abstract a bug into a pattern and systematically search for variants across sibling code and call paths.
  • Assess whether a patch is complete (all variants fixed) and explain why an incomplete fix invites a pivot.
  • Explain patch diffing's dual-use nature and why disclosure timing matters.

The Broader Perspective

This lab teaches the mindset that separates senior security engineers from instance-fixers: always ask "where else does this bug exist?" A single fix is a tactical win; closing the class is a strategic one, and it compounds — each pattern you eliminate is a category of future incidents prevented. The same "find all instances of the anti-pattern" discipline applies far beyond memory bugs: it's how you remediate a vulnerability class across a fleet (Phase 03 paved-road fixes that remove a bug class for every team), how you turn one detection into ATT&CK-technique coverage (Phase 09), and how you think about platform-level fixes at the staff level (Phase 12). Closing classes, not instances, is the highest-leverage move in security.

Interview Angle

  • "How do you assess a patch for variants?" — Diff to extract the exact change; abstract the bug into a pattern (e.g. "missing overflow check before allocation"); systematically search the codebase (grep/CodeQL/audit) for every instance, including siblings and similar call sites; check whether the vendor fixed all instances or just the reported one; flag affected versions and backport needs — without publishing weaponizable detail before users can patch.

Extension (Stretch)

Apply real variant analysis with CodeQL or semantic grep against an authorized open-source patch, and produce an affected-versions + backport + detection plan.

References

  • Phase 08 WARMUP Chapters 10–11; Google Project Zero variant-analysis writeups.
  • CodeQL documentation; the CVE Casebook.