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

(tudo escrito pelo deepseek, eu não entendo nada)

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

Natureza: root temporário, invalidado ao reiniciar.

Aviso Legal

Este repositório documenta 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 diretamente executável — os payloads e frameworks vêm de projetos públicos upstream; este repositório apenas os referencia, não os 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 neste repositório são válidos apenas para o único build de kernel listado neste documento; ao trocar o kernel, tudo se invalida.
• A falha relevante já foi corrigida no upstream (ver abaixo). O valor de longo prazo deste documento está no "registro em si" — um relato 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) + portador rt_sigreturn
  → injeção via LD_PRELOAD em processo do domínio shell
  → duas etapas: primeiro ativar 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 acioná-lo, causando panic imediato do kernel e reinicialização. 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 plano é inválido)

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

2. Panorama do caminho de escalação de privilégios

┌─ Materiais ───────────────────────────────────────────┐
│ 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 ser feitos corretamente (errar causa travamento ou panic direto):

1. Ordem obrigatória: primeiro real_cred, depois cred. A ordem inversa causa privilégios totais instantâneos e perda de controle das threads.
2. Entre as duas operações existe inevitavelmente um estado transiente com cred ≠ real_cred. Nesse momento, qualquer sched_setaffinity resultará em EPERM → travamento total do ciclo. A solução correta é fazer fork do processo "escritor pré-posicionado" antes da primeira operação (com credenciais limpas); o processo pai executa a primeira operação, o escritor executa a segunda, e nenhum dos dois faz syscall durante o estado transiente.
3. O modelo de endereços não depende de 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, que não corresponde à geometria de ponto de queda do waiter neste build, ver docs/06.

3. Índice

4. Linha do tempo

5. Uma frase para quem vier depois

Se você também está atacando um modelo com BL bloqueado, pense primeiro claramente no que você vai fazer com o root, porque nesses modelos o root provavelmente é uma janela que dura apenas cerca de dez minutos. Liste as operações que "precisam de root e devem persistir entre reinicializações", execute tudo de uma vez, e depois reboot para voltar ao estado limpo. Não tente "eliminar os efeitos colaterais" — esse é o custo inerente da técnica.