EVTX

Caratteristiche

• 🔒 Implementato utilizzando Rust 100% safe - e funziona su tutte le piattaforme supportate da Rust (che hanno stdlib).
• ⚡ Veloce - vedi i benchmark sotto. È più veloce di qualsiasi altra implementazione di ordini di grandezza!
• 🚀 Multithread.
• ✨ Supporta output XML e JSON, entrambi costruiti direttamente da una rappresentazione intermedia condivisa (IR) (nessuna conversione xml2json viene eseguita!)
• ⛏️ Supporta un recupero di base di record/chunk mancanti!
• 🐍 Sono disponibili anche binding Python su https://github.com/omerbenamram/pyevtx-rs (e su PyPi https://pypi.org/project/evtx/)

Visualizzatore basato sul web (EVTX Web)

Preferisci un'opzione senza installazione? Un esploratore EVTX completo funziona direttamente nel tuo browser, alimentato dallo stesso core Rust compilato in WebAssembly.

👉 Provalo ora: https://omerbenamram.github.io/evtx/

Tutto avviene localmente – i file non lasciano mai la tua macchina. Caratteristiche principali:

• Trascina e rilascia file .evtx (o clicca per sfogliare) – gestisce log molto grandi!
• Parsing velocissimo tramite WebAssembly e rendering a scorrimento virtuale
• Filtri facet su livello, provider, canale, ID evento e campi EventData dinamici – tutto supportato da DuckDB-WASM
• Ricerca full-text, gestione colonne ed esportazione JSON/XML in tempo reale del set filtrato
• Temi chiari/scuri, navigazione tramite tastiera e interfaccia in stile Windows

Il visualizzatore è servito staticamente da GitHub Pages; dopo il primo caricamento funziona completamente offline.

Installazione (utilità binaria associata):

• Scarica l'ultima versione eseguibile da https://github.com/omerbenamram/evtx/releases
  • Le versioni sono costruite automaticamente per Windows, macOS e Linux. (Solo eseguibili a 64 bit)
• Compila dai sorgenti usando cargo install evtx

evtx_dump (Utilità binaria):

L'utilità binaria principale fornita con questa crate è evtx_dump e fornisce un modo rapido per convertire file .evtx in diversi formati di output.

Alcuni esempi

• evtx_dump <evtx_file> scaricherà il contenuto dei record evtx come xml.
• evtx_dump -o json <evtx_file> scaricherà il contenuto dei record evtx come JSON.
• evtx_dump -f <output_file> -o json <input_file> scaricherà il contenuto dei record evtx come JSON in un file specificato.
• cat <evtx_file> | evtx_dump -o jsonl - leggerà il file EVTX da stdin (utile per piping/decompressione).

evtx_dump può essere combinato con fd per l'elaborazione batch conveniente dei file:

• fd -e evtx -x evtx_dump -o jsonl scansionerà una cartella e scaricherà tutti i file evtx in un unico file jsonlines.
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' creerà un file xml accanto a ciascun file evtx, per tutti i file nella cartella in modo ricorsivo!
• Se è necessario aggiungere la sorgente del file al json, è possibile usare xargs (o gxargs su mac) e jq: fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

Nota: per impostazione predefinita, evtx_dump tenterà di utilizzare il multithreading, il che significa che i record potrebbero essere restituiti fuori ordine. Per forzare l'uso a thread singolo (che garantirà anche l'ordine), si può passare -t 1.

Rendering offline dei template (WEVT_TEMPLATE)

I record EVTX possono fare riferimento a definizioni di template memorizzate in binari di provider (EXE/DLL/SYS). evtx_dump può estrarre questi template in una cache offline e usarli al momento del rendering.

Nota: questa funzionalità richiede la compilazione di evtx_dump con la feature Cargo wevt_templates (le versioni binarie potrebbero già includerla).

• Costruisci una cache (singolo file .wevtcache portatile):
  • evtx_dump extract-wevt-templates --input <provider.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• Scarica un file EVTX usando la cache (regola deterministica: si applica solo quando un record fallisce a causa di un GUID di template esplicitamente mancante/corrotto):
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

Aiuti per il debug:

• Scarica i valori di sostituzione di TemplateInstance di un record (JSONL):
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• Renderizza un GUID di template specifico con sostituzioni (XML su stdout):
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

