Shizuku Privileged API

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Shizuku ist ein Open-Source-Service, der einen privilegierten Java-Prozess mit app_process startet und ausgewählte Android system APIs over Binder bereitstellt. Da der Prozess mit denselben shell UID capabilities that ADB uses läuft, kann eine vom Benutzer ausdrücklich autorisierte App Binder-Aufrufe an Systemdienste proxyen without rooting the device.

In der Praxis bedeutet das, dass eine Shizuku-enabled App oft dieselben Primitive wie adb shell ausüben kann: Paketverwaltung, appops, settings, cmd connectivity, Log-Sammlung und viele andere vom Shell erlaubte Binder-Transaktionen. Sie ist weiterhin not root und bleibt durch Android permissions, Linux UID checks, SELinux policy, Android version, and OEM-specific restrictions eingeschränkt.

Typische Anwendungsfälle:

  • Sicherheitsaudits auf einem nicht-gerooteten Gerät
  • Paketverwaltung direkt auf dem Gerät, debloating und Installation von Split-APKs
  • Sammeln von Logs, Paketmetadaten und vom Shell einsehbaren Netzwerk-/Prozesszuständen
  • Erstellen von PoCs oder Hilfs-Tools, die ADB-grade Zugriff benötigen, aber keine vollständige Root-Kette

1. Starting the privileged service

moe.shizuku.privileged.api kann auf drei verschiedene Arten gestartet werden. Die über Binder an Client-Apps exponierte Schnittstelle ist dieselbe, aber die effektiven Privilegien hängen davon ab, ob das Backend ADB/shell oder root ist.

1.1 Wireless ADB (Android 11+)

  1. Aktivieren Sie Developer Options -> Wireless debugging und koppeln Sie das Gerät.
  2. In der Shizuku-App wählen Sie “Start via Wireless debugging”.
  3. Die Sitzung überlebt bis zum Reboot, sofern die OEM ROM nicht Wireless debugging beendet oder die Debugging-Autorisierung widerruft.

1.2 USB / local ADB one-liner

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

Dasselbe Skript kann über eine network ADB-Verbindung (adb connect <IP>:5555) ausgeführt werden.

1.3 Rooted devices

Wenn das Gerät bereits rooted ist, führe aus:

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

1.4 OEM-Eigenheiten, die beim Testen wichtig sind

  • MIUI / HyperOS verlangt häufig USB debugging (Security settings) zusätzlich zum normalen USB debugging toggle.
  • ColorOS / OxygenOS erfordert häufig, Permission monitoring oder äquivalente Sicherheits-Wrapper zu deaktivieren.
  • Auf Android 11+ reduziert Disable adb authorization timeout das zufällige Beenden von Shizuku während langer Testsitzungen.
  • Wenn der drahtlose Start wiederholt fehlschlägt, erlauben Sie Shizuku, im Hintergrund zu laufen; mehrere OEM-ROMs deaktivieren die lokale Netzwerk-Erkennung, wenn die App in den Hintergrund geschickt wird.

1.5 Überprüfen, ob es läuft

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

Ein erfolgreicher Start liefert einen laufenden Service zurück und stellt einen Binder-Service zur Verfügung, der mit moe.shizuku.privileged.api zusammenhängt.

2. Bindung aus einer Anwendung

Eine für Shizuku aktivierte App verwendet nicht den rohen Binder, den Shizuku zurückgibt, als wäre er IPackageManager. Der normale Ablauf ist:

  1. die Shizuku API-Berechtigung und ShizukuProvider hinzufügen,
  2. warten, bis der Shizuku Binder erscheint,
  3. die runtime-ähnliche Autorisierung von Shizuku vom Benutzer anfordern,
  4. den Binder des Ziel-Systemdienstes mit ShizukuBinderWrapper umhüllen.

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

Minimales Binder-wrapper-Beispiel:

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

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

That wrapper is what causes Binder transactions to be forwarded by the Shizuku service process instead of being executed with the caller app’s normal UID.

2.1 UserService: wenn du mehr als einen einzelnen Binder-Aufruf benötigst

Für alles Komplexere als direkte Binder-Transaktionen bevorzugt die moderne Shizuku-Entwicklung UserService statt des alten newProcess-Helpers. Ein UserService führt deinen eigenen Java/JNI-Code in einem separaten Prozess als UID 2000 (shell) aus, wenn Shizuku via ADB gestartet wurde, oder als UID 0, wenn Shizuku mit root läuft.

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

Shizuku.bindUserService(args, conn);

Das ist nützlich für offensive Tools, die einen dauerhaften Zustand, JNI-Hilfsfunktionen oder wiederholte Binder-Operationen benötigen, ohne immer wieder neue Shell-Befehle starten zu müssen. Beachte, dass der Service kein normaler App-Prozess ist: einige Context-Methoden verhalten sich nicht wie in einer regulären Android-Anwendung.

2.2 Grenzen, die weiterhin gelten

  • ADB/shell und root sind unterschiedliche Berechtigungsstufen. Shizuku.getUid() gibt 2000 für shell-gestützte Sitzungen und 0 für root-gestützte Sitzungen zurück.
  • Shell-Berechtigungen ändern sich zwischen Android-Versionen und können auch von OEMs eingeschränkt werden.
  • Die Shell kann weiterhin nicht direkt den privaten Sandbox-Bereich einer anderen App lesen, z. B. /data/user/0/<package>.
  • Einschränkungen der Hidden API gelten weiterhin für Code, der im normalen App-Prozess läuft; wenn du umfangreich non-SDK-Interfaces benötigst, verschiebe die Logik in einen UserService oder verwende einen dedizierten Hidden-API-Bypass.

