{"slug":"windiff-version-diff-analysis","title":"windiff-version-diff-analysis","summary":"Generate and interpret security-research diffs between Windows versions or patch levels using this repo's WinDiff CLI and databases. Use when comparing Windows builds or binaries such as ntoskrnl.exe, ntdll.dll, win32k*.sys, ci.dll, or cng.sys to find changed syscalls, symbols, t","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-08-23T08:58:25.04185Z","repo":{"url":"https://github.com/ergrelet/windiff","stars":389,"forks":20,"license":"GPL-3.0","updatedAt":"2026-09-22T22:04:48Z"},"bodyHtml":"
\n

name: windiff-version-diff-analysis\ndescription: >-\nGenerate and interpret security-research diffs between Windows versions or patch\nlevels using this repo's WinDiff CLI and databases. Use when comparing Windows\nbuilds or binaries such as ntoskrnl.exe, ntdll.dll, win32k*.sys, ci.dll, or cng.sys\nto find changed syscalls, symbols, types, mitigation flags, callbacks, ETW/EtwTi\ntelemetry, code-integrity behavior, drivers, or attack surface. Explain likely\nintent and security relevance with Windows-internals knowledge, and frame findings\nfor anti-malware/EDR, anti-cheat, and vulnerability-research audiences rather than\nreturning an uninterpreted symbol list.

\n

WinDiff Version Diff Analysis

\n

Compare two Windows builds and turn the raw symbol/type/syscall delta into a\nsecurity-research report: what was added, what it probably does, and why it\nmatters for attack surface, exploitation, or defense.

\n

Run this skill from a WinDiff repository checkout. It uses windiff_cli to\ngenerate the per-binary JSON databases, then diffs and interprets them. The\ninterpretation is the point: explain intent from Windows internals conventions\ninstead of merely listing symbols.

\n

Locate bundled resources

\n

Resolve all scripts/ and references/ paths relative to this SKILL.md, not\nrelative to the current working directory and not through a harness-specific\ndirectory such as .claude/ or .agents/. Before running a bundled script, set\nSKILL_DIR to the absolute directory containing this file. The examples below\nassume that has been done:

\n
SKILL_DIR=\"<absolute directory containing this SKILL.md>\"\n
\n

If separate shell-tool calls do not share environment, substitute that absolute\npath for $SKILL_DIR in each command instead of relying on prior shell state.

\n

Also identify the repository root (the directory containing windiff_cli/,\nwindiff_frontend/, and ci/) and run repository commands from there. Keep\ngenerated configs, databases, and analysis artifacts under its git-ignored\nlocal/ directory.

\n

Workflow

\n

1. Pin down scope

\n

Establish, asking the user only if genuinely ambiguous:

\n\n

ci/db_configuration.json is the canonical list of tracked versions and binaries\n— consult it for valid version/update spellings.

\n

2. Generate the databases with windiff_cli

\n

Write a minimal config containing only the two OS versions and the chosen\nbinaries, then run the CLI into a scratch output dir (keep it under the repo's\ngit-ignored local/). Use $SKILL_DIR/scripts/make_config.py to build the\nconfig:

\n
python3 \"$SKILL_DIR/scripts/make_config.py\" \\\n  --os \"21H2:BASE:amd64\" --os \"11-24H2:KB5074105:amd64\" \\\n  --binary ntoskrnl.exe --binary ntdll.dll --binary win32k.sys --binary ci.dll \\\n  > local/windiff_diff_config.json\n\ncd windiff_cli\ncargo run --release -- --low-storage-mode \\\n  ../local/windiff_diff_config.json ../local/windiff_diff_out/\n
\n

This downloads PEs from Winbindex and PDBs from MSDL, so it needs network\naccess and takes minutes per binary. Follow the active harness's normal\npermission or approval flow for networked commands. --low-storage-mode keeps\nmemory bounded. If the CLI fails for one OS (a build may be missing from\nWinbindex), report which version/update is unavailable and suggest the nearest\ntracked one from ci/db_configuration.json.

\n

If the user says the databases already exist (e.g. in windiff_frontend/public/),\nskip generation and point the diff script at that directory instead.

\n

3. Diff each binary

\n

$SKILL_DIR/scripts/windiff_diff.py does the deterministic set/text diff so you\nnever hand-compute it. Run it per binary; it prints a summary to stderr and\nstructured JSON to stdout.

\n
python3 \"$SKILL_DIR/scripts/windiff_diff.py\" \\\n  local/windiff_diff_out ntoskrnl.exe 21H2_BASE_amd64 11-24H2_KB5074105_amd64 \\\n  > local/diff_ntoskrnl.json\n
\n

Use --list to see available suffixes, --kinds to restrict (e.g.\n--kinds syscalls types). Anonymous _unnamed_0xNNNN types are hidden from the\ntop-level added/removed/modified lists by default (their synthetic ids churn\nbetween builds — noise); pass --include-anon only if you specifically need them.

\n

resolved_member_changes — where new mitigation flags actually show up.\nBitfields like _EPROCESS::MitigationFlagsValues, MitigationFlags2Values, or\n_KPROCESS flag words are typed as anonymous _unnamed_0xNNNN structs, and the\nindividual bits (e.g. RedirectionTrustPolicyEnabled : 1) live inside them. When\nMicrosoft adds a mitigation, a new bit appears in that anonymous struct — and its\nsynthetic id churns, so a naive diff would either hide it or show it as noise. The\nscript resolves this for you: the types.resolved_member_changes array follows\neach anonymous member back to its named parent (across the id change) and reports\nthe real per-member delta as <parent>::<member> with the added/removed\ndeclarations. This is the first place to look for new mitigation bits and other\nnew bitfield flags — e.g. a new bit under _EPROCESS::MitigationFlags2Values, or\na new _KALPC_MESSAGE::u1::s1 flag. Resolution recurses through nested anonymous\nstructs/unions, so the path may be several :: levels deep.

\n

Noise to discount when reading the output:

\n\n

4. Interpret with Windows internals knowledge — the core of the analysis

\n

For every meaningful addition, infer what it is and why it matters. Do not\njust relay names. Read $SKILL_DIR/references/windows-internals.md for the\nreasoning toolkit: API prefixes\n(Nt/Zw/Ps/Ke/Mm/Ob/Se/Cm/Alpc/Etw/Ci/Bcrypt), naming\npatterns for mitigations, the structures where security flags live\n(_PS_MITIGATION_OPTIONS, _KPROCESS/_EPROCESS flag bitfields,\n_SEP_TOKEN_*, CI policy structs), and — equally important — the\nnon-mitigation security surface: kernel notification/callback registration,\nETW providers and the EtwTi threat-intelligence channel, ELAM/AMSI, PPL and\nanti-tamper, minifilter hooks, and entirely new drivers/modules. Read\n$SKILL_DIR/references/windows-components.md for per-binary roles.

\n

Mitigations are only one of several things worth surfacing. Cast a wide net for\nany new security-relevant feature or component and frame it for whichever of\nthese audiences it serves — $SKILL_DIR/references/windows-internals.md §7 maps\nthe signals:

\n\n

For each finding, aim to state: the prefix/component it belongs to, the subsystem\nit touches, a concrete hypothesis about the feature/mitigation/component it\nimplements, the security angle (new attack surface, hardening, telemetry, exploit\nprimitive added/removed), and which audience(s) should care and why. Flag\nuncertainty honestly — \"likely\", \"consistent with\" — and suggest how a researcher\ncould confirm (reverse the routine, check public symbols, diff the disassembly).

\n

5. Write the report

\n

Use the structure in $SKILL_DIR/references/report-template.md. Lead with the\nhighest-signal security findings (new syscalls, mitigation flags, new\nETW/callback surface, new components), not an alphabetical dump. Group related\nsymbols by component and feature. Every nontrivial item gets an interpretation,\nnot just a name, and a note on which audience (EDR / anti-cheat / vuln research)\nit matters to. The report includes a dedicated section for security-relevant\nfeatures and components beyond mitigations so EDR and anti-cheat findings aren't\nburied.

\n

Quick reference

\n\n","files":[{"path":"agents/openai.yaml","sizeBytes":253,"isText":true},{"path":"evals/evals.json","sizeBytes":3396,"isText":true},{"path":"references/report-template.md","sizeBytes":4100,"isText":true},{"path":"references/windows-components.md","sizeBytes":3110,"isText":true},{"path":"references/windows-internals.md","sizeBytes":13196,"isText":true},{"path":"scripts/make_config.py","sizeBytes":2245,"isText":true},{"path":"scripts/windiff_diff.py","sizeBytes":15168,"isText":true},{"path":"SKILL.md","sizeBytes":9939,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-08-23T09:02:00.584064Z","sha256":"94EA8D01850A66C7DFD941ED06201A327D4D82A3751CEEBCC6545EF482598549","sizeBytes":22318},"review":null,"source":{"repositoryUrl":"https://github.com/ergrelet/windiff","path":"skills/windiff-version-diff-analysis","license":"GPL-3.0","commit":"c445aa5142fd01da2d609f9f9995b427480e7a17","subtreeSha":"00E29099C349515FD5C329A7731F0C00E583A4E4F1753F33C8ADB21F7C1E71A3","lastSyncedAt":"2026-09-25T07:37:53.599433Z"},"reviewedAt":"2026-08-23T09:08:25.274611Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/ergrelet/windiff/tree/master/skills/windiff-version-diff-analysis"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install ergrelet-windiff@llmmart"},{"target":"git","command":"git clone https://github.com/ergrelet/windiff.git"}]}