EVTX

機能

• 🔒 100% 安全な Rust で実装されており、Rust が対応するすべてのプラットフォーム（stdlib があるもの）で動作します。
• ⚡ 高速。以下のベンチマークを参照してください。他の実装よりも桁違いに高速です！
• 🚀 マルチスレッド対応。
• ✨ XML および JSON 出力に対応。どちらも共有の中間表現 (IR) から直接構築されます（xml2json 変換は行われません！）
• ⛏️ 欠落したレコード/チャンクの基本的な復元に対応しています！
• 🐍 Python バインディングも利用可能：https://github.com/omerbenamram/pyevtx-rs（PyPi でも入手可能：https://pypi.org/project/evtx/）

Web ベースのビューア（EVTX Web）

インストール不要のオプションをお好みですか？　フル機能の EVTX エクスプローラーがブラウザ上で動作します。同じ Rust コアを WebAssembly にコンパイルして使用しています。

👉 今すぐ試す: https://omerbenamram.github.io/evtx/

すべての処理はローカルで行われ、ファイルがマシンの外に出ることはありません。主な特長：

• .evtx ファイルをドラッグ＆ドロップ（またはクリックして選択） – 非常に大きなログでも処理可能！
• WebAssembly と仮想スクロールレンダリングによる圧倒的な高速解析
• レベル、プロバイダ、チャネル、イベント ID、動的な EventData フィールドに対するファセットフィルター – すべて DuckDB-WASM を利用
• 全文検索、カラム管理、フィルタリングされたセットのオンザフライでの JSON/XML エクスポート
• ライト/ダークテーマ、キーボードナビゲーション、Windows スタイルの UI

このビューアは GitHub Pages から静的に提供されており、初回ロード後は完全にオフラインで動作します。

インストール（関連バイナリユーティリティ）

• 最新の実行可能リリースを https://github.com/omerbenamram/evtx/releases からダウンロード
  • リリースは Windows、macOS、Linux 向けに自動ビルドされています。（64ビット実行可能ファイルのみ）
• ソースからビルドする場合： cargo install evtx

evtx_dump（バイナリユーティリティ）

このクレートに付属する主要なバイナリユーティリティは evtx_dump で、.evtx ファイルをさまざまな出力形式に変換する簡単な方法を提供します。

いくつかの例：

• evtx_dump <evtx_file> は evtx レコードの内容を XML として出力します。
• evtx_dump -o json <evtx_file> は evtx レコードの内容を JSON として出力します。
• evtx_dump -f <output_file> -o json <input_file> は evtx レコードの内容を JSON として指定されたファイルに出力します。
• cat <evtx_file> | evtx_dump -o jsonl - は標準入力から EVTX ファイルを読み取ります（パイプや展開に便利）。

evtx_dump は fd と組み合わせてファイルの一括処理に便利です：

• fd -e evtx -x evtx_dump -o jsonl はフォルダをスキャンし、すべての evtx ファイルを 1 つの jsonlines ファイルに出力します。
• fd -e evtx -x evtx_dump '{}' -f '{.}.xml' はフォルダ内のすべてのファイルについて、各 evtx ファイルの隣に XML ファイルを作成します。
• ファイルのソース情報を JSON に追加する必要がある場合は、xargs（Mac では gxargs）と jq を使用できます：fd -a -e evtx | xargs -I input sh -c "evtx_dump -o jsonl input | jq --arg path "input" '. + {path: \$path}'"

注意: デフォルトでは、evtx_dump はマルチスレッドを利用しようとします。そのため、レコードが順不同で返される可能性があります。

シングルスレッドでの使用を強制するには（これにより順序が保証されます）、-t 1 を渡してください。

オフラインテンプレートレンダリング（WEVT_TEMPLATE）

EVTX レコードは、プロバイダバイナリ（EXE/DLL/SYS）に保存されたテンプレート定義を参照することがあります。evtx_dump はこれらのテンプレートをオフラインキャッシュに抽出し、レンダリング時に使用できます。

注意: この機能を使用するには、Cargo フィーチャー wevt_templates を有効にして evtx_dump をビルドする必要があります（リリースバイナリには既に含まれている場合があります）。

• キャッシュの構築（単一のポータブル .wevtcache ファイル）：
  • evtx_dump extract-wevt-templates --input <provider.dll> --output /tmp/wevt_cache.wevtcache --overwrite
• キャッシュを使用して EVTX ファイルをダンプ（決定論的ルール：明示的なテンプレート GUID の欠落/破損によりレコードが失敗した場合のみ適用）：
  • evtx_dump --wevt-cache /tmp/wevt_cache.wevtcache <log.evtx>

デバッグ支援：

• レコードの TemplateInstance 置換値をダンプ（JSONL）：
  • evtx_dump dump-template-instances --input <log.evtx> --record-id <ID> | head -n1
