GhostLock — Jailbreak für gesperrte Bootloader

Kernel-Exploit für Android-Geräte mit gesperrtem Bootloader. Erreicht temporären Root + KernelSU-Installation, ohne den Bootloader zu entsperren oder das Boot-Image zu modifizieren. Laufzeit-Auto-Erkennung der Kernel-Version mit Multi-Geräte-Offset-Tabelle.

Schwachstelle

CVE-2026-43499 — Futex PI (Priority Inheritance) Use-After-Free

Betrifft Linux-Kernel 5.7 ~ 7.1. Behoben in Stable 6.1.175, 6.6.140, 6.12.86. Die meisten Android-Geräte sind Stand September 2026 weiterhin ungepatcht.

Der pselect6-Syscall kopiert fd_set-Daten auf den Kernel-Stack. In Kombination mit dem Futex-PI-Waiter-Mechanismus kann ein freigegebener Stack-Frame als rt_mutex_waiter-Struktur zurückgewonnen werden. Das rb-tree-Rebalancing während des PI-Chain-Walks schreibt dann kontrollierte Werte an beliebige Kernel-Adressen.

Unterstützte Geräte

Verifiziert funktionsfähig

Offsets extrahiert (Gerätetest ausstehend)

Nicht durchführbar

Das pselect-Stack-Overlay erfordert, dass der freigegebene rt_mutex_waiter innerhalb des benutzerkontrollierten stack_fds-Bereichs (Wörter 0–14) landet. Wo er landet, wird durch Compiler-PGO/LTO-Profile bestimmt, nicht durch die Kernel-Version. Siehe Stack-Layout.

Hinweis zur 6.1-Durchführbarkeit: OPLUS-6.1-Kernel sind durchgängig nicht durchführbar, da PGO do_futex inlined. Einige Nicht-OPLUS-6.1-Kernel (vivo) behalten jedoch die Standard-Call-Chain bei und sind durchführbar (vivo T4, X Fold3 Pro). Die Durchführbarkeit muss pro Gerät geprüft werden.

Exploit-Ablauf

Zwei Root-Pfade, automatisch basierend auf den Gerätefähigkeiten ausgewählt:

Pfad A: UMH-Root (bevorzugt, C-ashmem-Geräte)

Erfordert off_ashmem_misc_fops != 0 (C-ashmem mit statischem miscdevice in BSS).

PI-Write (mode=4)  →  miscdevice-fops auf Fake-fops umleiten
                   →  configfs r/w → pipe physrw (1-Byte-präzises Kernel-r/w)
                   →  SELinux enforcing = 0 (einzelnes Byte, keine policycap-Korruption)
                   →  UMH: work_struct in system_unbound_wq injizieren
                   →  Root-Skript → ksud late-load → KSU installiert

Verfügbar auf: OnePlus 13, OPPO Pad 4 Pro, 5.10/6.1 C-ashmem-Geräten. Nicht verfügbar auf Rust-ashmem (6.12 GKI) — Heap-alloziertes miscdevice.

Pfad B: Direkter PI-Write (Fallback)

Write 1 (mode=1)  →  SELinux enforcing = 0 (8-Byte-Write, korrumpiert angrenzende Bytes)
Write 2 (mode=2)  →  task->cred = init_cred (uid=0, alle Capabilities)
Root-Shell         →  ksud late-load → KSU → SELinux-Policy-Fix

Nach W1+W2 patcht der Exploit das Config-Feld der SELinux-Policy-Binärdatei (|= 0xC0000000 für ANDROID_NETLINK_ROUTE + GETNEIGH) und lädt es über /sys/fs/selinux/load neu, um die Netzwerkkonnektivität wiederherzustellen.

Bootstrap-Modus (Telefon eigenständig)

App (seccomp)  →  Write 1 → Mini-ADB-TCP → adb shell: vollständiger Exploit → Root

Auto-Boot

Der Bootzeit-Launcher wird von der separaten GhostLock Anchor App bereitgestellt.

Stack-Layout-Durchführbarkeit

