API privilégiée Shizuku

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Shizuku est un service open-source qui démarre un processus Java privilégié avec app_process et expose certaines API système Android via Binder.
Parce que le processus s’exécute avec les mêmes capabilités UID shell que ADB utilise, une application explicitement autorisée par l’utilisateur peut proxyfier les appels Binder vers les services système sans être root sur l’appareil.

En pratique, cela signifie qu’une app compatible Shizuku peut souvent utiliser les mêmes primitives que adb shell : gestion des paquets, appops, settings, cmd connectivity, collecte des logs, et bien d’autres transactions Binder autorisées pour le shell. Ce n’est toujours pas root et cela reste contraint par les permissions Android, les vérifications UID Linux, la politique SELinux, la version Android, et les restrictions spécifiques OEM.

Cas d’utilisation typiques :

  • Audit de sécurité depuis un appareil non rooté
  • Gestion des paquets sur l’appareil, debloating et installation de split-APK
  • Collecte de logs, métadonnées des paquets et état réseau/processus visible depuis le shell
  • Création de PoC ou d’outils d’aide nécessitant un accès ADB-grade sans une chaîne complète de root

1. Démarrage du service privilégié

moe.shizuku.privileged.api peut être démarré de trois manières différentes. L’interface Binder exposée aux apps clientes est la même, mais le privilège effectif dépend du backend, s’il s’agit d’ADB/shell ou de root.

1.1 ADB sans fil (Android 11+)

  1. Activez Options pour les développeurs -> Débogage sans fil et appairez l’appareil.
  2. Dans l’app Shizuku, sélectionnez “Start via Wireless debugging”.
  3. La session survit jusqu’au redémarrage sauf si le ROM OEM désactive le débogage sans fil ou révoque l’autorisation de débogage.

1.2 USB / ADB local — commande en une ligne

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

Le même script peut être exécuté via une connexion ADB réseau (adb connect <IP>:5555).

1.3 Appareils rootés

Si l’appareil est déjà rooté, exécutez :

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

1.4 Particularités OEM importantes lors des tests

  • MIUI / HyperOS nécessite souvent USB debugging (Security settings) en plus du commutateur USB debugging habituel.
  • ColorOS / OxygenOS exige souvent de désactiver Permission monitoring ou des wrappers de sécurité équivalents.
  • Sur Android 11+, Disable adb authorization timeout réduit les pertes aléatoires de Shizuku pendant les longues sessions de test.
  • Si le démarrage sans fil échoue systématiquement, autorisez Shizuku à s’exécuter en arrière-plan ; plusieurs ROM OEM suspendent la découverte du réseau local lorsque l’application est en arrière-plan.

1.5 Vérification qu’il est en cours d’exécution

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

Un démarrage réussi renvoie un service en cours d’exécution et expose un service Binder lié à moe.shizuku.privileged.api.

2. Liaison depuis une application

Une application compatible Shizuku n’utilise pas le Binder brut retourné par Shizuku comme s’il s’agissait de IPackageManager. Le déroulement normal est :

  1. ajouter la permission API de Shizuku et ShizukuProvider,
  2. attendre que le Binder Shizuku apparaisse,
  3. demander à l’utilisateur l’autorisation de type runtime de Shizuku,
  4. encapsuler le Binder du service système cible avec ShizukuBinderWrapper.

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

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

Ce wrapper est ce qui fait que les transactions Binder sont transmises par le processus de service Shizuku au lieu d’être exécutées avec l’UID normal de l’application appelante.

2.1 UserService : quand vous avez besoin de plus qu’un seul appel Binder

Pour tout ce qui est plus complexe que des transactions Binder directes, le développement moderne de Shizuku privilégie UserService au lieu de l’ancien helper newProcess. Un UserService exécute votre propre code Java/JNI dans un processus séparé en tant que UID 2000 (shell) lorsque Shizuku a été démarré via ADB, ou UID 0 lorsqu’il fonctionne avec root.

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

Shizuku.bindUserService(args, conn);

Cela est utile pour les outils offensifs qui ont besoin d’un état persistant, JNI helpers, ou d’opérations Binder répétées sans payer le coût de lancer des commandes shell encore et encore. Rappelez-vous que le service est n’est pas un processus d’application normal : certaines méthodes Context ne se comportent pas comme elles le font dans une application Android classique.

2.2 Limites qui restent valables

  • ADB/shell et root sont des niveaux de privilège différents. Shizuku.getUid() retourne 2000 pour les sessions soutenues par shell et 0 pour les sessions soutenues par root.
  • Les permissions shell changent entre les versions d’Android et peuvent aussi être restreintes par les OEM.
  • Le shell ne peut toujours pas lire directement le sandbox privé d’une autre application, comme /data/user/0/<package>.
  • Les restrictions de Hidden API s’appliquent toujours au code s’exécutant dans le processus d’application normal ; si vous avez besoin de non-SDK interfaces de façon intensive, déplacez la logique dans un UserService ou utilisez un hidden-API bypass dédié.

