Análise pós-CVE-2024-7344 do Howyar SysReturn NetCopy - notas de engenharia reversa, binários vulneráveis, correspondência com o fornecedor e ferramentas de prova de conceito para CVE-2026-79298 (contorno do Secure Boot IA-32 através do carregador PE personalizado RxPE em BOOTia32.efi).
themalwareguardian/uefi-security-research-howyar-sysreturn-netcopy
Sob o manto do Secure Boot, algumas arquiteturas afundam mais fundo do que as vulnerabilidades que as expuseram. Alguns binários são revogados. Alguns patches são distribuídos. Mas bem abaixo da superfície, velhos hábitos deixam rastros. Isto é o que resta quando uma vulnerabilidade é divulgada, corrigida e esquecida.
As descobertas documentadas neste repositório foram atribuídas à CVE-2026-79298.
Durante o processo de divulgação coordenada, o fornecedor confirmou que a remediação associada à CVE-2024-7344 abordou apenas o caminho de boot x64. O caminho de boot IA-32 - incluindo o BOOTia32.efi distribuído como parte do recurso SysReturn NetCopy - nunca foi incluído na remediação original. Como resultado, o componente IA-32 vulnerável continuou a ser distribuído comercialmente até a versão 11.3.034 (julho de 2026).
O repositório dedicado à CVE aponta de volta para cá para a profundidade técnica completa: engenharia reversa, análise de binários, correspondência com o fornecedor, artefatos de reprodução e ferramentas de prova de conceito.
Ao longo de 2026, estive profundamente envolvido com segurança UEFI - desenvolvimento de bootkits, bypasses de Secure Boot, exploração de firmware, análise de CVEs, desenvolvimento de ferramentas ofensivas, publicação de pesquisas. É a área na qual escolhi me especializar e cada semana traz algo novo. Parte desse trabalho envolve explorar CVEs conhecidas em componentes UEFI. Parte envolve pesquisar softwares que distribuem bootloaders UEFI mas receberam pouca análise pública. E parte - a parte que este repositório documenta - envolve fazer uma pergunta que acho que é negligenciada com demasiada frequência:
Como é um produto depois de uma CVE?
Não durante a correria dos patches. Não na semana em que o aviso é publicado. Dezoito meses depois, quando a pressão desapareceu, quando os pesquisadores seguiram em frente, quando ninguém mais está observando.
Este repositório é minha tentativa de responder a essa pergunta para um produto específico: Howyar SysReturn NetCopy.
E acho que o que encontrei vai surpreender as pessoas.
Tudo em pesquisa de segurança se conecta a algo mais se você seguir os fios por tempo suficiente. Este fio em particular começou no trabalho. Fomos encarregados de analisar o risco real de ataques UEFI e bootkit contra uma categoria específica de ambiente: centros educacionais. Parece nichado. Não é.
Aqui está a realidade que a maioria das pessoas fora deste campo não aprecia plenamente. Em uma cidade de médio porte, pode facilmente haver 70.000 ou mais dispositivos compartilhados implantados em escolas - laptops e workstations usados por estudantes entre oito e quinze anos, executando distribuições Linux porque o licenciamento do Windows nessa escala é frequentemente proibitivo.
Agora pergunte a si mesmo: quantas dessas máquinas têm o Secure Boot devidamente habilitado? A resposta honesta, na maioria dos lugares, é muito poucas. E a razão não é negligência. É a realidade operacional.
Habilitar o Secure Boot corretamente em um ambiente Linux significa assinar cada kernel. Cada atualização de kernel - e vulnerabilidades do kernel Linux têm surgido rapidamente nos últimos anos - exige uma nova imagem assinada a ser implantada em cada máquina. Isso significa pipelines de atualização coordenados, infraestrutura de gerenciamento de chaves, pessoal treinado e manutenção contínua em milhares de endpoints distribuídos por dezenas de locais.
Para organizações com esses recursos, é gerenciável. Para a maioria dos distritos escolares, não é. Simplesmente não há pessoas suficientes, orçamento suficiente e ferramentas suficientes para fazer isso corretamente nessa escala. Então o Secure Boot permanece desabilitado.
Senhas de BIOS não são configuradas - porque rotacioná-las em 70.000 máquinas com equipe limitada é impraticável. E essas máquinas ficam lá, totalmente expostas no nível do firmware, usadas por centenas de estudantes todos os dias.
O que isso realmente significa, do ponto de vista de segurança, é que um atacante que entende de exploração UEFI pode comprometer uma dessas máquinas na camada de firmware - antes do SO carregar, antes de qualquer software de segurança iniciar, antes de qualquer mecanismo de proteção ter a chance de intervir. Um bootkit pode persistir através de reinicializações, através de reinstalações do SO, através de tudo. Eu sei disso porque eu mesmo desenvolvo esse tipo de ferramenta. As técnicas existem. Não são teóricas.
Este é um problema conhecido. É amplamente reconhecido. E não vai desaparecer tão cedo.
A resposta operacional a esse problema - a coisa que as escolas realmente implantam em vez do Secure Boot adequado - é o software de recuperação.
A ideia é direta: qualquer coisa que um estudante faça durante uma sessão, tudo retorna a um estado conhecido como limpo após a próxima reinicialização. Malware, alterações de configuração, arquivos de sistema corrompidos, dados excluídos acidental ou intencionalmente - tudo desaparece. Isso reduz drasticamente os custos de manutenção e dá aos administradores uma maneira de gerenciar máquinas compartilhadas sem precisar de controles de segurança perfeitos no nível do firmware em cada dispositivo.
Quando começamos a avaliar quais produtos estavam sendo usados nesses ambientes, vários nomes surgiram. Um deles era o Howyar SysReturn - um produto taiwanês projetado especificamente para implantações educacionais, com suporte explícito para laboratórios de informática escolares, workstations compartilhadas e ambientes gerenciados em larga escala.
No momento em que vi esse nome, soube exatamente o que queria fazer.
Em janeiro de 2025, a ESET Research publicou a divulgação da CVE-2024-7344 - um bypass de Secure Boot afetando o SysReturn e vários outros produtos de recuperação construídos sobre a mesma base de código.
A vulnerabilidade era elegante de uma forma profundamente frustrante. Uma aplicação UEFI assinada pela Microsoft - confiada pelo firmware, capaz de executar mesmo com o Secure Boot habilitado - implementava seu próprio carregador PE personalizado inteiramente do zero. Em vez de usar as funções padrão UEFI LoadImage e StartImage, que impõem a verificação de assinatura do Secure Boot, ela analisava e executava binários EFI manualmente a partir de um arquivo chamado cloak.dat. Criptografado com XOR com uma chave de byte único. Sem verificação de assinatura. Qualquer coisa dentro desse arquivo executava com total confiança no nível do firmware.
A Microsoft revogou os binários vulneráveis na atualização Patch Tuesday de janeiro de 2025. A indústria de segurança seguiu para a próxima coisa. Mas eu continuei pensando nisso.
Não porque a vulnerabilidade em si não estava resolvida - a ESET a documentou minuciosamente e a revogação foi clara. O que continuava me incomodando era uma pergunta diferente. O tipo de pergunta que só se torna respondível com o tempo:
Eles realmente corrigiram? Ou apenas contornaram a pressão?
Há uma diferença. Uma correção real aborda a causa raiz - neste caso, o uso de um carregador PE personalizado que contorna o Secure Boot. Um contorno faz o problema imediato desaparecer enquanto deixa a arquitetura subjacente intacta.
Eu queria saber qual dos dois a Howyar havia feito.
Entrei em contato diretamente com a Howyar Technologies e solicitei uma cópia de avaliação do SysReturn para uma avaliação profissional de aquisição - o que, dado o contexto profissional que originou esta pesquisa, era totalmente preciso.
O fornecedor foi prestativo e responsivo. Eles forneceram uma licença de teste completa, manuais, vídeos tutoriais e um pacote de avaliação completo. Também responderam a perguntas detalhadas sobre compatibilidade com Secure Boot, o que acabou sendo diretamente relevante para o que encontrei depois.
Toda essa correspondência está incluída neste repositório, sem edições.
Não vou estragar os detalhes técnicos aqui - é para isso que serve o diretório Vulnerability Research, e recomendo genuinamente lê-lo na íntegra. Mas direi o seguinte.
UEFI é um mundo próprio. Os desenvolvedores que trabalham nele são poucos. Os processos de revisão de segurança que existem para software de aplicação ou serviços web não alcançam rotineiramente componentes de firmware. Más práticas, uma vez estabelecidas, tendem a persistir - não por malícia, mas porque o ecossistema é pequeno, o escrutínio é raro, e as consequências de errar são frequentemente invisíveis para todos, exceto para o punhado de pesquisadores prestando atenção.
O que encontrei no SysReturn v11.2.031 - lançado em abril de 2026, mais de quinze meses após a revogação da Microsoft - é um exemplo claro exatamente dessa dinâmica.
A causa raiz não foi corrigida. O binário vulnerável não foi substituído. O que mudou foi operacional: um caminho de boot diferente para sistemas com Secure Boot habilitado, deixando quase todo o resto intocado.
O carregador PE personalizado - o componente RxPE, nomeado nas próprias strings de debug do binário - está presente no lançamento de abril de 2026, funcionando de forma idêntica a como funcionava na versão que a ESET analisou em 2024.
O hash Authenticode do binário que a Howyar distribuiu em abril de 2026 corresponde, byte a byte, ao hash que a Microsoft revogou em janeiro de 2025.
Acho que isso importa. Acho que as pessoas deveriam saber disso. E acho que a documentação técnica neste repositório é detalhada o suficiente para que qualquer pessoa que queira verificar essas descobertas por conta própria possa fazê-lo.
| Diretório | Descrição |
|---|---|
📚 00 Manual | Manuais do fornecedor, brochuras e documentação oficial do produto fornecida pela Howyar |
📦 01 Binaries | Binários principais extraídos do pacote de avaliação para análise |
📬 02 Disclosure | Correspondência completa por e-mail com a Howyar Technologies durante o processo de avaliação |
🔬 03 Vulnerability Research | Engenharia reversa, análise de binários, verificação Authenticode, análise do formato ALRM, scripts e descobertas técnicas |
A história técnica - a engenharia reversa completa do BOOTia32.efi, o formato de payload ALRM, a descriptografia XOR, o carregador PE personalizado RxPE, a correspondência do hash Authenticode com o binário revogado, e a análise do que a Howyar realmente mudou versus o que deixou intocado - está toda em:
Se você quer contexto sobre a CVE em si antes de mergulhar na análise pós-"patch", o aviso da ESET é uma boa referência. Também mantenho um repositório documentando a CVE-2024-7344 e vulnerabilidades UEFI relacionadas com mais detalhes.
Comece a ler. O manto ainda está lá.
