CVE-2026-25262 applicabilità a Snapdragon 8 Gen 1 — risultati sperimentali
Stato:
Successo parziale — scrittura SRAM arbitraria confermata, inizializzazione completa di Firehose in attesa.
Questo repository contiene i risultati di uno studio sperimentale sull'applicabilità di CVE-2026-25262 (Write-What-Where nel protocollo Sahara di Qualcomm) alla piattaforma Snapdragon 8 Gen 1 (SM8450), in particolare al dispositivo POCO F4 GT (nome in codice ingres).
Risultati chiave (confermati):
CVE-2026-25262 è sfruttabile su SM8450. La scrittura arbitraria di dati in SRAM durante l'handshake Sahara è possibile bypassando la verifica della firma. Ciò conferma l'applicabilità della vulnerabilità a una moderna piattaforma ARMv9 a 64 bit oltre all'elenco ufficialmente riconosciuto di chipset legacy a 32 e 64 bit (ARMv7-A, ARMv8-A).
Il flag critico di autenticazione è stato identificato. L'analisi statica del loader Firehose (xbl_s_devprg_ns.melf) ha rivelato una struttura globale all'indirizzo 0x6b9cd500. Lo stato di autenticazione è controllato da un campo a 64 bit all'offset 0x38 (0x6b9cd538). Sulla base dell'analisi statica, impostare questo campo a 5 dovrebbe teoricamente concedere accesso completo.
L'iniezione del flag è tecnicamente fattibile. Utilizzando uno strumento personalizzato (cve_final_single), il valore 5 è stato scritto all'indirizzo 0x6b9cd538 prima di trasferire il controllo al loader. La scrittura viene registrata nel log, ma l'effetto diretto di questa operazione sulla disabilitazione dell'autenticazione rimane soggetto a ulteriori verifiche.
Il codice del loader è in esecuzione. Dopo l'iniezione, il loader Firehose risponde ai comandi base (nop) e l'errore di autenticazione (Only nop and sig tag...) non viene osservato. Ciò conferma che il codice è attivo, sebbene il contesto esatto di esecuzione (Non‑Secure World o stato transitorio) rimanga da analizzare.
L'accesso completo a UFS non è stato ancora ottenuto. Comandi come getstorageinfo restituiscono una risposta vuota; il loader non fornisce informazioni diagnostiche (TargetName, MemoryName, Version). Ciò indica un'inizializzazione incompleta.
Il comportamento del PBL in caso di errore di hash (con avvio standard firmato) è stato stabilito. La corruzione intenzionale della tabella hash in un file di riferimento attiva costantemente un errore di stato 48 (SAHARA_NAK_HASH_VERIFICATION_FAILURE) con gli strumenti originali (edl, qdl). Questo funge da baseline per la verifica.
Stato attuale:
Stiamo investigando attivamente i passaggi rimanenti per ottenere l'inizializzazione completa di Firehose. Due ipotesi principali sono in esame:
In parallelo, verrà esplorata l'ipotesi della dipendenza di Firehose da TrustZone: se il driver utilizza chiamate SMC per l'accesso UFS, queste dovranno essere neutralizzate tramite patching.
Il lavoro è in corso. Il repository verrà aggiornato man mano che si ottengono nuovi risultati.
Struttura del repository:
├── 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
⚠️ Divulgazione responsabile:
Questo lavoro è pubblicato a scopo educativo e di ricerca. Il codice di exploit completo non viene fornito. I dettagli descritti sono sufficienti per la verifica e ulteriori studi, ma non includono strumenti pronti per attacchi.
📬 Contatto:
Per domande o collaborazioni, si prega di aprire una issue in questo repository.
Ultimo aggiornamento: Luglio 2026