Estes são casos de teste de negação de serviço/consumo de recursos, não exploits demonstrados de execução de código. Execute-os apenas em um ambiente de teste isolado e limitado.

Instrumentação Binária com BLARE2

media-gen é a camada de reprodutibilidade, não o modo como esses casos foram descobertos. A parte difícil foi encontrar e provar o comportamento dentro de um grande executável nativo do Discord e de suas bibliotecas de mídia empacotadas. O blare2 tornou isso viável ao reescrever uma cópia isolada do runtime exato e permitir que sondagens estreitas observassem a execução sem alterar o aplicativo instalado.

Para o caso WebM, a sondagem semântica do blare2 parou exatamente na verificação AudioDiscardHelper::ProcessBuffers e registrou o estado de falha: discarded_frames = 129 e decoder_delay = 128. Sem essa observação, uma saída do renderer com STATUS_BREAKPOINT apenas identificaria uma asserção de release genérica; não estabeleceria qual invariante de mídia falhou nem se o padding construído realmente chegou até ela.

Para o caso M4A, as grandes alocações são transitórias e podem desaparecer antes que uma amostra normal do processo seja coletada. A cobertura do runtime exato e a instrumentação direcionada do blare2, combinadas com amostragem de processo em alta frequência e desmontagem, mostraram que o arquivo minúsculo chegou ao construtor da tabela de amostras MOV e que a contagem declarada escalou as alocações de AVIndexEntry e da tabela de temporização. Isso separou o problema de uma falha comum de decodificação AAC ou de uma correlação enganosa entre tamanho de arquivo e OOM. A cobertura ampla de entrada de funções por si só não foi suficiente: os arquivos de contagem baixa e alta seguiram as mesmas funções, enquanto seus tamanhos de alocação eram radicalmente diferentes.

O blare2 não substituiu a análise de contêiner, a revisão de código-fonte ou os controles, e não provou que o caminho de upload/CDN de produção do Discord preserva esses bytes. Seu valor foi a atribuição em tempo de execução: transformou um comportamento suspeito do parser em um achado reproduzível, fixado por versão, com um estado de falha exato e uma explicação defensável de alocação. Sem instrumentação binária desse tipo, encontrar esses dois casos teria sido substancialmente mais lento e muito mais difícil de validar.

Build

A partir da raiz do repositório:

O binário é target/release/media-gen (media-gen.exe no Windows). O próprio gerador precisa apenas de Rust e das dependências em Cargo.toml.

Crash de descarte em duas versões do WebM/Vorbis

O que o causa

Um DiscardPadding negativo do Matroska se torna um front skip do Vorbis. O caminho Vorbis mais antigo do Chromium atrasa esses metadados em um pacote codificado; o Chromium atual os aplica à saída decodificada atual e descarta os metadados do pacote 0 quando esse pacote de priming não emite PCM. Repetir um grande skip nos pacotes 0 e 1 faz a ponte entre os dois comportamentos:

A faixa tem um CodecDelay de 128 quadros. No modo atrasado mais antigo, o skip de 577 quadros do pacote 0 é aplicado ao pacote 1. No modo atual, o skip do pacote 0 é descartado e o skip idêntico do pacote 1 é aplicado diretamente. De qualquer forma, apenas 448 quadros podem ser removidos após o deslocamento do decoder-delay, então 129 quadros passam para o pacote 2. Seu front skip positivo chega à verificação de release do Chromium depois que esses 129 quadros já foram removidos. O invariante exigido é discarded_frames <= decoder_delay; 129 <= 128 falha e encerra o renderer.

O gerador analisa os cabeçalhos de setup do Vorbis, calcula os tamanhos decodificados dos pacotes 1 e 2 e falha de forma segura a menos que a ponte seja viável. Em seguida, ele:

• converte os três primeiros elementos SimpleBlock de áudio em elementos BlockGroup;
• grava DiscardPadding negativo compartilhado nos pacotes 0 e 1 e um gatilho positivo de um quadro no pacote 2;
• preserva os payloads de áudio e vídeo codificados; e
• substitui elementos obsoletos SeekHead, Cues e CRC de clusters afetados para que o contêiner reescrito permaneça analisável.

O manifesto relata os caminhos imediato e atrasado separadamente. Para a amostra incluída no repositório, ambos os caminhos indicam o pacote 2 como pacote de verificação e relatam expected_carry_frames: 129 e expected_check_fails: true.

Gerar um candidato

O repositório contém um WebM de controle de 43 ms e 4.185 bytes:

A entrada deve conter:

• uma faixa A_VORBIS;
• um CodecDelay positivo (normalmente lido da faixa); e
• pelo menos três pacotes de áudio cujos modos Vorbis possam ser decodificados;
• saída do pacote 1 maior que o codec delay; e
• saída do pacote 2 maior que o carry calculado.

Opções úteis são --trigger-skip, --codec-delay e --sample-rate. --second-skip permanece como alias para a opção renomeada --trigger-skip. Os padrões são os valores necessários para o estado de falha conhecido. O comando imprime o relatório JSON em stdout e grava o mesmo relatório em --manifest quando essa opção é fornecida.

O candidato incluído no repositório tem 43 ms e 4.206 bytes. Seu SHA-256 é:

Espera-se que o hash de saída mude se a entrada, a janela de pacotes ou as opções mudarem.

Alocação por contagem constante de amostras em M4A

O que a causa

O caso M4A abusa de uma forma válida de tabela de amostras MP4, em vez do payload AAC codificado. O gerador altera uma semente da seguinte forma:

1. Substitui o array explícito de tamanhos de amostra stsz por sample_size = 1.
2. Define a contagem declarada de amostras em stsz, na primeira execução stsc e na primeira execução stts com o mesmo valor grande.
3. Remove as entradas antigas de tamanho explícito e repara os tamanhos das caixas ancestrais.
4. Repara o offset absoluto stco para que o payload AAC de um byte ainda aponte para dentro de mdat.

O demuxer fixado do FFmpeg trata a contagem declarada como autoritativa ao construir suas tabelas de índice e temporização. As estruturas relevantes usam aproximadamente 24 bytes por amostra declarada para AVIndexEntry e 12 bytes por amostra para dados de temporização: 36 bytes por entrada de contagem no total. A contagem máxima aceita na build testada é 178.956.969 (0x0AAAAAA9), o que projeta:

O renderer exato do Discord atingiu um pico de 6.614.761.472 bytes de memória privada ao carregar metadados. A contagem adjacente 178.956.970 é rejeitada pelo limite fixado do FFmpeg e permaneceu próxima da memória normal. Isso é consumo descontrolado de recursos (CWE-400), não um integer-wrap observado, alocação de tamanho negativo ou escrita fora dos limites. O payload AAC real pode ser truncado; a reprodução bem-sucedida não é necessária para atingir a grande alocação.

Gerar um candidato

O gerador aceita intencionalmente uma semente em vez de embutir um codificador AAC. Use um arquivo AAC/M4A fast-start com uma tabela stsz explícita, uma execução stsc, uma ou mais entradas stts e offsets de chunk stco. Ele falha de forma segura se a estrutura necessária estiver ausente.

O --sample-count padrão é 178956969, o valor máximo aceito na build fixada. Use um valor menor para um teste de fumaça com pouca memória, por exemplo:

--sample-count 178956970 é um controle útil de rejeição adjacente, não o valor que dispara o gatilho. A flag opcional --moov-at-end move moov para depois de mdat e atualiza stco/co64; é útil ao testar um arquivo cujos bytes AAC físicos ocorrem antes de seus metadados, mas não é necessária para o mecanismo de alocação.

Para produzir esse layout explicitamente:

Os artefatos correspondentes são samples/short-vorbis-dual-control.webm, samples/short-vorbis-dual-crash.webm, e samples/short-vorbis-dual-crash.json.