EVTX

Fonctionnalités

• 🔒 Implémenté en utilisant 100% de Rust sécurisé - et fonctionne sur toutes les plateformes supportées par Rust (qui ont stdlib).
• ⚡ Rapide - voir les benchmarks ci-dessous. Il est plus rapide que toute autre implémentation par ordre(s) de grandeur !
• 🚀 Multi‑threadé.
• ✨ Prend en charge les sorties XML et JSON, toutes deux directement construites à partir d'une représentation intermédiaire (IR) partagée (aucune conversion xml2json n'est effectuée !)
• ⛏️ Prend en charge une récupération de base des enregistrements/blocs manquants !
• 🐍 Des liaisons Python sont également disponibles à l'adresse https://github.com/omerbenamram/pyevtx-rs (et sur PyPi https://pypi.org/project/evtx/)

Visualiseur Web (EVTX Web)

Vous préférez une option sans installation ? Un explorateur EVTX complet s'exécute directement dans votre navigateur, propulsé par le même noyau Rust compilé en WebAssembly.

👉 Essayez-le maintenant : https://omerbenamram.github.io/evtx/

Tout se passe localement – les fichiers ne quittent jamais votre machine. Points forts :

• Glissez-déposez des fichiers .evtx (ou cliquez pour parcourir) – gère de très gros fichiers journaux !
• Analyse extrêmement rapide via WebAssembly et rendu à défilement virtuel
• Filtres à facettes sur le niveau, le fournisseur, le canal, l'ID d'événement et les champs EventData dynamiques – tous soutenus par DuckDB‑WASM
• Recherche en texte intégral, gestion des colonnes et export JSON/XML à la volée de l'ensemble filtré
• Thèmes clair/sombre, navigation au clavier et interface utilisateur de style Windows

Le visualiseur est servi statiquement depuis GitHub Pages ; après le premier chargement, il fonctionne complètement hors ligne.

Installation (utilitaire binaire associé) :

• Téléchargez la dernière version exécutable depuis https://github.com/omerbenamram/evtx/releases
  • Les versions sont automatiquement construites pour Windows, macOS et Linux. (exécutables 64 bits uniquement)
• Construisez à partir des sources en utilisant cargo install evtx

evtx_dump (Utilitaire binaire) :

L'utilitaire binaire principal fourni avec cette crate est evtx_dump, et il offre un moyen rapide de convertir des fichiers .evtx en différents formats de sortie.

Quelques exemples

• evtx_dump <evtx_file> exportera le contenu des enregistrements evtx en xml.
• evtx_dump -o json <evtx_file> exportera le contenu des enregistrements evtx en JSON.
• evtx_dump -f <output_file> -o json <input_file> exportera le contenu des enregistrements evtx en JSON vers un fichier donné.
• cat <evtx_file> | evtx_dump -o jsonl - lira le fichier EVTX depuis stdin (utile pour le pipe/décompression).

evtx_dump peut être combiné avec fd pour un traitement par lots pratique des fichiers :

• fd -e evtx -x evtx_dump -o jsonl analysera un dossier et exportera tous les fichiers evtx vers un seul fichier jsonlines.
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' créera un fichier xml à côté de chaque fichier evtx, pour tous les fichiers du dossier de manière récursive !
• Si la source du fichier doit être ajoutée au json, xargs (ou gxargs sur mac) et jq peuvent être utilisés : fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

Remarque : par défaut, evtx_dump essaiera d'utiliser le multithreading, ce qui signifie que les enregistrements peuvent être retournés dans le désordre.

