Shizuku, das legitime Tool, das Malware die Schlüssel zu Android gibt

Technische Analyse

Shizuku ist ein legitimes Open-Source-Tool, das bei fortgeschrittenen Android-Nutzern sehr beliebt ist. Es ermöglicht einer App, die Rechte eines Technikers zu erhalten, ohne das Telefon zu rooten. Die 2025 aufgetauchte Malware RedHook hat gezeigt, dass sich auch Angreifer für diese Fähigkeiten interessieren: Ihre im Juli 2026 analysierte Variante verwendete den Code von Shizuku wieder, um sich diese Rechte zu verschaffen, ohne eine einzige Schwachstelle auszunutzen.

Unsere Experten wollten genau messen, was dieses Tool einer App in die Hand gibt. Sie haben eine Test-App entwickelt, 41 Befehle mit und ohne Shizuku unter Android 16 ausgeführt und anschließend vier Missbrauchsszenarien nachgestellt. Hier ist, was sie beobachtet haben, und wie man Shizuku auf einem Gerät erkennt.

Shizuku, der Technikerausweis, der an Apps verliehen wird

Unter Android lebt jede App in einer Sandbox. Sie sieht nur ihre eigenen Daten und muss jede sensible Berechtigung über ein Bestätigungsfenster einholen. Die ADB-Shell, die Entwickler nutzen, wenn sie das Telefon von einem Computer aus steuern, verfügt über deutlich weitreichendere Rechte. Sie kann das gesamte Logcat-Protokoll lesen, über alle Apps und Systemkomponenten hinweg (das Kernel-Protokoll bleibt dagegen verweigert), alle Apps auflisten, geschützte Einstellungen ändern oder den Installer steuern.

Lange Zeit musste eine App, die diese Rechte wollte, Root verlangen. Das setzt in der Regel einen entsperrten Bootloader voraus: Die Integrität des Geräts ist nicht mehr gewährleistet, und Apps, die auf Play Integrity setzen, insbesondere Banking-Apps, können den Dienst verweigern. Shizuku bietet einen dritten Weg. Es hebt die App nicht an, es leiht ihr die Identität der Shell.

So funktioniert es

1. Der Nutzer startet einen Shizuku-Server über ADB, per Kabel oder kabelloses Debugging. Dieser Server läuft unter der Shell-Identität (uid 2000), in einem von der Shizuku-App selbst getrennten Prozess.
2. Eine Client-App fragt die Freigabe zur Nutzung dieses Servers an. Der Nutzer akzeptiert sie ein einziges Mal.
3. Die App übermittelt ihre Befehle anschließend an den Server, der sie mit seinen eigenen Rechten ausführt.

Für Experten liegt der entscheidende Punkt im Schnittstellenvertrag, den unsere Test-App verwendet. Der Server lädt und führt Code aus, den die Client-App bereitstellt, und dieser Code akzeptiert eine beliebige Zeichenkette:

// IUserService.aidl
interface IUserService {
    String run(String command);   // beliebiger Befehl
}

Es gibt keine Whitelist von Operationen. Delegiert wird eine Identität, keine bestimmte Fähigkeit. Eine freigegebene App kann alles tun, was die Shell tun kann.

Die legitimen Einsatzzwecke sind zahlreich: alternative Paketmanager, Entfernen vorinstallierter Apps, Backups, Automatisierung, Firewalls. Genau das macht es zu einem Sicherheitsthema. Ein Mechanismus, der dafür gedacht ist, die Sandbox legitim zu umgehen, bleibt konstruktionsbedingt ein Mechanismus zur Umgehung der Sandbox.

Shizuku funktioniert auch im Root-Modus (uid 0), mit noch umfassenderen Rechten. Unsere Messungen beziehen sich ausschließlich auf den ADB-Modus, den zugänglichsten, da er kein Root erfordert. Die folgenden Ergebnisse sind daher ein Minimum.

Was unsere Experten gemessen haben

