CVE-2026-25262 aplicabilidade ao Snapdragon 8 Gen 1 — resultados experimentais
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:
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