API Privilegiada do Shizuku

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Shizuku é um serviço open-source que inicia um processo Java privilegiado com app_process e expõe APIs selecionadas do sistema Android via Binder. Como o processo roda com as mesmas capacidades do UID shell que o ADB usa, um app explicitamente autorizado pelo usuário pode fazer proxy de chamadas Binder para serviços do sistema sem fazer root no dispositivo.

Na prática, isso significa que um app com suporte a Shizuku frequentemente pode usar os mesmos primitivos que adb shell: gerenciamento de pacotes, appops, settings, cmd connectivity, coleta de logs, e muitas outras transações Binder permitidas ao shell. Ainda não é root e continua limitado por permissões Android, verificações de UID do Linux, política SELinux, versão do Android e restrições específicas do OEM.

Casos de uso típicos:

  • Auditoria de segurança a partir de um handset sem root
  • Gerenciamento de pacotes no dispositivo, debloating e instalação de split-APK
  • Coleta de logs, metadados de pacotes e estado de rede/processos visível ao shell
  • Construção de PoCs ou ferramentas auxiliares que precisam de acesso no nível ADB-grade mas não de uma cadeia completa de root

1. Iniciando o serviço privilegiado

moe.shizuku.privileged.api pode ser iniciado de três maneiras diferentes. A interface Binder exposta às apps cliente é a mesma, mas o privilégio efetivo depende se o backend é ADB/shell ou root.

1.1 ADB sem fio (Android 11+)

  1. Habilite Opções do desenvolvedor -> Depuração sem fio e emparelhe o dispositivo.
  2. Dentro do app Shizuku selecione “Start via Wireless debugging”.
  3. A sessão sobrevive até o reboot, a menos que a ROM do OEM encerre a depuração sem fio ou revogue a autorização de depuração.

1.2 USB / local ADB one-liner

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

O mesmo script pode ser executado através de uma conexão ADB pela rede (adb connect <IP>:5555).

1.3 Dispositivos com root

Se o dispositivo já estiver com root, execute:

su -c sh /data/adb/shizuku/start.sh

1.4 OEM quirks that matter during testing

  • MIUI / HyperOS frequentemente exige USB debugging (Security settings) além da alternância normal de USB debugging.
  • ColorOS / OxygenOS normalmente requer desativar Permission monitoring ou mecanismos de segurança equivalentes.
  • No Android 11+, Disable adb authorization timeout reduz perdas aleatórias do Shizuku durante longas sessões de teste.
  • Se a inicialização wireless continuar falhando, permita que o Shizuku seja executado em segundo plano; várias ROMs de OEM suspendem a descoberta de rede local quando o app fica em segundo plano.

1.5 Verifying that it is running

adb shell dumpsys activity service moe.shizuku.privileged.api | head
adb shell service list | grep shizuku

Uma inicialização bem-sucedida retorna um serviço em execução e expõe um serviço Binder relacionado a moe.shizuku.privileged.api.

2. Vinculação a partir de uma aplicação

Um app compatível com Shizuku não usa o Binder bruto retornado pelo Shizuku como se fosse IPackageManager. O fluxo normal é:

  1. adicionar a permissão da API do Shizuku e ShizukuProvider,
  2. aguardar que o Binder do Shizuku apareça,
  3. solicitar ao usuário a autorização no estilo runtime do Shizuku,
  4. envolver o Binder do serviço de sistema alvo com ShizukuBinderWrapper.

Requisitos do Manifest:

<uses-permission android:name="moe.shizuku.manager.permission.API"/>

<provider
android:name="rikka.shizuku.ShizukuProvider"
android:authorities="${applicationId}.shizuku"
android:multiprocess="false"
android:enabled="true"
android:exported="true"
android:permission="android.permission.INTERACT_ACROSS_USERS_FULL" />

Exemplo mínimo de Binder-wrapper:

Shizuku.addBinderReceivedListenerSticky(() -> {
if (Shizuku.checkSelfPermission() != PackageManager.PERMISSION_GRANTED) {
Shizuku.requestPermission(1000);
return;
}

IPackageManager pm = IPackageManager.Stub.asInterface(
new ShizukuBinderWrapper(SystemServiceHelper.getSystemService("package"))
);
});

Esse wrapper é o que faz com que as transações Binder sejam encaminhadas pelo processo de serviço do Shizuku em vez de serem executadas com o UID normal do aplicativo chamador.

2.1 UserService: quando você precisa de mais do que uma única chamada Binder

Para qualquer coisa mais complexa do que transações Binder diretas, o desenvolvimento moderno do Shizuku prefere UserService em vez do antigo newProcess helper. Um UserService executa seu próprio código Java/JNI em um processo separado como UID 2000 (shell) quando o Shizuku foi iniciado via ADB ou UID 0 quando suportado por root.

Shizuku.UserServiceArgs args = new Shizuku.UserServiceArgs(
new ComponentName(this, AuditService.class))
.daemon(false)
.version(1)
.processNameSuffix("audit");

Shizuku.bindUserService(args, conn);

Isto é útil para ferramentas ofensivas que precisam de estado de longa duração, helpers JNI, ou operações Binder repetidas sem pagar o custo de spawnar comandos shell repetidamente. Lembre-se de que o serviço é não um processo de app normal: alguns métodos Context não se comportam como dentro de uma aplicação Android regular.

