Conferma Sperimentale di CVE-2026-25262 su Snapdragon 8 Gen 1 (SM8450)

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:

• Caricamento di una "raw image" – caricare solo i segmenti LOAD (senza header ELF e il sovrapposto certificato) potrebbe consentire un'inizializzazione corretta.
• Dipendenze da TrustZone – Firehose potrebbe dipendere dal Secure World (chiamate SMC), che potrebbe essere inattivo durante la consegna basata su CVE.

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