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グループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

Shizuku はオープンソースのサービスで、app_process で特権付きの Java プロセスを起動し、選択された Android のシステム API を Binder 経由で公開します。
このプロセスは ADB が使用するのと同じ shell UID 権限 で実行されるため、ユーザーに明示的に許可されたアプリは Binder 呼び出しをシステムサービスにプロキシし、デバイスを root せずに 実行できます。

実務的には、Shizuku 対応アプリは多くの場合 adb shell と同じプリミティブを利用できます: package management、appops、settings、cmd connectivity、ログ収集、その他多くの shell に許可された Binder トランザクション。なお、これはあくまで root ではない ため、Android permissions, Linux UID checks, SELinux policy, Android version, and OEM-specific restrictions によって制約されます。

典型的なユースケース:

• root化されていない端末からのセキュリティ監査
• デバイス上でのパッケージ管理、debloating、split-APK のインストール
• ログ、パッケージメタデータ、shell から見えるネットワーク/プロセス状態の収集
• フル root チェーンを必要としない、ADB-grade なアクセスを必要とする PoC やヘルパーツールの構築

1. 特権サービスの起動

moe.shizuku.privileged.api は3つの方法で起動できます。クライアントアプリに公開される Binder インターフェースは同じですが、実際の権限はバックエンドが ADB/shell か root かによって異なります。

1.1 ワイヤレス ADB (Android 11+)

1. Developer Options -> Wireless debugging を有効にし、デバイスをペアリングします。
2. Shizuku アプリ内で “Start via Wireless debugging” を選択します。
3. OEM ROM が wireless debugging を停止するかデバッグ許可を取り消さない限り、セッションは再起動まで持続します。

1.2 USB / ローカル ADB ワンライナー

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

同じスクリプトはネットワーク ADB接続（adb connect <IP>:5555）でも実行できます。

1.3 Rooted デバイス

デバイスが既に rooted の場合は、次を実行:

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

1.4 テスト中に重要となる OEM 固有の挙動

• MIUI / HyperOS では、通常の USB デバッグ トグルに加えて USB debugging (Security settings) が必要になることが多い。
• ColorOS / OxygenOS では、一般に Permission monitoring や同等のセキュリティラッパーを無効にする必要があることが多い。
• Android 11+ では、Disable adb authorization timeout を設定すると長時間のテスト中に発生する Shizuku のランダムな切断を減らせる。
• ワイヤレス起動が繰り返し失敗する場合は、Shizuku をバックグラウンドで実行できるようにする。いくつかの OEM ROM はアプリがバックグラウンドに回ると local-network discovery を停止する。

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. ターゲットのシステムサービス Binder を 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" />

最小限の 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 トランザクションを呼び出し元アプリの通常の UID で実行するのではなく、Shizuku サービスプロセスに転送させる原因です。

2.1 UserService: 単一の Binder 呼び出しだけでは足りないとき

直接的な Binder トランザクションより複雑な処理が必要な場合、現在の Shizuku 開発では古い newProcess ヘルパーの代わりに UserService を推奨します。UserService は、Shizuku が ADB 経由で起動された場合は別プロセスで your own Java/JNI code を 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);

これは、長期間の状態を保持する必要がある offensive tooling、JNI ヘルパー、または毎回シェルコマンドを起動するコストを払わずに繰り返し Binder 操作を行うツールに有用です。サービスは not a normal app process であることを忘れないでください: 一部の Context メソッドは通常の Android アプリ内での挙動とは異なります。

2.2 それでも適用される境界

• ADB/shell and root は異なる権限レベルです。 Shizuku.getUid() は shell-backed sessions で 2000 を、root-backed sessions で 0 を返します。
• Shell permissions は Android リリース間で変化 し、OEM によって制限されることもあります。
• Shell は依然として他のアプリのプライベートサンドボックス（例: /data/user/0/<package>）を直接読み取ることはできません。
• Hidden API restrictions は通常のアプリプロセスで動作するコードにも引き続き適用されます；non-SDK インターフェイスを多用する必要がある場合は、ロジックを UserService に移すか、専用の hidden-API bypass を使用してください。

3. Rish - Termux 内の昇格されたシェル

Shizuku の設定画面には 「端末アプリで Shizuku を使用」 のオプションがあります。これを有効にすると rish がダウンロードされ、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

これはpentests中に、appやMDM agentが実際に攻撃的なAppOps操作をrootを必要とせずに許容するかどうかを検証するのに有用です。

アプリごとのネットワーク隔離（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

評価では、これはターゲットアプリが、デバイスの他の部分はオンラインのままの状態で競合する security、telemetry、または management package がネットワークから選択的に切断されたときにどのように振る舞うかを素早くテストする方法を提供します。状態は再起動でクリアされます。

On-device advanced installs and split APK workflows

最近の Shizuku インストーラ（InstallWithOptions や InstallerX-Revived など）は、shell-backed PackageInstaller アクセスを用いて、通常のアプリからは扱いづらい操作を行います: split APK installs、test-only packages、batch installs、および一部の Android 14 package-install flags。

攻撃的テストの観点からは、重要なのは GUI ではなくプリミティブです: Shizuku は package installation をデバイス上での shell 承認アクションに戻します。これは非-root ハンドセット上での persistence tests、downgrade checks、および helper payloads の迅速な展開に有用です。

Work-profile and secondary-user boundaries

Shell-backed Shizuku は引き続き Android のユーザー制限の対象です。managed profiles では、次のようなエラーに頻繁に遭遇します:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

もし特に work-profile のバイパスや required-app の置き換えをテストしている場合、その内容はここに重複して記載せず、専用ページにまとめてください: Android Enterprise Work Profile Required-App Replacement

4. Security considerations / detection

1. Shizuku は最初に ADB debugging または root を必要とするため、非 root デバイスでは Developer Options -> USB/Wireless debugging を有効にする必要があります。
2. サービスは moe.shizuku.privileged.api という名前で登録されます。 adb shell service list | grep shizuku と adb shell dumpsys activity service moe.shizuku.privileged.api は信頼できる簡易チェックです。
3. 機能は現在のバックエンドが持つ権限に限定されます。ADB バックエンドのセッションでは、実質的な攻撃面はその Android ビルド上で com.android.shell に公開されているものと、SELinux が許可する範囲に相当します。
4. デバイスが root になっておらず Shizuku が起動時デーモンとして構成されていない限り、セッションは再起動で持続しません。
5. OEM の「セキュリティ」レイヤはしばしば Shizuku の機能を壊したり黙って制限したりします。直接 adb shell では動作するコマンドが Shizuku 経由で失敗する場合は、現在のバックエンド UID（Shizuku.getUid()）、OEM のデバッグ設定、デバイスが shell の権限を削減していないかを比較してください。

5. Mitigation

• 本番デバイスで USB/Wireless debugging を無効にする。
• moe.shizuku.privileged.api を公開している Binder サービスを監視する。
• 管理ユーザからデバッグ機能を削除するよう、work-profile や MDM の制限を強制する。
• Shizuku 対応ツールは脅威モデリング時に ADB-equivalent と見なすこと；デバイスが root でない場合でも、ポストエクスプロイトのフォースマルチプライヤになります。

References

• 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グループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。