Von 41 Befehlen liefern 27 strikt mehr Informationen, wenn sie über Shizuku laufen. Das Protokoll ist einfach: Derselbe Befehl wird zweimal ausgeführt, einmal von der App selbst und einmal über Shizuku. Nur die Identität des Prozesses ändert sich.

Ein Großteil dieser Unterschiede lässt sich durch eine einzige Barriere erklären. Die Tools settings, cmd, pm oder appops ermitteln zunächst den aktuellen Benutzer, was die Berechtigung INTERACT_ACROSS_USERS erfordert. Nur die Shell, das System und Root besitzen sie. Shizuku schaltet also nicht dreizehn unabhängige Fähigkeiten frei: Es überwindet eine Barriere, hinter der das gesamte Shell-Werkzeug verfügbar wird.

Die Unterschiede in der Sichtbarkeit sind ebenso aufschlussreich:

Ohne Shizuku sieht die App buchstäblich nur ihre eigenen Prozesse. Mit Shizuku erhält sie dasselbe Inventar wie eine adb shell: die vollständige Liste der Pakete des Benutzers und alle für die Shell sichtbaren Prozesse, einschließlich init, Root-Prozessen und Kernel-Threads.

Demonstration 1: Logs anderer Apps lesen, einschließlich OTP-Codes

Ein anderer Prozess schreibt zwei Geheimnisse in das Systemprotokoll, wie es eine zu gesprächige App tun würde: einen gefälschten Bank-Bestätigungscode und ein Authentifizierungstoken. Die Test-App führt anschließend logcat -d -s OTPDEMO:I aus.

[Über Shizuku]
I OTPDEMO : Your MyBank verification code is 471953 - do not share it
I OTPDEMO : Bearer eyJhbGciOiJIUzI1NiJ9.demo.token

[Ohne Shizuku]
(keine Ausgabe)

Die Berechtigung READ_LOGS ist Komponenten vorbehalten, die von der Plattform signiert sind. Auf dem Gerät lautet ihre Schutzstufe signature|privileged|development, außer Reichweite einer App aus dem Play Store. Die Shell hingegen gehört zur Gruppe log (1007), die diesen Filter aufhebt. Jedes in das Systemprotokoll geschriebene Geheimnis bleibt, solange es sich noch im Ringpuffer von logd befindet, für jede App lesbar, die der Nutzer in Shizuku freigegeben hat. Eine nicht freigegebene App sieht nur ihre eigenen Zeilen.

Demonstration 2: Eine App ohne jeden Bildschirm installieren

Die Nutzlast ist eine harmlose APK von 8,5 KB, ganz ohne Code. Unsere Experten haben sie in zwei getrennten Messungen geprüft. Die erste isoliert die Berechtigungsbarriere: Ohne Shizuku wird der Befehl pm install-create bereits beim Öffnen der Sitzung verweigert (INTERACT_ACROSS_USERS_FULL). Die App kann zwar über die API PackageInstaller eine Sitzung öffnen, doch der Commit wartet auf eine Aktion des Nutzers, und es wird kein Paket installiert.

pm install-create

[Über Shizuku]
Success: created install session [1908906140]

[Ohne Shizuku]
java.lang.SecurityException: Permission Denial: doCreateSession ...
    this requires android.permission.INTERACT_ACROSS_USERS_FULL

Die zweite Messung demonstriert die Installation von Anfang bis Ende: Über Shizuku liefert pm install -r Success (die APK muss für das System lesbar sein: abgelegt in /data/local/tmp oder über die Standardeingabe mit pm install -S übergeben, denn eine Datei unter Android/data wird von SELinux verweigert), und die App erscheint anschließend in der Liste der installierten Pakete.

Es wurde kein Fenster angezeigt. Unsere Experten haben das auf drei Arten überprüft: Die Test-App blieb während der gesamten Ausführung im Vordergrund, es wurde keine Activity des Installers (im Android-Sinne: kein Fenster) gestartet, auch wenn das Systemprotokoll die Installation selbst und das Aufwecken des Installer-Prozesses zum Versenden des Ereignisses PACKAGE_ADDED erfasst, und die Screenshots zeigen nie einen Installationsbildschirm. Das ist das typische Verhalten eines Droppers, der weitere Malware herunterlädt und installiert.

Demonstration 3: Sich eine Berechtigung ohne Popup erteilen

Nur für diese Demonstration wurde die Test-App so geändert, dass sie zwei sensible Berechtigungen deklariert, den Zugriff auf Kontakte und SMS, ohne sie anzufordern. Anschließend führt sie pm grant nur für die Kontakte aus. Die SMS dienen als Kontrollwert. Die App fragt Android vorher und nachher ab:

VORHER   READ_CONTACTS  granted=false
VORHER   READ_SMS       granted=false
NACHHER  READ_CONTACTS  granted=true    ← erteilt, ohne jede Interaktion
NACHHER  READ_SMS       granted=false   ← Kontrollwert unverändert

Das Berechtigungsfenster ist seit Version 6 der Zustimmungsmechanismus von Android. Hier umgeht die App ihn vollständig. Da die Berechtigung tatsächlich erteilt ist, erscheinen alle folgenden Aufrufe dem System als legitim. Nichts hindert daran, dasselbe für Standort, Mikrofon oder Kamera zu tun.

Demonstration 4: Ein vollständiges Profil des Geräts erstellen

Über Shizuku ruft die App die android_id der Shell ab (die von adb shell settings get secure android_id zurückgegebene, die allen Apps gemeinsam ist, die über Shizuku oder adb gehen, und die sich von der eigenen android_id der App unterscheidet, die diese bereits ohne jede Berechtigung liest), die Seriennummer, die Liste der 261 Apps mit ihrem Speicherort, die registrierten Konten und die Nutzungsstatistiken der letzten 24 Stunden.

Am aufdringlichsten bleibt die Tabelle der Netzwerkverbindungen (/proc/net/tcp und /proc/net/tcp6), die jede Verbindung der Kennung der App zuordnet, die sie hält. In Kombination mit cmd package list packages -U zeigt sie, welche App mit welchem Server kommuniziert. Und das ganz ohne Netzwerkberechtigung.

Über die Demonstrationen hinaus

Im ADB-Modus öffnet Shizuku nicht die privaten Daten anderer Apps: Der Ordner /data/data bleibt der Shell verwehrt. Eine App kann daher nicht direkt die Datenbank einer Banking-App lesen, sofern diese nicht als debuggable gekennzeichnet ist. Nur ein debuggable-Paket öffnet sich der Shell, über run-as. Dagegen ermöglicht Shizuku, die IMEI auszulesen, den Bildschirm aufzuzeichnen und Gesten zu simulieren: RedHook nutzt dies, um den Bildschirm ohne Zustimmungsfenster aufzuzeichnen.

Warum das ein blinder Fleck ist

Shizuku ist keine Schwachstelle. Es ist eine Funktion, die bestimmungsgemäß genutzt wird, und daher gibt es nichts zu beheben, weder bei Shizuku noch bei Android. Was sich ändert, ist das Zustimmungsmodell.

Wer Shizuku installiert, tut dies für einen legitimen Zweck. Nichts weist ihn darauf hin, dass die Freigabe für eine App bedeutet, ihr seine Logs, das Inventar seiner Apps und das Recht abzutreten, sich selbst Berechtigungen zu erteilen.

Ein weiterer bemerkenswerter Punkt: Shizuku zu erkennen, erfordert keinerlei Rechte. Unsere Test-App weiß, ob ein Server läuft, noch bevor sie die geringste Freigabe erhalten hat. Eine bösartige App kann daher auf Geräten ohne Shizuku inaktiv bleiben und nur dort handeln, wo sie Erfolg haben wird.

RedHook geht noch weiter

