TimerRoot

Front end Android para CVE-2026-98260 (use-after-free de timer de CPU POSIX), a mesma classe de bug que a CVE-2026-64560. Um toque fornece um shell root e, em seguida, carrega tardiamente o KernelSU (u:r:ksu:s0).

O exploit em si não está incluído aqui. Este repositório é a camada de aplicação em torno dele: UI, detecção de estado e a infraestrutura do Shizuku necessária para executar um exploit de domínio shell a partir de um aplicativo comum.

Por que o aplicativo precisa do Shizuku

Um aplicativo é executado como untrusted_app e não pode ler /sys/kernel/tracing, que o exploit precisa para seu vazamento e acionamento. O TimerRoot, portanto, inicia um serviço de usuário Shizuku, que o Shizuku executa como o usuário shell (uid 2000, u:r:shell:s0). O binário do exploit é executado dentro desse processo, de modo que obtém o mesmo ambiente que teria a partir de adb shell.

MainActivity (untrusted_app)
  └─ Shizuku user service (uid 2000, u:r:shell:s0)
       ├─ extracts assets/timer to /data/local/tmp/timer
       └─ runs it; on success keeps /system/bin/sh alive

Requisitos

• Android 12+ (minSdk 30), arm64
• Shizuku em execução (inicie-o a partir do aplicativo Shizuku via depuração sem fio, ou via ADB)
• Gerenciador KernelSU instalado, para o caminho Load KernelSU
• Uma compilação de kernel para a qual o exploit foi portado. O binário upstream tem como alvo 6.12.69-android16-6-g242e1a07f878-ab15865446-4k; veja abaixo.

Obtendo o binário do exploit

O TimerRoot espera o exploit compilado em app/src/main/assets/timer:

git clone https://github.com/YuKongA/CVE-2026-98260
cp CVE-2026-98260/timer/timer app/src/main/assets/timer

ou

scripts/fetch-timer.ps1

O binário é licenciado sob MIT pelos seus autores; use-o apenas em hardware que você possui e apenas quando o seu kernel corresponder à build para a qual ele foi portado.

Build

Android Studio / Gradle

Abra o projeto e faça o build, ou:

./gradlew assembleDebug

O projeto precisa do Android SDK com a plataforma 36 e build-tools 36. A API do Shizuku é obtida via Maven (dev.rikka.shizuku:api).

Sem Gradle

scripts/build.ps1 compila e assina um APK apenas com o SDK, javac, d8, aapt2 e apksigner. Ele não incorpora nada: compila o app junto com os fontes da API do Shizuku, então clone esses primeiro:

git clone https://github.com/RikkaApps/Shizuku-API
scripts/build.ps1 -Sdk "C:\Users\<you>\AppData\Local\Android\Sdk"

Uso

1. Iniciar o Shizuku

O Shizuku precisa estar em execução antes que o TimerRoot possa fazer qualquer coisa: é o processo que fornece o usuário shell de que o exploit precisa. O Shizuku para a cada reinicialização, portanto este é o primeiro passo todas as vezes.

Depuração sem fio (sem PC após o primeiro emparelhamento)

1. Ative as opções do desenvolvedor: Configurações -> Sobre o dispositivo -> toque em Número da versão 7x.
2. Configurações -> Sistema -> Opções do desenvolvedor -> Depuração sem fio -> ativado.
3. Abra o aplicativo Shizuku -> Iniciar -> Iniciar via depuração sem fio.
4. Permita a notificação e, em Emparelhar dispositivo com código de emparelhamento, insira o código de 6 dígitos exibido no telefone.
5. O Shizuku informa "Shizuku is running" (a notificação diz que o servidor está ativo).

Via USB

Com o telefone conectado e a depuração USB autorizada:

adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

Versões mais recentes do Shizuku podem não incluir mais esse script; se ele estiver ausente, use a rota de depuração sem fio acima.

Verifique se o servidor está ativo:

adb shell ps -A | grep shizuku_server
# shell  12345  1  ...  shizuku_server