3. Rish - Shell mit erhöhten Rechten in Termux

Der Shizuku-Einstellungsbildschirm bietet „Shizuku in Terminal-Apps verwenden“ an. Wenn diese Option aktiviert wird, wird rish heruntergeladen, das eine entfernte privilegierte Shell öffnet, die von Shizuku bereitgestellt wird.

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

Nützliche Details für Termux-lastige Workflows: wenn Shizuku als ADB/shell läuft, vermeidet rish standardmäßig bewusst, die Termux-Umgebung zu erhalten, da der shell-Benutzer normalerweise nicht durch Termux-private Pfade navigieren kann.

3.1 Nützliche Befehle aus der rish-Shell

  • Laufende Prozesse eines bestimmten Pakets auflisten:
ps -A | grep com.facebook.katana
  • Lauschende Sockets aufzählen und ihnen Pakete zuordnen:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Logs jeder Anwendung, die der shell zugänglich sind, ausgeben:
logcat -d | grep -iE "(error|exception)"
  • Bulk-Debloat (Beispiel):
pm uninstall --user 0 com.miui.weather2
  • Benutzer und Profilaufbau vor Multi-User-Missbrauch untersuchen:
pm list users
dumpsys user

3.2 Moderne Missbrauchs-Muster, die durch shell-gestütztes Shizuku ermöglicht werden

AppOps und Manipulation spezieller Berechtigungen

Shizuku-aktivierte Manager wie App Ops oder App Manager kapseln effektiv shell-autorisierte appops- und Paketmanager-Binder-Aufrufe. Von rish aus kann dieselbe Primitive direkt verwendet werden:

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

Das ist während pentests nützlich, um zu validieren, ob eine App oder ein MDM-Agent aggressive AppOps-Manipulation tatsächlich toleriert, ohne root zu benötigen.

Pro-App-Netzwerkisolation ohne VPN oder root

Neue Shizuku-basierte Tools wie ShizuWall nutzen die chain-3-Kontrollen des connectivity-Service, um den Netzwerkzugriff für ausgewählte Pakete zu blockieren:

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

Für Assessments bietet das eine schnelle Möglichkeit zu testen, wie sich eine Ziel-App verhält, wenn ein konkurrierendes Sicherheits-, Telemetrie- oder Management-Paket selektiv vom Netzwerk abgeschottet wird, während der Rest des Geräts online bleibt. Der Zustand wird beim Neustart gelöscht.

On-device fortgeschrittene Installationen und split APK-Workflows

Moderne Shizuku-Installer wie InstallWithOptions oder InstallerX-Revived verwenden shell-gestützten PackageInstaller-Zugriff, um Operationen durchzuführen, die aus einer normalen App sonst umständlich wären: split APK installs, test-only packages, batch installs und einige Android 14 package-install flags.

Aus offensiver Test-Perspektive ist nicht die GUI wichtig, sondern die Primitive: Shizuku verwandelt die Paketinstallation wieder in eine on-device, shell-autorisierte Aktion, was für persistence tests, downgrade checks und die schnelle Bereitstellung von helper payloads auf einem nicht-gerooteten Gerät nützlich ist.

Work-profile und secondary-user-Grenzen

Shell-gestütztes Shizuku unterliegt weiterhin den Nutzerbeschränkungen von Android. Bei verwalteten Profilen stößt man häufig auf Fehler wie:

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. Sicherheitsüberlegungen / Erkennung

  1. Shizuku benötigt zuerst ADB debugging oder root, daher müssen Developer Options -> USB/Wireless debugging auf non-rooted devices aktiviert sein.
  2. Der Service registriert sich unter dem Namen moe.shizuku.privileged.api. adb shell service list | grep shizuku und adb shell dumpsys activity service moe.shizuku.privileged.api sind zuverlässige Schnellchecks.
  3. Die Fähigkeiten sind auf das beschränkt, was das aktuelle Backend bereitstellt. Bei ADB-gestützten Sessions bedeutet das, dass die effektive Angriffsfläche diejenige ist, die com.android.shell auf diesem Android-Build exponiert, zuzüglich dessen, was SELinux erlaubt.
  4. Sessions überleben einen Reboot nicht, es sei denn, das Gerät ist rooted und Shizuku ist als Startup-Daemon konfiguriert.
  5. OEM-“Sicherheits”-Layer brechen häufig oder reduzieren stillschweigend die Shizuku-Funktionalität. Wenn ein Befehl direkt via adb shell funktioniert, aber über Shizuku fehlschlägt, vergleichen Sie die aktuelle Backend-UID (Shizuku.getUid()), OEM-Debugging-Toggles und ob das Gerät Shell-Berechtigungen beschnitten hat.

5. Gegenmaßnahmen

  • Deaktivieren Sie USB/Wireless debugging auf Produktionsgeräten.
  • Überwachen Sie Binder-Services auf Exposition von moe.shizuku.privileged.api.
  • Erzwingen Sie Work-Profile- oder MDM-Einschränkungen, die Debugging-Funktionen bei verwalteten Nutzern entfernen.
  • Behandeln Sie Shizuku-kompatible Tools während der Threat-Modelling-Phase als ADB-equivalent; es ist ein post-exploitation Kraftmultiplikator, selbst wenn das Gerät nicht rooted ist.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks