Shizuku, the legitimate tool that gives malware access to Android

Shizuku: the technician's badge, lent to applications

On Android, every application lives in a sandbox. It only sees its own data and must obtain each sensitive permission through a confirmation dialog. The ADB shell, used by developers to control the phone from a computer, has far broader rights. It can read the entire logcat buffer, across all applications and system components (the kernel log remains off-limits), list every installed application, change protected settings or drive the package installer.

For a long time, an application that wanted these rights had to require root, which usually means an unlocked bootloader: device integrity can no longer be guaranteed, and applications that rely on Play Integrity, banking applications in particular, may refuse to run. Shizuku offers a third way. It does not elevate the application, it lends it the shell's identity.

How it works

1. The user starts a Shizuku server via ADB, over USB or wireless debugging. This server runs under the shell identity (uid 2000), in a process separate from the Shizuku application itself.
2. A client application requests permission to use this server. The user grants it once.
3. The application then sends its commands to the server, which executes them with its own privileges

For experts, the key point lies in the interface contract used by our test application. The server loads and runs code supplied by the client application, and that code accepts an arbitrary string:

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

There is no allowlist of operations. What is delegated is an identity, not a specific capability. An authorized application can do anything the shell can do.

Legitimate uses are many: alternative package managers, bloatware removal, backups, automation, firewalls. That is precisely what makes it a security issue. A mechanism designed to legitimately bypass the sandbox remains, by design, a sandbox bypass mechanism.

Shizuku also runs in root mode (uid 0), with even broader rights. Our measurements cover ADB mode only, the most accessible since it requires no root. The results below are therefore a lower bound.

What our experts measured

Out of 41 commands, 27 return strictly more information when they go through Shizuku. The protocol is simple: the same command is run twice, once by the application itself and once through Shizuku. Only the process identity changes.

Test setup

ARM64 emulator running Android 16 (SDK 36), SELinux enforcing, Shizuku v13.6 started in ADB mode without root. The test application declares no Android permission other than Shizuku's, not even Internet access.

Much of this gap comes down to a single barrier. The settings, cmd, pm and appops tools start by resolving the current user, which requires the INTERACT_ACROSS_USERS permission. Only the shell, the system and root hold it. Shizuku therefore does not unlock thirteen independent capabilities: it clears one barrier behind which the entire shell toolset becomes available.

The visibility gaps are just as telling :

Without Shizuku, the application literally sees only its own processes. With it, it gets the same inventory as an adb shell: the full list of the user's packages and every process visible to the shell, including init, root processes and kernel threads.

Demonstration 1: reading other applications' logs, OTP codes included

Another process writes two secrets to the system log, as an overly verbose application would: a fake bank verification code and an authentication token. The test application then runs logcat -d -s OTPDEMO:I.

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

[Without Shizuku]
(no output)

The READ_LOGS permission is reserved for platform-signed components. On the device, its protection level is signature|privileged|development, out of reach for a Play Store application. The shell, however, belongs to the log group (1007), which lifts this filter. Any secret written to the system log remains readable, as long as it is still in logd's ring buffer, by any application the user has authorized in Shizuku. An unauthorized application only sees its own lines.

Demonstration 2: installing an application with no screen at all

The payload is a harmless 8.5 KB APK containing no code. Our experts tested it in two separate measurements. The first isolates the permission barrier: without Shizuku, the pm install-create command is rejected as soon as the session is opened (INTERACT_ACROSS_USERS_FULL). The application can still open a session through the PackageInstaller API, but the commit waits for user action and no package is installed.

pm install-create  

[Via Shizuku] 
Success: created install session [1908906140]  

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

The second measurement demonstrates end-to-end installation: through Shizuku, pm install -r returns Success (the APK must be readable by the system, either placed in /data/local/tmp or piped through standard input with pm install -S, since SELinux denies access to files under Android/data) and the application then appears in the list of installed packages.

No window was displayed. Our experts verified this in three ways: the test application stayed in the foreground throughout the run, no installer activity (in the Android sense, meaning no window) was started, even though the system log records the installation itself and the installer process waking up to broadcast the PACKAGE_ADDED event, and screenshots never show an installation screen. This is typical dropper behavior, which downloads and then installs additional malware.

Demonstration 3: granting itself a permission without a prompt

For this demonstration only, the test application was modified to declare two sensitive permissions, contacts and SMS access, without requesting them. It then runs pm grant on contacts only. SMS serves as the control. The application queries Android before and after:

BEFORE READ_CONTACTS  granted=false 
BEFORE READ_SMS       granted=false
AFTER  READ_CONTACTS  granted=true    ← granted, with no user interaction 
AFTER  READ_SMS       granted=false   ← control unchanged

The runtime permission dialog has been Android's consent mechanism since version 6. Here, the application bypasses it entirely. Because the permission is genuinely granted, every subsequent call looks legitimate to the system. Nothing prevents doing the same for location, the microphone or the camera.

Demonstration 4: building a complete device profile

Through Shizuku, the application retrieves the shell's android_id (the one returned by adb shell settings get secure android_id, shared by every application going through Shizuku or adb, and different from the application's own android_id, which it can already read without any permission), the serial number, the list of 261 applications with their install paths, registered accounts and usage statistics for the last 24 hours.

The most intrusive item is the network connection table (/proc/net/tcp and /proc/net/tcp6), which maps each connection to the uid of the application that owns it. Cross-referenced with cmd package list packages -U, it reveals which application talks to which server. All without any network permission.

Beyond the demonstrations

In ADB mode, Shizuku does not open other applications' private data: the /data/data directory remains off-limits to the shell. An application therefore cannot directly read a banking application's database, as long as that application is not flagged as debuggable, which is the case for production applications. Only a debuggable package is accessible to the shell, via run-as. Shizuku does, however, make it possible to read the IMEI, capture the screen and simulate gestures: RedHook uses it to capture the screen without a consent dialog.

Two pitfalls for anyone reproducing these measurements

• run-as does not simulate an application. A process launched this way inherits the shell's groups, including log and readproc. All our "without Shizuku" values come from the application itself.
• An exit code of 0 proves nothing. dumpsys returns 0 even when it refuses to respond. A test that only reads the exit code underestimates the gap by half: it saw only 13 gains instead of 27.

Why it is a blind spot

Shizuku is not a vulnerability. It is a feature used exactly as designed, so there is nothing to patch, either in Shizuku or in Android. What changes is the consent model.

A user who installs Shizuku does so for a legitimate purpose. Nothing tells them that authorizing an application means handing over their logs, their application inventory and the right to grant itself permissions.

Another notable point: detecting Shizuku requires no privileges. Our test application can tell whether a server is running before obtaining any authorization. A malicious application can therefore stay dormant on devices without Shizuku and act only where it will succeed.

RedHook goes further

The tested scenario assumes the user installed and started Shizuku themselves. RedHook does not need that. Once it has obtained accessibility permissions through social engineering, it enables Developer options and wireless debugging on its own. It then pairs with the phone's own ADB service and deploys its own Shizuku-based server. After a reboot, it re-enables debugging and regains its privileges within seconds.

The capabilities measured in our demonstrations overlap with those it exploits: silent application installation, modification of protected settings and granting permissions without a confirmation dialog.

How to spot Shizuku

Four signals should raise a red flag on a device.

• Developer options enabled. They are a prerequisite for ADB mode.
• USB or wireless debugging active. Wireless debugging lets Shizuku be restarted without a cable, and RedHook enables it itself.
• Shizuku application installed. It reveals use of the tool, legitimate or not.
• Unknown application with accessibility access. This is RedHook's entry point. Since it embeds its own Shizuku-based server, it does not appear under that name in the list of applications.
  
  

For technical teams, via ADB 

Technical teams can check these points from a connected workstation, using the commands our experts ran on their test setup:

# USB and wireless debugging (1 = enabled) 
adb shell settings get global adb_enabled 
adb shell settings get global adb_wifi_enabled 

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

If a server is running, the last command returns a shizuku_server process running under the shell identity.

How Pradeo responds

Checking every phone by hand does not scale across a fleet. Pradeo's Mobile Threat Defense continuously monitors, across every device, the conditions that make Shizuku exploitable :

• Risky configurations. It flags any abnormal activation of Developer options and wireless debugging, the prerequisites for Shizuku's ADB mode.
• Critical permissions. Any application requesting accessibility access is flagged as potentially malicious.
• Applications from outside official stores. It detects applications installed from other sources, RedHook's distribution method.
• Mobile phishing. Blocking malicious links received by SMS or instant messaging, RedHook's distribution channels, cuts the infection chain upstream.
  
  

On the application publisher side, our Runtime Application Self-Protection solution detects when an application runs on a phone in developer mode, a prerequisite for Shizuku's ADB mode. The application thus knows it is running in a risky environment and can react before a third party abuses these privileges.