CVE-2026-43499 · Honor WIN RT (AAK-AN00) Temporäre-Root-Forschungsnotizen

(Alles von deepseek geschrieben, ich verstehe selbst nichts davon)

Geräte-Bootloader dauerhaft gesperrt (ro.oem_unlock.supported ist leer), kein fastboot, kein persistentes su, kein Magisk. Der einzige noch gangbare Weg ist eine Kernel-Schwachstelle. Dieses Repository dokumentiert den vollständigen Prozess von „Kann man es überhaupt ausnutzen" bis „Wie stabil ist es tatsächlich nach der Ausnutzung".

Art: temporäres Root, nach Neustart ungültig.

Haftungsausschluss

Dieses Repository dokumentiert einen Sicherheitsforschungsprozess auf einem eigenen Gerät mit dem Ziel, die Ursachen und Stabilitätsgrenzen einer Kernel-PI-Race-Bedingung zu verstehen.

• Enthält keine Exploit-Binärdateien oder direkt ausführbare Nutzlasten — Nutzlasten und Framework stammen aus öffentlichen Upstream-Projekten; dieses Repository zitiert sie nur, verbreitet sie nicht weiter.
• Bietet keine Anleitungen für Umgehungsmethoden bestimmter Hersteller und ermutigt nicht zur Nutzung auf nicht autorisierten Geräten.
• Die im Repository enthaltenen Offsets und Symboladressen gelten nur für den einen hier aufgeführten Kernel-Build; bei einem anderen Kernel werden sie alle ungültig.
• Die betreffenden Fehler sind upstream bereits behoben (siehe unten). Der langfristige Wert dieses Dokuments liegt in „dieser Aufzeichnung selbst" — eine echte, unter nicht idealen Bedingungen durchgeführte Retrospektive eines Race-Condition-Exploits, einschließlich aller unangenehmen Nebenwirkungen.

0. Fazit in einem Satz

Der einzige erfolgreich beschrittene Pfad ist:

CVE-2026-43499 (futex PI Race write-what-where) + rt_sigreturn Carrier
  → LD_PRELOAD-Injektion in Shell-Domain-Prozess
  → Zweistufig: zuerst SELinux Permissive setzen, dann task->real_cred / cred auf init_cred ändern
  → uid=0(root) context=u:r:kernel:s0, und su-Daemon implantieren

Aber was wirklich aufgeschrieben werden sollte, ist nicht „wie man root erlangt" — sondern was danach passiert.

Was man erhält, ist kein stabiles Root, sondern ein „jederzeit zur Explosion bringbarer Zustand".

Das Schreibprimitiv des Exploits hängt einen gefälschten rt_mutex_waiter in die echte futex-PI-Kette, und der Träger dieses Waiters ist ein Kernel-Stack / Spray-Page, der von nachfolgenden Systemaufrufen wiederverwendet wird. Daher kann ab dem Moment, in dem root erreicht ist, jede systemweite Scheduling- oder Prioritätsänderung darauf treten und direkt einen Kernel-Panic-Neustart auslösen. Das ist kein Bug, sondern der inhärente Preis dieser Ausnutzungstechnik — siehe docs/03.

1. Anwendungsgrenzen (bei Abweichung wird das gesamte Verfahren ungültig)

Warum die Kernel-Version zwingend festgelegt werden muss: Der Fehler wurde in 6.6.140 behoben; das Gerät hat 6.6.118 < 6.6.140, ist also noch betroffen; gleichzeitig sind alle Kernel-Symboladressen und die „Carrier-Geometrie" des Exploits an genau diesen einen Build gebunden. Nach einem Kernel-Wechsel wird die Offset-Tabelle sofort ungültig, und ein Zurückrollen ist in der Regel nicht möglich.

2. Überblick über den Privilegieneskalationspfad

┌─ Material ────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (aus Geräte-Firmware extrahiert) │
│        ↓ Symbolauflösung                               │
│ target.h (Kernel-Symboladressen, byteweise mit kallsyms abgeglichen) │
│        ↓ Build                                         │
│ preload.so ──► geräteseitig /data/local/tmp/*.so       │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD-Injektion
     ┌──────────── Zweistufig (erfordert zwei unabhängige Prozesse) ────────────┐
     │ Phase A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Phase B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (durch „Vorbereitungs-Writer"-Prozess) │
     │         → setresuid(0,0,0) Normalisierung                   │
     │         → eingebettetes su + Daemon implantieren            │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Drei Dinge, die zwingend korrekt gemacht werden müssen (sonst hängt es oder es kommt direkt zum Panic):

1. Reihenfolge eisern: zuerst real_cred, dann cred. Umgekehrte Reihenfolge führt sofort zu voller Berechtigung und außer Kontrolle geratenen Threads.
2. Zwischen den beiden Schnitten existiert zwangsläufig ein transienter Zustand mit cred ≠ real_cred. In diesem Moment führt jedes sched_setaffinity zu EPERM → die gesamte Runde hängt. Die richtige Lösung ist, vor dem ersten Schnitt einen „Vorbereitungs-Writer"-Prozess zu forken (saubere Credentials); der Elternprozess führt den ersten Schnitt aus, der Writer den zweiten, und keiner befindet sich im transienten Zustand, wenn er einen Syscall absetzt.
3. Das Adressmodell ist unabhängig von KASLR. Die gesamte Ausnutzung nutzt nur den linearen Mapping-Alias alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), über Neustarts hinweg stabil; der eigentliche Wert der sogenannten „Slide-Phase" ist die Selbstprüfung des Schreibprimitivs, nicht die Umgehung von KASLR.

Upstream-Framework: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Beachte: Dies ist nicht GhostLock — GhostLock nutzt den pselect-Pfad, der nicht zur Waiter-Landegeometrie dieses Builds passt, siehe docs/06.

3. Verzeichnis

4. Zeitleiste

5. Ein Satz an Nachfolger

Wenn du ebenfalls ein Gerät mit gesperrtem BL angreifst, überlege dir zuerst genau, was du mit root machen willst, denn auf solchen Geräten ist root wahrscheinlich ein Fenster, das nur etwa zehn Minuten lang nutzbar ist. Erstelle eine Liste der „Operationen, die root erfordern und über Neustarts hinweg erhalten bleiben müssen", führe sie in einem Durchgang aus und mache dann reboot in einen sauberen Zustand. Versuche nicht, „die Nebenwirkungen zu beseitigen" — das ist der Preis der Technik selbst.