Estos son casos de prueba de denegación de servicio/consumo de recursos, no exploits de ejecución de código demostrados. Ejecútalos solo en un entorno de prueba aislado y acotado.

Instrumentación binaria con BLARE2

media-gen es la capa de reproducibilidad, no la forma en que se descubrieron estos casos. La parte difícil fue encontrar y demostrar el comportamiento dentro de un gran ejecutable nativo de Discord y sus bibliotecas de medios incluidas. blare2 lo hizo práctico al reescribir una copia aislada del runtime exacto y permitir que sondas estrechas observaran la ejecución sin cambiar la aplicación instalada.

Para el caso WebM, la sonda semántica de blare2 se detuvo en la comprobación exacta AudioDiscardHelper::ProcessBuffers y registró el estado de fallo: discarded_frames = 129 y decoder_delay = 128. Sin esa observación, una salida del renderizador con STATUS_BREAKPOINT solo identificaría una aserción de versión genérica; no establecería qué invariante de medios falló ni si el relleno manipulado realmente llegó hasta ella.

Para el caso M4A, las asignaciones grandes son transitorias y pueden desaparecer antes de que se tome una muestra normal del proceso. La cobertura del runtime exacto y la instrumentación dirigida de blare2, combinadas con muestreo de procesos de alta frecuencia y desensamblado, mostraron que el archivo diminuto llegaba al constructor de tablas de muestras MOV y que el recuento declarado escalaba las asignaciones de AVIndexEntry y de la tabla de tiempos. Esto separó el problema de un fallo ordinario de decodificación AAC o de una correlación engañosa entre tamaño de archivo y OOM. La cobertura amplia de entradas de funciones por sí sola no bastaba: los archivos de recuento bajo y alto seguían las mismas funciones, mientras que sus tamaños de asignación eran radicalmente diferentes.

blare2 no sustituyó el análisis de contenedores, la revisión del código fuente ni los controles, y no demostró que la ruta de producción de subida/CDN de Discord conserve estos bytes. Su valor fue la atribución en tiempo de ejecución: convirtió un comportamiento sospechoso del analizador en un hallazgo reproducible, fijado a una versión, con un estado de fallo exacto y una explicación defendible de la asignación. Sin instrumentación binaria de este tipo, encontrar estos dos casos habría sido sustancialmente más lento y mucho más difícil de validar.

Compilación

Desde la raíz del repositorio:

El binario es target/release/media-gen (media-gen.exe en Windows). El propio generador solo necesita Rust y las dependencias de Cargo.toml.

Fallo por descarte en WebM/Vorbis con doble versión

Qué lo causa

Un DiscardPadding negativo de Matroska se convierte en un salto frontal de Vorbis. La ruta Vorbis antigua de Chromium retrasa esos metadatos un paquete codificado; el Chromium actual los aplica a la salida decodificada actual y descarta los metadatos del paquete 0 cuando ese paquete de cebado no emite PCM. Repetir un salto grande en los paquetes 0 y 1 tiende un puente entre ambos comportamientos:

La pista tiene un CodecDelay de 128 fotogramas. En el modo retardado antiguo, el salto de 577 fotogramas del paquete 0 se aplica al paquete 1. En el modo actual, el salto del paquete 0 se descarta y el salto idéntico del paquete 1 se aplica directamente. En cualquier caso, solo se pueden eliminar 448 fotogramas tras el desplazamiento por retardo del códec, por lo que 129 fotogramas pasan al paquete 2. Su salto frontal positivo llega a la comprobación de versión de Chromium después de que esos 129 fotogramas ya se hayan eliminado. El invariante requerido es discarded_frames <= decoder_delay; 129 <= 128 falla y termina el renderizador.

El generador analiza las cabeceras de configuración de Vorbis, calcula los tamaños decodificados de los paquetes 1 y 2, y falla de forma segura a menos que el puente sea viable. Después:

• convierte los tres primeros elementos SimpleBlock de audio en elementos BlockGroup;
• escribe un DiscardPadding negativo compartido en los paquetes 0 y 1 y un disparador positivo de un fotograma en el paquete 2;
• conserva las cargas útiles de audio y vídeo codificadas; y
• reemplaza los elementos obsoletos SeekHead, Cues y los CRC de clúster afectados para que el contenedor reescrito siga siendo analizable.

El manifiesto informa por separado de las rutas inmediata y retardada. Para la muestra incluida en el repositorio, ambas rutas nombran el paquete 2 como paquete de comprobación e informan expected_carry_frames: 129 y expected_check_fails: true.

Generar un candidato

El repositorio contiene un WebM de control de 43 ms y 4.185 bytes:

La entrada debe contener:

• una pista A_VORBIS;
• un CodecDelay positivo (normalmente leído de la pista); y
• al menos tres paquetes de audio cuyos modos Vorbis puedan decodificarse;
• una salida del paquete 1 mayor que el retardo del códec; y
• una salida del paquete 2 mayor que el acarreo calculado.

Las opciones útiles son --trigger-skip, --codec-delay y --sample-rate. --second-skip sigue siendo un alias de la opción renombrada --trigger-skip. Los valores predeterminados son los necesarios para el estado de fallo conocido. El comando imprime el informe JSON en stdout y escribe el mismo informe en --manifest cuando se proporciona esa opción.

El candidato incluido en el repositorio es de 43 ms y 4.206 bytes. Su SHA-256 es:

Se espera que el hash de salida cambie si cambian la entrada, la ventana de paquetes o las opciones.

Asignación por recuento constante de muestras en M4A

Qué lo causa

El caso M4A abusa de una forma válida de tabla de muestras MP4 en lugar de la carga útil AAC codificada. El generador modifica una semilla de la siguiente manera:

1. Reemplaza el array explícito de tamaños de muestra stsz por sample_size = 1.
2. Establece el recuento de muestras declarado en stsz, la primera ejecución stsc y la primera ejecución stts al mismo valor grande.
3. Elimina las antiguas entradas de tamaño explícitas y repara los tamaños de las cajas ancestro.
4. Repara el desplazamiento absoluto stco para que la carga útil AAC de un byte siga apuntando dentro de mdat.

El demuxer de FFmpeg fijado trata el recuento declarado como autoritativo mientras construye sus tablas de índice y tiempos. Las estructuras relevantes usan aproximadamente 24 bytes por muestra declarada para AVIndexEntry y 12 bytes por muestra para los datos de tiempos: 36 bytes por entrada de recuento en total. El recuento máximo aceptado en la compilación probada es 178.956.969 (0x0AAAAAA9), lo que proyecta:

El renderizador exacto de Discord alcanzó un pico de memoria privada de 6.614.761.472 bytes mientras cargaba los metadatos. El recuento adyacente 178.956.970 es rechazado por el límite de FFmpeg fijado y se mantuvo cerca de la memoria normal. Esto es consumo de recursos no controlado (CWE-400), no un desbordamiento de entero observado, una asignación de tamaño negativo ni una escritura fuera de límites. La carga útil AAC real puede truncarse; no se requiere una reproducción correcta para alcanzar la asignación grande.

Generar un candidato

El generador acepta intencionadamente una semilla en lugar de incorporar un codificador AAC. Usa un archivo AAC/M4A fast-start con una tabla stsz explícita, una ejecución stsc, una o más entradas stts y desplazamientos de fragmento stco. Falla de forma segura si la estructura requerida está ausente.

El valor predeterminado de --sample-count es 178956969, el valor máximo aceptado en la compilación fijada. Usa un valor menor para una prueba de humo con poca memoria, por ejemplo:

--sample-count 178956970 es un control de rechazo adyacente útil, no el valor desencadenante. La opción opcional --moov-at-end mueve moov después de mdat y actualiza stco/co64; es útil al probar un archivo cuyos bytes AAC físicos aparecen antes de sus metadatos, pero no es necesaria para el mecanismo de asignación.

Para producir esa disposición explícitamente:

Los artefactos correspondientes son samples/short-vorbis-dual-control.webm, samples/short-vorbis-dual-crash.webm, y samples/short-vorbis-dual-crash.json.