AutoPiff

Automatisiertes Patch-Intelligence- und Finding-Framework

Eine semantische Analyse-Engine zur Erkennung von Sicherheitslücken-Fixes in Windows-Kernel-Treiber-Patches. AutoPiff verwendet konservative YAML-Regeln, um sicherheitsrelevante Codeänderungen mit hoher Präzision und Erklärbarkeit zu identifizieren.

Übersicht

AutoPiff analysiert die Unterschiede zwischen verwundbaren und gepatchten Treiberversionen, um automatisch Folgendes zu erkennen:

• Use-After-Free-Fixes (Null-Zuweisungen nach ExFreePool)
• Bounds-Check-Ergänzungen (Längenvalidierung vor memcpy)
• User-/Kernel-Grenzhärtung (ProbeForRead/ProbeForWrite)
• Integer-Überlaufschutz (sichere Mathe-Helfer)
• Zustandshärtung (Interlocked-Referenzzählung)
• IOCTL-Eingabevalidierung, Pool-Corruption-Guards, Privilegienprüfungen und mehr

Hauptmerkmale

• Hohe Präzision: Konservative Regeln minimieren Fehlalarme
• Erklärbar: Jeder Fund enthält Begründung und Nachweise
• Sink-bewusst: Regeln berücksichtigen die Nähe zu gefährlichen APIs
• Bewertungsmodell: Bewertet Funde nach Ausnutzbarkeit und Erreichbarkeit
• Karton-Integration: Läuft als verteilter Dienst in Malware-Analyse-Pipelines

Warum AutoPiff?

Nadel im Heuhaufen

Hersteller veröffentlicht 500 Treiber-Updates/Jahr
├── 490 sind Funktions-/Leistungs-/kosmetische Änderungen
├── 8 sind kleinere Fehlerbehebungen
└── 2 sind stille Sicherheitsfixes (kein CVE zugewiesen)

Ohne Automatisierung: Manuelles Überprüfen von 500, um 2 zu finden
Mit AutoPiff:      Überprüfung von 10 hoch bewerteten, um 2 zu finden

Sicherheitspatches werden oft ohne CVE-Zuweisung veröffentlicht. Manuelles Reverse-Engineering jedes Treiber-Updates, um die sicherheitsrelevanten zu finden, ist nicht praktikabel. AutoPiff löst dieses Problem, indem es automatisch die relevanten Änderungen hervorhebt.

Was AutoPiff automatisiert

Gesamt: 4-12 Stunden pro Treiberpaar auf 2-5 Minuten reduziert

Was weiterhin menschliches Fachwissen erfordert

┌─────────────────────────────────────────────────────────────────┐
│  AUTOMATISIERT durch AutoPiff                                    │
│  ├── Finde die Nadel: "Diese Funktion hat sich nahe ExFreePool   │
│  │     geändert"                                                 │
│  ├── Klassifiziere: "Sieht aus wie ein Use-After-Free-Fix"       │
│  └── Bewerte: "Punktzahl 5,5 – eine Untersuchung wert"          │
├─────────────────────────────────────────────────────────────────┤
│  WEITERHIN MANUELL (Ihr Fachwissen)                              │
│  ├── Bestätige Ausnutzbarkeit: "Kann ich das tatsächlich        │
│  │     auslösen?"                                                │
│  ├── Ursachenanalyse: "Warum war das verwundbar?"                │
│  ├── Exploit-Entwicklung: "Wie erreiche ich diesen Sink?"       │
│  └── Auswirkungsbewertung: "Welches reale Risiko besteht?"      │
└─────────────────────────────────────────────────────────────────┘

AutoPiff ersetzt nicht die Exploit-Forschung. Es macht sie im großen Maßstab durchführbar, indem es die Aufklärungsphase automatisiert.

Anwendungsfälle

1. Stille Patch-Erkennung

