Shizuku Privileged API

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Shizuku is an open-source service that starts a privileged Java process with app_process and exposes selected Android system APIs over Binder. Because the process runs with the same shell UID capabilities that ADB uses, an app that is explicitly authorised by the user can proxy Binder calls to system services without rooting the device.

In practice, this means a Shizuku-enabled app can often exercise the same primitives as adb shell: package management, appops, settings, cmd connectivity, log collection, and many other shell-allowed Binder transactions. It is still not root and it is still constrained by Android permissions, Linux UID checks, SELinux policy, Android version, and OEM-specific restrictions.

Typical use cases:

  • Security auditing from an un-rooted handset
  • On-device package management, debloating and split-APK installation
  • Collecting logs, package metadata and shell-visible network/process state
  • Building PoCs or helper tooling that need ADB-grade access but not a full root chain

1. Starting the privileged service

moe.shizuku.privileged.api can be started in three different ways. The Binder interface exposed to client apps is the same, but the effective privilege depends on whether the backend is ADB/shell or root.

1.1 Wireless ADB (Android 11+)

  1. Enable Developer Options -> Wireless debugging and pair the device.
  2. Inside the Shizuku app select “Start via Wireless debugging”.
  3. The session survives until reboot unless the OEM ROM kills wireless debugging or revokes the debugging authorisation.

1.2 USB / local ADB one-liner

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

The same script can be executed over a network ADB connection (adb connect <IP>:5555).

1.3 Rooted devices

If the device is already rooted run:

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

1.4 OEM quirks that matter during testing

  • MIUI / HyperOS often requires USB debugging (Security settings) in addition to the normal USB debugging toggle.
  • ColorOS / OxygenOS commonly requires disabling Permission monitoring or equivalent security wrappers.
  • On Android 11+, Disable adb authorization timeout reduces random Shizuku loss during long test sessions.
  • If wireless startup keeps failing, allow Shizuku to run in the background; several OEM ROMs suspend local-network discovery when the app is backgrounded.

1.5 Verifying that it is running

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

A successful start returns a running service and exposes a Binder service related to moe.shizuku.privileged.api.

2. Binding from an application

A Shizuku-enabled app does not use the raw Binder returned by Shizuku as if it were IPackageManager. The normal flow is:

  1. add the Shizuku API permission and ShizukuProvider,
  2. wait for the Shizuku Binder to appear,
  3. request Shizuku’s runtime-style authorisation from the user,
  4. wrap the target system-service Binder with ShizukuBinderWrapper.

Manifest requirements:

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

Minimal Binder-wrapper example:

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: when you need more than a single Binder call

For anything more complex than direct Binder transactions, modern Shizuku development prefers UserService instead of the old newProcess helper. A UserService runs your own Java/JNI code in a separate process as UID 2000 (shell) when Shizuku was started via ADB or UID 0 when backed by root.

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

Shizuku.bindUserService(args, conn);

This is useful for offensive tooling that needs long-lived state, JNI helpers, or repeated Binder operations without paying the cost of spawning shell commands over and over. Remember that the service is not a normal app process: some Context methods do not behave like they do inside a regular Android application.

2.2 Boundaries that still apply

  • ADB/shell and root are different privilege levels. Shizuku.getUid() returns 2000 for shell-backed sessions and 0 for root-backed sessions.
  • Shell permissions change between Android releases and can also be trimmed by OEMs.
  • Shell still cannot directly read another app’s private sandbox such as /data/user/0/<package>.
  • Hidden API restrictions still apply to code running in the normal app process; if you need non-SDK interfaces extensively, move the logic into a UserService or use a dedicated hidden-API bypass.

3. Rish - elevated shell inside Termux

The Shizuku settings screen exposes “Use Shizuku in terminal apps”. Enabling it downloads rish, which opens a remote privileged shell backed by 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 Useful commands from the rish shell

  • List running processes of a given package: 
    ps -A | grep com.facebook.katana
  • Enumerate listening sockets and map them to packages: 
    netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
    printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Dump every application’s logs exposed to shell: 
    logcat -d | grep -iE "(error|exception)"
  • Bulk debloat (example): 
    pm uninstall --user 0 com.miui.weather2
  • Inspect users and profile layout before multi-user abuse: 
    pm list users
dumpsys user

3.2 Modern abuse patterns enabled by shell-backed Shizuku

AppOps and special-permission tampering

Shizuku-enabled managers such as App Ops or App Manager are effectively wrapping shell-authorised appops and package-manager Binder calls. From rish, the same primitive can be used directly:

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

This is useful during pentests to validate whether an app or MDM agent actually tolerates aggressive AppOps manipulation without requiring root.

Per-app network isolation without VPN or root

Recent Shizuku-based tools such as ShizuWall use the connectivity service’s chain-3 controls to block networking for selected packages:

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

For assessments, this gives you a fast way to test how a target app behaves when a competing security, telemetry or management package is selectively cut off from the network while the rest of the device remains online. The state is cleared on reboot.

On-device advanced installs and split APK workflows

Modern Shizuku installers such as InstallWithOptions or InstallerX-Revived use shell-backed PackageInstaller access to perform operations that are otherwise awkward from a normal app: split APK installs, test-only packages, batch installs, and some Android 14 package-install flags.

From an offensive-testing point of view, the important part is not the GUI but the primitive: Shizuku turns package installation back into an on-device shell-authorised action, which is useful for persistence tests, downgrade checks and rapid deployment of helper payloads on a non-rooted handset.

Work-profile and secondary-user boundaries

Shell-backed Shizuku is still subject to Android’s user restrictions. On managed profiles you will often hit errors such as:

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. Security considerations / detection

  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. Capabilities are limited to what the current backend has. On ADB-backed sessions, that means the effective attack surface is the one exposed to com.android.shell on that Android build, plus whatever SELinux permits.
  4. Sessions do not survive a reboot unless the device is rooted and Shizuku is configured as a startup daemon.
  5. OEM “security” layers often break or silently reduce Shizuku functionality. If a command works via direct adb shell but fails through Shizuku, compare the current backend UID (Shizuku.getUid()), OEM debugging toggles, and whether the device trimmed shell permissions.

5. Mitigation

  • Disable USB/Wireless debugging on production devices.
  • Monitor for Binder services exposing moe.shizuku.privileged.api.
  • Enforce work-profile or MDM restrictions that remove debugging features from managed users.
  • Treat Shizuku-compatible tooling as ADB-equivalent during threat modelling; it is a post-exploitation force multiplier even when the device is not rooted.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks