CVE-2025-21479 Replikation: vivo iQOO 11 Pro (PD2254) temporärer Root

Autorisierte Sicherheitsforschung am eigenen Gerät. CVE-2025-21479 ist eine öffentlich bekannte, bereits behobene (2025-08), in der CISA-KEV gelistete Qualcomm-Adreno-GPU-Schwachstelle. Dieses Dokument beschreibt den vollständigen Ablauf und die endgültige Bereitstellung der Replikation eines temporären Roots auf dem iQOO 11 Pro.

1. Schwachstellenübersicht

• CVE: CVE-2025-21479 (CVSS 8.6, CWE-863 Incorrect Authorization)
• Komponente: Qualcomm-Adreno-GPU-Firmware (a740_sqe.fw)
• Grundursache: Fehlerhafte Filterbedingung der Mikrocode-Anweisung and $04, $12, 0x3 der v675-Firmware (Patch-Version: 0x7), die es Benutzermodus-Befehlsströmen ermöglicht, Berechtigungsprüfungen zu umgehen, privilegierte GPU-Operationen auszuführen (SMMU-Seitentabellen-Übernahme) und so letztlich beliebige physische Speicherzugriffe zu erreichen
• Betroffen: Adreno-A7xx-Serie (Snapdragon 8 Gen 1/2/3 usw.)
• Fix: Qualcomm 2025-06 Bulletin / Google 2025-08 Security Patch (Firmware v676+)

2. Zielgerät

Die Android-16-Firmware (16.3.10.1) ist bereits gepatcht; diese Replikation funktioniert nur unter Android 15 (15.2.12.2).

3. Replikationsquellen

• zhuowei/cheese (Quest 3/3S, Adreno 740)
• ma4the/omae-wa-cheese-da (Galaxy Z Flip5, SM8550/Adreno 740 v675)

4. Portierungsarbeiten

4.1 Validierung der Schwachstellenverfügbarkeit (offline)

• Extraktion von a740_sqe.fw aus dem OTA-Vollpaket: 75.380 Bytes; Suche nach dem verwundbaren Befehlsmuster 0300 422a (and $04,$12,0x3) ergab 3 Treffer → nicht gepatcht
• Das Muster fehlt in derselben Datei des Android-16-Pakets → gepatcht

4.2 Extraktion von Kernel-Material (offline)

• boot.img → kernel.raw → vmlinux-to-elf zur Symbolwiederherstellung
• Wichtige Symbole: _text=0xffffffc008000000, _stext=0xffffffc008010000, swapper_pg_dir, selinux_state, init_task
• BTF-Strukturoffsets (task_struct / mm_struct / cred)
• KASLR-Validierung: physisches _stext fixiert bei 0xa8010000 (PHYS_OFFSET=0xA8000000, SM8550-Standardlayout), auf VMLINUX-Seite bestätigt unter 0xffffffc008010000

4.3 Wichtige Portierungspunkte (relativ zu omae-wa-cheese-da)

1. KASLR-Konstanten: VA von swapper_pg_dir / init_task / selinux_state durch A15-Werte ersetzt
2. SELinux-Bypass: Physisches Schreiben von selinux_state.enforcing=0. Verifiziert, dass der PD2254-A15-Kernel CONFIG_SECURITY_SELINUX_DEVELOP=y enthält (kallsyms enthält sel_write_enforce/enforcing_setup); enforcing_enabled() liest das Feld zur Laufzeit → Schreiben wirkt, getenforce zeigt Permissive
3. Adaption der GPU-Spray-Kandidaten (kritisch): Die Samsung-Kandidaten (0xbe..-0xfe..) liegen im 2-4-GB-Geräte-Reservierungsbereich von vivo; >4GB (0x100000000) löst einen GPU-SMMU-Fehler mit Neustart aus. Kombinierte Strategie = verifizierter 0xfebeb000-Cluster + benachbarte 2-4-GB-Kandidaten + spärlich verteilte Hochbereichs-Kandidaten von 5-11 GB → deutlich höhere Trefferquote
4. Root-Entwicklung (nur Caps, Kernmaßnahme gegen vivo Anti-Root): vivos vr.ko (Modul in vendorboot eingebettet) tötet über kprobe/tracepoint-Hooks + einen Watchdog-Thread jeden uid=0-Prozess, und das Modul versteckt sich selbst und prüft vermagic. Daher kein Null-UID, sondern physisches Überschreiben der Capability-Bits von cred (uid bleibt 2000 + alle Caps + PR_SET_KEEPCAPS/) → vollständige Capability-Menge bleibt über exec hinweg erhalten, entspricht Root, ohne den Watchdog auszulösen

