CVE-2026-25262 Anwendbarkeit auf Snapdragon 8 Gen 1 — experimentelle Ergebnisse
Status:
Teilerfolg – willkürliches SRAM-Schreiben bestätigt, vollständige Firehose-Initialisierung ausstehend.
Dieses Repository enthält die Ergebnisse einer experimentellen Studie zur Anwendbarkeit von CVE-2026-25262 (Write-What-Where im Qualcomm Sahara-Protokoll) auf der Snapdragon 8 Gen 1 (SM8450)-Plattform, insbesondere auf dem POCO F4 GT-Gerät (Codename ingres).
Wichtige Erkenntnisse (bestätigt):
CVE-2026-25262 ist auf SM8450 ausnutzbar. Ein willkürliches Schreiben von Daten in den SRAM während des Sahara-Handshakes ist unter Umgehung der Signaturprüfung möglich. Dies bestätigt die Anwendbarkeit der Schwachstelle auf eine moderne 64-Bit-ARMv9-Plattform, die über die offiziell anerkannte Liste veralteter 32- und 64-Bit-Chipsätze (ARMv7-A, ARMv8-A) hinausgeht.
Das kritische Authentifizierungs-Flag wurde identifiziert. Die statische Analyse des Firehose-Laders (xbl_s_devprg_ns.melf) offenbarte eine globale Struktur an der Adresse 0x6b9cd500. Der Authentifizierungszustand wird durch ein 64-Bit-Feld bei Offset 0x38 (0x6b9cd538) gesteuert. Basierend auf der statischen Analyse sollte das Setzen dieses Feldes auf 5 theoretisch vollen Zugriff gewähren.
Die Flag-Injektion ist technisch machbar. Mit einem benutzerdefinierten Tool (cve_final_single) wurde der Wert 5 an die Adresse 0x6b9cd538 geschrieben, bevor die Kontrolle an den Lader übergeben wurde. Der Schreibvorgang wird im Log aufgezeichnet, aber die direkte Auswirkung dieser Operation auf die Deaktivierung der Authentifizierung bleibt weiterer Überprüfung vorbehalten.
Der Lader-Code wird ausgeführt. Nach der Injektion antwortet der Firehose-Lader auf grundlegende Befehle (nop), und der Authentifizierungsfehler (Only nop and sig tag...) wird nicht beobachtet. Dies bestätigt, dass der Code aktiv ist, obwohl der genaue Ausführungskontext (Non‑Secure World oder ein Übergangszustand) weiterer Analyse vorbehalten bleibt.
Voller UFS-Zugriff wurde noch nicht erreicht. Befehle wie getstorageinfo geben eine leere Antwort zurück; der Lader liefert keine Diagnoseinformationen (TargetName, MemoryName, Version). Dies deutet auf eine unvollständige Initialisierung hin.
Das PBL-Verhalten bei Hash-Fehler (unter standardmäßigem, signaturverifiziertem Boot) wurde ermittelt. Das absichtliche Korrumpieren der Hash-Tabelle in einer Referenzdatei löst bei Original-Tools (edl, qdl) konsistent einen 48-Statusfehler (SAHARA_NAK_HASH_VERIFICATION_FAILURE) aus. Dies dient als Basislinie für die Verifikation.
Aktueller Status:
Wir untersuchen aktiv die verbleibenden Schritte zur vollständigen Firehose-Initialisierung. Zwei Haupthypothesen werden geprüft:
Parallel dazu wird die Hypothese bezüglich der TrustZone-Abhängigkeit von Firehose untersucht: Wenn der Treiber SMC-Aufrufe für den UFS-Zugriff verwendet, müssen diese durch Patchen neutralisiert werden.
Die Arbeit läuft. Das Repository wird aktualisiert, sobald neue Ergebnisse vorliegen.
Repository-Struktur:
├── 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
⚠️ Verantwortungsvolle Offenlegung:
Diese Arbeit wird zu Bildungs- und Forschungszwecken veröffentlicht. Der vollständige Exploit-Code wird nicht bereitgestellt. Die beschriebenen Details sind ausreichend für die Verifikation und weitere Studien, beinhalten jedoch keine gebrauchsfertigen Werkzeuge für Angriffe.
📬 Kontakt:
Bei Fragen oder zur Zusammenarbeit öffnen Sie bitte ein Issue in diesem Repository.
Zuletzt aktualisiert: Juli 2026