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 浏览器直接在浏览器中运行，由编译为 WebAssembly 的相同 Rust 核心驱动。

👉 立即尝试： https://omerbenamram.github.io/evtx/

所有操作都在本地完成——文件永远不会离开您的机器。亮点：

• 拖放 .evtx 文件（或点击浏览）——可处理非常大的日志！
• 通过 WebAssembly 和虚拟滚动渲染实现极速解析
• 基于 Facet 的过滤器，支持级别、提供程序、通道、事件 ID 和动态 EventData 字段——全部由 DuckDB-WASM 支持
• 全文搜索、列管理，以及即时将过滤结果导出为 JSON/XML
• 浅色/深色主题、键盘导航和 Windows 风格界面

该查看器静态部署在 GitHub Pages 上；首次加载后即可完全离线使用。

安装（关联二进制工具）：

• 从 https://github.com/omerbenamram/evtx/releases 下载最新可执行发行版
  • 发行版自动构建适用于 Windows、macOS 和 Linux（仅 64 位可执行文件）
• 使用 cargo install evtx 从源代码构建

evtx_dump（二进制工具）：

本 crate 提供的主要二进制工具是 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 文件转储到单个 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 输出到 stdout）：
  • 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!("记录 {}\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）。

系统：Arch Linux（Linux 7.0.11-arch1-1 x86_64）。

基准测试提交：99a6def。

evtx 列——以及 pyevtx-rs，我们自己的 Python 绑定（它封装了相同的 Rust 核心）——是在编译模板重写落地后（参见 docs/compiled-templates.html）于 2026 年 6 月在同一台机器上重新测量的。两者都是为 Linux/macOS 发布的 PGO 构建（发行版二进制文件和 PyPI wheel；详见下文）。pyevtx-rs 的性能受限于每条记录的 Python 编组（每条记录一个字典），而非解析器本身，因此看不到完整核心加速。其余竞争对手的数据（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 在处理 xml 日志转储时比 python-evtx 快超过 7000 倍。

在此 30MB 样本上，吞吐量在大约 8 线程时达到饱和：单线程解析已足够快（在同一台机器上比 2026 年 1 月的数据快约 3.8 倍），因此 30MB 的数据量不足以让所有 24 个逻辑核心保持忙碌——24 线程与 8 线程速度相当（两者在测量误差范围内，因此表格突出显示 8 线程列作为饱和点）。此时 evtx 比采用类似多线程策略的 golang-evtx 快约 65 倍。

PGO 构建

上述数据来自基于配置引导的构建（./build_pgo.sh）：它在样本语料库上训练一个插桩二进制文件，然后使用该配置文件重新构建。CI 为 Linux（x86_64）和 macOS 发行版二进制文件执行此操作，因此表格反映了大多数人下载的工件（输出与普通构建字节相同）。与普通的 cargo build --release --features fast-alloc 相比，PGO 在单线程吞吐量方面大约提升 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 许可证的定义，应按上述方式双授权，无需附加条款或条件。