AutoPiff Integration
AutoPiff is the automated patch diffing pipeline that underpins much of KernelSight's analysis. It monitors Windows Update for new driver builds, downloads pre-patch and post-patch binaries, decompiles them with Ghidra, diffs the functions, applies semantic rules to classify the changes, performs reachability analysis to determine whether changed code is accessible from user-mode attack surfaces, and produces risk-scored reports. The pipeline runs continuously, processing each Patch Tuesday's output within hours of release.
How AutoPiff Works
The pipeline is built on Karton, a distributed malware processing framework repurposed for patch analysis. Each stage is an independent Karton task that consumes inputs from the previous stage and produces outputs for the next.
-
Stage 0 (
autopiff-driver-monitor) watches WinBIndex and VirusTotal for new driver builds. When a new build appears for a tracked component, it downloads the updated binary and pairs it with the previous version. -
Stages 1-4 (
karton-driver-patch-differ) perform structural comparison using BinDiff. Functions are matched between the two versions, and changed functions are extracted with their pre-patch and post-patch assembly. -
Stage 5 (
karton-driver-reachability) decompiles the changed functions using Ghidra's headless mode, exporting C pseudocode. It then traces call paths from user-accessible entry points (IOCTL handlers, IRP dispatch routines) to the changed functions, filtering out changes that are not reachable from the attack surface. -
Stage 6 (
karton-driver-ranking) applies semantic detection rules to the decompiled diff and scores each finding based on the detected pattern, the proximity to user input, and the severity of the vulnerability class. -
Stages 7-8 (
karton-driver-report,autopiff-alerter) generate structured reports and send Telegram alerts for high-scoring findings that likely represent exploitable security fixes.
Rule Mapping
AutoPiff's semantic rules map directly to KernelSight vulnerability classes and patch patterns. The complete mapping is maintained in index/autopiff_rule_map.yaml.
| AutoPiff Category | KernelSight Technique | What the Rule Detects |
|---|---|---|
bounds_check |
Buffer Overflow | Added length/size validation before memory operations |
lifetime_fix |
Use-After-Free | Reference counting changes, free-path modifications |
user_boundary_check |
Arbitrary R/W Primitives | ProbeForRead/ProbeForWrite additions, user buffer capture |
int_overflow |
Integer Overflow | Safe integer arithmetic additions, overflow checks |
race_condition |
Race Conditions | Lock acquisitions, interlocked operations, synchronization |
type_confusion |
Type Confusion | Type field validation, object signature checks |
authorization |
Logic Bugs | Access control additions, privilege checks |
info_disclosure |
Uninitialized Memory | Buffer zeroing, pointer scrubbing |
ioctl_hardening |
IOCTL Handlers | SDDL changes, device ACL modifications |
mdl_handling |
MDL Mapping | MDL flag validation, mapping permission changes |
Connection to KernelSight
All 28 CVE case studies in KernelSight were bootstrapped from AutoPiff's validation corpus. Each case study includes the vulnerable and fixed builds with KB numbers, the expected detection rules and categories, and the function patterns where AutoPiff identified the patch. This means the case studies serve double duty: they document the vulnerability for researchers and validate AutoPiff's detection accuracy for the pipeline.
When AutoPiff processes a new Patch Tuesday, its findings cross-reference against the KernelSight taxonomy. A bounds_check detection on clfs.sys maps to the buffer overflow vulnerability class, the pool overflow primitive, and the file format corruption exploit chain pattern (archetype A from Exploit Chain Patterns). This mapping turns a raw binary diff into a structured assessment of the vulnerability's exploitation potential.