ps mostrando apenas moe.shizuku.privileged.api significa que o aplicativo gerenciador está aberto, mas o servidor não está em execução; o exploit não pode iniciar até que esteja.

2. Primeira execução

1. Abra o TimerRoot.
2. Quando o Shizuku perguntar Permitir que o TimerRoot acesse o Shizuku?, escolha Permitir o tempo todo.
3. O cartão muda para Pronto (Shizuku conectado, ainda sem root). Se ainda disser Not connected, pressione Shizuku na linha de ferramentas para solicitar novamente.

3. Preparar

Prepare extrai assets/timer para /data/local/tmp/timer:

installed 307192 bytes

4. Obter shell root

Um toque. O aplicativo escala privilégios, mantém um shell uid=0 dentro do serviço e então inicia o carregamento tardio do KernelSU automaticamente:

[child] woke uid=0
root shell ready - loading KernelSU...
Loading KernelSU... 12s
KSU_LOADED

O cartão vai para Root shell -> Jailbreak mode (u:r:ksu:s0). Se o estágio do KernelSU perder a corrida, o cartão fica vermelho com KernelSU failed, e você deve reiniciar antes de tentar novamente.

5. Reiniciar

Use o botão Reboot. Ele passa pelo serviço (svc power reboot), então funciona mesmo quando nenhum shell root está aberto ainda. Reiniciar também é a única forma limpa de remover processos estacionados e descarregar o KernelSU.

Após reiniciar, comece novamente a partir do passo 1: o Shizuku está parado e o KernelSU não existe mais.

O cartão de status reflete o que está realmente ativo, detectado executando su -c id e verificando u:r:ksu:s0:

cartão	significado
Not connected	O Shizuku não está em execução / não está vinculado
Ready	Shizuku conectado, ainda sem root
Root shell	uid=0, u:r:shell:s0
Jailbreak mode	KernelSU carregado, su funciona em u:r:ksu:s0

Solução de problemas

KernelSU failed e base calibration failed no log

O estágio de credencial falsa precisa da base do mapa linear do kernel, que o exploit deriva dos eventos de rastreamento de alocação de páginas. Ele assume páginas de 4 KB:

[base] made=512 best=0 count=0
[-] base calibration failed

Verifique o tamanho da página do dispositivo:

adb shell getconf PAGE_SIZE

• 4096: o layout difere por outro motivo; colete uname -r, o modelo e o log completo e reporte isso upstream.
• 16384: o exploit não pode funcionar neste dispositivo como fornecido. Ele precisa ser reconstruído para páginas de 16 KB (deslocamentos de página, máscaras e tamanhos de ordem), o que é um trabalho de portabilidade e não uma configuração de aplicativo.

O shell root ainda pode ter sucesso em tal dispositivo, porque esse caminho só precisa do endereço de credencial vazado, não da base do mapa linear.

O cartão permanece em Not connected

O Shizuku não está em execução. Inicie-o novamente (ele para a cada reinicialização) e veja o passo 1.

Prepare não reporta nada

Uma caixa de diálogo do sistema pode estar cobrindo o aplicativo (emparelhamento do Shizuku, verificação do instalador OPPO). Feche-a e pressione Prepare novamente.

Segurança

Este é um exploit de kernel. Leia isto antes de pressionar qualquer coisa.

• Não mate um processo estacionado. O exploit mantém um processo vivo com a página de credencial falsa fixada nos buffers de socket. Eliminá-lo pode causar panic no kernel. A reinicialização é a única maneira limpa de removê-lo.
• Uma reinicialização limpa tudo: KernelSU, o shell root e os processos estacionados. Essa é a maneira pretendida de parar.
• O SELinux é deixado permissivo até a próxima reinicialização.
• Uma tentativa falha deixa um nó de timerqueue obsoleto; outros aplicativos podem travar até você reiniciar.
• Use isto apenas em um dispositivo que você possui ou que está explicitamente autorizado a modificar.

Layout