3. Rish - shell élevé dans Termux

L’écran de paramètres de Shizuku propose “Use Shizuku in terminal apps”. L’activation télécharge rish, qui ouvre un shell distant privilégié pris en charge par 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

Useful detail for Termux-heavy workflows: when Shizuku runs as ADB/shell, rish intentionally avoids preserving Termux’s environment by default because the shell user usually cannot traverse Termux-private paths.

3.1 Commandes utiles depuis le shell rish

  • Lister les processus en cours d’un package donné :
ps -A | grep com.facebook.katana
  • Énumérer les sockets à l’écoute et les mapper aux packages :
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Extraire les logs de chaque application exposés au shell :
logcat -d | grep -iE "(error|exception)"
  • Désinstallation en masse (exemple) :
pm uninstall --user 0 com.miui.weather2
  • Inspecter les utilisateurs et la disposition des profils avant un abus multi-utilisateur :
pm list users
dumpsys user

3.2 Schémas d’abus modernes rendus possibles par Shizuku basé sur shell

AppOps et manipulation des permissions spéciales

Les gestionnaires compatibles Shizuku tels que App Ops ou App Manager encapsulent en pratique des appels appops autorisés par le shell et des appels Binder du package manager. Depuis rish, la même primitive peut être utilisée directement:

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

Cela est utile lors de pentests pour vérifier si une application ou un agent MDM tolère effectivement des manipulations AppOps agressives sans nécessiter root.

Isolation réseau par application sans VPN ni root

Des outils récents basés sur Shizuku, comme ShizuWall, utilisent les contrôles chain-3 du service connectivity pour bloquer la connectivité réseau pour des paquets sélectionnés :

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

Pour les évaluations, cela vous donne un moyen rapide de tester comment une application cible se comporte lorsqu’un paquet concurrent de sécurité, de télémétrie ou de gestion est coupé sélectivement du réseau tandis que le reste de l’appareil reste en ligne. L’état est effacé au redémarrage.

Installations avancées sur l’appareil et workflows split APK

Les installateurs Shizuku modernes tels que InstallWithOptions ou InstallerX-Revived utilisent un accès PackageInstaller soutenu par le shell pour effectuer des opérations qui seraient autrement gênantes depuis une application normale : split APK installs, test-only packages, batch installs, et certains Android 14 package-install flags.

Du point de vue des tests offensifs, l’important n’est pas le GUI mais le primitif : Shizuku transforme l’installation de paquets en une action autorisée par le shell sur l’appareil, ce qui est utile pour les tests de persistance, les vérifications de downgrade et le déploiement rapide de helper payloads sur un appareil non rooté.

Frontières des work-profile et des utilisateurs secondaires

Shizuku soutenu par le shell est toujours soumis aux restrictions d’utilisateurs d’Android. Sur les profils gérés, vous rencontrerez souvent des erreurs telles que :

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. Considérations de sécurité / détection

  1. Shizuku needs ADB debugging or root first, so Developer Options -> USB/Wireless debugging must be enabled on non-rooted devices.
  2. The service registers itself under the name moe.shizuku.privileged.api. adb shell service list | grep shizuku and adb shell dumpsys activity service moe.shizuku.privileged.api are reliable quick checks.
  3. Les capacités sont limitées à ce que le backend actuel possède. Sur les sessions basées sur ADB, cela signifie que la surface d’attaque effective est celle exposée à com.android.shell sur cette build Android, plus ce que SELinux permet.
  4. Les sessions ne survivent pas à un redémarrage à moins que l’appareil soit rooté et que Shizuku soit configuré comme démon au démarrage.
  5. Les couches de “sécurité” des OEM cassent souvent ou réduisent silencieusement la fonctionnalité de Shizuku. Si une commande fonctionne via direct adb shell mais échoue via Shizuku, comparez le UID du backend actuel (Shizuku.getUid()), les options de débogage OEM, et si l’appareil a réduit les permissions du shell.

5. Atténuation

  • Désactiver le débogage USB/Wireless sur les appareils en production.
  • Surveiller les services Binder exposant moe.shizuku.privileged.api.
  • Appliquer des restrictions work-profile ou MDM qui retirent les fonctionnalités de débogage aux utilisateurs gérés.
  • Traitez les outils compatibles Shizuku comme ADB-equivalent lors de la modélisation des menaces ; c’est un multiplicateur de force post-exploitation même lorsque l’appareil n’est pas rooté.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks