Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
AutoPiff — Motore di analisi semantica per il rilevamento di correzioni di vulnerabilità nelle patch dei driver del kernel Windows — 58 regole YAML, decompilazione Ghidra, tracciamento della raggiungibilità e punteggio | Kitploit
Strumenti/GitHubGitHub/splintersfury/autopiff
Analisi StaticaAnalisi delle VulnerabilitàExploitReverse EngineeringAnalisi MalwareAnalisi di BinariAnalisi del Firmware
GitHubsplintersfury/autopiff

AutoPiff

Motore di analisi semantica per il rilevamento di correzioni di vulnerabilità nelle patch dei driver del kernel Windows — 58 regole YAML, decompilazione Ghidra, tracciamento della raggiungibilità e punteggio

Vedi Repository
64426 mesi faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

AutoPiff

Automated Patch Intelligence and Finding Framework

Un motore di analisi semantica per rilevare correzioni di vulnerabilità nelle patch dei driver del kernel Windows. AutoPiff utilizza regole YAML conservative per identificare le modifiche al codice rilevanti per la sicurezza con elevata precisione e spiegabilità.

Panoramica

AutoPiff analizza le differenze tra le versioni vulnerabili e quelle corrette dei driver per rilevare automaticamente:

  • Correzioni Use-After-Free (assegnazioni null dopo ExFreePool)
  • Aggiunte di controllo dei limiti (validazione della lunghezza prima di memcpy)
  • Rafforzamento del confine utente/kernel (ProbeForRead/ProbeForWrite)
  • Protezioni da overflow di interi (helper matematici sicuri)
  • Rafforzamento dello stato (refcounting interlocked)
  • Validazione input IOCTL, protezioni da corruzione pool, controlli privilegi e altro

Caratteristiche principali

  • Alta precisione: regole conservative minimizzano i falsi positivi
  • Spiegabile: ogni risultato include motivazione e prove
  • Consapevolezza dei sink: le regole considerano la prossimità a API pericolose
  • Modello di punteggio: classifica i risultati in base a sfruttabilità e raggiungibilità
  • Integrazione Karton: funziona come servizio distribuito nelle pipeline di analisi malware

Perché AutoPiff?

Un ago in un pagliaio

root@kitploit:~
Il fornitore rilascia 500 aggiornamenti driver/anno
├── 490 sono modifiche estetiche/di funzionalità/prestazioni
├── 8 sono correzioni di bug minori
└── 2 sono correzioni di sicurezza silenziose (nessun CVE assegnato)

Senza automazione: revisione manuale di 500 per trovare 2
Con AutoPiff:      revisione di 10 con punteggio alto per trovare 2

Le patch di sicurezza sono spesso rilasciate senza assegnazione CVE. La reverse engineering manuale di ogni aggiornamento del driver per trovare quelli rilevanti per la sicurezza non è fattibile. AutoPiff risolve questo problema individuando automaticamente le modifiche che contano.

Cosa automatizza AutoPiff

FaseSforzo manualeCon AutoPiffTempo risparmiato
Abbinamento versioni5-15 min/driverAutomatico~100%
Decompilazione2-10 min/binarioIn batch, parallelo~95%
Matching funzioni30-60 min/coppiaIstantaneo~100%
Identificazione modifiche di sicurezza2-8 ore/coppiaSecondi~99%
Triage e classificazione iniziale1-2 oreIstantaneo~100%
Generazione report30-60 minIstantaneo~100%

Totale: da 4-12 ore per coppia di driver a 2-5 minuti

Cosa richiede ancora competenza umana

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│  AUTOMATIZZATO da AutoPiff                                       │
│  ├── Trova l'ago: "Questa funzione è cambiata vicino a ExFreePool"│
│  ├── Classifica: "Sembra una correzione use-after-free"          │
│  └── Classifica: "Punteggio 5.5 - vale la pena indagare"         │
├─────────────────────────────────────────────────────────────────┤
│  ANCORA MANUALE (La tua competenza)                              │
│  ├── Conferma sfruttabilità: "Posso davvero attivarlo?"          │
│  ├── Analisi delle cause profonde: "Perché era vulnerabile?"     │
│  ├── Sviluppo exploit: "Come raggiungo questo sink?"             │
│  └── Valutazione dell'impatto: "Qual è il rischio nel mondo reale?"│
└─────────────────────────────────────────────────────────────────┘

AutoPiff non sostituisce la ricerca sugli exploit. La rende fattibile su larga scala automatizzando la fase di ricognizione.

Casi d'uso

