媒体解析器测试用例生成器

media-gen 是一个小型、依赖轻量的 Rust 命令行工具，用于构建两个媒体解析器测试用例。它就地编辑现有的有效媒体文件；它不会调用 FFmpeg、修补浏览器、联系服务器或上传任何内容。

WebM 用例包含一个桥接布局，同时适用于较旧的单缓冲区延迟 Vorbis 路径和当前的立即丢弃路径。已检入的短样本已通过 Discord Desktop 1.0.9257（Electron 42.11.1 / Chromium 148.0.7778.280）和 Chrome 153.0.8010.48 验证。M4A 用例仍特定于固定的 Discord/FFmpeg 构建。其他版本可能会拒绝这些文件、安全地处理它们，或以不同方式失败。

这些是拒绝服务/资源消耗测试用例，而非已证明的代码执行漏洞利用。仅在隔离的、有界的测试环境中运行它们。

BLARE2 二进制插桩

media-gen 是复现层，而非这些用例的发现方式。困难的部分是在一个大型原生 Discord 可执行文件及其捆绑的媒体库中发现并证明该行为。blare2 通过重写精确运行时的隔离副本，并允许窄探针在不更改已安装应用程序的情况下观察执行，使这变得可行。

对于 WebM 用例，blare2 的语义探针在精确的 AudioDiscardHelper::ProcessBuffers 检查处停止，并记录了失败状态：discarded_frames = 129 和 decoder_delay = 128。如果没有该观察，渲染器以 STATUS_BREAKPOINT 退出只会识别出通用的发布断言；它无法确定哪个媒体不变量失败，或者构造的填充是否实际到达了它。

对于 M4A 用例，大分配是瞬时的，可能在正常进程采样之前消失。blare2 的精确运行时覆盖和有针对性的插桩，结合高频进程采样和反汇编，表明这个微小文件到达了 MOV 样本表构建器，并且声明的计数按比例放大了 AVIndexEntry 和时序表分配。这将该问题与普通的 AAC 解码失败或误导性的文件大小/OOM 相关性区分开来。仅靠广泛的函数入口覆盖是不够的：低计数和高计数文件遵循相同的函数，而它们的分配大小却截然不同。

blare2 并未取代容器分析、源代码审查或对照，也没有证明 Discord 的生产上传/CDN 路径会保留这些字节。它的价值在于运行时归因：它将可疑的解析器行为转变为可复现的、版本固定的发现，具有精确的失败状态和可辩护的分配解释。如果没有这种二进制插桩，发现这两个用例将大大减慢，并且更难验证。

构建

从仓库根目录：

cargo build --release -p media-gen

二进制文件是 target/release/media-gen（Windows 上为 media-gen.exe）。生成器本身只需要 Rust 和 Cargo.toml 中的依赖项。

cargo run --release -p media-gen -- --help
cargo run --release -p media-gen -- webm --help
cargo run --release -p media-gen -- m4a --help

WebM/Vorbis 双版本丢弃崩溃

原因

Matroska 负 DiscardPadding 变为 Vorbis 前端跳过。Chromium 较旧的 Vorbis 路径将该元数据延迟一个编码数据包；当前 Chromium 将其应用于当前解码输出，并在该启动数据包不发出 PCM 时丢弃数据包 0 的元数据。在数据包 0 和 1 上重复一个大的跳过桥接了这两种行为：

该轨道具有 128 帧的 CodecDelay。在较旧的延迟模式下，数据包 0 的 577 帧跳过应用于数据包 1。在当前模式下，数据包 0 的跳过被丢弃，数据包 1 的相同跳过直接应用。无论哪种方式，在解码器延迟偏移之后只能移除 448 帧，因此 129 帧带入数据包 2。其正前端跳过在这些 129 帧已被移除后到达 Chromium 的发布检查。所需的不变量是 discarded_frames <= decoder_delay；129 <= 128 失败并终止渲染器。

生成器解析 Vorbis 设置头，计算数据包 1 和 2 的解码大小，并在桥接不可行时故障关闭。然后它：

• 将前三个音频 SimpleBlock 元素转换为 BlockGroup 元素；
• 在数据包 0 和 1 上写入共享的负 DiscardPadding，并在数据包 2 上写入正的一帧触发器；
• 保留编码的音频和视频负载；以及
• 替换过时的 SeekHead、Cues 和受影响的簇 CRC 元素，以便重写的容器保持可解析。