Pour forcer l'utilisation d'un seul thread (ce qui garantira également l'ordre), -t 1 peut être passé.

Rendu hors ligne des modèles (WEVT_TEMPLATE)

Les enregistrements EVTX peuvent référencer des définitions de modèle stockées dans les binaires du fournisseur (EXE/DLL/SYS). evtx_dump peut extraire ces modèles dans un cache hors ligne et les utiliser au moment du rendu.

Remarque : cette fonctionnalité nécessite de construire evtx_dump avec la fonctionnalité Cargo wevt_templates (les binaires de version peuvent déjà l'inclure).

• Construire un cache (fichier .wevtcache portable unique) :
  • evtx_dump extract-wevt-templates --input <provider.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• Exporter un fichier EVTX en utilisant le cache (règle déterministe : s'applique uniquement lorsqu'un enregistrement échoue en raison d'un GUID de modèle explicitement manquant/corrompu) :
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

Aides au débogage :

• Exporter les valeurs de substitution TemplateInstance d'un enregistrement (JSONL) :
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• Rendre un GUID de modèle spécifique avec substitutions (XML vers stdout) :
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

Voir docs/wevt_templates.md pour les détails et le contexte (issue #103).

Exemple d'utilisation (en tant que bibliothèque) :

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 version parallèle est activée lors de la compilation avec la fonctionnalité "multithreading" (activée par défaut).

Benchmarking des performances

En utilisant le multithreading - evtx est significativement plus rapide que tout autre analyseur disponible. Pour les performances monocœur, il est à la fois le plus rapide et le seul analyseur multiplateforme qui prend en charge les sorties xml et JSON.

Les performances ont été mesurées sur ma machine avec hyperfine (outil de mesures statistiques).

Je lance les tests sur un AMD Ryzen 3900X 12 cœurs.

Exécution du benchmark : Juin 2026 (evtx 0.12.2).

Système : Arch Linux (Linux 7.0.11-arch1-1 x86_64).

Commit du benchmark : 99a6def.

Les colonnes evtx — et pyevtx-rs, nos propres liaisons Python, qui encapsulent le même noyau Rust — ont été remesurées en Juin 2026 sur cette même machine, après l'arrivée de la réécriture des modèles compilés (voir docs/compiled-templates.html). Les deux sont les builds PGO qui sont livrés pour Linux/macOS (le binaire de version et la roue PyPI ; détails ci-dessous). pyevtx-rs est limité par le marshaling Python par enregistrement (un dict par enregistrement) plutôt que par l'analyseur, donc il ne voit pas l'accélération complète du noyau. Les chiffres des concurrents restants (libevtx, velocidex/evtx, golang-evtx, python-evtx) sont repris inchangés de l'exécution de Janvier 2026 sur le même matériel — des outils externes dont les performances n'ont pas changé.

Bibliothèques testées :

• python-evtx(https://github.com/williballenthin/python-evtx) - Avec CPython et PyPy
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - Liaisons Python pour cette bibliothèque
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - seulement JSON (utilise le multithreading)
• evtx(https://github.com/Velocidex/evtx) - seulement JSON.
• evtx (Cette bibliothèque)

Remarque : les nombres affichés sont des mesures de temps réel (temps nécessaire pour terminer l'invocation). Les mesures de temps utilisateur sont plus élevées lors de l'utilisation du multithreading/multiprocessing, en raison de la surcharge de synchronisation.

Avec 8 threads - evtx est plus de 7000x plus rapide que python-evtx lorsqu'il exporte des journaux xml.

Le débit sature désormais à environ 8 threads sur cet échantillon de 30 Mo : l'analyse monothread est devenue suffisamment rapide (~3,8 fois plus rapide que les chiffres de janvier 2026, sur la même machine) pour que 30 Mo ne contiennent plus assez de travail pour occuper les 24 cœurs logiques — 24 threads ne sont pas plus rapides que 8 (les deux sont dans le bruit de mesure, donc le tableau met en évidence la colonne 8 threads comme point de saturation). À ce stade, evtx est environ 65x plus rapide que golang-evtx, qui utilise une stratégie de multithreading similaire.

Build PGO

Les chiffres ci-dessus proviennent d'une build guidée par profil (./build_pgo.sh) : elle entraîne un binaire instrumenté sur le corpus d'échantillons, puis reconstruit avec ce profil. CI exécute cela pour les binaires de version Linux (x86_64) et macOS, donc le tableau reflète l'artefact que la plupart des gens téléchargent (la sortie est identique octet par octet à une build normale). PGO apporte environ 2 à 5 % de débit monothread par rapport à un simple cargo build --release --features fast-alloc (JSON 77,6 → 75 ms, XML 73,0 → 71 ms) ; à 8+ threads, la charge de travail est limitée par saturation, donc PGO y est dans le bruit de mesure.

Limitations

• Actuellement non implémenté :
  • Nœuds CDATA.
  • Type de nœud EVTHandle.

Si l'analyseur génère une erreur sur l'un de ces nœuds, n'hésitez pas à ouvrir un problème ou à m'envoyer un email avec un échantillon.

Licence

Sous licence selon l'une ou l'autre des

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

à votre discrétion.

Contribution

Sauf indication contraire explicite de votre part, toute contribution intentionnellement soumise pour inclusion dans le travail par vous, telle que définie dans la licence Apache-2.0, sera doublement licenciée comme ci-dessus, sans aucun terme ou condition supplémentaire.