1. Rilevamento di patch silenziose

  • Monitora i driver per correzioni di sicurezza rilasciate senza CVE
  • Ricevi avvisi quando compaiono delta semantici con punteggio alto
  • Cattura le vulnerabilità prima che siano divulgate pubblicamente

2. Ricerca di vulnerabilità 1-Day

  • Quando viene annunciato un CVE, identifica rapidamente la patch esatta
  • Correla i modelli di patch con le classi di vulnerabilità
  • Accelera le tempistiche di sviluppo exploit

3. Audit di sicurezza del fornitore

  • Analizza tutte le versioni di una famiglia di driver nel tempo
  • Genera timeline che mostrano quando sono apparse le correzioni
  • Identifica modelli nel modo in cui i fornitori affrontano le vulnerabilità

4. Creazione di un corpus CVE storico

  • Elabora coppie di driver CVE note per costruire dati di training
  • Convalida e migliora le regole di rilevamento
  • Crea una knowledge base di firme di patch

Architettura

AutoPiff funziona come una pipeline Karton con 8 fasi sequenziali più un ramo parallelo di triage DriverAtlas. Ogni fase è un microservizio indipendente che comunica tramite Redis/RabbitMQ.

root@kitploit:~
graph LR
    sources["WinBIndex<br/>VirusTotal"]:::src --> s0["Fase 0<br/>Monitor"]
    s0 --> s14["Fasi 1-4<br/>Patch Differ"]
    s0 --> triage["DriverAtlas<br/>Triage"]:::triage
    s14 --> s5["Fase 5<br/>Raggiungibilità"]
    s5 --> s6["Fase 6<br/>Classificazione"]
    s6 --> s7["Fase 7<br/>Report"]
    s6 --> s8["Fase 8<br/>Alerter"]
    triage --> alerts["MWDB Tags<br/>+ Avvisi"]:::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
FaseServizioCosa fa
0driver-monitorSonda WinBIndex e VirusTotal per nuove versioni di driver, carica su MWDB
1-4karton-patch-differAbbinamento versioni, decompilazione Ghidra, matching funzioni, valutazione regole semantiche
5karton-reachabilityBFS del grafo delle chiamate Ghidra dai punti di ingresso IOCTL/IRP alle funzioni modificate, esportazione decompilazione completa
6karton-rankingValuta i risultati usando raggiungibilità, gravità semantica e superficie d'attacco
7karton-reportGenera report markdown strutturati, carica su MWDB
8autopiff-alerterInvia avvisi Telegram per risultati con punteggio >= 8.0
—autopiff-driver-triageValutazione superficie d'attacco DriverAtlas (parallelo a 1-4), tagga campioni MWDB, avvisi Telegram

Regole semantiche

AutoPiff include 58 regole in 22 categorie. Vedi Docs/semantic_rules.md per le specifiche complete e Docs/SEMANTIC_RULES_REFERENCE.md per il riferimento tecnico.

CategoriaEsempio di rilevamento
bounds_checkAggiunto controllo lunghezza prima di memcpy
lifetime_fixAssegnazione null dopo ExFreePool
user_boundary_checkAggiunto ProbeForRead/ProbeForWrite
int_overflowUtilizzo helper matematici sicuri
state_hardeningOperazioni refcount interlocked
ioctl_input_validationNuovi controlli dimensione/tipo negli handler dispatch
pool_type_hardeningMigrazione a NonPagedPoolNx
privilege_checkAggiunto SeSinglePrivilegeCheck

Gruppi di sink

Il motore delle regole tiene traccia di oltre 50 simboli API pericolosi in 8 gruppi di sink:

  • 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

Modello di punteggio

I risultati vengono valutati utilizzando un modello configurabile (rules/scoring.yaml):

root@kitploit:~
punteggio_finale = punteggio_semantico + bonus_raggiungibilità + bonus_sink - penalità

Componenti del punteggio:

  • Punteggio semantico: Peso regola x confidenza x moltiplicatore categoria
  • Bonus raggiungibilità: IOCTL (+4.0), IRP (+2.5), PnP (+2.0), Interno (+0.5)
  • Bonus sink: memory_copy (+1.5), user_probe (+1.5), pool_alloc (+1.2)
  • Penalità: Bassa qualità matching, alto rischio rumore

Soglie:

  • I risultati con confidenza < 0.45 vengono scartati
  • Confidenza matching < 0.40 limita il punteggio a 3.0

Installazione

Come servizio Karton (Consigliato)

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

Per lo stack di produzione completo con MWDB, dashboard e monitoraggio, vedi driver_analyzer.

Libreria standalone

root@kitploit:~
pip install pyyaml

from services.karton_patch_differ.rule_engine import SemanticRuleEngine

