API privilegiada de Shizuku

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Shizuku es un servicio de código abierto que inicia un proceso Java privilegiado con app_process y expone APIs seleccionadas del sistema Android sobre Binder. Como el proceso se ejecuta con las mismas capacidades UID de shell que utiliza ADB, una app que esté explícitamente autorizada por el usuario puede hacer de proxy de llamadas Binder a los servicios del sistema sin rootear el dispositivo.

En la práctica, esto significa que una app habilitada para Shizuku puede a menudo usar los mismos primitivos que adb shell: gestión de paquetes, appops, settings, cmd connectivity, recopilación de logs y muchas otras transacciones Binder permitidas para shell. Sigue sin ser root y continúa estando limitada por permisos de Android, comprobaciones de UID de Linux, la política SELinux, la versión de Android y restricciones específicas del OEM.

Casos de uso típicos:

  • Auditoría de seguridad desde un dispositivo sin root
  • Gestión de paquetes en el dispositivo, debloating e instalación de split-APK
  • Recopilación de logs, metadatos de paquetes y estado de red/procesos visible para shell
  • Construcción de PoCs o herramientas auxiliares que necesiten acceso de nivel ADB pero no una cadena de root completa

1. Inicio del servicio privilegiado

moe.shizuku.privileged.api puede iniciarse de tres maneras diferentes. La interfaz Binder expuesta a las apps cliente es la misma, pero el privilegio efectivo depende de si el backend es ADB/shell o root.

1.1 Wireless ADB (Android 11+)

  1. Habilita Opciones de desarrollador -> Depuración inalámbrica y empareja el dispositivo.
  2. Dentro de la app Shizuku selecciona “Start via Wireless debugging”.
  3. La sesión sobrevive hasta el reinicio a menos que la ROM del OEM cierre la depuración inalámbrica o revoque la autorización de depuración.

1.2 USB / local ADB one-liner

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

El mismo script se puede ejecutar a través de una conexión ADB en red (adb connect <IP>:5555).

1.3 Rooted devices

Si el dispositivo ya está rooted, ejecuta:

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

1.4 Peculiaridades de los OEM que importan durante las pruebas

  • MIUI / HyperOS a menudo requiere USB debugging (Security settings) además del conmutador normal de USB debugging.
  • ColorOS / OxygenOS comúnmente requiere desactivar Permission monitoring u envoltorios de seguridad equivalentes.
  • En Android 11+, Disable adb authorization timeout reduce las desconexiones aleatorias de Shizuku durante sesiones de prueba largas.
  • Si el arranque inalámbrico sigue fallando, permite que Shizuku se ejecute en segundo plano; varias ROMs de OEM suspenden el descubrimiento de la red local cuando la app está en segundo plano.

1.5 Verificando que esté en ejecución

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

A successful start returns a running service and exposes a Binder service related to moe.shizuku.privileged.api.

2. Vinculación desde una aplicación

Una aplicación habilitada para Shizuku no usa el Binder bruto devuelto por Shizuku como si fuera IPackageManager. El flujo normal es:

  1. agregar el permiso de la API de Shizuku y ShizukuProvider,
  2. esperar a que aparezca el Binder de Shizuku,
  3. solicitar al usuario la autorización de estilo runtime de Shizuku,
  4. envolver el Binder del servicio de sistema objetivo con ShizukuBinderWrapper.

Requisitos del manifiesto:

<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" />

Ejemplo 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"))
);
});

Ese wrapper es lo que provoca que las transacciones Binder sean reenviadas por el proceso de servicio de Shizuku en lugar de ser ejecutadas con el UID normal de la aplicación que llama.

2.1 UserService: cuando necesitas más que una única llamada Binder

Para cualquier cosa más compleja que transacciones Binder directas, el desarrollo moderno de Shizuku prefiere UserService en lugar del viejo helper newProcess. Un UserService ejecuta tu propio código Java/JNI en un proceso separado como UID 2000 (shell) cuando Shizuku fue iniciado vía ADB o UID 0 cuando está respaldado por root.

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

Shizuku.bindUserService(args, conn);

Esto es útil para tooling ofensivo que necesita estado persistente, JNI helpers, o operaciones repetidas de Binder sin pagar el coste de lanzar comandos de shell una y otra vez. Recuerda que el servicio es not a normal app process: algunos métodos de Context no se comportan como lo hacen dentro de una aplicación Android regular.

2.2 Boundaries that still apply

  • ADB/shell y root son niveles de privilegio diferentes. Shizuku.getUid() devuelve 2000 para sesiones respaldadas por shell y 0 para sesiones con root.
  • Los permisos del shell cambian entre las versiones de Android y también pueden ser recortados por los OEM.
  • El shell aún no puede leer directamente el sandbox privado de otra app, como /data/user/0/<package>.
  • Las restricciones de Hidden API siguen aplicándose al código que se ejecuta en el proceso normal de la app; si necesitas interfaces non-SDK de forma extensiva, mueve la lógica a un UserService o usa un bypass dedicado de hidden-API.