2.2 Limites que ainda se aplicam

  • ADB/shell e root são níveis de privilégio diferentes. Shizuku.getUid() retorna 2000 para sessões baseadas em shell e 0 para sessões baseadas em root.
  • As permissões do shell mudam entre versões do Android e também podem ser reduzidas pelos OEMs.
  • O shell ainda não pode ler diretamente o sandbox privado de outro app, como /data/user/0/<package>.
  • Restrições de Hidden API ainda se aplicam ao código rodando no processo de app normal; se você precisar usar interfaces non-SDK extensivamente, mova a lógica para um UserService ou use um bypass dedicado de hidden-API.

3. Rish - shell elevado dentro do Termux

A tela de configurações do Shizuku exibe “Use Shizuku in terminal apps”. Ao habilitar essa opção, o Shizuku baixa rish, que abre um shell remoto privilegiado respaldado pelo Shizuku.

pkg install wget
wget https://rikka.app/rish/latest -O rish && chmod +x rish

# start elevated shell (inherits the binder connection)
./rish
whoami   # -> shell
id       # uid=2000(shell) gid=2000(shell) groups=... context=u:r:shell:s0

Detalhe útil para fluxos de trabalho centrados em Termux: quando Shizuku é executado como ADB/shell, rish evita intencionalmente preservar o ambiente do Termux por padrão porque o usuário shell normalmente não consegue acessar caminhos privados do Termux.

3.1 Useful commands from the rish shell

  • Listar processos em execução de um pacote específico:
ps -A | grep com.facebook.katana
  • Enumerar sockets de escuta e mapear para pacotes:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Extrair os logs de todas as aplicações expostos ao shell:
logcat -d | grep -iE "(error|exception)"
  • Remoção em massa (exemplo):
pm uninstall --user 0 com.miui.weather2
  • Inspecionar usuários e layout de perfis antes de abuso multi-usuário:
pm list users
dumpsys user

3.2 Modern abuse patterns enabled by shell-backed Shizuku

AppOps and special-permission tampering

Shizuku-enabled managers such as App Ops or App Manager are effectively wrapping shell-authorised appops and package-manager Binder calls. From rish, the same primitive can be used directly:

cmd appops get com.target.app
cmd appops set --uid com.target.app RUN_IN_BACKGROUND ignore
cmd appops set com.target.app SYSTEM_ALERT_WINDOW allow

Isto é útil durante pentests para validar se um app ou agente MDM realmente tolera manipulação agressiva de AppOps sem exigir root.

Isolamento de rede por app sem VPN ou root

Ferramentas recentes baseadas em Shizuku, como ShizuWall, usam os controles chain-3 do serviço connectivity para bloquear o acesso à rede para pacotes selecionados:

cmd connectivity set-chain3-enabled true
cmd connectivity set-package-networking-enabled false com.example.agent
cmd connectivity set-package-networking-enabled true com.example.agent

Para avaliações, isto dá uma forma rápida de testar como um app alvo se comporta quando um pacote concorrente de segurança, telemetria ou gerenciamento é seletivamente cortado da rede enquanto o resto do dispositivo permanece online. O estado é limpo ao reiniciar.

On-device advanced installs and split APK workflows

Instaladores modernos do Shizuku, como InstallWithOptions ou InstallerX-Revived, usam acesso shell-backed ao PackageInstaller para executar operações que seriam complicadas a partir de um app normal: split APK installs, test-only packages, batch installs, e algumas package-install flags do Android 14.

Do ponto de vista de testes ofensivos, a parte importante não é a GUI, mas a primitiva: Shizuku transforma a instalação de pacotes novamente em uma ação autorizada pelo shell no dispositivo, o que é útil para testes de persistência, verificações de downgrade e implantação rápida de payloads auxiliares em um dispositivo não-rootado.

Work-profile and secondary-user boundaries

Shell-backed Shizuku ainda está sujeito às restrições de usuário do Android. Em perfis gerenciados você frequentemente encontrará erros como:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

If you are specifically testing work-profile bypasses or required-app replacement, keep that material in the dedicated page instead of duplicating it here: Android Enterprise Work Profile Required-App Replacement

4. Considerações de segurança / detecção

  1. Shizuku precisa primeiro de ADB debugging ou root, portanto Developer Options -> USB/Wireless debugging must be enabled on non-rooted devices.
  2. O serviço se registra sob o nome moe.shizuku.privileged.api. adb shell service list | grep shizuku and adb shell dumpsys activity service moe.shizuku.privileged.api são verificações rápidas confiáveis.
  3. As capacidades são limitadas ao que o backend atual possui. Em sessões ADB-backed, isso significa que a superfície de ataque efetiva é a exposta para com.android.shell nessa build do Android, além do que o SELinux permite.
  4. As sessões não sobrevivem a um reboot a menos que o dispositivo seja rooted e o Shizuku esteja configurado como um daemon de inicialização.
  5. Camadas de “segurança” de OEM frequentemente quebram ou reduzem silenciosamente a funcionalidade do Shizuku. Se um comando funciona via adb shell direto mas falha via Shizuku, compare o UID do backend atual (Shizuku.getUid()), as opções de depuração do OEM e se o dispositivo reduziu as permissões do shell.

5. Mitigação

  • Desative USB/Wireless debugging em dispositivos de produção.
  • Monitore por serviços Binder expondo moe.shizuku.privileged.api.
  • Aplique restrições de work-profile ou MDM que removam recursos de depuração de usuários gerenciados.
  • Trate ferramentas compatíveis com Shizuku como ADB-equivalent durante a modelagem de ameaças; é um multiplicador de força post-exploitation mesmo quando o dispositivo não está rooted.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks