Shizuku 特权 API

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

• 查看 订阅计划!
• 加入 💬 Discord 群组 或 Telegram 群组 或 在 Twitter 🐦 上关注我们 @hacktricks_live.
• 通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

Shizuku 是一个开源服务，通过 app_process 启动一个特权 Java 进程，并通过 Binder 暴露选定的 Android 系统 API。 因为该进程以与 ADB 使用的 shell UID 能力 相同的权限运行，用户显式授权的应用可以代理 Binder 调用到系统服务，无需将设备 root。

实际上，这意味着启用 Shizuku 的应用通常可以行使与 adb shell 相同的基本操作：包管理、appops、settings、cmd connectivity、日志收集，以及许多其他 shell 允许的 Binder 事务。它仍然不是 root，并且仍受 Android 权限、Linux UID 检查、SELinux 策略、Android 版本和 OEM 特定限制 的约束。

典型用例：

• 在未 root 的手机上进行安全审计
• 设备端包管理、debloating（精简）和 split-APK 安装
• 收集日志、包元数据以及 shell 可见的网络/进程状态
• 构建需要 ADB 级别 访问但不需要完整 root 链的 PoCs 或辅助工具

1. 启动特权服务

moe.shizuku.privileged.api 可以通过三种不同方式启动。向客户端应用暴露的 Binder 接口相同，但实际生效的特权取决于后端是 ADB/shell 还是 root。

1.1 Wireless ADB (Android 11+)

1. 启用 开发者选项 -> 无线调试 并配对设备。
2. 在 Shizuku 应用内选择 “通过无线调试启动”。
3. 会话会持续到重启，除非 OEM ROM 终止无线调试或撤销调试授权。

1.2 USB / 本地 ADB 单行命令

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

相同的脚本可以通过网络 ADB连接执行（adb connect <IP>:5555）。

1.3 Rooted devices

如果设备已经 rooted，请运行：

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

1.4 在测试时需要注意的 OEM 特性

• MIUI / HyperOS 通常除了常规的 USB debugging 切换外，还需要 USB debugging (Security settings)。
• ColorOS / OxygenOS 通常需要禁用 Permission monitoring 或等效的安全保护层。
• 在 Android 11+ 上，Disable adb authorization timeout 可减少长时间测试期间随机 Shizuku 丢失。
• 如果无线启动持续失败，请允许 Shizuku 在后台运行；一些 OEM ROM 会在应用被置于后台时暂停本地网络发现。

1.5 验证其是否正在运行

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

成功启动会返回一个正在运行的服务并暴露与 moe.shizuku.privileged.api 相关的 Binder 服务。

2. 在应用中绑定

启用 Shizuku 的应用 不会 将 Shizuku 返回的原始 Binder 当作 IPackageManager 来使用。正常流程为：

1. 添加 Shizuku API 权限和 ShizukuProvider，
2. 等待 Shizuku Binder 出现，
3. 向用户请求 Shizuku 的运行时风格授权，
4. 使用 ShizukuBinderWrapper 封装目标系统服务的 Binder。

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

最小的 Binder-wrapper 示例:

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

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

该包装器会导致 Binder 事务由 Shizuku 服务进程转发执行，而不是以调用方应用的正常 UID 执行。

2.1 UserService: 当你需要不止一次 Binder 调用时

对于比直接 Binder 事务更复杂的任何情况，现代 Shizuku 开发更倾向使用 UserService 而不是旧的 newProcess helper。UserService 会在单独的进程中运行 你自己的 Java/JNI 代码，当 Shizuku 通过 ADB 启动时以 UID 2000 (shell) 运行，或在由 root 支持时以 UID 0 运行。

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

Shizuku.bindUserService(args, conn);

这对需要长期状态、JNI helpers，或反复进行 Binder 操作而不想一遍又一遍地生成 shell 命令的 offensive tooling 很有用。请记住该服务不是一个普通的应用进程：某些 Context 方法在此处的行为与常规 Android 应用内不同。

2.2 仍然适用的限制

