Confirmação Experimental do CVE-2026-25262 no Snapdragon 8 Gen 1 (SM8450)

Status:
Sucesso parcial — gravação arbitrária em SRAM confirmada, inicialização completa do Firehose pendente.

Este repositório contém os resultados de um estudo experimental sobre a aplicabilidade do CVE-2026-25262 (Write-What-Where no protocolo Qualcomm Sahara) à plataforma Snapdragon 8 Gen 1 (SM8450), especificamente no dispositivo POCO F4 GT (codinome ingres).

Principais descobertas (confirmadas):

• CVE-2026-25262 é explorável no SM8450. A gravação arbitrária de dados na SRAM durante o handshake do Sahara é possível contornando a verificação de assinatura. Isso confirma a aplicabilidade da vulnerabilidade a uma plataforma ARMv9 moderna de 64 bits, além da lista oficialmente reconhecida de chipsets legados de 32 e 64 bits (ARMv7-A, ARMv8-A).

• O sinalizador crítico de autenticação foi identificado. A análise estática do carregador Firehose (xbl_s_devprg_ns.melf) revelou uma estrutura global no endereço 0x6b9cd500. O estado de autenticação é controlado por um campo de 64 bits no offset 0x38 (0x6b9cd538). Com base na análise estática, definir este campo como 5 teoricamente deve conceder acesso total.

• A injeção do sinalizador é tecnicamente viável. Usando uma ferramenta personalizada (cve_final_single), o valor 5 foi gravado no endereço 0x6b9cd538 antes de transferir o controle para o carregador. A gravação é registrada no log, mas o efeito direto dessa operação na desabilitação da autenticação permanece sujeito a verificação adicional.

• O código do carregador está em execução. Após a injeção, o carregador Firehose responde a comandos básicos (nop), e o erro de autenticação (Only nop and sig tag...) não é observado. Isso confirma que o código está ativo, embora o contexto exato de execução (Non‑Secure World ou um estado transitório) permaneça sujeito a análise adicional.

• O acesso completo à UFS ainda não foi obtido. Comandos como getstorageinfo retornam uma resposta vazia; o carregador não fornece informações de diagnóstico (TargetName, MemoryName, Version). Isso indica inicialização incompleta.

• O comportamento do PBL em caso de erro de hash (sob boot padrão com verificação de assinatura) foi estabelecido. A corrupção intencional da tabela de hash em um arquivo de referência aciona consistentemente um erro de status 48 (SAHARA_NAK_HASH_VERIFICATION_FAILURE) com ferramentas originais (edl, qdl). Isso serve como nossa linha de base para verificação.

Status atual:
Estamos investigando ativamente as etapas restantes para alcançar a inicialização completa do Firehose. Duas hipóteses principais estão sendo examinadas:

• Carregar uma "imagem raw" – carregar apenas os segmentos LOAD (sem cabeçalhos ELF e a sobreposição de certificado) pode permitir a inicialização correta.
• Dependências do TrustZone – o Firehose pode depender do Secure World (chamadas SMC), que pode estar inativo durante a entrega baseada em CVE.

Em paralelo, a hipótese sobre a dependência do Firehose do TrustZone será explorada: se o driver usar chamadas SMC para acesso à UFS, elas precisarão ser neutralizadas via patching.

O trabalho está em andamento. O repositório será atualizado à medida que novos resultados forem obtidos.

Estrutura do repositório:

├── README.md                 
├── docs/
│   └── README_ru.md          
├── article/
│   ├── article_en.md        
│   └── article_ru.md         
├── evidence/
│   ├── pbl_status_en.md
│   └── pbl_status_ru.md  
│   ├── ghidra_analysis_en.md
│   └── ghidra_analysis_ru.md
│   └── cve_injection_log_en.md
│   └── cve_injection_log_ru.md 
└── tools/
    ├── README_en.md
    └── README_ru.md             

⚠️ Divulgação responsável:
Este trabalho é publicado para fins educacionais e de pesquisa. O código de exploração completo não é fornecido. Os detalhes descritos são suficientes para verificação e estudo adicional, mas não incluem ferramentas prontas para ataques.

📬 Contato:
Para perguntas ou colaboração, por favor abra uma issue neste repositório.

Última atualização: julho de 2026