pirosap/aquos-r7-ghostlockGerätespezifischer Linux-5.10-Kernel-Root-Exploit für Sharp AQUOS R7 (CVE-2026-43499), der temporär UID 0 mit SELinux permissive und einem su-Daemon gewährt.
Gerätespezifischer Linux-5.10-Port von GhostLock (CVE-2026-43499) für das Sharp
AQUOS R7. Das validierte Ziel ist das AQUOS R7 (Mineva, SGA202SH/A202SH)
mit Android 14 Build 03.00.11, Kernel
5.10.237-android12-9-00013-gd09ef2e980e0-ab13968955 (SM8450).
Das zuvor validierte Ziel, Build 03.00.06 / Kernel
5.10.218-android12-9-00041-g124993efd06e-ab12385094, ist im
Git-Tag v1.0-030006 erhalten.
Dies ist ein Port von aquos-r6-ghostlock
(AQUOS R6, Kernel 5.4.61-qgki). Jede Konstante — KASLR-Behandlung, das
selinux_state-Leak-Fenster, Task-/Cred-Offsets, die Zero-BSS-Scratch-Region —
wurde neu hergeleitet und gegen den R7-Kernel validiert; die R6-Stack-Geometrie
diente lediglich als Ausgangsreferenz.
Ein erfolgreicher Lauf verleiht UID 0 mit SELinux im permissiven Modus und startet einen kleinen
su-Kommando-Daemon. Er gewährt keinen vollständigen Linux-Capability-Satz und die
Änderung ist nicht persistent: Ein Neustart stellt den ursprünglichen Kernel-Zustand wieder her.
Der Android-NDK-clang mit Ziel aarch64-linux-android29 ist erforderlich (getestet
mit NDK r30):
make build/ghostlock510 # ~3.4 MB static binary
make strip # optional; ~0.6 MB, same behaviour
Reproduzierbarkeit (Kalibrierung 03.00.11): Diese Quelle, mit der obigen
Toolchain gebaut, ist byte-identisch (MD5 25fc1d5d0e92d36c56f00f983a49667d) mit der
Binärdatei, die im On-Device-Test 03.00.11 verwendet wurde. Das Release-Asset ist die
llvm-strip-te Form genau dieser Binärdatei (598.672 Bytes, SHA-256
5c413a80e9fcc41032412f4e0e5183bc723dde9a2e0ace5a6d9c79681b04b9cd).
Für den Build 03.00.06 siehe Tag v1.0-030006 (ungestrippte MD5
fa896ebd361519766b46cc2bab70dea2).
Übertrage die Binärdatei (Release-Asset oder deinen eigenen Build) und führe sie einmal aus:
adb push ghostlock510 /data/local/tmp/ghostlock510
adb shell chmod 755 /data/local/tmp/ghostlock510
adb shell "setsid nohup /data/local/tmp/ghostlock510 --use-setattr --stamp3 --perm-pc --cred-swap --install-su --stamp-off 0xf0 --log /data/local/tmp/ghostlock510.log </dev/null >/dev/null 2>&1 &"
Verwenden Sie den installierten su-Client für Root-Befehle (vollständiger Pfad erforderlich):
adb shell "/data/local/tmp/su -c 'id; getenforce'"
# uid=0(root) gid=2000(shell) groups=2000(shell) context=u:r:kernel:s0
# Permissive
su kommuniziert mit dem Daemon des Exploits über Loopback-TCP (Port 9999); es wird keine persistente Root-Shell angehängt. Befehle sind zeilenbasiert, und das Verschachteln von su innerhalb von su funktioniert nicht. Interaktive Programme (vi, top, …) benötigen ein PTY; ein interaktiver su-Modus auf Basis des Daemons bleibt zukünftiger Arbeit vorbehalten.
Gemessen auf genau diesem Build (siehe VERIFICATION.md):
Also: neu starten, ghostlock510 einmal ausführen und nicht erneut ausführen, solange diese Sitzung aktiv ist. Ein Neustart ist der Bereinigungsweg.
Große externe Eingaben sind bewusst nicht in diesem Repository enthalten:
vmlinux/System.map des Android-CI-Kernel-Builds 13968955 entnommen; die bytegenaue Identität mit dem tatsächlich auf dem Gerät laufenden Kernel wurde über dessen boot_b-Image verifiziert (alle 23 PT_LOAD-Segmente, segmentweiser Vergleich). Der CVE-Fix (5.10.y-Backport 2026-07-21) ist neuer als dieser Tree (HEAD 2025-08-20), und kernel/futex/core.c ist blob-identisch mit dem 03.00.06-Build — die Schwachstelle ist weiterhin vorhanden.v1.0-030006): Die Offsets stammen aus dem Android-CI-Kernel-Build 12385094, bytegenau verifiziert über das boot_a-Image des Geräts.--stamp3 / --use-setattr wurde davon inspiriert (in jenem Repository ist keine Lizenz angegeben).