• 特定のテンプレート GUID を置換値でレンダリング（XML を標準出力）：
  • evtx_dump apply-wevt-cache --cache /tmp/wevt_cache.wevtcache --template-guid <GUID> --evtx <log.evtx> --record-id <ID>

詳細と背景については docs/wevt_templates.md を参照してください（issue #103）。

ライブラリとしての使用例

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

// これを .evtx サンプルのパスに変更してください。
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),
    }
}

並列バージョンは、フィーチャー "multithreading" を有効にしてコンパイルすると有効になります（デフォルトで有効）。

パフォーマンスベンチマーク

マルチスレッドを使用する場合、evtx は利用可能な他のどのパーサーよりも大幅に高速です。 シングルコアのパフォーマンスでも、最速であり、XML と JSON の両方の出力に対応する唯一のクロスプラットフォームパーサーです。

パフォーマンスは、hyperfine（統計的測定ツール）を使用して私のマシンでベンチマークしました。

テスト環境：12 コア AMD Ryzen 3900X。

ベンチマーク実行日：2026 年 6 月（evtx 0.12.2）。

OS：Arch Linux（Linux 7.0.11-arch1-1 x86_64）。

ベンチマークコミット：99a6def。

evtx の列、および同じ Rust コアをラップする独自の Python バインディングである pyevtx-rs は、コンパイル済みテンプレートの書き換えが行われた後（docs/compiled-templates.html を参照）、同じマシン上で 2026 年 6 月に再測定されました。どちらも Linux/macOS 向けに出荷される PGO ビルドです（リリースバイナリと PyPI ホイール。詳細は下記）。pyevtx-rs はパーサー自体ではなく、レコードごとの Python マーシャリング（レコードごとに 1 つの dict）によって制約されるため、コアの速度向上を完全には享受していません。残りの競合製品の数値（libevtx, velocidex/evtx, golang-evtx, python-evtx）は、同じハードウェアでの 2026 年 1 月の実行から変更せずに引き継いでいます。これらの外部ツールのパフォーマンスは変わっていません。

ベンチマークしたライブラリ：

• python-evtx(https://github.com/williballenthin/python-evtx) - CPython および PyPy で
• pyevtx-rs(https://github.com/omerbenamram/pyevtx-rs) / evtx(https://pypi.org/project/evtx/) - このライブラリの Python バインディング
• libevtx(https://github.com/libyal/libevtx)
• golang-evtx(https://github.com/0xrawsec/golang-evtx.git) - JSON のみ（マルチスレッドを使用）
• evtx(https://github.com/Velocidex/evtx) - JSON のみ。
• evtx（このライブラリ）

注: 表示されている数値は real-time 測定値（呼び出しが完了するまでの時間）です。マルチスレッド/マルチプロセスを使用する場合、同期オーバーヘッドのため user-time の測定値は高くなります。

8 スレッドの場合、evtx は python-evtx よりも 7000 倍以上高速に XML ログをダンプします。

この 30MB サンプルでは、スループットは約 8 スレッドで飽和します。シングルスレッドの解析が十分に高速になったため（同じマシンで 2026 年 1 月の数値と比較して約 3.8 倍高速）、30MB ではすべての 24 論理コアをビジー状態に保つのに十分な作業量がなくなりました（24 スレッドは 8 スレッドと同程度で、測定ノイズの範囲内であるため、表では 8 スレッド列を飽和点として強調しています）。この時点で、evtx は同様のマルチスレッド戦略を使用する golang-evtx よりも約 65 倍高速です。

PGO ビルド

上記の数値は、プロファイルガイド付きビルド（./build_pgo.sh）によるものです。サンプルコーパスでインストルメント化されたバイナリをトレーニングし、そのプロファイルを使用してリビルドします。CI は Linux（x86_64）および macOS リリースバイナリに対してこれを実行するため、表はほとんどの人がダウンロードするアーティファクトを反映しています（出力は通常のビルドとバイト単位で同一です）。PGO は、単純な cargo build --release --features fast-alloc と比較して、シングルスレッドのスループットを約 2～5% 向上させる価値があります（JSON 77.6 → 75 ms、XML 73.0 → 71 ms）。8 スレッド以上ではワークロードが飽和するため、PGO は測定ノイズの範囲内です。

注意点

• 現在未実装：
  • CDATA ノード。
  • EVTHandle ノードタイプ。

これらのノードでパーサーがエラーになった場合は、遠慮なく issue を開くか、サンプルを添付してメールを送ってください。

ライセンス

以下のいずれかの条件でライセンスされています：

• Apache License, Version 2.0（LICENSE-APACHE または http://www.apache.org/licenses/LICENSE-2.0）
• MIT ライセンス（LICENSE-MIT または http://opensource.org/licenses/MIT）

お客様の選択によります。

コントリビューション

明示的に別段の表明がない限り、Apache-2.0 ライセンスで定義される、あなたが意図的に本著作物に提出するコントリビューションは、追加の条件なしに上記の通りデュアルライセンスされるものとします。