Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
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.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Tools/GitHubGitHub/yakidango-official/ghostlock-h80gt
Android-SicherheitPrivilege EscalationExploitationMobile SicherheitBinary-Exploitation
GitHubyakidango-official/ghostlock-h80gt

GhostLock-H80GT

Honor 80 GT (MagicOS 8.0.0.128, kernel 5.10.168) Privilege-Escalation-PoC: GhostLock (CVE-2026-43499) + Laden benutzerdefinierter KernelSU-Module

Repository anzeigen

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
11vor 8h 34mNoch nicht geprüft

Englisch | 中文

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 — eine Use-after-Free-Schwachstelle im rtmutex-remove_waiter-Pfad des Kernels — plus eine begleitende Lösung zum Laden des KernelSU-Kernelmoduls.

Grundsätzlich gelten der Bug und die hier beschriebenen Techniken für jeden MagicOS-Build bis 9.0.0.220. Angepasste Versionen:

MagicOSKernelStatus
8.0.0.1285.10.168verifiziert
8.0.0.1605.10.209verifiziert
9.0.0.1575.10.209verifiziert
9.0.0.200SP15.10.236verifiziert
9.0.0.220SP2 / SP45.10.236auf dem Gerät verifiziert (SP4 wird mit demselben Boot-Image wie SP2 ausgeliefert)

Andere Versionen der 9.0-Reihe sollten funktionieren, nachdem die Offsettabelle (src/targets/) neu generiert und der kstack-Trägerslot erneut geprüft wurde.

⚠️ Warnung

  • Nur für Sicherheitsforschung auf dem eigenen Gerät.
  • NUTZUNG AUF EIGENE GEFAHR. Diese Software wird OHNE jegliche Garantie bereitgestellt (siehe LICENSE). Das bloße Ausführen sollte das Gerät theoretisch nicht bricken oder zu Datenverlust führen, aber erstelle trotzdem zuerst ein Backup; was auch immer geschieht – durch das Ausführen dieses Codes oder durch alles, was du mit dem von ihm gewährten Root-Zugriff tust – liegt in deiner Verantwortung, nicht in der der Autoren.
  • Der Exploit verändert Kernel-Speicher über eine UAF. Ein fehlgeschlagener Versuch startet das Gerät neu; ein Neustart stellt alles wieder her. Der Erfolg ist pro Lauf nicht 100 % – führe ihn einfach erneut aus.
  • Root bedeutet vollständige Kontrolle über das Gerät – gehe vorsichtig damit um. Dieses Projekt verschafft dir nur Root; anschließendes Flashen von Images, Schreiben von Partitionen, Deaktivieren von Schutzmechanismen oder Installieren ungetesteter Module kann das Gerät dauerhaft bricken, und das ist deine Sache.

Repository-Struktur

root@kitploit:~
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.

Vorgefertigte Pakete pro Firmware: Nimm das passende für deine MagicOS-Version aus Releases, entpacke es auf dem Host und führe Folgendes aus:

root@kitploit:~
./setup.sh            # PC, with adb: checks the kernel version, pushes
                      # everything, runs the chain, retries on the
                      # occasional miss

Kein PC in der Nähe? Entpacke das Paket auf dem Telefon und führe dasselbe Skript aus einer Shizuku-Shell (rish) aus – es erkennt, wo es sich befindet, und erledigt den Rest lokal:

root@kitploit:~
sh /sdcard/ghostlock-<version>/setup.sh

Stattdessen aus dem Quellcode bauen:

root@kitploit:~
# 1. Build the device 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
#    (./docker-build.sh ondevice builds the static binary with the default
#     env config baked in; first run pulls the NDK, ~1.2GB)

# 2. Obtain/build the KSU bundle binaries into ksu/tools/ —
#    see ksu/tools/README.md (kernelsu_h80gt.ko: ksu/README.md — build it
#    against the opensource tree matching your firmware's kernel sublevel;
#    ksud: shipped in the repo; magiskpolicy: 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 + permissive + sig_enforce-Umschalten), Injektion der SELinux-Richtlinie über magiskpolicy, Bind-Mount eines Fake-kallsyms, load_ko (init_module), dann die ksud-Bring-up-Phasen, wobei SELinux enforcing als allerletzter Schritt wiederhergestellt wird. Warte, bis kernelsu in /proc/modules erscheint, und öffne dann den KernelSU-Manager (zeigt „Working <LKM> [Jailbreak mode]“).

Warum ein eigenes .ko und ein 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).
  • Namens-Entfernung in kallsyms: Honor entfernt commit_creds und andere aus /proc/kallsyms, sodass der Kernel-Loader die undefinierten Symbole der .ko nicht auflösen kann. Der Ablauf bind-mountet ein gefälschtes kallsyms, bei dem die entfernten Symbole an ihren tatsächlichen Laufzeitadressen (Link-Adresse + KASLR-Slide) vorangestellt werden.
  • Auch die GKI-Strukturlayouts weichen von denen Honors ab, daher kann das Standard-GKI android12-5.10_kernelsu.ko nicht direkt verwendet werden. ksu/ baut KernelSU v3.2.5 gegen den MagicOS-Kernelquellcode neu, der zum Sublevel der Firmware und zur eigenen Kernel-Konfiguration des Geräts passt. Siehe ksu/README.md.

Verifizierungsstatus

Die vollständige Kette (UAF → KASLR → beliebiges R/W → cred → SELinux permissive → sig_enforce → KernelSU live, enforcing wiederhergestellt, boot_id wiederhergestellt) wurde für jede Version in der obigen Tabelle auf einem echten Gerät verifiziert. Ein Lauf kann früh fehlschlagen und das Telefon neu starten (etwa in einem von vier Fällen); das Setup-Skript wiederholt den Vorgang automatisch, oder führe ihn einfach erneut aus.

Danksagungen

  • CyberMeowfia / IonStack
  • KernelSU
  • Magisk

Lizenz

  • Der Exploit und die Werkzeuge in diesem Repository (exploit/, Dokumente auf oberster Ebene) stehen unter der Apache License 2.0 (siehe LICENSE), ebenso wie das Upstream-IonStack-PoC, aus dem dieser Port hervorgeht.
  • Die Dateien unter ksu/ sind GPL-2.0 (siehe ksu/LICENSE): init-h80gt.patch und das ksu_rules.annotated-Policy-Set stammen aus dem kernel/-Verzeichnis von KernelSU, das GPL-2.0 ist.
Tool herunterladen