5. Verifizierungsergebnisse (echtes Gerät)

Erfolgslog (erster Lauf, Gerät anfangs Enforcing, über den physischen Schreibpfad für enforcing):

phyaddr: 0xfebeb000 (attempt 1/27)        # Spray-Kandidat getroffen
GPU R/W ready                             # Beliebiger physischer Lese-/Schreibzugriff hergestellt
found _stext at 0xa8010000                # KASLR-Leak (Scan-Pfad; bei explizitem CHEESE_STEXT_PA wird diese Zeile nicht ausgegeben)
FW symbols resolved
stext = 0xa8010000                        # physisches _stext = VA - 0xffffffc000000000 + 0xA8000000
SELinux enforcing overwrite verified (readback=1 enforce=0)
self creds: full caps granted (uid=2000 kept, watchdog dodge)
root shell (uid=2000, full caps kept)...

Bei einem zweiten Lauf in derselben Sitzung (SELinux bereits permissiv) lautet die Zeile SELinux already permissive.

6. Verwendung

# Nach dem Flashen von Android 15 (15.2.12.2) auf dem Gerät:
adb push cheese /data/local/tmp/
adb shell chmod 755 /data/local/tmp/cheese
adb shell CHEESE_STEXT_PA=0xa8010000 /data/local/tmp/cheese
# Danach ist die aktuelle adb-Shell-Sitzung eine Root-Shell (uid=2000 + volle Caps), SELinux im Permissive-Modus

Umgebungsvariablen:

Automatische Wiederholung: bash cheese_auto.sh (Schleifenausführung, Erkennung von Offline-Neustarts, Protokollierung in Dateien).

7. Hinweise

• Temporärer Root: Nach jedem Neustart erneut ausführen; SELinux kehrt zu Enforcing zurück
• GPU-Spray ist probabilistisch: Bei Fehlschlag einfach wiederholen (nach kombinierten Kandidaten hohe Trefferquote in der ersten Runde)
• Einige Hochbereichs-Kandidaten können einen GPU-Fehler mit Geräteneustart auslösen (harmlos; automatische Wiederholung nach dem Neustart)
• Bekannte Einschränkungen: vivos vr.ko tötet uid=0-Prozesse und das Modul versteckt sich selbst; keine Persistenz / KernelSU-Integration (KernelSU-Modul kann wegen nicht exportierter Kernel-Symbole nicht per insmod geladen werden, siehe Anhang)
• Nur für autorisierte Sicherheitsforschung am eigenen Gerät

8. Dateiliste

• cheese: Kompiliertes Artefakt (aarch64-Android-ELF, NDK r28, Binärbereitstellung, Quellcode nicht öffentlich)
• cheese_auto.sh: Skript für automatische Wiederholung
• README.md: Dieses Dokument

Anhang: vivos Anti-Root-Mechanismus (vr.ko)

• Quelle: lib/modules/5.15-gki/vr.ko in vendorboot.img (389 KB)
• Mechanismus: kprobe-/tracepoint-Hooks + Watchdog-Thread, überwacht und tötet uid=0-Prozesse; versteckt sich nach dem Laden selbst, rmmod wirkungslos
• Schlussfolgerung zur Gegenmaßnahme: Normales setuid, physisches Ändern von cred auf uid=0 und Vererbung durch Kindprozesse werden alle abgetötet → einziger stabiler Pfad ist nur Caps (uid≠0 + volle Caps)

Haftungsausschluss

Dieses Repository dient ausschließlich Sicherheitsforschung und Bildungszwecken; alle Tests wurden auf dem eigenen Gerät des Autors durchgeführt. Bitte nur im rechtlich autorisierten Rahmen verwenden; die Verwendung erfolgt auf eigene Verantwortung.