EVTX

Características

• 🔒 Implementado usando 100% Rust seguro - y funciona en todas las plataformas soportadas por Rust (que tengan stdlib).
• ⚡ Rápido - vea los benchmarks a continuación. ¡Es más rápido que cualquier otra implementación por órdenes de magnitud!
• 🚀 Multihilo.
• ✨ Soporta salidas XML y JSON, ambas construidas directamente a partir de una representación intermedia compartida (IR) (¡no se realiza conversión xml2json!)
• ⛏️ Soporta cierta recuperación básica de registros/chunks faltantes.
• 🐍 Los bindings de Python también están disponibles en https://github.com/omerbenamram/pyevtx-rs (y en PyPi https://pypi.org/project/evtx/)

Visor basado en web (EVTX Web)

¿Prefieres una opción sin instalación? Un explorador EVTX con todas las funciones se ejecuta directamente en tu navegador, impulsado por el mismo núcleo Rust compilado a WebAssembly.

👉 Pruébalo ahora: https://omerbenamram.github.io/evtx/

Todo ocurre localmente – los archivos nunca salen de tu máquina. Destacados:

• Arrastra y suelta archivos .evtx (o haz clic para explorar) – ¡maneja logs muy grandes!
• Análisis ultrarrápido mediante WebAssembly y renderizado con desplazamiento virtual
• Filtros por facetas en nivel, proveedor, canal, ID de evento y campos dinámicos de EventData – todo respaldado por DuckDB-WASM
• Búsqueda de texto completo, gestión de columnas y exportación en vivo a JSON/XML del conjunto filtrado
• Temas claro/oscuro, navegación por teclado y una interfaz al estilo Windows

El visor se sirve estáticamente desde GitHub Pages; tras la primera carga funciona completamente sin conexión.

Instalación (utilidad binaria asociada):

• Descarga la última versión ejecutable desde https://github.com/omerbenamram/evtx/releases
  • Las versiones se construyen automáticamente para Windows, macOS y Linux. (solo ejecutables de 64 bits)
• Compila desde las fuentes usando cargo install evtx

evtx_dump (Utilidad binaria):

La utilidad binaria principal proporcionada con esta crate es evtx_dump, y proporciona una forma rápida de convertir archivos .evtx a diferentes formatos de salida.

Algunos ejemplos

• evtx_dump <evtx_file> volcará el contenido de los registros evtx como xml.
• evtx_dump -o json <evtx_file> volcará el contenido de los registros evtx como JSON.
• evtx_dump -f <output_file> -o json <input_file> volcará el contenido de los registros evtx como JSON a un archivo dado.
• cat <evtx_file> | evtx_dump -o jsonl - leerá el archivo EVTX desde stdin (útil para tuberías/descompresión).

evtx_dump se puede combinar con fd para el procesamiento por lotes conveniente de archivos:

• fd -e evtx -x evtx_dump -o jsonl escaneará una carpeta y volcará todos los archivos evtx a un único archivo jsonlines.
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' creará un archivo xml junto a cada archivo evtx, ¡para todos los archivos en la carpeta de forma recursiva!
• Si es necesario agregar la fuente del archivo a json, se puede usar xargs (o gxargs en mac) y jq: fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

Nota: por defecto, evtx_dump intentará utilizar multihilo, esto significa que los registros pueden devolverse desordenados.

Para forzar el uso de un solo hilo (lo que también asegurará el orden), se puede pasar -t 1.

Renderizado de plantillas sin conexión (WEVT_TEMPLATE)

Los registros EVTX pueden hacer referencia a definiciones de plantillas almacenadas en binarios de proveedores (EXE/DLL/SYS). evtx_dump puede extraer esas plantillas en una caché sin conexión y usarlas al renderizar.

Nota: esta funcionalidad requiere compilar evtx_dump con la característica de Cargo wevt_templates (los binarios de lanzamiento pueden ya incluirla).

• Construir una caché (un único archivo portátil .wevtcache):
  • evtx_dump extract-wevt-templates --input <provider.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• Volcar un archivo EVTX usando la caché (regla determinista: solo se aplica cuando un registro falla debido a un GUID de plantilla explícitamente faltante o corrupto):
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

Ayudantes de depuración:

