Italiano | 中文

PoC di escalation dei privilegi Honor 80 GT: GhostLock (CVE-2026-43499)

Un exploit di escalation locale dei privilegi per Honor 80 GT (AGT-AN00), CVE-2026-43499 — un use-after-free nel percorso remove_waiter del rtmutex del kernel — più una soluzione complementare per il caricamento dei moduli del kernel KernelSU.

In linea di principio il bug e le tecniche qui descritte si applicano a ogni build MagicOS fino alla 9.0.0.220. Versioni adattate:

Le altre versioni della serie 9.0 dovrebbero funzionare dopo aver rigenerato la tabella degli offset (src/targets/) e aver ricontrollato lo slot del carrier kstack.

⚠️ Avvertenza

• Solo per ricerca di sicurezza su un dispositivo di tua proprietà.
• USO A PROPRIO RISCHIO. Questo software non fornisce ALCUNA garanzia di alcun tipo (vedi LICENSE). In teoria la sola esecuzione non dovrebbe brickare il dispositivo o perdere dati, ma esegui comunque un backup; qualunque cosa accada — dall'esecuzione di questo codice o da qualsiasi cosa tu faccia con l'accesso root che concede — è responsabilità tua, non degli autori.
• L'exploit modifica la memoria del kernel tramite una UAF. Un tentativo fallito riavvia il dispositivo; un riavvio ripristina tutto. Il successo non è al 100% per ogni esecuzione — basta riprovare.
• Root significa controllo totale del dispositivo — usalo con attenzione. Questo progetto ti dà solo root; in seguito, flashing di immagini, scrittura di partizioni, disabilitazione di protezioni o installazione di moduli non testati possono brickare permanentemente il dispositivo, e la responsabilità è tua.

Struttura del repository

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)

Utilizzo

Requisiti: Docker, Android Platform Tools.

Bundle precompilati per firmware: prendi quello corrispondente alla tua versione MagicOS da Releases, decomprimilo sull'host ed esegui

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

Niente PC a disposizione? Decomprimi il bundle sul telefono ed esegui lo stesso script da una shell Shizuku (rish): rileva dove si trova e fa il resto in locale:

sh /sdcard/ghostlock-<version>/setup.sh

Oppure compila dal sorgente:

# 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

Lo script gestisce l'intera catena tramite adb: GhostLock (root + permissive + flip di sig_enforce), iniezione delle policy SELinux tramite magiskpolicy, bind-mount di un falso kallsyms, load_ko (init_module), quindi le fasi di avvio di ksud, ripristinando SELinux enforcing come ultimissimo passaggio. Attendi kernelsu in /proc/modules, poi apri il manager KernelSU (mostra "Working <LKM> [Jailbreak mode]").

Perché un .ko e un loader personalizzati

• CONFIG_MODULE_SIG_FORCE=y — il flag runtime sig_enforce blocca il caricamento di moduli non firmati; l'exploit lo imposta temporaneamente a 0 (lo script del loader lo ripristina a 1 una volta caricato il modulo).
• Rimozione dei nomi da kallsyms: Honor rimuove commit_creds e simili da /proc/kallsyms, quindi il loader del kernel non riesce a risolvere i simboli non definiti del .ko. Il flusso esegue il bind-mount di un falso kallsyms con i simboli rimossi preposti ai loro veri indirizzi runtime (indirizzo di link + slide KASLR).
• Anche i layout delle struct GKI differiscono da quelli di Honor, quindi il GKI standard android12-5.10_kernelsu.ko non può essere usato direttamente. ksu/ ricompila KernelSU v3.2.5 contro il sorgente del kernel MagicOS corrispondente al sublevel del firmware e alla config del kernel del dispositivo. Vedi ksu/README.md.

Stato della verifica

Catena completa (UAF → KASLR → lettura/scrittura arbitraria → cred → SELinux permissive → sig_enforce → KernelSU attivo, enforcing ripristinato, boot_id ripristinato) verificata su un dispositivo reale per ogni versione nella tabella sopra. Un'esecuzione può fallire subito e riavviare il telefono (circa una volta su quattro); lo script di setup riprova automaticamente, oppure esegui di nuovo.

Crediti

• CyberMeowfia / IonStack
• KernelSU
• Magisk

Licenza

• L'exploit e gli strumenti in questo repository (exploit/, documenti di primo livello) sono sotto Apache License 2.0 (vedi LICENSE), come il PoC IonStack upstream da cui deriva questa porta.
• I file in ksu/ sono GPL-2.0 (vedi ksu/LICENSE): init-h80gt.patch e il set di policy ksu_rules.annotated derivano dalla directory kernel/ di KernelSU, che è GPL-2.0.