Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
GhostLock-H80GT — Honor 80 GT Privilegieneskalation PoC: GhostLock (CVE-2026-43499) + benutzerdefiniertes Laden von KernelSU-Modulen | Kitploit
Tools/GitHubGitHub/yakidango-official/ghostlock-h80gt
Android-SicherheitPrivilege EscalationExploitationMobile SicherheitBinary-Exploitation
GitHubyakidango-official/ghostlock-h80gt

GhostLock-H80GT

Honor 80 GT Privilegieneskalation PoC: GhostLock (CVE-2026-43499) + benutzerdefiniertes Laden von KernelSU-Modulen

Repository anzeigen

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
30634vor 1 MonatVon Kitploit geprüft

English | 中文

Honor 80 GT Privilege-Escalation-PoC: GhostLock (CVE-2026-43499)

Ein lokaler Privilege-Escalation-Exploit für das Honor 80 GT (AGT-AN00), CVE-2026-43499 — ein Use-after-free im Kernel-rtmutex-Pfad remove_waiter — plus eine begleitende KernelSU-Lösung zum Laden von Kernelmodulen.

Im Prinzip gelten der Bug und die hier beschriebenen Techniken für jeden MagicOS-Build bis 9.0.0.230. Angepasste Versionen:

MagicOSKernelStatus
8.0.0.1285.10.168✅ verifiziert
8.0.0.1605.10.209✅ verifiziert
9.0.0.1575.10.209✅ verifiziert
9.0.0.200SP15.10.236✅ verifiziert
9.0.0.220SP2 / SP45.10.236✅ verifiziert (SP4 enthält dasselbe Boot-Image wie SP2)
9.0.0.2305.10.236✅ verifiziert
8.0.0.1315.10.198⚠️ nicht auf einem echten Gerät verifiziert
8.0.0.135 / 143 / 1505.10.198⚠️ nicht auf einem echten Gerät verifiziert
8.0.0.1615.10.209⚠️ nicht auf einem echten Gerät verifiziert
9.0.0.102 / 103 / 120 / 130 / 1655.10.209⚠️ nicht auf einem echten Gerät verifiziert (103 enthält dasselbe Boot-Image wie 102)
9.0.0.175SP1 / 1875.10.226⚠️ nicht auf einem echten Gerät verifiziert
9.0.0.2105.10.236⚠️ nicht auf einem echten Gerät verifiziert

⚠️ Warnung

  • Nur für Sicherheitsforschung auf deinem eigenen Gerät.
  • NUTZUNG AUF EIGENE GEFAHR. Diese Software wird ohne jegliche Gewährleistung bereitgestellt (siehe LICENSE). Das bloße Ausführen sollte dein Gerät theoretisch nicht bricken oder Datenverlust verursachen, aber erstelle trotzdem vorher ein Backup; was auch immer passiert — durch das Ausführen dieses Codes oder durch alles, was du mit dem gewährten Root-Zugriff tust — liegt in deiner Verantwortung, nicht bei den Autoren.
  • Der Exploit verändert den Kernel-Speicher über einen UAF. Ein fehlgeschlagener Versuch startet das Gerät neu; ein Neustart stellt alles wieder her. Der Erfolg liegt nicht bei 100 % pro Durchlauf — führe ihn erneut aus.
  • Root bedeutet vollständige Kontrolle über das Gerät — nutze es sorgfältig. Dieses Projekt verschafft dir nur Root; das Flashen von Images, das Schreiben von Partitionen, das Deaktivieren von Schutzmechanismen oder das anschließende Installieren ungetesteter Module kann das Gerät dauerhaft bricken, und das liegt in deiner Verantwortung.

Repository-Struktur

exploit/     GhostLock PoC source (Android arm64) + build system
  src/         exploit core: futex UAF, KASLR slide, sysctl boot_id hijack,
               arbitrary R/W, cred/SELinux/sig_enforce writes, KSU load
  src/targets/ per-firmware offset tables (target.h)
ksu/         custom kernelsu.ko build (MagicOS kernel + device config) and the
             PC-side adb load driver
  tools/       on-device load helpers: load_ko.c / kmsg_dumper.c (built from
               source), policy rules, loader template (+ where to get the
               binaries)

Verwendung

Voraussetzungen: Docker, Android Platform Tools.

Ein vorgefertigtes Bundle deckt jede unterstützte Firmware ab: Lade es von Releases herunter, entpacke es auf dem Host und führe

