Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
GhostLock-H80GT — PoC di privilege escalation per Honor 80 GT: GhostLock (CVE-2026-43499) + caricamento di moduli KernelSU personalizzati | Kitploit
Strumenti/GitHubGitHub/yakidango-official/ghostlock-h80gt
Sicurezza AndroidEscalation di PrivilegiExploitSicurezza MobileBinary Exploitation
GitHubyakidango-official/ghostlock-h80gt

GhostLock-H80GT

PoC di privilege escalation per Honor 80 GT: GhostLock (CVE-2026-43499) + caricamento di moduli KernelSU personalizzati

Vedi Repository

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
286311 mese faRevisionato da Kitploit

English | 中文

PoC di privilege escalation per Honor 80 GT: GhostLock (CVE-2026-43499)

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

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

MagicOSKernelStato
8.0.0.1285.10.168✅ verificato
8.0.0.1605.10.209✅ verificato
9.0.0.1575.10.209✅ verificato
9.0.0.200SP15.10.236✅ verificato
9.0.0.220SP2 / SP45.10.236✅ verificato (SP4 distribuisce la stessa boot image di SP2)
9.0.0.2305.10.236✅ verificato
8.0.0.1315.10.198⚠️ non verificato su un dispositivo reale
8.0.0.135 / 143 / 1505.10.198⚠️ non verificato su un dispositivo reale
8.0.0.1615.10.209⚠️ non verificato su un dispositivo reale
9.0.0.102 / 103 / 120 / 130 / 1655.10.209⚠️ non verificato su un dispositivo reale (103 distribuisce la stessa boot image di 102)
9.0.0.175SP1 / 1875.10.226⚠️ non verificato su un dispositivo reale
9.0.0.2105.10.236⚠️ non verificato su un dispositivo reale

⚠️ Avvertenza

  • Solo per ricerca sulla sicurezza sul proprio dispositivo.
  • USARE A PROPRIO RISCHIO E PERICOLO. Questo software non fornisce alcuna garanzia di alcun tipo (vedi LICENSE). In teoria la semplice esecuzione non dovrebbe brickare il dispositivo né causare perdita di dati, ma eseguire comunque prima un backup; qualunque cosa accada — dall'esecuzione di questo codice o da qualsiasi cosa fatta con l'accesso root che concede — è responsabilità vostra, 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 è garantito al 100% per esecuzione — eseguirlo di nuovo.
  • Root significa pieno controllo del dispositivo — usarlo con cautela. Questo progetto fornisce solo l'accesso root; flashare immagini, scrivere partizioni, disabilitare protezioni o installare moduli non testati in seguito può brickare permanentemente il dispositivo, e questa è responsabilità vostra.

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.

Un bundle precompilato copre tutti i firmware supportati: scaricalo da Releases, estrailo sull'host ed esegui

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

Senza un PC, decomprimi il bundle sul telefono ed esegui lo stesso script da una shell Shizuku (rish) — rileva dove si trova e fa il resto localmente:

sh /sdcard/ghostlock/setup.sh

Lo script confronta il kernel in esecuzione con il manifest incluso: i firmware verificati vengono eseguiti direttamente, quelli noti ma non testati richiedono conferma, qualsiasi altro viene rifiutato.

Compila dai sorgenti invece:

# 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

Lo script guida l'intera catena tramite adb: GhostLock (accesso root, SELinux permissivo, sig_enforce disabilitato), iniezione della policy SELinux tramite magiskpolicy, bind-mount falso di kallsyms, load_ko (init_module), poi le fasi di avvio di ksud, ripristinando SELinux enforcing come ultimissimo passo. Quando il jailbreak è completato, lo script apre per te il gestore di 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 che il modulo è caricato).
  • 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 kallsyms falso con i simboli rimossi anteposti ai loro veri indirizzi runtime (indirizzo di link + slide KASLR).
  • Anche i layout delle struct GKI differiscono da quelli di Honor, quindi il android12-5.10_kernelsu.ko GKI stock non può essere usato direttamente. ksu/ ricompila KernelSU contro il sorgente del kernel MagicOS corrispondente al sublevel del firmware e alla configurazione del kernel del dispositivo stesso. Vedi ksu/README.md.

Stato di verifica

Catena completa (UAF → KASLR → R/W arbitrario → cred → SELinux permissivo → sig_enforce → KernelSU attivo, enforcing ripristinato, boot_id ripristinato) verificata su un dispositivo reale per le versioni contrassegnate con ✅ sopra; le versioni contrassegnate con ⚠️ sono adattate ma non verificate su un dispositivo reale. Un'esecuzione può fallire e riavviare il telefono; lo script di setup riprova automaticamente, oppure eseguilo di nuovo.

Crediti

  • CyberMeowfia / IonStack
  • KernelSU
  • Magisk

Licenza

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