清单分别报告立即路径和延迟路径。对于已检入的样本，两条路径都将数据包 2 命名为检查数据包，并报告 expected_carry_frames: 129 和 expected_check_fails: true。

生成候选

仓库包含一个 43 毫秒、4,185 字节的控制 WebM：

cargo run --release -- webm \
  --input samples/short-vorbis-dual-control.webm \
  --output .build/short-vorbis-dual-crash.webm \
  --manifest .build/short-vorbis-dual-crash.json \
  --force

输入必须包含：

• 一个 A_VORBIS 轨道；
• 一个正的 CodecDelay（通常从轨道读取）；以及
• 至少三个音频数据包，其 Vorbis 模式可解码；
• 数据包 1 输出大于编解码器延迟；以及
• 数据包 2 输出大于计算出的携带量。

有用的选项是 --trigger-skip、--codec-delay 和 --sample-rate。--second-skip 仍然是重命名后的 --trigger-skip 选项的别名。默认值是已知失败状态所需的值。该命令将 JSON 报告打印到 stdout，并在提供该选项时将相同的报告写入 --manifest。

已检入的候选是 43 毫秒和 4,206 字节。其 SHA-256 为：

a0ab9e146c629f037b86612addc1ab6fff9200711d45aa5f5edbb9576cc206ac

如果输入、数据包窗口或选项发生变化，输出哈希预计会改变。

M4A 常量样本计数分配

原因

M4A 用例滥用有效的 MP4 样本表形状，而非编码的 AAC 负载。生成器按如下方式更改种子：

1. 它将显式的 stsz 样本大小数组替换为 sample_size = 1。
2. 它将 stsz、第一个 stsc 运行和第一个 stts 运行中声明的样本计数设置为相同的大值。
3. 它移除旧的显式大小条目并修复祖先盒大小。
4. 它修复绝对 stco 偏移，以便单字节 AAC 负载仍指向 mdat 内部。

固定的 FFmpeg 解复用器在构建其索引和时序表时将声明的计数视为权威。相关结构对每个声明的样本使用约 24 字节用于 AVIndexEntry，每个样本 12 字节用于时序数据：每个计数条目总共 36 字节。在测试构建中接受的最大计数是 178,956,969（0x0AAAAAA9），其预计为：

178,956,969 * 24 = 4,294,967,256 bytes
178,956,969 * 12 = 2,147,483,628 bytes
combined         = 6,442,450,884 bytes

确切的 Discord 渲染器在加载元数据时达到 6,614,761,472 字节的私有内存峰值。相邻计数 178,956,970 被固定的 FFmpeg 边界拒绝，并保持在正常内存附近。这是不受控的资源消耗（CWE-400），而非观察到的整数回绕、负大小分配或越界写入。实际的 AAC 负载可以被截断；成功播放不需要达到大分配。

生成候选

生成器有意接受种子，而不是嵌入 AAC 编码器。使用具有一个显式 stsz 表、一个 stsc 运行、一个或多个 stts 条目以及 stco 块偏移的快速启动 AAC/M4A 文件。如果所需结构不存在，它会故障关闭。

cargo run --release -p media-gen -- m4a \
  --input path/to/base-faststart.m4a \
  --output .build/media-gen/constant-stsz.m4a \
  --manifest .build/media-gen/constant-stsz.json \
  --force

默认 --sample-count 是 178956969，即固定构建中接受的最大值。使用较小的值进行低内存冒烟测试，例如：

cargo run --release -p media-gen -- m4a \
  --input path/to/base-faststart.m4a \
  --output .build/media-gen/constant-stsz-32000000.m4a \
  --sample-count 32000000 \
  --force

--sample-count 178956970 是一个有用的相邻拒绝对照，而非触发值。可选的 --moov-at-end 标志将 moov 移动到 mdat 之后，并更新 stco/co64；当测试物理 AAC 字节出现在其元数据之前的文件时，它很有用，但对于分配机制不是必需的。

要显式生成该布局：

cargo run --release -p media-gen -- m4a \
  --input path/to/base-faststart.m4a \
  --output .build/media-gen/constant-stsz-moov-end.m4a \
  --moov-at-end \
  --force

匹配的工件是 samples/short-vorbis-dual-control.webm、 samples/short-vorbis-dual-crash.webm 和 samples/short-vorbis-dual-crash.json。