engine = SemanticRuleEngine('rules/semantic_rules.yaml', 'rules/sinks.yaml')
hits = engine.evaluate(nome_funzione, codice_vecchio, codice_nuovo, linee_diff)

Configurazione

Variabili d'ambiente

VariabileDescrizioneDefault
MWDB_API_URLEndpoint API MWDB Corehttp://mwdb-core:8080/api/
MWDB_API_KEYChiave API MWDB per upload(obbligatorio)
KARTON_REDIS_HOSTHost Redis per Kartonkarton-redis
AUTOPIFF_GHIDRA_TIMEOUTTimeout decompilazione Ghidra (sec)900
VT_API_KEYChiave API VirusTotal per monitoraggio driver(opzionale)
TELEGRAM_BOT_TOKENToken bot Telegram per avvisi(opzionale)
TELEGRAM_CHAT_IDChat Telegram per avvisi(opzionale)
AUTOPIFF_SCORE_THRESHOLDPunteggio minimo per avvisi Telegram8.0
DRIVERATLAS_SCORE_THRESHOLDPunteggio superficie d'attacco minimo per avvisi triage8.0

Personalizzazione delle regole

Modifica rules/semantic_rules.yaml per aggiungere o modificare regole:

root@kitploit:~
rules:
  - rule_id: mia_regola_personalizzata
    category: bounds_check
    confidence: 0.85
    required_signals:
      - sink_group: memory_copy
      - change_type: guard_added
      - guard_kind: length_check
    plain_english_summary: Aggiunta validazione lunghezza prima della copia di memoria.

Formato di output

AutoPiff produce report JSON allegati ai campioni MWDB:

root@kitploit:~
{
  "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": "Il puntatore ora viene impostato a NULL dopo la liberazione della memoria."
      }
    ],
    "summary": {
      "total_deltas": 1,
      "top_score": 5.5,
      "match_rate": 100.0
    }
  }
}

Documentazione

DocumentoDescrizione
Docs/semantic_rules.mdSpecifica delle regole semantiche: come sono strutturate le regole e cosa rileva ciascuna categoria
Docs/SEMANTIC_RULES_REFERENCE.mdRiferimento tecnico per il motore delle regole, la logica di valutazione e il punteggio
Docs/reachability.mdSpecifica del tagging di raggiungibilità: BFS del grafo delle chiamate dai punti di ingresso dispatch
Docs/reporting.mdSpecifica e formato dell'output dei report
Docs/decisions.mdDecisioni di progettazione e registro motivazioni
rules/semantic_rules.yamlTutte le 58 regole di rilevamento (YAML)
rules/sinks.yamlOltre 50 simboli API pericolosi raggruppati per categoria
rules/scoring.yamlConfigurazione del modello di punteggio
schemas/Schemi JSON per l'output di ogni fase della pipeline

Struttura del progetto

root@kitploit:~
AutoPiff/
├── Docs/                          # Documenti di progettazione e specifiche
├── ghidra/scripts/                # Script Ghidra headless
│   └── autopiff_reachability.py   # BFS raggiungibilità + esportazione decompilazione
├── rules/
│   ├── semantic_rules.yaml        # 58 regole di rilevamento
│   ├── sinks.yaml                 # Oltre 50 simboli API pericolosi
│   └── scoring.yaml               # Configurazione del modello di punteggio
├── schemas/                       # Schemi JSON per ogni fase
├── services/
│   ├── karton-patch-differ/       # Fasi 1-4: diffing + analisi semantica
│   ├── karton-reachability/       # Fase 5: grafo chiamate + decompilazione
│   ├── karton-ranking/            # Fase 6: punteggio
│   ├── karton-report/             # Fase 7: generazione report
│   ├── karton-driver-triage/      # Triage superficie d'attacco DriverAtlas
│   ├── autopiff-alerter/          # Fase 8: avvisi Telegram
│   ├── driver-monitor/            # Fase 0: polling versioni
│   └── dashboard/                 # Interfaccia web
├── tests/unit/                    # 137 test unitari
├── docker-compose.yml
└── README.md

Integrazione con driver_analyzer

AutoPiff è progettato per funzionare con driver_analyzer, che fornisce l'infrastruttura di produzione completa (MWDB, Karton, MinIO, dashboard). Il file compose di driver_analyzer costruisce i servizi AutoPiff direttamente:

root@kitploit:~
# 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

Vedi il README di driver_analyzer per le istruzioni di configurazione.

Licenza

Licenza MIT - Vedi LICENSE per i dettagli.

Ringraziamenti

  • Karton - Framework distribuito per l'elaborazione malware
  • MWDB Core - Repository malware
  • Ghidra - Framework di reverse engineering della NSA
Scarica lo strumento