• Überwacht Treiber auf Sicherheitsfixes, die ohne CVEs veröffentlicht werden
• Erhalte Benachrichtigungen, wenn hoch bewertete semantische Deltas auftauchen
• Erfasse Sicherheitslücken, bevor sie öffentlich bekannt gegeben werden

2. 1-Tage-Schwachstellenforschung

• Wenn ein CVE angekündigt wird, identifiziere schnell den genauen Patch
• Korreliere Patch-Muster mit Schwachstellenklassen
• Beschleunige die Exploit-Entwicklungszeitpläne

3. Sicherheitsaudit von Herstellern

• Analysiere alle Versionen einer Treiberfamilie im Zeitverlauf
• Erstelle Zeitlinien, die zeigen, wann Fixes erschienen sind
• Identifiziere Muster, wie Hersteller Schwachstellen adressieren

4. Aufbau eines historischen CVE-Korpus

• Verarbeite bekannte CVE-Treiberpaare, um Trainingsdaten zu erstellen
• Validiere und verbessere Erkennungsregeln
• Erstelle eine Wissensdatenbank von Patch-Signaturen

Architektur

AutoPiff läuft als Karton-Pipeline mit 8 aufeinanderfolgenden Stufen plus einem parallelen DriverAtlas-Triage-Zweig. Jede Stufe ist ein unabhängiger Mikroservice, der über Redis/RabbitMQ kommuniziert.

graph LR
    sources["WinBIndex<br/>VirusTotal"]:::src --> s0["Stufe 0<br/>Monitor"]
    s0 --> s14["Stufen 1-4<br/>Patch Differ"]
    s0 --> triage["DriverAtlas<br/>Triage"]:::triage
    s14 --> s5["Stufe 5<br/>Erreichbarkeit"]
    s5 --> s6["Stufe 6<br/>Bewertung"]
    s6 --> s7["Stufe 7<br/>Bericht"]
    s6 --> s8["Stufe 8<br/>Alarm"]
    triage --> alerts["MWDB-Tags<br/>+ Alarme"]:::triage

    classDef src fill:#1a1a2e,stroke:#e94560,color:#eee
    classDef triage fill:#1a1a2e,stroke:#e9a345,color:#eee
    classDef default fill:#16213e,stroke:#0f3460,color:#eee

Semantische Regeln

AutoPiff enthält 58 Regeln in 22 Kategorien. Siehe Docs/semantic_rules.md für die vollständige Spezifikation und Docs/SEMANTIC_RULES_REFERENCE.md für die technische Referenz.

Sink-Gruppen

Die Regel-Engine verfolgt 50+ gefährliche API-Symbole in 8 Sink-Gruppen:

• memory_copy: RtlCopyMemory, memcpy, memmove
• pool_alloc: ExAllocatePool, ExAllocatePoolWithTag
• pool_free: ExFreePool, ExFreePoolWithTag
• user_probe: ProbeForRead, ProbeForWrite
• io_sanitization: RtlULongAdd, RtlSizeTMult
• exceptions: __try, __except
• string_copy: strcpy, wcsncpy
• refcounting: InterlockedIncrement/Decrement

Bewertungsmodell

Funde werden mit einem konfigurierbaren Modell bewertet (rules/scoring.yaml):

final_score = semantic_score + reachability_bonus + sink_bonus - penalties

Bewertungskomponenten:

• Semantischer Wert: Regelgewicht × Konfidenz × Kategoriemultiplikator
• Erreichbarkeitsbonus: IOCTL (+4,0), IRP (+2,5), PnP (+2,0), Intern (+0,5)
• Sink-Bonus: memory_copy (+1,5), user_probe (+1,5), pool_alloc (+1,2)
• Abzüge: Niedrige Matching-Qualität, hohes Rauschrisiko

Schwellwerte:

• Funde mit Konfidenz < 0,45 werden verworfen
• Matching-Konfidenz < 0,40 begrenzt den Wert auf 3,0

Installation

Als Karton-Dienst (Empfohlen)

git clone https://github.com/splintersfury/AutoPiff.git
cd AutoPiff
docker compose up -d

