O3 Root

Tradução em chinês: README.zh-CN.md — uma tradução deste arquivo; em caso de divergência entre os dois, este arquivo em inglês é a versão autoritativa.

Escalonamento local de privilégios + KernelSU para a família Xiaomi yingtian (Pad 9 Pro Max) e lhasa (Xiaomi 18 Fold) no HyperOS 4 (Android 17, kernel 6.18.21). Toda a cadeia é entregue como um app Android normal que aciona o Shizuku em modo shell, explora a CVE-2026-98260 e carrega o LKM da família KernelSU que corresponde ao gerenciador instalado (KernelSU / KernelSU-Next / SukiSU) — sem PC, sem bootloader desbloqueado, sem alterações de partição.

Projeto de pesquisa / educação / reparo de dispositivos. Apenas para o boot atual (um reboot o remove). Execute apenas em dispositivos que você possui. Leia docs/SECURITY.md antes de usar.

Agentes / colaboradores automatizados: comece por AGENTS.md (ponto de entrada: invariantes, receitas de build/teste, armadilhas, higiene), depois docs/AGENT_HANDOFF.md (estado verificado, experimentos falhos, trabalho em aberto). Execute bash scripts/verify.sh antes de commitar; ele também reconstrói o payload/APK quando o ambiente da toolchain está configurado.

Versão em chinês: AGENTS.zh-CN.md / docs/AGENT_HANDOFF.zh-CN.md

Status

release	v3.2 (release/o3root2-v3.2.apk, 14.239.248 B, sha256 64bbc654…)
build de teste O1	v3.3.3-o1-test (release/test/o3root2-v3.3.3-o1-test.apk, 14.247.440 B, sha256 62411f72…): v3.2 mais um perfil O1 (XRING) experimental (dijun / jinghu / violin) e o console root oculto. Aceita qualquer build OS4.0.0.x na série de kernel 6.18.21-android17…-4k: o build analisado é o caminho verificado, outros builds rodam em modo relaxado com um aviso; apenas para testadores, nunca validado em hardware
build de teste anterior	v3.2.1-console (release/beta/o3root2-v3.2.1-console.apk, 14.243.344 B, sha256 9cba365a…): v3.2 estável mais um console root oculto (pressione e segure a linha de versão; três confirmações)
dispositivos O1	SoC Xiaomi O1 dijun / jinghu / violin no OS4.0.0.x: todos os três trazem o mesmo kernel 6.18.21 (sha256 0d9917ca…, g1d099fcb35e0); a análise estática indica que a cadeia se aplica, ainda sem teste em dispositivo
LKM personalizado	.ko opcional da família KernelSU fornecido pelo usuário (verificação básica de compatibilidade; recorre ao módulo adaptativo embutido; a escolha é salva e restaurada ao iniciar — pressione e segure a linha para limpar)
cadeia	shell do Shizuku → CVE-2026-98260 → uid=0 + caps completas → LKM KernelSU correspondente (KernelSU / KernelSU-Next / SukiSU) → rootd
persistência	nenhuma (apenas o boot atual)
dispositivo testado	Xiaomi Pad 9 Pro Max yingtian, HyperOS OS4.0.16.0.XBMCNXM
segundo dispositivo	lhasa (Xiaomi 18 Fold, OS4.0.26.0.XPNCNXM): o kernel de boot é bit a bit idêntico ao do yingtian (sha256 cde87cd7…), então o mesmo payload se aplica; não testado em dispositivo

Como funciona (versão curta)

1. O app inicia /system/bin/sh -c … através do newProcess do Shizuku, pelo que o payload é executado em u:r:shell:s0 (uid=2000).
2. O payload aciona a corrida entre CLOCK_THREAD_CPUTIME_ID e execve/de_thread (CVE-2026-98260), recupera a página slab de ordem 1 posix_timers_cache libertada com um buffer kmalloc-8k pulverizado contendo um nó RB-tree forjado, e utiliza o segundo timerqueue_del → rb_erase para escrever um valor de 8 bytes num endereço arbitrário do kernel.
3. O estágio 0 limpa enforcing com uma escrita desalinhada de 8 bytes em selinux_state-7 (isto também limpa os bytes pendentes/cauda adjacentes de notif_lock; initialized/policycap permanecem intactos); o estágio 1 escreve task_struct.cred numa página cred falsa (uid 0, todas as capabilities).
4. O payload carrega o LKM KernelSU incorporado: os símbolos indefinidos são resolvidos em tempo de execução através de /proc/kallsyms (alternativa: religação da união de 248 símbolos + o deslocamento KASLR atual), sem patch de init — porque policycap permaneceu limpo, o próprio setenforce(1) do KernelSU é inofensivo e o dispositivo termina em Enforcing. Depois é feito insmod e fica um daemon rootd em execução (socket abstrato @o3p_rootd, peer-uid 0/2000). Os LKMs upstream KernelSU, KernelSU-Next e SukiSU funcionam todos (legado: O3P_CODEPATCH=1 aplica patch ao imediato de setenforce). Desde a v3.1 a app pode, em vez disso, carregar um .ko à sua escolha (verificação básica de compatibilidade ELF/.modinfo, fallback automático para o LKM incorporado quando é rejeitado ou falha ao carregar). Desde a v3.1.1 essa seleção é persistida (files/custom-ko.ko + custom-ko.meta) e restaurada no arranque; um ficheiro obsoleto que já não valida é descartado, e um toque longo na linha do módulo limpa-o. Desde a v3.2 a caixa de log é selecionável e tem uma ação 复制 que copia o log completo; só faz scroll automático enquanto já está perto do fundo. Num dispositivo O1 reconhecido, a build de teste pede uma confirmação de risco em dois passos antes de o payload iniciar. A build de teste também esconde uma consola root atrás de um toque longo na linha da versão: três confirmações não ignoráveis, e depois os comandos são executados como root através do socket rootd (requer uma execução do payload no arranque atual). A build estável não contém as classes da consola.

Consulte docs/ARCHITECTURE.md para os offsets, a primitiva de escrita, o patch do KernelSU e o guia de portabilidade.

Início rápido

1. No dispositivo: ative as Opções de programador → Depuração sem fios (ou ADB). Instale o Shizuku / ShizukuX e inicie-o em modo shell: shizuku_plus_server tem de ser executado como uid=2000, u:r:shell:s0.
2. Instale release/o3root2-v3.2.apk (a MIUI pode exigir que "Instalar via USB" esteja permitido).
3. Abra o O3 Root, conceda a permissão do Shizuku, prima Continue to UID 0. O log mostra ★ UIDNOW uid=0, ★ KSU_MODULE LIVE, e o gestor do KernelSU abre automaticamente.

A testar num dispositivo O1 (dijun / jinghu / violin)? Instale release/test/o3root2-v3.3.3-o1-test.apk em vez disso e siga docs/TESTING_O1.md. O gate aceita os três codenames em qualquer kernel 6.18.21-android17…-4k (OS4.0.0.x); a build analisada g1d099fcb35e0 obtém o caminho verificado, outras builds registam 固件门禁通过（O1 宽松模式：…） e reutilizam o endereço O1 com um aviso. O payload regista SELINUX_PROFILE kernel=… base=… src=env|uname, pelo que o relatório só precisa do log exportado.