Técnica `R2R stomping` oculta comportamento real em binários .NET ReadyToRun

Método explora a diferença entre código IL e código nativo pré-compilado em assemblies .NET para dificultar análise estática e depuração gerenciada.

Componente	Binários .NET compilados no formato ReadyToRun (R2R), introduzido a partir do .NET Core 3.0 e observado em ambientes .NET Core, .NET 5+, .NET 6 e .NET 7.
Vetor	Alteração pós-compilação que cria divergência entre o código intermediário IL e o código nativo pré-compilado preservado dentro do mesmo assembly.
Impacto	Execução normal pode priorizar o código nativo pré-compilado, enquanto depuradores gerenciados como dnSpy e dnSpyEx podem apresentar ou executar uma visão diferente baseada em IL.
Prioridade	Analisar assemblies R2R também no nível nativo, validar cabeçalhos READYTORUN_HEADER, comparar fluxo IL contra código pré-compilado e reforçar triagem de binários .NET suspeitos.
Artefatos	Estruturas ManagedNativeHeader, READYTORUN_HEADER, assinatura 0x00525452 e métodos pré-compilados localizados por ferramentas como R2RDump aparecem como pontos úteis de verificação defensiva.
Mitigação	Correlacionar descompilação gerenciada, desmontagem nativa, metadados .NET, comportamento em tempo de execução e diferenças entre execução normal e execução sob depurador.

Resumo técnico

A técnica R2R stomping explora uma característica do formato ReadyToRun usado por aplicações .NET para reduzir tempo de inicialização. Em um assembly comum, o código intermediário IL é compilado em tempo de execução pelo compilador JIT. No formato R2R, o binário passa a carregar tanto o IL quanto uma representação nativa pré-compilada de partes do mesmo programa. Essa duplicidade melhora desempenho, mas cria uma superfície de análise mais complexa: o que aparece em uma visão gerenciada do assembly pode não representar o caminho efetivamente executado quando o runtime prioriza o trecho nativo já presente no arquivo.

O ponto central da técnica é modificar um dos lados dessa relação sem manter equivalência semântica com o outro. Um operador pode alterar o IL para parecer inofensivo e deixar o código nativo original intacto, ou pode preservar o IL como isca e substituir a região nativa pré-compilada por outro comportamento compatível com a arquitetura alvo. O resultado é um binário que pode parecer limpo em ferramentas focadas em IL, mas executar lógica diferente fora do depurador gerenciado. Para equipes defensivas, o risco não está em uma vulnerabilidade remota específica, e sim na possibilidade de empacotar comportamento oculto em um formato legítimo do ecossistema .NET.

Fluxo técnico

ReadyToRun é uma forma de compilação antecipada que mantém dependência dos metadados originais do assembly .NET. O binário resultante continua seguindo o formato CLI, mas inclui um ManagedNativeHeader que aponta para um READYTORUN_HEADER. A assinatura 0x00525452, associada a RTR, permite diferenciar imagens ReadyToRun de outras imagens gerenciadas com cabeçalhos nativos. Como o código nativo pré-compilado ainda depende de metadados, alterações mal feitas podem quebrar a execução. Por isso, a técnica descrita depende de preservar a estrutura do PE, os metadados e as referências necessárias enquanto altera o conteúdo que será visto ou executado em cada camada.

Em um cenário demonstrado, o IL de um método é substituído por instruções neutras, enquanto o código nativo pré-compilado correspondente permanece intacto. A inspeção gerenciada passa a sugerir que a chamada sensível não existe mais, mas a execução normal do assembly continua acionando o comportamento nativo preservado. Em outro cenário, o IL permanece como código isca e o trecho nativo pré-compilado é localizado por endereço relativo e tamanho, depois substituído por bytes nativos adequados ao sistema operacional e à arquitetura. O material descreve testes em Windows, Linux e macOS, com foco demonstrativo em Windows x64 e .NET 6, mas também menciona compatibilidade em uma faixa maior de runtimes que dão suporte a ReadyToRun.

A diferença entre execução normal e depuração gerenciada é relevante para análise de malware. Ferramentas como dnSpy e dnSpyEx são frequentemente usadas para revisar assemblies .NET porque expõem IL e C# descompilado de forma conveniente. No entanto, configurações de depuração que suprimem otimizações podem induzir uma trajetória diferente daquela tomada fora do depurador. Isso significa que uma análise baseada apenas na camada gerenciada pode concluir que um método é benigno, vazio ou alterado, enquanto a execução do arquivo fora desse contexto aciona a parte nativa pré-compilada.

Superfície afetada

A técnica se aplica a assemblies .NET publicados com ReadyToRun, recurso disponível a partir do .NET Core 3.0 e presente nos ramos modernos do runtime .NET. A superfície inclui aplicações console, componentes publicados para arquiteturas específicas e binários que mantêm IL, metadados e código nativo pré-compilado no mesmo artefato. O contexto também indica que formatos como assemblies single-file e distribuições self-contained podem aumentar a dificuldade de análise quando combinados com o método, embora esses formatos não sejam necessários para que a divergência entre IL e código nativo exista.

O risco prático aparece quando pipelines de análise, revisão de artefatos ou resposta a incidentes tratam arquivos .NET como se a descompilação gerenciada fosse suficiente. Em ambientes corporativos, isso pode afetar triagem de anexos, utilitários internos, ferramentas administrativas, artefatos coletados de endpoints e binários incluídos em pacotes de software. A técnica não prova, por si só, que um arquivo é malicioso; ela mostra que um binário R2R pode conter duas representações relevantes de comportamento e que divergências entre elas precisam ser interpretadas como sinal de investigação.