• ADB/shell 和 root 是不同的权限级别。 Shizuku.getUid() 在由 shell 支持的会话返回 2000，在由 root 支持的会话返回 0。
• Shell 权限会在不同 Android 版本之间发生变化，并且可能被 OEMs 裁剪。
• Shell 仍然无法直接读取其他应用的私有沙箱，例如 /data/user/0/<package>。
• 隐藏 API 的限制仍然适用于在普通应用进程中运行的代码；如果需要大量使用 non-SDK 接口，请将逻辑移入 UserService 或使用专用的 hidden-API bypass。

3. Rish - 在 Termux 内的提权 shell

Shizuku 的设置界面提供了 “Use Shizuku in terminal apps”。启用后会下载 rish，rish 会打开一个由 Shizuku 支持的远程特权 shell。

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 来自 rish shell 的有用命令

• 列出给定包的运行进程：

ps -A | grep com.facebook.katana

• 枚举监听套接字并将它们映射到包：

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

• 导出暴露给 shell 的每个应用的日志：

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

• 批量精简（示例）：

pm uninstall --user 0 com.miui.weather2

• 在进行多用户滥用之前检查用户和配置文件布局：

pm list users
dumpsys user

3.2 由 shell 支持的 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

这在 pentests 中很有用，用于验证某个 app 或 MDM agent 是否在不需要 root 的情况下真正容忍激进的 AppOps 操作。

按应用的网络隔离（无需 VPN 或 root）

最近基于 Shizuku 的工具，例如 ShizuWall，使用 connectivity 服务的 chain-3 控制来阻止选定包的网络访问：

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

在评估时，这为你提供了一种快速方法，测试目标应用在竞争的安全、遥测或管理包被选择性地从网络中切断而设备其余部分保持在线时的行为。状态会在重启时清除。

设备上高级安装与 split APK 工作流

现代的 Shizuku 安装器（例如 InstallWithOptions 或 InstallerX-Revived）使用基于 shell 的 PackageInstaller 访问来执行普通应用难以完成的操作：split APK 安装、仅测试包、批量安装，以及某些 Android 14 的 package-install 标志。

从 offensive-testing 的角度来看，重要的不是 GUI，而是原语：Shizuku 将包安装转换回设备上由 shell 授权的操作，这对于持久性测试、降级检查以及在非 root 的手机上快速部署辅助 payload 很有用。

Work-profile 和 secondary-user 边界

基于 shell 的 Shizuku 仍然受 Android 的用户限制。在 managed profiles 上你常常会遇到如下错误：

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. 安全注意事项 / 检测

1. Shizuku 需要先获得 ADB debugging 或 root，因此在未 root 的设备上必须在 Developer Options -> USB/Wireless debugging 中启用该选项。
2. 该 service 在 Binder 下注册名为 moe.shizuku.privileged.api。adb shell service list | grep shizuku 和 adb shell dumpsys activity service moe.shizuku.privileged.api 是可靠的快速检查方法。
3. 功能受限于当前 backend 所提供的权限。在 ADB-backed 会话中，这意味着有效攻击面是该 Android 构建中对 com.android.shell 暴露的权限，再加上 SELinux 允许的部分。
4. 会话在重启后不会保留，除非设备已 rooted 且 Shizuku 被配置为启动时的 daemon。
5. OEM 的“security”层常常会破坏或静默地限制 Shizuku 的功能。如果某个命令在直接使用 adb shell 时可行但通过 Shizuku 失败，请比较当前 backend 的 UID（Shizuku.getUid()）、OEM 的 debugging 开关，以及设备是否裁剪了 shell 的权限。

5. 缓解措施

• 在生产设备上禁用 USB/Wireless debugging。
• 监控暴露 moe.shizuku.privileged.api 的 Binder 服务。
• 强制实施 work-profile 或 MDM 限制，从受管理用户中移除调试功能。
• 在进行威胁建模时，将与 Shizuku 兼容的工具视为 ADB-equivalent；它即使在设备未 rooted 时也会成为一种 post-exploitation 的放大器。

参考资料

• Shizuku Official Documentation
• Shizuku-API Developer Guide
• awesome-shizuku - list of supported apps

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

• 查看 订阅计划!
• 加入 💬 Discord 群组 或 Telegram 群组 或 在 Twitter 🐦 上关注我们 @hacktricks_live.
• 通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。