Mit NFDS=320 alloziert core_sys_select einen 256-Byte-stack_fds-Puffer auf dem Kernel-Stack:

stack_fds:  0    5    10   14 | 15   20   25   29
            ├─in─┤─out─┤─ex──┤ ├res_in┤res_out┤res_ex┤
            ◄── BENUTZERKONTROLLIERT ──►│◄── KERNEL GENULLT ──►

Der Exploit platziert Fake-Waiter-Felder (task, lock) in den fd_set-Eingabe-Bitmaps. Für 6.12 Nested-Waiter (14 Wörter): maximal durchführbares Waiter-Wort = 3. Für 5.10/6.1 Compact-Waiter (10 Wörter): maximal durchführbares Waiter-Wort = 7.

Die Waiter-Position hängt von der Call-Chain-Tiefe ab:

kernel_phys_load

Alle Kernel-Writes verwenden den Linear-Map-Alias. Der Bootloader wählt kernel_phys_load, das je nach SoC variiert:

Ein falscher Wert schlägt still fehl. Auf einem gerooteten Gerät auslesen:

su -c 'grep -i "Kernel code" /proc/iomem'   # c7810000-... → 0xc7800000

Zur Laufzeit überschreiben: KPHYS=0xc7800000 /data/local/tmp/a/e

PSELECT_SHIFT

/data/local/tmp/a/e                        # Standard (shift=0)
PSELECT_SHIFT=-2 /data/local/tmp/a/e       # OnePlus 13 (6.6)

KIMAGE_TEXT_BASE

5.10-Kernel verwenden 0xffffffc008000000 (VA_BITS=39, abweichend vom 6.x-Standard 0xffffffc080000000). Dies wird automatisch über das Feld kimage_text_base im Geräte-Offset-Eintrag behandelt.

Build

make NDK_ROOT=/pfad/zu/android-ndk

Oder direkt:

NDK=/pfad/zu/android-ndk
"$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android35-clang" \
  -O2 -Wall -Isrc/core -Isrc/devices -DTARGET_CONFIG_H=\"target.h\" \
  src/core/main.c src/core/util.c src/core/slide.c \
  src/core/fops.c src/core/pipe_physrw.c src/core/root.c \
  src/core/miniadb.c src/core/umh_root.c \
  -o ./ghostlock -fPIE -pie -pthread

Voraussetzungen

ksud (für KSU-Installation erforderlich)

GhostLock stellt temporären Root bereit. Die KernelSU-Installation erfordert ksud, das kernelsu.ko für jede KMI-Version bündelt.

Einrichtung

adb shell mkdir -p /data/local/tmp/a
adb push ./ghostlock /data/local/tmp/a/e
adb shell chmod 755 /data/local/tmp/a/e
adb shell /data/local/tmp/a/e

Nach Abschluss des Bootvorgangs ausführen, sobald ADB bereit ist.

Hinzufügen neuer Geräte

Nur boot.img wird benötigt — kein Root, kein Gerätezugriff erforderlich.

1. Kernel und kallsyms extrahieren

Siehe kallsyms-Tools-Anleitung für den vollständigen Workflow, oder:

python tools/extract_target.py --kallsyms kallsyms.txt
python tools/extract_btf.py kernel

2. Durchführbarkeit bestimmen

Prüfen, ob do_futex PGO-inlined ist, indem die Kernel-Binärdatei nach allen Branch-Instruktionen durchsucht wird, die auf futex_wait_requeue_pi abzielen. Wenn __arm64_sys_futex es direkt aufruft (unter Umgehung von do_futex), ist das Gerät wahrscheinlich nicht durchführbar.

3. Geräteeintrag erstellen

src/devices/<name>/offsets.h mit den extrahierten Offsets hinzufügen und in src/devices/offsets.h einbinden. Das passende Struct-Offsets-Makro verwenden:

Für 5.10/6.1-Compact-Waiter-Geräte zusätzlich .kimage_text_base=0xffffffc008000000ULL setzen.

Dateien

Lizenz

Nur für autorisierte Sicherheitsforschung und Bildungszwecke.