EVTX

Funcionalidades

• 🔒 Implementado usando 100% Rust seguro - e funciona em todas as plataformas suportadas pelo Rust (que possuem stdlib).
• ⚡ Rápido - veja benchmarks abaixo. É mais rápido que qualquer outra implementação por ordens de magnitude!
• 🚀 Multi-threaded.
• ✨ Suporta saídas XML e JSON, ambas construídas diretamente de uma representação intermediária (RI) compartilhada (nenhuma conversão xml2json é realizada!)
• ⛏️ Suporta alguma recuperação básica de registros/chunks ausentes!
• 🐍 Bindings Python também estão disponíveis em https://github.com/omerbenamram/pyevtx-rs (e no PyPi https://pypi.org/project/evtx/)

Visualizador baseado na Web (EVTX Web)

Prefere uma opção sem instalação? Um explorador EVTX completo é executado diretamente no seu navegador, alimentado pelo mesmo núcleo Rust compilado para WebAssembly.

👉 Experimente agora: https://omerbenamram.github.io/evtx/

Tudo acontece localmente – os arquivos nunca saem da sua máquina. Destaques:

• Arraste e solte arquivos .evtx (ou clique para procurar) – lida com logs muito grandes!
• Análise extremamente rápida via WebAssembly e renderização com scroll virtual
• Filtros facetados por nível, provedor, canal, ID do Evento e campos dinâmicos do EventData – todos apoiados pelo DuckDB-WASM
• Pesquisa de texto completo, gerenciamento de colunas e exportação JSON/XML sob demanda do conjunto filtrado
• Temas claro/escuro, navegação por teclado e uma interface estilo Windows

O visualizador é servido estaticamente pelo GitHub Pages; após o primeiro carregamento, funciona completamente offline.

Instalação (utilitário binário associado):

• Baixe a última versão executável de https://github.com/omerbenamram/evtx/releases
  • As versões são construídas automaticamente para Windows, macOS e Linux (apenas executáveis de 64 bits).
• Compile a partir dos fontes usando cargo install evtx

evtx_dump (Utilitário Binário):

O principal utilitário binário fornecido com este crate é evtx_dump, e oferece uma forma rápida de converter arquivos .evtx para diferentes formatos de saída.

Alguns exemplos

• evtx_dump <evtx_file> irá despejar o conteúdo dos registros evtx como xml.
• evtx_dump -o json <evtx_file> irá despejar o conteúdo dos registros evtx como JSON.
• evtx_dump -f <output_file> -o json <input_file> irá despejar o conteúdo dos registros evtx como JSON para um arquivo específico.
• cat <evtx_file> | evtx_dump -o jsonl - irá ler o arquivo EVTX da entrada padrão (útil para pipes/descompressão).

evtx_dump pode ser combinado com fd para processamento em lote conveniente de arquivos:

• fd -e evtx -x evtx_dump -o jsonl irá escanear uma pasta e despejar todos os arquivos evtx para um único arquivo jsonlines.
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' criará um arquivo xml ao lado de cada arquivo evtx, para todos os arquivos na pasta recursivamente!
• Se a origem do arquivo precisar ser adicionada ao json, xargs (ou gxargs no mac) e jq podem ser usados: fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

Nota: por padrão, evtx_dump tentará utilizar multithreading, o que significa que os registros podem ser retornados fora de ordem.

Para forçar o uso de única thread (o que também garantirá a ordem), -t 1 pode ser passado.

Renderização offline de modelos (WEVT_TEMPLATE)

Registros EVTX podem referenciar definições de modelo armazenadas em binários de provedores (EXE/DLL/SYS). evtx_dump pode extrair esses modelos para um cache offline e usá-los no momento da renderização.

Nota: esta funcionalidade requer a compilação de evtx_dump com a funcionalidade Cargo wevt_templates (as versões de lançamento podem já incluí-la).

• Construir um cache (único arquivo .wevtcache portátil):
  • evtx_dump extract-wevt-templates --input <provider.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• Despejar um arquivo EVTX usando o cache (regra determinística: só se aplica quando um registro falha devido a um GUID de modelo explicitamente ausente/corrompido):
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

Ajudantes de depuração:

