Was wurde unternommen

1. Quellcode-Analyse → Struktur-Offsets extrahiert

Extrahiert aus arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Speicherlayout: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 Bits, vollständig analysiert (ABI XML layout-offset-in-bits)
• file_operations: kein iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 Bytes, uid=0x04
• struct page: 64 Bytes, slab_cache=0x18

Wichtige Erkenntnis: Quelle ist android15 GKI, Gerät ist android13 GKI — task_struct-Offsets weichen um 0x40~0x88 Bytes ab, können nicht direkt aus der Quelle übernommen werden.

2. Firmware-Entpackung → Symbole extrahiert

Symbole aus zwei Firmware-Versionen (15.2.7.6 / 15.2.10.2) extrahiert — dasselbe Symbol weicht zwischen den Versionen um 10KB~200KB ab, die richtige Version muss verwendet werden.

3. Disassemblierungs-Verifikation → capstone bestätigt kritische Offsets

Dies bestätigt, dass das task_struct-Layout dem android15-Zweig entspricht, nicht frankels android13.

4. Kompilierung → erfolgreich

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Ausführung → wiederholte Abstürze

Absturz-Instruktion (capstone):

Warum es fehlschlug

Grundursache 1: KernelSnitch auf MTK unzuverlässig

KernelSnitch ist der Einstiegspunkt des gesamten Exploits — es leakt die mm_struct-Adresse über Timing-Unterschiede im futex-Hash-Bucket:

1. Kollisionserkennung erfolgreich — 5 Kollisionen bei niedriger Schwelle gefunden
2. Bruteforce-Matching schlägt fast immer fehl — das Kernproblem:

Pixel-Geräte haben kein KASAN_HW_TAGS, dort funktioniert dieser Mechanismus. MTK nicht.

Grundursache 2: CONFIG_PANIC_ON_OOPS ist der Killer

Zudem ist der Bootloader gesperrt (flash.locked=1) → kein Flashen eines benutzerdefinierten Kernels möglich, um diese Option zu entfernen.

Grundursache 3: Kernel-Versionsdrift

Obwohl die Hauptversionsnummern beide 5.15.178 sind, unterscheiden sich die GKI-Zweige (android13 vs android15), wodurch die Layouts kritischer Strukturen wie task_struct/cred inkonsistent sind. Nach wiederholtem Wechsel zwischen frankel/android15-Offset-Sätzen wurde die korrekte Version letztlich per Disassemblierung bestimmt.

Versuchte Anpassungen (alle wirkungslos)

Aktueller Stand von target.h

In exploit/targets/android_15.0_kernel_MT6985/target.h:

Assemblierung erfolgreich, läuft, scheitert auf der letzten Meile.

Wenn du weitermachen willst

Notwendige Bedingungen (alle erforderlich)

1. CONFIG_PANIC_ON_OOPS entfernen — entweder benutzerdefinierten Kernel flashen (Bootloader-Entsperrung erforderlich) oder ein MT6985-Gerät finden, bei dem diese Option standardmäßig deaktiviert ist
2. KernelSnitch lösen — Cache-Timing-Kalibrierung für MTK Dimensity 9200 erforderlich, oder KernelSnitch im Exploit vollständig durch eine andere mm_struct-Leak-Methode ersetzen

Mögliche alternative Ansätze

• /proc/self/pagemap — auf diesem Gerät eingeschränkt (gibt nur Nullen zurück)
• MTK-spezifische Debug-Schnittstellen (/proc/mtk_*) — vorhanden, aber weitere Analyse erforderlich
• MTK-Kamera/GPU-Treiber-ioctl-Schwachstellen — einfacherer Privilege-Escalation-Pfad
• Auf Community-Adaption für MTK-Varianten warten

Verbleibender Wert dieses Repos

• symbols/kallsyms_PD2241_15.2.10.2.txt — vollständige 15.2.10.2-Symboltabelle, direkt für Nachfolger nutzbar
• device_config.txt — tatsächliche Kernel-Konfiguration des Geräts, zeigt Vendor-Änderungen
• exploit/targets/android_15.0_kernel_MT6985/target.h — Struktur-Offsets verifiziert
• scripts/server_compile.py — automatisierte Kompilierung, schnelle Neukompilierung nach Parameteränderungen

Fehler-Checkliste (zur Vermeidung für Nachfolger)

1. Dateien unter Windows entpacken: tar -xf kann bei großen ZIPs fehlschlagen, Python zipfile verwenden oder manuell zuerst entpacken
2. payload_dumper-Protobuf-Versionskonflikt: Generiertes update_metadata_pb2.py erfordert protobuf 5.x, die runtime_version-Importzeile muss manuell entfernt werden
3. Direkte Ausführung von ./preload.so führt zu Segfault: /system/bin/linker64 /data/local/tmp/preload.so muss verwendet werden
4. ABI XML ist genauer als Quellcode: layout-offset-in-bits wird vom Compiler berechnet, 100× genauer als manuelles Zählen über 5000 Bytes
5. GKI-Zweig beeinflusst Layout: task_struct unterscheidet sich zwischen android13/14/15, Offsets dürfen nicht über Zweige hinweg kopiert werden
6. Unterschiedliche Firmware-Versionen → unterschiedliche Symbol-Offsets: 15.2.7.6 und 15.2.10.2 weichen um 10KB~200KB ab
7. vivo-Vendor fügt viele OEM-Felder hinzu: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → Abweichung vom Standard-GKI
8. Toolchain zur Symbol-Extraktion: boot.img → kernel.bin → LZ4 entpacken → Image → kallsyms-finder → Symboltabelle

Zeitlinie

2026-07-29, lived to tell the tale

2026-07-31 Fortsetzung: Verifikation und Korrektur nach Erhalt des Quellcodes

Nach Erhalt von android_15.0_kernel_MT6985.tar.gz (5.15.178-Quellbaum + ABI XML) wurde eine vollständige Kreuzvalidierung durchgeführt, Details in VERIFICATION.md. Zusammenfassung:

1. MT6985 = Dimensity 9200 (MT6989 ist die 9300), oben korrigiert.
2. Symbol-Offsets 23/23 korrekt (kallsyms-verifiziert), task_struct / cred / waiter / page / pipe / configfs-Offsets stimmen alle mit dem Quellbaum-ABI überein.
3. FOPS-Offsets waren falsch: ursprünglich von frankel übernommen (android13 GKI, ohne iopoll, ioctl=0x48); aber das task_struct-Layout des Geräts (pi_blocked_on=0x8b0, per Laufzeit-Disassemblierung bestätigt) stimmt mit diesem Quellbaum überein, daher sollte file_operations desselben Kernels iopoll@0x30, ioctl=0x50, open=0x70 usw. haben — target.h korrigiert, zusätzlich mit der im Exploit enthaltenen leak_kernel_base()-Selbstverifikation auf dem echten Gerät als Absicherung.
4. KernelSnitch-MTK-Kompatibilitätspatch (patches/kernelsnitch_mtk_fixes.patch):
   • Größe der Userspace-futex-Hash-Tabelle an den Kernel angeglichen (possible CPU + 2, aufgerundet auf Zweierpotenz), um das zwangsläufige Scheitern von Bruteforce bei possible≠online zu vermeiden;
   • MTE-Tag-Durchlauf um 0xf (untagged) ergänzt und KSNITCH_MTE_ENABLED=1 tatsächlich wirksam gemacht (original util.c hatte mte=0 hartkodiert);
   • Keine Auswirkung auf Nicht-MTK-Targets.
5. Der Absturzpunkt rt_mutex_adjust_prio_chain+0x1b0 liegt in der pselect/pi-Kettenphase, vor der FOPS-Selbstverifikation; nach den obigen Korrekturen ist eine erneute Verifikation auf dem Gerät sinnvoll.

2026-07-31 Echtgerätetest: KernelSnitch funktioniert, Slide-Phase bleibt die Hürde

Gerät (PD2241, compiler251203103903) mit 8+ Testrunden auf echter Hardware:

• KernelSnitch repariert und verifiziert: MM_STRUCT_SZ=0x400 (ursprünglich 0x500 führte zu versetztem Scan-Raster und nur False Positives) + MTE-Tag-Durchlauf 0..15 (Geräte-mm-Pointer-Tags ändern sich) + Untagging gefälschter Adressen. Findet jetzt stabil echte mm_struct.
• Jede Runde stürzt weiterhin bei rt_mutex_adjust_prio_chain+0x1b0 ab: pselect/pi-Ketten- Timing-Race (gefälschter waiter landet nicht am korrekten Offset im Kernel-Stack). Der vivo-RSC- Scheduler hat den futex/pi-Pfad verändert, was dieses Race grundlegend zerstören könnte. Die Slide-Stack-Ausrichtung wurde als Umgebungsvariable SLIDE_SHIFT parametrisiert, Scan noch nicht abgeschlossen.
• FOPS/pipe/cred-Phase noch nicht erreicht, Echtgeräte-Verifikation ausstehend.

Endgültige Entscheidung: kostenpflichtige Bootloader-Entsperrung (nicht mehr von diesem Pfad abhängig).