CVE-2026-43499 · Honor WIN RT (AAK-AN00) Notas de Pesquisa de Root Temporário

(tudo escrito pelo deepseek, eu não entendo nada) (passei mais alguns dias mexendo, progresso zero, desisti) (no momento é possível obter root, mas é muito instável, após o root a rede cai, desconectar o cabo reinicia) (todas as conclusões deste repositório se aplicam apenas ao Honor WIN RT, vulnerabilidade CVE-2026-43499, kernel 6.6.118-android15-8-gf17133276a57-abogki518694926-4k, não generalize as conclusões para root temporário, o root temporário pode durar e operar de forma relativamente estável)

O Bootloader do dispositivo está permanentemente travado (ro.oem_unlock.supported vazio), sem fastboot, sem su persistente, sem Magisk. O único caminho restante é a vulnerabilidade de kernel. Este repositório registra o processo completo desde "dá pra atacar?" até "depois de atacar, quão estável é de fato".

Natureza: root temporário, invalidado ao reiniciar.

---

Aviso Legal

Este repositório registra um processo de pesquisa de segurança realizado em dispositivo próprio, com o objetivo de compreender a causa e os limites de estabilidade de uma race condition de PI no kernel.

• Não contém nenhum binário de exploit ou payload de exploração diretamente executável —— os payloads e frameworks vêm de projetos públicos upstream, este repositório apenas referencia, não redistribui.
• Não fornece tutoriais de métodos de bypass para nenhum fabricante específico, nem incentiva o uso em dispositivos não autorizados.
• Os offsets e endereços de símbolos dentro do repositório são válidos apenas para o único build de kernel listado neste documento, trocar o kernel invalida tudo.
• As falhas relacionadas já foram corrigidas no upstream (ver abaixo). O valor de longo prazo deste documento está no "próprio registro" —— uma retrospectiva real de exploração de race condition em condições não ideais, incluindo todos os seus efeitos colaterais desconfortáveis.

---

0. Conclusão em uma frase

O único caminho que funcionou foi:

CVE-2026-43499 (race condition de futex PI write-what-where) + portadora rt_sigreturn
  → injeção via LD_PRELOAD em processo do domínio shell
  → duas etapas: primeiro atacar SELinux Permissive, depois alterar task->real_cred / cred para init_cred
  → uid=0(root) context=u:r:kernel:s0, e implantar daemon su

Mas o que realmente vale a pena registrar não é "como obter root" —— é o que acontece depois de obtê-lo.

O que se obtém não é um root estável, mas um "estado que pode ser detonado a qualquer momento".

A primitiva de escrita do exploit insere um rt_mutex_waiter forjado na cadeia real de futex PI, e o portador desse waiter é uma pilha de kernel / página spray que será reutilizada por chamadas de sistema subsequentes. Assim, a partir do momento em que o root é estabelecido, qualquer mudança de escalonamento ou prioridade em nível de sistema pode pisar nele, causando panic direto do kernel e reinício. Isso não é um bug, é o custo inerente dessa técnica de exploração —— ver docs/03.

---

1. Limites de Aplicabilidade (se não corresponder, todo o esquema é inválido)

Item	Valor	Descrição
Modelo	Honor WIN RT, modelo AAK-AN00	Nome comercial "Honor WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	Firmware não é compatível com Honor WIN (AAP-AN00, SM8850-AC)
Sistema	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Condição obrigatória, correspondência caractere por caractere
Config do kernel	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Pré-requisito da geometria da portadora
Pacote de firmware	.170	.160 / .175 não testados
Bootloader	Permanentemente travado	Sem fastboot / sem su persistente

Por que é obrigatório fixar a versão do kernel: a falha foi corrigida em 6.6.140, este dispositivo tem 6.6.118 < 6.6.140 então ainda está presente; além disso, todos os endereços de símbolos do kernel do exploit e a "geometria da portadora" estão ancorados neste único build, após trocar o kernel a tabela de offsets é imediatamente invalidada, e geralmente não é possível reverter.

---

2. Panorama do Caminho de Escalação de Privilégios

┌─ Material ────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extraídos do firmware do dispositivo) │
│        ↓ resolução de símbolos                          │
│ target.h (endereços de símbolos do kernel, verificados byte a byte com kallsyms) │
│        ↓ build                                          │
│ preload.so ──► /data/local/tmp/*.so no dispositivo     │
└────────────────────────────────────────────────────────┘
                 ↓  injeção via LD_PRELOAD
     ┌──────────── duas etapas (obrigatoriamente dois processos independentes) ────────────┐
     │ Etapa A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Etapa B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (realizado pelo processo "escritor pré-posicionado") │
     │         → setresuid(0,0,0) normalização                     │
     │         → implantar su embutido + daemon                    │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Três pontos que precisam estar corretos (errar causa travamento ou panic direto):

1. Regra de ordem: primeiro real_cred, depois cred. Inverter causa privilégio total instantâneo e perda de controle das threads.
2. Entre os dois golpes existe inevitavelmente um estado transiente de cred ≠ real_cred. Nesse momento qualquer sched_setaffinity resulta em EPERM → travamento total do ciclo. A solução correta é fazer fork do processo "escritor pré-posicionado" antes do primeiro golpe (credenciais limpas), o processo pai executa o primeiro golpe, o escritor executa o segundo, nenhum dos dois faz syscall no estado transiente.
3. O modelo de endereços não tem relação com KASLR. Toda a exploração usa apenas o alias de mapeamento linear alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), estável entre reinicializações; o verdadeiro valor da chamada "fase de slide" é a autoverificação da primitiva de escrita, não contornar KASLR.

Framework upstream: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Atenção: isto não é GhostLock —— GhostLock usa a rota pselect, incompatível com a geometria de ponto de queda do waiter deste build, ver docs/06.

---

3. Índice