Das getestete Szenario setzt voraus, dass der Nutzer Shizuku selbst installiert und gestartet hat. RedHook kommt ohne das aus. Sobald es die Bedienungshilfen-Rechte durch Social Engineering erlangt hat, aktiviert es selbstständig die Entwickleroptionen und das kabellose Debugging. Anschließend koppelt es sich mit dem ADB-Dienst des Telefons selbst und stellt dann seinen eigenen, auf Shizuku basierenden Server bereit. Nach einem Neustart aktiviert es das Debugging erneut und erlangt seine Rechte in wenigen Sekunden zurück.

Die in unseren Demonstrationen gemessenen Fähigkeiten decken sich mit denen, die es ausnutzt: stille Installation von Apps, Änderung geschützter Einstellungen und Erteilung von Berechtigungen ohne Bestätigungsfenster.

So erkennen Sie Shizuku

Vier Signale sollten auf einem Gerät aufhorchen lassen.

• Aktivierte Entwickleroptionen. Sie sind die Voraussetzung für den ADB-Modus.
• Aktives USB- oder kabelloses Debugging. Das kabellose Debugging ermöglicht es, Shizuku ohne Kabel neu zu starten, und RedHook aktiviert es selbst.
• Installierte Shizuku-App. Sie zeigt eine Nutzung des Tools an, legitim oder nicht.
• Unbekannte App mit Zugriff auf die Bedienungshilfen. Das ist das Einfallstor von RedHook, das seinen eigenen, auf Shizuku basierenden Server mitbringt und daher nicht unter diesem Namen in der App-Liste erscheint.

Für technische Teams, über ADB

Technische Teams können diese Punkte von einem verbundenen Rechner aus prüfen, mit den Befehlen, die unsere Experten auf ihrem Testaufbau verwendet haben:

# USB- und kabelloses Debugging (1 = aktiviert)
adb shell settings get global adb_enabled
adb shell settings get global adb_wifi_enabled

# Aktiver Shizuku-Server
adb shell ps -A -o USER,PID,NAME | grep -i shizuku

Ist ein Server aktiv, liefert der letzte Befehl einen Prozess shizuku_server, der unter der Identität shell läuft.

Für Herausgeber sensibler Apps

Eine App kann Shizuku aus ihrer Sandbox heraus erkennen, ohne besondere Freigabe. Unsere Test-App kombiniert drei sich ergänzende Ansätze: die Installationsspuren, die Antwort des Servers und die Systemspuren.

Der Ping benötigt keine Bibliothek: Eine App, die die Berechtigung moe.shizuku.manager.permission.API_V23 deklariert und einen Provider <package>.shizuku bereitstellt, erhält von Shizuku ein Bundle mit dessen Binder, und ein pingBinder() auf diesen Binder antwortet mit wahr oder falsch.

Wie Pradeo reagiert

Jedes Telefon von Hand zu prüfen, ist im Maßstab einer Flotte nicht machbar. Die Lösung Mobile Threat Defense von Pradeo überwacht kontinuierlich auf allen Endgeräten die Bedingungen, die Shizuku ausnutzbar machen:

• Riskante Konfigurationen. Sie meldet jede ungewöhnliche Aktivierung der Entwickleroptionen und des kabellosen Debuggings, Voraussetzungen für den ADB-Modus von Shizuku.
• Kritische Berechtigungen. Jede App, die Zugriff auf die Bedienungshilfen anfordert, wird als potenziell bösartig gemeldet.
• Apps außerhalb offizieller Stores. Sie erkennt Apps, die aus einer anderen Quelle installiert wurden, dem Verbreitungsweg von RedHook.
• Mobiles Phishing. Das Blockieren betrügerischer Links, die per SMS oder Instant Messaging eingehen, den Verbreitungskanälen von RedHook, unterbricht die Infektionskette frühzeitig.

Für App-Herausgeber erkennt unsere Lösung Runtime Application Self Protection, wenn eine App auf einem Telefon im Entwicklermodus läuft, der Voraussetzung für den ADB-Modus von Shizuku. Die App weiß so, dass sie in einer riskanten Umgebung läuft, und kann reagieren, bevor ein Dritter diese Rechte missbraucht.