Shizuku Privileged API

Shizuku est un service open-source qui génère un processus Java privilégié en utilisant app_process et expose des API système Android sélectionnées via Binder. Étant donné que le processus est lancé avec les mêmes capabilités UID shell que celles utilisées par ADB, toute application (ou terminal) qui se lie à l'interface AIDL exportée peut effectuer de nombreuses actions qui nécessitent normalement WRITE_SECURE_SETTINGS, INSTALL_PACKAGES, accès aux fichiers dans /data, etc. – sans rooter l'appareil.

Cas d'utilisation typiques :

• Audit de sécurité depuis un appareil non rooté
• Suppression de bloatware / désencombrement des applications système
• Collecte de journaux, clés Wi-Fi, informations sur les processus et les sockets pour les équipes bleues/DFIR
• Automatisation de la configuration de l'appareil depuis des applications personnalisées ou des scripts shell

1. Démarrer le service privilégié

moe.shizuku.privileged.api peut être démarré de trois manières différentes – le service Binder résultant se comporte de la même manière dans tous les cas.

1.1 ADB sans fil (Android 11+)

1. Activez Options pour les développeurs ➜ Débogage sans fil et associez l'appareil.
2. Dans l'application Shizuku, sélectionnez “Démarrer via le débogage sans fil” et copiez le code d'association.
3. Le service survit jusqu'au prochain redémarrage (les sessions de débogage sans fil sont effacées au démarrage).

1.2 USB / ligne de commande ADB locale

adb push start.sh \
/storage/emulated/0/Android/data/moe.shizuku.privileged.api/

# spawn the privileged process
adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh

Le même script peut être exécuté via une connexion network ADB (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 Vérification de son fonctionnement

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

Un démarrage réussi renvoie Running services (1) ainsi que le PID du processus privilégié.

2. Liaison depuis une application

Les applications tierces n'ont besoin que de ce qui suit dans leur AndroidManifest.xml:

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

Au moment de l'exécution, ils obtiennent le binder :

IBinder binder = ShizukuProvider.getBinder();
IPackageManager pm  = IPackageManager.Stub.asInterface(binder);

À partir de ce moment, l'application peut invoquer n'importe quelle méthode que l'utilisateur shell peut appeler – par exemple :

pm.installPackage(new Uri("file:///sdcard/app.apk"), null, 0, null);
Settings.Global.putInt(resolver, Settings.Global.ADB_ENABLED, 1);

Une liste soigneusement sélectionnée de plus de 170 applications compatibles avec Shizuku est maintenue sur awesome-shizuku.

3. Rish – shell élevé à l'intérieur de Termux

L'écran des paramètres de Shizuku expose “Utiliser Shizuku dans les applications terminal”. L'activer télécharge rish (/data/local/tmp/rish).

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

3.1 Commandes utiles du 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 (par exemple, CVE-2019-6447 ES File Explorer) :

netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done

• Dump des logs de chaque application :

logcat -d | grep -iE "(error|exception)"

• Lire les identifiants Wi-Fi stockés (Android 11 +) :

cat /data/misc/wifi/WifiConfigStore.xml | grep -i "<ConfigKey>"

• Débloat en masse (exemple) :

pm uninstall --user 0 com.miui.weather2

4. Considérations de sécurité / détection

1. Shizuku nécessite des privilèges ADB debugging, donc Options pour les développeurs → Débogage USB/Sans fil doit être activé. Les organisations peuvent bloquer cela via un MDM ou avec settings put global development_settings_enabled 0.
2. Le service s'enregistre sous le nom moe.shizuku.privileged.api. Une simple adb shell service list | grep shizuku (ou règle de sécurité des points de terminaison) détecte sa présence.
3. Les capacités sont limitées à ce que l'utilisateur shell peut déjà faire – ce n'est pas root. Les API sensibles qui nécessitent l'utilisateur system ou root restent inaccessibles.
4. Les sessions ne survivent pas à un redémarrage à moins que l'appareil ne soit rooté et que Shizuku soit configuré comme un démon de démarrage.

5. Atténuation

• Désactiver le débogage USB/Sans fil sur les appareils de production.
• Surveiller les services Binder exposant moe.shizuku.privileged.api.
• Utiliser des politiques SELinux (Android enterprise) pour bloquer l'interface AIDL des applications non gérées.

Références

• Blog – Shizuku : Déverrouiller des capacités avancées d'Android sans root
• Documentation officielle de Shizuku
• awesome-shizuku – liste des applications prises en charge
• shell rish (shell reverse-adb privilégié)