O método também amplia a importância de entender a relação entre metadados e código nativo em .NET. Referências aparentemente não usadas no IL ainda podem existir porque o código nativo preservado depende delas. Em programas maiores, esse tipo de inconsistência pode passar despercebido, principalmente quando apenas um método foi alterado e o restante do assembly mantém aparência normal. Uma revisão defensiva precisa diferenciar otimizações legítimas de sinais de adulteração pós-compilação.

• Assemblies .NET com ManagedNativeHeader e READYTORUN_HEADER devem ser tratados como artefatos com duas camadas de comportamento: IL e código nativo pré-compilado.
• Depuradores gerenciados podem não reproduzir a mesma trajetória observada na execução normal do arquivo fora do ambiente de depuração.
• Publicações single-file ou self-contained podem dificultar a inspeção, especialmente quando a análise não extrai e valida os componentes internos.

Hunting e telemetria

A caça defensiva deve começar pela identificação de binários .NET que usam ReadyToRun. A presença de ManagedNativeHeader, READYTORUN_HEADER e da assinatura RTR é um ponto de partida para separar esses artefatos de assemblies puramente gerenciados. Depois, a análise precisa comparar o que a camada IL declara com o que o código nativo pré-compilado faz. Diferenças isoladas podem ocorrer por razões de otimização, mas discrepâncias de alto impacto, como chamadas presentes nos metadados e ausentes da descompilação, regiões nativas anômalas ou métodos com IL artificialmente neutralizado, merecem aprofundamento.

Em endpoint, a telemetria deve correlacionar o processo .NET com comportamento real observado em execução. Como a técnica pode esconder a intenção do programa de ferramentas gerenciadas, eventos de criação de processo, carregamento de módulos, acesso a arquivos, conexões de rede e operações de memória continuam sendo fontes mais confiáveis para confirmar impacto. Quando um binário parece benigno no IL, mas cria processos inesperados ou apresenta comportamento incompatível com a função declarada, a investigação deve incluir desmontagem nativa das regiões R2R e comparação entre execução instrumentada e execução fora do depurador.

Em laboratórios de engenharia reversa, um procedimento defensivo útil é manter duas trilhas de análise. A primeira revisa IL, metadados, referências e C# descompilado. A segunda examina o PE, os cabeçalhos ReadyToRun, os métodos pré-compilados e a região nativa associada. Ferramentas capazes de enumerar métodos R2R, endereços relativos e tamanhos ajudam a localizar áreas que devem ser desmontadas. O objetivo não é reproduzir a técnica, mas verificar se o arquivo contém divergência material entre o comportamento apresentado ao analista e o comportamento provável em tempo de execução.

• Presença de READYTORUN_HEADER em binários .NET submetidos à triagem.
• Métodos com IL vazio, neutralizado ou inconsistente com metadados ainda referenciados pelo assembly.
• Diferença entre comportamento visto em dnSpy ou dnSpyEx e eventos reais de execução coletados no endpoint.
• Regiões nativas pré-compiladas com bytes substituídos, tamanho incomum ou fluxo incompatível com o método gerenciado correspondente.
• Publicações .NET empacotadas que dificultam extração, enumeração de métodos ou correlação entre IL e código nativo.

Mitigação

A resposta defensiva deve tratar binários .NET R2R suspeitos como artefatos híbridos. A análise apenas por descompilação gerenciada não deve ser usada como decisão final quando o arquivo possui código nativo pré-compilado. O primeiro passo é classificar o artefato, confirmar se há cabeçalho ReadyToRun e preservar o arquivo original para comparação. Em seguida, a equipe deve revisar o IL, os metadados e a região nativa correspondente aos métodos relevantes, procurando divergências que indiquem adulteração pós-compilação ou comportamento oculto atrás de código isca.

Na contenção, o foco deve ficar no comportamento confirmado do binário em ambiente controlado e na telemetria dos endpoints onde ele foi executado. Se o arquivo acionou criação de processos, conexões, escrita em disco ou carregamento de componentes não esperados, essas ações devem orientar escopo, bloqueio e remoção. Em pipelines de desenvolvimento, artefatos .NET publicados como ReadyToRun devem manter rastreabilidade de build, assinatura, hash interno e origem. Diferenças entre binário publicado e binário esperado pelo processo de build podem indicar manipulação após a compilação.

Para reduzir exposição, equipes de AppSec e engenharia devem revisar quando o uso de ReadyToRun é realmente necessário e adicionar validações específicas quando esse formato for adotado. Isso inclui manter artefatos de build reproduzíveis, assinar binários, bloquear substituições não autorizadas no pipeline e treinar analistas para reconhecer limitações de depuradores gerenciados. Em resposta a incidentes, a validação deve combinar desmontagem nativa, análise comportamental e revisão de metadados, principalmente quando o IL parecer limpo, mas a execução observada indicar outra lógica.

• Inventariar assemblies .NET ReadyToRun em artefatos recebidos, endpoints investigados e pacotes distribuídos internamente.
• Comparar IL, metadados e código nativo pré-compilado antes de concluir que um binário .NET é benigno.
• Executar análise comportamental em ambiente isolado e registrar criação de processos, módulos carregados, arquivos acessados e tráfego gerado.
• Validar integridade de build, assinatura e origem dos binários .NET publicados em pipelines corporativos.
• Atualizar playbooks de engenharia reversa para incluir inspeção de READYTORUN_HEADER, enumeração de métodos R2R e desmontagem das regiões nativas relevantes.