• Despejar os valores de substituição (TemplateInstance) de um registro (JSONL):
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• Renderizar um GUID de modelo específico com substituições (XML para stdout):
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

Veja docs/wevt_templates.md para detalhes e contexto (issue #103).

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

A versão paralela é habilitada ao compilar com a funcionalidade "multithreading" (habilitada por padrão).

Benchmark de desempenho

Ao usar multithreading, evtx é significativamente mais rápido que qualquer outro analisador disponível. Para desempenho de núcleo único, é tanto o mais rápido quanto o único analisador multiplataforma que suporta saídas XML e JSON.

O desempenho foi testado na minha máquina usando hyperfine (ferramenta de medição estatística).

Estou executando testes em um AMD Ryzen 3900X de 12 núcleos.

Execução do benchmark: Junho de 2026 (evtx 0.12.2).

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

Commit do benchmark: 99a6def.

As colunas evtx — e pyevtx-rs, nossos próprios bindings Python, que encapsulam o mesmo núcleo Rust — foram remensuradas em Junho de 2026 nesta mesma máquina, após a reescrita de modelos compilados (veja docs/compiled-templates.html). Ambos são as builds PGO que são distribuídas para Linux/macOS (o binário de lançamento e a wheel PyPI; detalhes abaixo). pyevtx-rs é limitado pela serialização Python por registro (um dicionário por registro) em vez do analisador, portanto não vê toda a aceleração do núcleo. Os números restantes dos concorrentes (libevtx, velocidex/evtx, golang-evtx, python-evtx) são mantidos inalterados da execução de Janeiro de 2026 no mesmo hardware — ferramentas externas cujo desempenho não mudou.

Bibliotecas testadas:

• python-evtx(https://github.com/williballenthin/python-evtx) - Com CPython e PyPy
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - Bindings Python para esta biblioteca
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - apenas JSON (usa multithreading)
• evtx(https://github.com/Velocidex/evtx) - apenas JSON.
• evtx (Esta biblioteca)

Nota: os números mostrados são medições de tempo real (tempo que a invocação leva para ser concluída). As medidas de tempo de usuário são maiores ao usar mais multithreading/multiprocessamento, devido à sobrecarga de sincronização.

Com 8 threads, evtx é mais de 7000x mais rápido que python-evtx ao despejar logs xml.

A taxa de transferência agora satura em torno de 8 threads nesta amostra de 30MB: a análise de thread única tornou-se rápida o suficiente (~3.8x mais rápida que os números de Janeiro de 2026, na mesma máquina) que 30MB não contém mais trabalho suficiente para manter todos os 24 núcleos lógicos ocupados — 24 threads não são mais rápidas que 8 (as duas estão dentro do ruído de medição, então a tabela destaca a coluna de 8 threads como o ponto de saturação). Nesse ponto, evtx é cerca de 65x mais rápido que golang-evtx, que usa uma estratégia de multithreading semelhante.

Construção PGO

Os números acima vêm de uma construção guiada por perfil (./build_pgo.sh): ela treina um binário instrumentado no corpus de amostra e depois reconstrói com esse perfil. O CI executa isso para os binários de lançamento Linux (x86_64) e macOS, portanto a tabela reflete o artefato que a maioria das pessoas baixa (a saída é byte-idêntica a uma construção normal). O PGO vale aproximadamente 2–5% da taxa de transferência de thread única em comparação com um simples cargo build --release --features fast-alloc (JSON 77.6 → 75 ms, XML 73.0 → 71 ms); com 8+ threads a carga de trabalho está limitada pela saturação, portanto o PGO aí está dentro do ruído de medição.

Ressalvas

• Atualmente não implementado:
  • Nós CDATA.
  • Tipo de nó EVTHandle.

Se o analisador emitir erro em algum desses nós, fique à vontade para abrir uma issue ou me enviar um e-mail com uma amostra.

Licença

Licenciado sob uma das

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

à sua escolha.

Contribuição

A menos que você declare explicitamente o contrário, qualquer contribuição intencionalmente submetida para inclusão no trabalho por você, conforme definido na licença Apache-2.0, será licenciada duplamente como acima, sem quaisquer termos ou condições adicionais.