./setup.sh            # PC, with adb: identifies the kernel, picks the
                      # matching exploit, runs the chain, retries when an
                      # attempt fails

Ohne einen PC das Bundle auf dem Telefon entpacken und dasselbe Skript aus einer Shizuku-Shell (rish) ausführen — es erkennt, wo es sich befindet, und erledigt den Rest lokal:

sh /sdcard/ghostlock/setup.sh

Das Skript gleicht den laufenden Kernel mit dem mitgelieferten Manifest ab: verifizierte Firmwares werden direkt ausgeführt, bekannte, aber ungetestete erfordern eine Bestätigung, alles andere wird abgelehnt.

Stattdessen aus dem Quellcode bauen:

# 1. Build the exploit binary
cd exploit && ./docker-build.sh bin             # exploit_static (8.0.0.128)
#    8.0.0.160: ./docker-build.sh PROJECT=annap-AGT-AN00_8.0.0.160 bin
#    (the static binary bakes in the default env config; any knob can still
#     be overridden by environment variables at launch; first run pulls the NDK, ~1.2GB)

# 2. The KSU-side binaries live in ksu/tools/ (see ksu/tools/README.md):
#    kernelsu.ko — build per ksu/README.md;
#    ksud, magiskpolicy, ksu_rules — shipped in the repo;
#    load_ko, kmsg_dumper — ./docker-build.sh tools

# 3. Enable ADB debugging on the phone, then
bash ../ksu/ksu_load_ko.sh
#    8.0.0.160: PROJECT=annap-AGT-AN00_8.0.0.160 bash ../ksu/ksu_load_ko.sh

Das Skript steuert die gesamte Kette über adb: GhostLock (Root-Zugriff, SELinux permissiv, sig_enforce deaktiviert), SELinux-Policy-Injektion via magiskpolicy, Fake-kallsyms- Bind-Mount, load_ko (init_module), dann die ksud-Bring-up-Phasen, wobei die Wiederherstellung von SELinux enforcing als allerletzter Schritt erfolgt. Wenn der Jailbreak abgeschlossen ist, öffnet das Skript den KernelSU-Manager für dich (zeigt „Working <LKM> [Jailbreak mode]“ an).

Warum ein eigenes .ko und ein eigener Loader

  • CONFIG_MODULE_SIG_FORCE=y — das Laufzeit-Flag sig_enforce blockiert das Laden unsignierter Module; der Exploit setzt es vorübergehend auf 0 (das Loader- Skript stellt es wieder auf 1, sobald das Modul geladen ist).
  • kallsyms-Namensentfernung: Honor entfernt commit_creds und ähnliche aus /proc/kallsyms, sodass der Kernel-Loader die undefinierten Symbole des .ko nicht auflösen kann. Der Ablauf bind-mountet ein Fake-kallsyms mit den entfernten Symbolen, die an ihren echten Laufzeitadressen vorangestellt werden (Link-Adresse + KASLR-Slide).
  • Auch die GKI-Struktur-Layouts unterscheiden sich von denen von Honor, daher kann das Stock-GKI-android12-5.10_kernelsu.ko nicht direkt verwendet werden. ksu/ baut KernelSU gegen die MagicOS-Kernelquelle neu, passend zum Sublevel der Firmware und zur Kernel-Konfiguration des Geräts selbst. Siehe ksu/README.md.

Verifikationsstatus

Vollständige Kette (UAF → KASLR → beliebiges R/W → cred → SELinux permissiv → sig_enforce → KernelSU live, enforcing wiederhergestellt, boot_id wiederhergestellt) auf einem echten Gerät für die oben mit ✅ markierten Versionen verifiziert; Versionen mit ⚠️ sind angepasst, aber nicht auf einem echten Gerät verifiziert. Ein Lauf kann fehlschlagen und das Telefon neu starten; das Setup-Skript versucht es automatisch erneut, oder führe es erneut aus.

Danksagungen

  • CyberMeowfia / IonStack
  • KernelSU
  • Magisk

Lizenz

  • Der Exploit und die Tooling-Dateien in diesem Repository (exploit/, Top-Level-Dokumentation) stehen unter der Apache License 2.0 (siehe LICENSE), ebenso wie der Upstream-IonStack-PoC, von dem dieser Port abstammt.
  • Die Dateien unter ksu/ stehen unter GPL-2.0 (siehe ksu/LICENSE): init-bootid.patch und das Policy-Set ksu_rules.annotated stammen aus dem Verzeichnis kernel/ von KernelSU, das unter GPL-2.0 steht.
Tool herunterladen