• Volcar los valores de sustitución de TemplateInstance de un registro (JSONL):
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• Renderizar un GUID de plantilla específico con sustituciones (XML a stdout):
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

Consulte docs/wevt_templates.md para obtener detalles y antecedentes (issue #103).

Ejemplo de uso (como biblioteca):

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 versión en paralelo se habilita al compilar con la característica "multithreading" (habilitada por defecto).

Benchmarks de rendimiento

Al usar multihilo, evtx es significativamente más rápido que cualquier otro analizador disponible. En rendimiento de un solo núcleo, es tanto el más rápido como el único analizador multiplataforma que soporta salidas XML y JSON.

El rendimiento se evaluó en mi máquina usando hyperfine (herramienta de mediciones estadísticas).

Estoy ejecutando pruebas en un AMD Ryzen 3900X de 12 núcleos.

Ejecución del benchmark: Junio 2026 (evtx 0.12.2).

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

Commit del benchmark: 99a6def.

Las columnas de evtx — y pyevtx-rs, nuestros propios bindings de Python, que envuelven el mismo núcleo Rust — fueron re-medidas en junio de 2026 en esta misma máquina, después de que la reescritura de plantillas compiladas se implementara (consulte docs/compiled-templates.html). Ambos son las compilaciones PGO que se distribuyen para Linux/macOS (el binario de lanzamiento y el wheel de PyPI; detalles abajo). pyevtx-rs está limitado por el marshaling de Python por registro (un dict por registro) en lugar del analizador, por lo que no ve la aceleración completa del núcleo. Las cifras restantes de competidores (libevtx, velocidex/evtx, golang-evtx, python-evtx) se trasladan sin cambios desde la ejecución de enero de 2026 en el mismo hardware — herramientas externas cuyo rendimiento no ha cambiado.

Libraries benched:

• python-evtx(https://github.com/williballenthin/python-evtx) - Con CPython y PyPy
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - bindings de Python para esta biblioteca
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - solo JSON (usa multihilo)
• evtx(https://github.com/Velocidex/evtx) - solo JSON.
• evtx (Esta biblioteca)

Nota: los números mostrados son mediciones de tiempo real (tiempo que tarda la invocación en completarse). Las mediciones de tiempo de usuario son más altas cuando se usa más multihilo/multiprocesamiento, debido a la sobrecarga de sincronización.

Con 8 hilos, evtx es más de 7000x más rápido que python-evtx al volcar logs xml.

El rendimiento ahora se satura alrededor de 8 hilos en esta muestra de 30MB: el análisis de un solo hilo se volvió lo suficientemente rápido (~3.8 veces más rápido que los números de enero de 2026, en la misma máquina) que 30MB ya no tiene suficiente trabajo para mantener ocupados los 24 núcleos lógicos — 24 hilos no es más rápido que 8 (ambos están dentro del ruido de medición, por lo que la tabla destaca la columna de 8 hilos como el punto de saturación). En ese punto, evtx es aproximadamente 65x más rápido que golang-evtx, que utiliza una estrategia de multihilo similar.

Compilación PGO

Los números anteriores provienen de una compilación guiada por perfil (./build_pgo.sh): entrena un binario instrumentado en el corpus de muestra, luego recompila con ese perfil. CI ejecuta esto para los binarios de lanzamiento de Linux (x86_64) y macOS, por lo que la tabla refleja el artefacto que la mayoría de la gente descarga (la salida es byte-idéntica a una compilación normal). PGO vale aproximadamente un 2–5% de rendimiento de un solo hilo en comparación con un cargo build --release --features fast-alloc simple (JSON 77.6 → 75 ms, XML 73.0 → 71 ms); con 8+ hilos la carga de trabajo está limitada por saturación, por lo que PGO allí está dentro del ruido de medición.

Advertencias

• Actualmente no implementado:
  • Nodos CDATA.
  • Tipo de nodo EVTHandle.

Si el analizador da error en alguno de estos nodos, no dudes en abrir un issue o enviarme un correo electrónico con una muestra.

Licencia

Licenciado bajo cualquiera de

• 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 tu elección.

Contribución

A menos que indiques explícitamente lo contrario, cualquier contribución enviada intencionalmente para su inclusión en el trabajo por ti, según lo definido en la licencia Apache-2.0, se licenciará de forma dual como se indica arriba, sin términos ni condiciones adicionales.