Vedi docs/wevt_templates.md per dettagli e background (issue #103).

Esempio di utilizzo (come libreria):

use evtx::EvtxParser;
use std::path::PathBuf;

// Change this to a path of your .evtx sample.
let fp = PathBuf::from(format!("{}/samples/security.evtx", std::env::var("CARGO_MANIFEST_DIR").unwrap()));

let mut parser = EvtxParser::from_path(fp).unwrap();
for record in parser.records() {
    match record {
        Ok(r) => println!("Record {}\n{}", r.event_record_id, r.data),
        Err(e) => eprintln!("{}", e),
    }
}

La versione parallela è abilitata durante la compilazione con la feature "multithreading" (abilitata per impostazione predefinita).

Benchmark delle prestazioni

Quando si utilizza il multithreading - evtx è significativamente più veloce di qualsiasi altro parser disponibile. Per le prestazioni single-core, è sia il più veloce che l'unico parser multipiattaforma che supporta output sia xml che JSON.

Le prestazioni sono state misurate sulla mia macchina usando hyperfine (strumento di misurazione statistica).

Sto eseguendo i test su un AMD Ryzen 3900X a 12 core.

Esecuzione del benchmark: Giugno 2026 (evtx 0.12.2).

Sistema: Arch Linux (Linux 7.0.11-arch1-1 x86_64).

Commit del benchmark: 99a6def.

Le colonne evtx — e pyevtx-rs, i nostri binding Python, che incapsulano lo stesso core Rust — sono state rimisurate a Giugno 2026 sulla stessa macchina, dopo il rilascio della riscrittura del template compilato (vedi docs/compiled-templates.html). Entrambe sono le build PGO fornite per Linux/macOS (il binario di rilascio e la wheel PyPI; dettagli sotto). pyevtx-rs è limitato dalla marshalling Python per record (un dict per record) piuttosto che dal parser, quindi non vede il pieno aumento di velocità del core. Le restanti cifre dei concorrenti (libevtx, velocidex/evtx, golang-evtx, python-evtx) sono riprese invariate dall'esecuzione di Gennaio 2026 sullo stesso hardware — strumenti esterni le cui prestazioni non sono cambiate.

Librerie misurate:

• python-evtx(https://github.com/williballenthin/python-evtx) - Con CPython e PyPy
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - Binding Python per questa libreria
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - solo JSON (usa multithreading)
• evtx(https://github.com/Velocidex/evtx) - solo JSON.
• evtx (Questa libreria)

Nota: i numeri mostrati sono misurazioni real-time (tempo impiegato per completare l'invocazione). Le misurazioni user-time sono più elevate quando si utilizza più multithreading/multiprocessing, a causa del sovraccarico di sincronizzazione.

Con 8 thread - evtx è più di 7000x più veloce di python-evtx durante lo scaricamento di log xml.

La produttività ora satura intorno agli 8 thread su questo campione di 30 MB: l'analisi single-thread è diventata abbastanza veloce (~3.8x più veloce dei numeri di Gennaio 2026, sulla stessa macchina) che 30 MB non contiene più abbastanza lavoro per tenere occupati tutti i 24 core logici — 24 thread non sono più veloci di 8 (i due sono entro il rumore di misurazione, quindi la tabella evidenzia la colonna a 8 thread come punto di saturazione). A quel punto evtx è circa 65x più veloce di golang-evtx, che utilizza una strategia di multithreading simile.

Build PGO

I numeri sopra provengono da una build guidata dal profilo (./build_pgo.sh): allena un binario strumentato sul corpus di campioni, quindi ricostruisce con quel profilo. CI esegue questo per i binari di rilascio Linux (x86_64) e macOS, quindi la tabella riflette l'artefatto che la maggior parte delle persone scarica (l'output è byte-identico a una build normale). PGO vale circa 2-5% di produttività single-thread rispetto a un semplice cargo build --release --features fast-alloc (JSON 77.6 → 75 ms, XML 73.0 → 71 ms); a 8+ thread il carico di lavoro è saturato, quindi PGO in quel caso è entro il rumore di misurazione.

Avvertenze

• Attualmente non implementati:
  • Nodi CDATA.
  • Tipo di nodo EVTHandle.

Se il parser segnala errori su uno di questi nodi, sentiti libero di aprire un issue o inviarmi una email con un campione.

Licenza

Concesso in licenza sotto uno dei seguenti:

• Apache License, Version 2.0, (LICENSE-APACHE o http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT o http://opensource.org/licenses/MIT)

a tua scelta.

Contributo

Salvo che tu non dichiari esplicitamente il contrario, qualsiasi contributo inviato intenzionalmente per l'inclusione nel lavoro da te, come definito nella licenza Apache-2.0, sarà concesso in doppia licenza come sopra, senza termini o condizioni aggiuntivi.