Für den vollständigen Produktions-Stack mit MWDB, Dashboards und Überwachung siehe driver_analyzer.

Eigenständige Bibliothek

pip install pyyaml

from services.karton_patch_differ.rule_engine import SemanticRuleEngine

engine = SemanticRuleEngine('rules/semantic_rules.yaml', 'rules/sinks.yaml')
hits = engine.evaluate(func_name, old_code, new_code, diff_lines)

Konfiguration

Umgebungsvariablen

Regelanpassung

Bearbeite rules/semantic_rules.yaml, um Regeln hinzuzufügen oder zu ändern:

rules:
  - rule_id: my_custom_rule
    category: bounds_check
    confidence: 0.85
    required_signals:
      - sink_group: memory_copy
      - change_type: guard_added
      - guard_kind: length_check
    plain_english_summary: Added length validation before memory copy.

Ausgabeformat

AutoPiff erstellt JSON-Berichte, die an MWDB-Beispiele angehängt werden:

{
  "pairing": {
    "driver_new": {"sha256": "...", "version": "2.0.9.0"},
    "driver_old": {"sha256": "...", "version": "2.0.8.0"},
    "decision": "accept",
    "confidence": 0.95
  },
  "semantic_deltas": {
    "deltas": [
      {
        "function": "HandleIoctl",
        "rule_id": "null_after_free_added",
        "category": "lifetime_fix",
        "confidence": 0.88,
        "sinks": ["pool_free"],
        "final_score": 5.5,
        "why_matters": "Pointer is now set to NULL after freeing memory."
      }
    ],
    "summary": {
      "total_deltas": 1,
      "top_score": 5.5,
      "match_rate": 100.0
    }
  }
}

Dokumentation

Projektstruktur

AutoPiff/
├── Docs/                          # Entwurfsdokumente und Spezifikationen
├── ghidra/scripts/                # Ghidra-Headless-Skripte
│   └── autopiff_reachability.py   # Erreichbarkeits-BFS + Dekompilierungs-Export
├── rules/
│   ├── semantic_rules.yaml        # 58 Erkennungsregeln
│   ├── sinks.yaml                 # 50+ gefährliche API-Symbole
│   └── scoring.yaml               # Konfiguration des Bewertungsmodells
├── schemas/                       # JSON-Schemas für jede Stufe
├── services/
│   ├── karton-patch-differ/       # Stufen 1-4: Diffing + semantische Analyse
│   ├── karton-reachability/       # Stufe 5: Call-Graph + Dekompilierung
│   ├── karton-ranking/            # Stufe 6: Bewertung
│   ├── karton-report/             # Stufe 7: Berichtserstellung
│   ├── karton-driver-triage/      # DriverAtlas-Angriffsflächen-Triage
│   ├── autopiff-alerter/          # Stufe 8: Telegram-Benachrichtigungen
│   ├── driver-monitor/            # Stufe 0: Versionsabfrage
│   └── dashboard/                 # Weboberfläche
├── tests/unit/                    # 137 Unit-Tests
├── docker-compose.yml
└── README.md

Integration mit driver_analyzer

AutoPiff ist für die Arbeit mit driver_analyzer konzipiert, der die vollständige Produktionsinfrastruktur (MWDB, Karton, MinIO, Dashboards) bereitstellt. Die compose-Datei von driver_analyzer baut AutoPiff-Dienste direkt ein:

# In driver_analyzer/docker-compose.yml
karton-driver-patch-differ:
  build:
    context: ../AutoPiff
    dockerfile: services/karton-patch-differ/Dockerfile
  volumes:
    - ../AutoPiff/rules:/app/rules:ro

Siehe die driver_analyzer README für Einrichtungsanweisungen.

Lizenz

MIT-Lizenz – Siehe LICENSE für Details.

Danksagungen

• Karton – Verteiltes Malware-Verarbeitungs-Framework
• MWDB Core – Malware-Repository
• Ghidra – NSAs Software-Reverse-Engineering-Framework