Brasileiro de 12 anos desenvolve pesquisa de engenharia reversa aplicada à detecção de malware
- Cyber Security Brazil
- há 5 horas
- 5 min de leitura

O brasileiro Lucas Freitas Vieira, de 12 anos, desenvolveu uma pesquisa que combina engenharia reversa, análise estática e regras YARA para identificar estruturas associadas a Return-Oriented Programming (ROP) em arquivos de malware. A versão mais recente do trabalho amplia a metodologia, os experimentos e a revisão da literatura, além de estabelecer uma separação mais rigorosa entre a identificação de capacidade relacionada a ROP e a confirmação de cadeias efetivamente montadas dentro de um binário.
Intitulado Static Detection of ROP Gadget Chains in Malware via Entropy-Aware YARA Rules, o trabalho está disponível no Zenodo como preprint. O estudo ainda está em processo de aprimoramento e não deve ser interpretado como uma pesquisa já validada por revisão por pares. A intenção é submetê-lo à avaliação de especialistas para incorporar críticas e fortalecer a metodologia antes de buscar publicação em plataformas acadêmicas como o arXiv.
A pesquisa aborda uma lacuna específica na análise estática de malware. Ferramentas como ROPgadget e Ropper conseguem enumerar gadgets — pequenas sequências de instruções que podem ser reutilizadas em ataques ROP — existentes em um executável. A presença desses elementos, porém, não significa que o arquivo contenha uma cadeia ROP pronta para execução, já que programas legítimos também apresentam diversos gadgets.
A metodologia desenvolvida procura estruturas mais significativas, como stack pivots, sequências POP;RET usadas no carregamento de registradores e terminadores responsáveis pelo despacho da cadeia. O processo combina essas características com análise de entropia de Shannon por seção do executável PE e uma segunda etapa de verificação baseada em desassemblagem.
A versão revisada organiza o processo em cinco estágios: triagem do arquivo e análise de entropia; identificação de packers; desempacotamento ou localização do Original Entry Point (OEP); engenharia reversa no Ghidra e verificação dos ponteiros da cadeia; e geração e validação das regras YARA.
Um dos pontos centrais é a chamada chain-pointer verification. A etapa procura, nas seções de dados do executável, sequências de ponteiros que direcionem para regiões de código executável. Os destinos são desassemblados e classificados em categorias como PIVOT, POP, TERM ou OTHER. O método também tenta eliminar estruturas legítimas que poderiam ser confundidas com cadeias ROP, incluindo jump tables e vtables.
Essa distinção tornou-se especialmente importante na nova avaliação. O estudo mostra que uma regra YARA baseada apenas na coexistência de determinados padrões pode funcionar como um indicador de capacidade ou estruturas compatíveis com ROP, mas não necessariamente comprova que uma cadeia ROP esteja montada no arquivo. Para uma afirmação de maior confiança, o trabalho reserva a confirmação à etapa adicional de verificação estrutural.
Nos testes internos, a pesquisa avaliou 160 amostras distribuídas entre cinco grupos: 50 shellcode droppers, 50 amostras de AsyncRAT, 30 de njRAT, 10 implantes C2 personalizados e 20 trojans bancários. Como duas regras são avaliadas sobre as mesmas 20 amostras do trojan bancário, o trabalho contabiliza 180 avaliações individuais.
As regras alcançaram TPR agregado de 93,9%, com 169 resultados verdadeiramente positivos nas 180 avaliações. A taxa agregada de falsos positivos foi de 0,026%, correspondente a 13 ocorrências no corpus de 50 mil arquivos PE considerados limpos. O próprio artigo ressalta que as 180 avaliações não são totalmente independentes devido à dupla avaliação das amostras de trojan bancário. Ao atribuir peso igual às cinco famílias, o resultado é de 93,8%.
A análise de entropia também apresentou impacto nos testes. Nas três famílias contendo variantes empacotadas, as condições baseadas em entropia aumentaram em média a taxa de detecção em 16,2 pontos percentuais em comparação com as regras baseadas somente em padrões.
O trabalho compara ainda os resultados com o conjunto de regras YARA-Forge. No corpus utilizado na pesquisa, a abordagem proposta registrou TPR médio de 93,9%, contra 71,2% do baseline, uma diferença de 22,7 pontos percentuais. Em contrapartida, o YARA-Forge apresentou FPR menor: 0,003%, contra 0,026% do método avaliado.
A nova versão amplia significativamente a validação externa. Foram utilizados 56 arquivos de malware provenientes de 22 conjuntos de famílias, incluindo Zeus, SpyEye, Carberp, Dyre, Emotet, AgentTesla, Bumblebee e outras ameaças, além de amostras adicionais de stealers escritos em Rust e controles legítimos selecionados para testar cenários adversos.
A regra estrutural genérica identificou 32 dos 56 binários externos, ou 57,1%, registrando pelo menos uma detecção em 18 dos 22 conjuntos avaliados. Os resultados abrangem RATs, trojans bancários, loaders, droppers, ransomware e stealers lançados entre 2007 e 2025.
Essa avaliação também revelou uma limitação relevante. Três dos quatro arquivos legítimos escolhidos especificamente para testar situações envolvendo software empacotado ou comprimido acionaram pelo menos uma das regras. PuTTY e o instalador do 7-Zip, por exemplo, produziram correspondências relacionadas ao vocabulário de gadgets, enquanto uma versão do PuTTY empacotada com UPX também acionou a trilha destinada a arquivos empacotados.
Por isso, o artigo alerta que determinadas regras devem ser interpretadas como sinais para threat hunting quando não há uma confirmação estrutural adicional. A análise de entropia, isoladamente, também não é considerada evidência suficiente de atividade maliciosa.
A etapa de verificação por ponteiros apresentou um resultado diferente. Nenhuma cadeia ROP estaticamente montada foi confirmada nos 59 arquivos PE reais analisados — 56 amostras externas de malware e três executáveis legítimos. Em contrapartida, o verificador detectou corretamente um executável sintético construído com uma cadeia de cinco gadgets e rejeitou um controle negativo baseado em vtable.
Esse resultado levou o estudo a uma conclusão mais cautelosa: nas amostras externas examinadas, o sinal estático mais útil esteve relacionado à presença de capacidade, padrões estruturais e características de loaders, e não à confirmação de cadeias ROP previamente montadas. Segundo o trabalho, malwares modernos podem construir essas cadeias dinamicamente durante a execução ou simplesmente não utilizar ROP.
Outra mudança importante está na fundamentação acadêmica. A versão revisada documenta uma busca sistemática pela literatura seguindo diretrizes de Kitchenham e o modelo PRISMA 2020. Foram identificados 250 registros, 177 permaneceram após a remoção de duplicatas e 33 estudos foram sintetizados diretamente no trabalho, além de pesquisas fundamentais recuperadas por análise das referências.
O levantamento também permitiu delimitar melhor a contribuição proposta. Já existem pesquisas sobre detecção de ROP em tempo de execução, tráfego de rede e documentos contendo exploits, mas o trabalho concentra-se no cenário de triagem estática de malware PE dentro do ecossistema de ferramentas como YARA e antivírus.
A pesquisa reconhece limitações. As cinco famílias internas possuem entre 10 e 50 amostras cada, os conjuntos utilizados são amostras de conveniência e o corpus de arquivos limpos não representa adequadamente toda a variedade de softwares legítimos empacotados. A cobertura principal também está concentrada nas arquiteturas x86 e x64, enquanto ARM64 e Thumb foram avaliados apenas com gadgets sintéticos.
Além disso, cadeias construídas dinamicamente durante a execução podem não deixar uma estrutura estática para o verificador encontrar. Por esse motivo, o trabalho posiciona a abordagem como uma camada complementar de análise pré-execução, e não como substituta de mecanismos de proteção em runtime.
Os artefatos utilizados na pesquisa foram disponibilizados publicamente, incluindo as regras YARA, scripts de análise de entropia, verificador de ponteiros, anotações das análises realizadas no Ghidra e informações para reprodução dos experimentos. As amostras de malware não são redistribuídas pelo projeto.