3. Rish - elevated shell inside Termux

La pantalla de ajustes de Shizuku expone “Use Shizuku in terminal apps”. Activarlo descarga rish, que abre un shell privilegiado remoto respaldado por 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

Detalle útil para flujos de trabajo centrados en Termux: cuando Shizuku se ejecuta como ADB/shell, rish evita intencionalmente preservar el entorno de Termux por defecto porque el usuario shell normalmente no puede atravesar rutas privadas de Termux.

3.1 Comandos útiles desde el shell de rish

  • Listar procesos en ejecución de un paquete dado:
ps -A | grep com.facebook.katana
  • Enumerar sockets en escucha y mapearlos a paquetes:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Volcar los logs de cada aplicación expuestos al shell:
logcat -d | grep -iE "(error|exception)"
  • Debloat masivo (ejemplo):
pm uninstall --user 0 com.miui.weather2
  • Inspeccionar usuarios y diseño de perfiles antes de abusar del multi-usuario:
pm list users
dumpsys user

3.2 Patrones modernos de abuso habilitados por Shizuku con respaldo de shell

AppOps y manipulación de permisos especiales

Los gestores habilitados por Shizuku, como App Ops o App Manager, efectivamente envuelven llamadas autorizadas por shell a appops y llamadas Binder del package manager. Desde rish, la misma primitiva puede usarse directamente:

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

Esto es útil durante pentests para validar si una app o un agente MDM realmente tolera manipulaciones agresivas de AppOps sin requerir root.

Aislamiento de red por app sin VPN ni root

Herramientas recientes basadas en Shizuku, como ShizuWall, usan los controles chain-3 del servicio connectivity para bloquear la conectividad de paquetes seleccionados:

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 las evaluaciones, esto te ofrece una forma rápida de comprobar cómo se comporta una app objetivo cuando un paquete de seguridad, telemetría o gestión competidor queda selectivamente aislado de la red mientras el resto del dispositivo permanece en línea. El estado se borra al reiniciar.

On-device advanced installs and split APK workflows

Los instaladores modernos de Shizuku, como InstallWithOptions o InstallerX-Revived, utilizan acceso shell-backed a PackageInstaller para realizar operaciones que de otro modo son engorrosas desde una app normal: instalaciones de split APK, paquetes test-only, instalaciones por lote y algunas banderas de instalación de paquetes de Android 14.

Desde el punto de vista de las pruebas ofensivas, lo importante no es la GUI sino el primitivo: Shizuku convierte la instalación de paquetes de nuevo en una acción autorizada por shell on-device, lo que resulta útil para persistence tests, downgrade checks y despliegue rápido de helper payloads en un non-rooted handset.

Work-profile and secondary-user boundaries

Shell-backed Shizuku sigue sujeto a las restricciones de usuario de Android. En managed profiles a menudo te encontrarás con errores 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. Consideraciones de seguridad / detección

  1. Shizuku necesita primero ADB debugging o root, por lo que Developer Options -> USB/Wireless debugging debe estar habilitado en dispositivos sin root.
  2. El servicio se registra con el nombre moe.shizuku.privileged.api.
    adb shell service list | grep shizuku y adb shell dumpsys activity service moe.shizuku.privileged.api son verificaciones rápidas fiables.
  3. Las capacidades están limitadas a las que tenga el backend actual. En sesiones respaldadas por ADB, eso significa que la superficie de ataque efectiva es la expuesta a com.android.shell en esa compilación de Android, además de lo que SELinux permita.
  4. Las sesiones no sobreviven a un reinicio a menos que el dispositivo tenga root y Shizuku esté configurado como un demonio de inicio.
  5. Las capas de “seguridad” de los OEM a menudo rompen o reducen silenciosamente la funcionalidad de Shizuku. Si un comando funciona vía adb shell directo pero falla a través de Shizuku, compara el UID del backend actual (Shizuku.getUid()), los toggles de depuración del OEM y si el dispositivo recortó los permisos del shell.

5. Mitigación

  • Deshabilitar USB/Wireless debugging en dispositivos de producción.
  • Monitorizar servicios Binder que expongan moe.shizuku.privileged.api.
  • Hacer cumplir restricciones de work-profile o MDM que eliminen las funciones de depuración para usuarios gestionados.
  • Tratar las herramientas compatibles con Shizuku como ADB-equivalent durante el modelado de amenazas; es un multiplicador de fuerza post-exploitation incluso cuando el dispositivo no tiene root.

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks