EVTX

Funktionen

• 🔒 Implementiert mit 100 % sicherem Rust – und läuft auf allen von Rust unterstützten Plattformen (die eine stdlib haben).
• ⚡ Schnell – siehe Benchmarks unten. Um Größenordnungen schneller als jede andere Implementierung!
• 🚀 Multithreaded.
• ✨ Unterstützt XML- und JSON-Ausgaben, beide direkt aus einer gemeinsamen Zwischendarstellung (IR) erstellt (keine xml2json-Konvertierung!).
• ⛏️ Unterstützt eine grundlegende Wiederherstellung fehlender Datensätze/Chunks!
• 🐍 Python-Bindings sind ebenfalls verfügbar unter https://github.com/omerbenamram/pyevtx-rs (und auf PyPi https://pypi.org/project/evtx/)

Webbasierter Viewer (EVTX Web)

Bevorzugen Sie eine installationsfreie Option? Ein voll ausgestatteter EVTX-Explorer läuft direkt in Ihrem Browser, unterstützt von demselben Rust-Kern, der zu WebAssembly kompiliert wurde.

👉 Jetzt ausprobieren: https://omerbenamram.github.io/evtx/

Alles geschieht lokal – Dateien verlassen niemals Ihren Rechner. Highlights:

• Drag-and-Drop von .evtx-Dateien (oder Klicken zum Durchsuchen) – verarbeitet auch sehr große Logs!
• Blitzschnelles Parsen via WebAssembly und Virtual-Scroll-Rendering
• Facettierte Filter auf Level, Anbieter, Kanal, Ereignis-ID und dynamische EventData-Felder – alle unterstützt durch DuckDB-WASM
• Volltextsuche, Spaltenverwaltung und sofortiger JSON/XML-Export des gefilterten Satzes
• Helle/dunkle Designs, Tastaturnavigation und eine Windows-ähnliche Benutzeroberfläche

Der Viewer wird statisch von GitHub Pages ausgeliefert; nach dem ersten Laden funktioniert er vollständig offline.

Installation (zugehöriges Binärprogramm):

• Laden Sie die neueste ausführbare Version von https://github.com/omerbenamram/evtx/releases herunter
  • Releases werden automatisch für Windows, macOS und Linux erstellt. (Nur 64-Bit-Executables)
• Aus den Quellen erstellen mit cargo install evtx

evtx_dump (Binärprogramm):

Das wichtigste Binärprogramm, das mit dieser Crate bereitgestellt wird, ist evtx_dump, und es bietet eine schnelle Möglichkeit, .evtx-Dateien in verschiedene Ausgabeformate zu konvertieren.

Einige Beispiele

• evtx_dump <evtx_datei> gibt den Inhalt der EVTX-Datensätze als XML aus.
• evtx_dump -o json <evtx_datei> gibt den Inhalt der EVTX-Datensätze als JSON aus.
• evtx_dump -f <ausgabedatei> -o json <eingabedatei> gibt den Inhalt der EVTX-Datensätze als JSON in eine bestimmte Datei aus.
• cat <evtx_datei> | evtx_dump -o jsonl - liest die EVTX-Datei von der Standardeingabe (nützlich für Piping/Dekompression).

evtx_dump kann mit fd für die bequeme Stapelverarbeitung von Dateien kombiniert werden:

• fd -e evtx -x evtx_dump -o jsonl durchsucht einen Ordner und gibt alle EVTX-Dateien in eine einzige JSON-Lines-Datei aus.
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' erstellt neben jeder EVTX-Datei eine XML-Datei, und zwar für alle Dateien im Ordner rekursiv!
• Wenn die Quelle der Datei zum JSON hinzugefügt werden muss, können xargs (oder gxargs auf dem Mac) und jq verwendet werden: fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

Hinweis: Standardmäßig versucht evtx_dump, Multithreading zu nutzen. Das bedeutet, dass die Datensätze möglicherweise in falscher Reihenfolge zurückgegeben werden.

Um eine Single-Thread-Nutzung zu erzwingen (die auch die Reihenfolge sicherstellt), kann -t 1 übergeben werden.

Offline-Template-Rendering (WEVT_TEMPLATE)

EVTX-Datensätze können auf Template-Definitionen verweisen, die in Anbieter-Binärdateien (EXE/DLL/SYS) gespeichert sind. evtx_dump kann diese Templates in einen Offline-Cache extrahieren und sie zur Renderzeit verwenden.

Hinweis: Diese Funktionalität erfordert das Erstellen von evtx_dump mit dem Cargo-Feature wevt_templates (Release-Binärdateien enthalten es möglicherweise bereits).

• Einen Cache erstellen (einzelne tragbare .wevtcache-Datei):
  • evtx_dump extract-wevt-templates --input <anbieter.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• Eine EVTX-Datei unter Verwendung des Caches ausgeben (deterministische Regel: wird nur angewendet, wenn ein Datensatz aufgrund einer explizit fehlenden/beschädigten Template-GUID fehlschlägt):
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

Debugging-Hilfen:

• Substitutionswerte einer TemplateInstance eines Datensatzes ausgeben (JSONL):
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• Eine bestimmte Template-GUID mit Substitutionen rendern (XML nach stdout):
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

Siehe docs/wevt_templates.md für Details und Hintergrund (Issue #103).

Beispielverwendung (als Bibliothek):

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),
    }
}

Die parallele Version ist aktiviert, wenn mit dem Feature "multithreading" kompiliert wird (standardmäßig aktiviert).

Leistungs-Benchmarking

Bei Verwendung von Multithreading ist evtx deutlich schneller als jeder andere verfügbare Parser. Für die Single-Core-Leistung ist es sowohl der schnellste als auch der einzige plattformübergreifende Parser, der sowohl XML- als auch JSON-Ausgaben unterstützt.

Die Leistung wurde auf meinem Rechner mit hyperfine (statistisches Messwerkzeug) gemessen.

Ich führe Tests auf einem 12-Kern AMD Ryzen 3900X durch.

Bench-Lauf: Juni 2026 (evtx 0.12.2).

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

Benchmark-Commit: 99a6def.

Die evtx-Spalten – und pyevtx-rs, unsere eigenen Python-Bindings, die denselben Rust-Kern verwenden – wurden im Juni 2026 auf demselben Rechner neu gemessen, nachdem die kompilierte Template-Neufassung eingeführt wurde (siehe docs/compiled-templates.html). Beides sind die PGO-Builds, die für Linux/macOS ausgeliefert werden (das Release-Binary und das PyPI-Wheel; Details unten). pyevtx-rs ist durch das Marshalling pro Datensatz (ein Dict pro Datensatz) eingeschränkt, nicht durch den Parser, sodass es die volle Kern-Beschleunigung nicht sieht. Die verbleibenden Konkurrenzwerte (libevtx, velocidex/evtx, golang-evtx, python-evtx) sind unverändert aus dem Januar-2026-Lauf auf derselben Hardware übernommen – externe Werkzeuge, deren Leistung sich nicht geändert hat.

Verglichene Bibliotheken:

• python-evtx(https://github.com/williballenthin/python-evtx) - Mit CPython und PyPy
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - Python-Bindings für diese Bibliothek
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - nur JSON (verwendet Multithreading)
• evtx(https://github.com/Velocidex/evtx) - nur JSON.
• evtx (Diese Bibliothek)

Hinweis: Die gezeigten Zahlen sind real-time-Messungen (Zeit, die der Aufruf benötigt). user-time-Messungen sind bei Verwendung von Multithreading/Multiprozessing aufgrund des Synchronisationsaufwands höher.

Mit 8 Threads ist evtx mehr als 7000x schneller als python-evtx beim Ausgeben von XML-Logs.

Der Durchsatz sättigt bei diesem 30MB-Beispiel bei etwa 8 Threads: Single-Threaded-Parsing ist schnell genug (etwa 3,8x schneller als die Januar-2026-Zahlen auf demselben Rechner), sodass 30MB nicht mehr genug Arbeit bietet, um alle 24 logischen Kerne auszulasten – 24 Threads sind nicht schneller als 8 (die beiden liegen innerhalb der Messungenauigkeit, daher hebt die Tabelle die 8-Thread-Spalte als Sättigungspunkt hervor). An diesem Punkt ist evtx etwa 65x schneller als golang-evtx, das eine ähnliche Multithreading-Strategie verwendet.

PGO-Build

Die obigen Zahlen stammen von einem profilgesteuerten Build (./build_pgo.sh): Es trainiert ein instrumentiertes Binary auf dem Beispielkorpus und erstellt dann mit diesem Profil neu. CI führt dies für die Linux (x86_64)- und macOS-Release-Binaries aus, sodass die Tabelle das Artefakt widerspiegelt, das die meisten Leute herunterladen (die Ausgabe ist byteidentisch mit einem normalen Build). PGO bringt etwa 2–5 % Single-Threaded-Durchsatz gegenüber einem einfachen cargo build --release --features fast-alloc (JSON 77.6 → 75 ms, XML 73.0 → 71 ms); bei 8+ Threads ist die Arbeitslast sättigungsgebunden, sodass PGO dort innerhalb der Messungenauigkeit liegt.

Einschränkungen

• Derzeit nicht implementiert:
  • CDATA-Knoten.
  • EVTHandle-Knotentyp.

Wenn der Parser bei einem dieser Knoten einen Fehler ausgibt, können Sie gerne ein Issue eröffnen oder mir eine E-Mail mit einem Beispiel schicken.

Lizenz

Lizenziert unter einer der folgenden Lizenzen:

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

nach Ihrer Wahl.

Beitrag

Sofern Sie nicht ausdrücklich etwas anderes erklären, wird jeder Beitrag, den Sie absichtlich zur Aufnahme in das Werk einreichen, wie von Ihnen im Sinne der Apache-2.0-Lizenz definiert, unter den oben genannten Lizenzen dual lizenziert, ohne zusätzliche Bedingungen oder Klauseln.