Inglês | 中文

PoC de Escalada de Privilégios Honor 80 GT: GhostLock (CVE-2026-43499)

Um exploit local de escalada de privilégios para o Honor 80 GT (AGT-AN00), CVE-2026-43499 — um use-after-free no caminho remove_waiter do rtmutex do kernel — além de uma solução complementar de carregamento de módulo de kernel KernelSU.

Em princípio, o bug e as técnicas aqui apresentados se aplicam a todas as versões do MagicOS até 9.0.0.220. Versões adaptadas:

Outras versões da linha 9.0 devem funcionar após regenerar a tabela de offsets (src/targets/) e reverificar o slot do carrier kstack.

⚠️ Aviso

• Apenas para pesquisa de segurança no seu próprio dispositivo.
• USE POR SUA CONTA E RISCO. Este software não oferece NENHUMA garantia de qualquer tipo (veja LICENSE). Em teoria, apenas executá-lo não deve brickar seu dispositivo nem causar perda de dados, mas faça backup antes mesmo assim; o que acontecer — ao executar este código ou ao fazer qualquer coisa com o acesso root que ele concede — é de sua responsabilidade, não dos autores.
• O exploit modifica a memória do kernel por meio de um UAF. Uma tentativa sem sucesso reinicia o dispositivo; uma reinicialização restaura tudo. O sucesso não é 100% por execução — basta executá-lo novamente.
• Root é controle total do dispositivo — use com cuidado. Este projeto apenas obtém root para você; flashar imagens, gravar partições, desativar proteções ou instalar módulos não testados depois pode brickar o dispositivo permanentemente, e isso é com você.

Estrutura do repositório

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)

Uso

Pré-requisitos: Docker, Android Platform Tools.

Pacotes pré-compilados por firmware: pegue o que corresponde à sua versão do MagicOS em Releases, descompacte-o no host e execute:

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

Sem um PC por perto? Descompacte o pacote no telefone e execute o mesmo script em um shell Shizuku (rish) — ele detecta onde está e faz o restante localmente:

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

Prefere compilar a partir do código-fonte:

# 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

O script conduz toda a cadeia via adb: GhostLock (root + permissivo + inversão de sig_enforce), injeção de política SELinux via magiskpolicy, kallsyms falso via bind-mount, load_ko (init_module), depois os estágios de subida do ksud, restaurando o SELinux enforcing como a última etapa absoluta. Aguarde por kernelsu em /proc/modules, e abra o gerenciador KernelSU (mostra "Working <LKM> [Jailbreak mode]").

Por que um .ko personalizado e um carregador

• CONFIG_MODULE_SIG_FORCE=y — a flag de tempo de execução sig_enforce bloqueia carregamentos de módulos não assinados; o exploit a inverte temporariamente para 0 (o script de carregamento a restaura para 1 assim que o módulo é carregado).
• Remoção de nomes do kallsyms: a Honor remove commit_creds e outros de /proc/kallsyms, então o carregador do kernel não consegue resolver os símbolos indefinidos do .ko. O fluxo faz bind-mount de um kallsyms falso com os símbolos removidos prefixados em seus endereços reais de tempo de execução (endereço de link + slide do KASLR).
• Os layouts das structs GKI também diferem dos da Honor, portanto o GKI padrão android12-5.10_kernelsu.ko não pode ser usado diretamente. ksu/ recompila o KernelSU v3.2.5 contra o código-fonte do kernel MagicOS que corresponde ao sublevel do firmware e à configuração de kernel do próprio dispositivo. Veja ksu/README.md.

Status de verificação

Cadeia completa (UAF → KASLR → R/W arbitrário → cred → SELinux permissivo → sig_enforce → KernelSU ativo, enforcing restaurado, boot_id restaurado) verificada em um dispositivo real para cada versão da tabela acima. Uma execução pode falhar cedo e reiniciar o telefone (cerca de uma em cada quatro); o script de configuração tenta novamente automaticamente, ou basta executá-la de novo.

Créditos

• CyberMeowfia / IonStack
• KernelSU
• Magisk

Licença

• O exploit e as ferramentas neste repositório (exploit/, documentação de nível superior) estão sob a Apache License 2.0 (veja LICENSE), assim como o PoC IonStack upstream do qual este port é derivado.
• Os arquivos em ksu/ são GPL-2.0 (veja ksu/LICENSE): init-h80gt.patch e o conjunto de políticas ksu_rules.annotated são derivados do diretório kernel/ do KernelSU, que é GPL-2.0.