Shizuku Privileged 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 का समर्थन करें

Shizuku एक open-source service है जो app_process के साथ privileged Java process शुरू करती है और चयनित Android system APIs को Binder के माध्यम से एक्सपोज़ करती है। चूंकि यह process वही shell UID capabilities जो ADB उपयोग करता है के साथ चलता है, एक ऐसा app जिसे उपयोगकर्ता स्पष्ट रूप से अधिकृत करता है, वह system services को Binder कॉल्स का proxy कर सकता है बिना device को root किए।

व्यवहार में, इसका मतलब है कि एक Shizuku-enabled app अक्सर वही primitives का उपयोग कर सकता है जो adb shell देता है: package management, appops, settings, cmd connectivity, log collection, और कई अन्य shell-allowed Binder transactions। यह फिर भी root नहीं है और यह अभी भी Android permissions, Linux UID checks, SELinux policy, Android version, और OEM-specific restrictions द्वारा सीमित है।

Typical use cases:

  • बिना root वाले हैंडसेट पर सुरक्षा ऑडिटिंग
  • डिवाइस पर package management, debloating और split-APK installation
  • लॉग्स, package metadata और shell-visible network/process स्थिति इकट्ठा करना
  • ऐसे PoCs या सहायक टूलिंग बनाना जिन्हें ADB-grade access चाहिए लेकिन पूरा root chain नहीं चाहिए

1. प्रिविलेज्ड सर्विस शुरू करना

moe.shizuku.privileged.api को तीन अलग-अलग तरीकों से शुरू किया जा सकता है। client apps के लिए expose की गई Binder interface वही रहती है, लेकिन प्रभावी privilege इस बात पर निर्भर करता है कि backend ADB/shell है या root।

1.1 Wireless ADB (Android 11+)

  1. Developer Options -> Wireless debugging को सक्षम करें और डिवाइस को pair करें।
  2. Shizuku app के अंदर “Start via Wireless debugging” चुनें।
  3. यह session reboot तक रहता है जब तक कि OEM ROM wireless debugging को kill न कर दे या debugging authorisation revoke न कर दे।

1.2 USB / local ADB one-liner

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

एक ही स्क्रिप्ट को network ADB कनेक्शन (adb connect <IP>:5555) के ऊपर निष्पादित किया जा सकता है।

1.3 Rooted डिवाइस

यदि डिवाइस पहले से rooted है तो चलाएँ:

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

1.4 OEM quirks that matter during testing

  • MIUI / HyperOS अक्सर USB debugging (Security settings) की आवश्यकता होती है, सामान्य USB debugging टॉगल के अलावा।
  • ColorOS / OxygenOS में आम तौर पर Permission monitoring या समकक्ष सुरक्षा रैपर को निष्क्रिय करने की आवश्यकता होती है।
  • On Android 11+, Disable adb authorization timeout लंबे परीक्षण सत्रों के दौरान यादृच्छिक Shizuku लॉस को कम करता है।
  • यदि wireless startup बार-बार विफल हो रहा है, तो Shizuku को बैकग्राउंड में चलने दें; कई OEM ROMs ऐप बैकग्राउंड में होने पर local-network discovery को निलंबित कर देते हैं।

1.5 इसे चलने की पुष्टि करना

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. एप्लिकेशन से बाइंडिंग

Shizuku-सक्षम ऐप उस कच्चे Binder का उपयोग नहीं करती जो Shizuku द्वारा लौटाया गया हो, मानो वह IPackageManager हो। सामान्य प्रवाह इस प्रकार है:

  1. Shizuku API permission और ShizukuProvider जोड़ें,
  2. Shizuku Binder के प्रकट होने तक प्रतीक्षा करें,
  3. उपयोगकर्ता से Shizuku का रनटाइम-स्टाइल अनुमोदन अनुरोध करें,
  4. लक्षित system-service Binder को ShizukuBinderWrapper से रैप करें।

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"))
);
});

That wrapper वह चीज़ है जो Binder transactions को Shizuku service process द्वारा आगे भेजती है बजाय इसके कि वे caller app के सामान्य UID के साथ निष्पादित हों।

2.1 UserService: जब आपको एक ही Binder कॉल से अधिक की ज़रूरत हो

सीधे Binder transactions से अधिक जटिल किसी भी चीज़ के लिए, आधुनिक Shizuku विकास पुराने newProcess helper की बजाय UserService को प्राथमिकता देता है। एक UserService आपके अपने Java/JNI code को एक अलग process में UID 2000 (shell) के रूप में चलाता है जब Shizuku ADB के माध्यम से शुरू किया गया हो, या UID 0 के रूप में जब वह root द्वारा समर्थित हो।

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

Shizuku.bindUserService(args, conn);

यह offensive tooling के लिए उपयोगी है जिन्हें long-lived state, JNI helpers, या बार-बार होने वाले Binder operations की आवश्यकता होती है, और बार-बार shell commands spawn करने की लागत नहीं उठानी पड़ती। याद रखें कि यह service एक सामान्य ऐप प्रोसेस नहीं है: कुछ Context methods नियमित Android application के अंदर की तरह व्यवहार नहीं करते।

2.2 अभी भी लागू सीमाएँ

  • ADB/shell और root अलग privilege स्तर हैं। Shizuku.getUid() shell-backed sessions के लिए 2000 और root-backed sessions के लिए 0 लौटाता है।
  • Shell permissions Android releases के बीच बदलती हैं और OEMs इन्हें भी सीमित कर सकते हैं।
  • Shell अभी भी सीधे किसी अन्य ऐप के private sandbox को नहीं पढ़ सकता जैसे /data/user/0/<package>।
  • Hidden API restrictions अभी भी normal app process में चलने वाले code पर लागू होते हैं; अगर आपको non-SDK interfaces का व्यापक उपयोग करना है, तो logic को UserService में ले जाएँ या dedicated hidden-API bypass का उपयोग करें।

3. Rish - Termux के अंदर elevated shell

Shizuku settings screen पर “Use Shizuku in terminal apps” दिखाई देता है। इसे सक्षम करने पर rish डाउनलोड होता है, जो Shizuku द्वारा समर्थित एक remote privileged 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: जब Shizuku ADB/shell के रूप में चलता है, तो rish जानबूझकर डिफ़ॉल्ट रूप से Termux का environment संरक्षित करने से बचता है क्योंकि shell उपयोगकर्ता आमतौर पर Termux-private paths को traverse नहीं कर पाता।

3.1 Useful commands from the rish shell

  • किसी दिए गए package के चल रहे processes की सूची:
ps -A | grep com.facebook.katana
  • listening sockets की enumerate करके उन्हें packages से मैप करें:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • shell को एक्सपोज़ किए गए हर application’s logs को dump करें:
logcat -d | grep -iE "(error|exception)"
  • Bulk debloat (example):
pm uninstall --user 0 com.miui.weather2
  • multi-user abuse से पहले users और profile layout का निरीक्षण करें:
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 प्रभावी रूप से shell-authorised appops और package-manager Binder calls को wrap करते हैं। From rish, वही primitive सीधे इस्तेमाल किया जा सकता है:

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 के दौरान उपयोगी है यह सत्यापित करने के लिए कि कोई ऐप या MDM agent वास्तव में aggressive AppOps manipulation को बिना root की आवश्यकता के सहन करता है या नहीं।

प्रति-ऐप नेटवर्क अलगाव बिना VPN या root के

हाल के Shizuku-based tools जैसे ShizuWall चयनित पैकेजों के लिए नेटवर्किंग ब्लॉक करने के लिए connectivity service के chain-3 controls का उपयोग करते हैं:

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 पैकेज नेटवर्क से चयनात्मक रूप से काट दिया जाता है जबकि डिवाइस का बाकी हिस्सा ऑनलाइन रहता है। यह स्थिति reboot पर साफ़ हो जाती है।

On-device उन्नत इंस्टॉल और split APK workflows

आधुनिक Shizuku इंस्टॉलर जैसे InstallWithOptions या InstallerX-Revived शेल-समर्थित PackageInstaller एक्सेस का उपयोग करते हैं ताकि वे वे ऑपरेशन्स कर सकें जो एक सामान्य ऐप से करना अन्यथा अजीब होता है: split APK installs, test-only packages, batch installs, और कुछ 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, जो persistence tests, downgrade checks और non-rooted हैंडसेट पर helper payloads की तेज़ तैनाती के लिए उपयोगी है।

Work-profile and secondary-user boundaries

Shell-backed Shizuku अब भी Android के user restrictions के अधीन है। managed profiles पर अक्सर आपको निम्नलिखित errors मिलेंगे:

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 की आवश्यकता होती है, इसलिए Developer Options -> USB/Wireless debugging नॉन-rooted डिवाइस पर सक्षम होना चाहिए।
  2. सर्विस स्वयं को नाम moe.shizuku.privileged.api के तहत रजिस्टर करती है। adb shell service list | grep shizuku और adb shell dumpsys activity service moe.shizuku.privileged.api भरोसेमंद त्वरित जाँचें हैं।
  3. क्षमताएँ केवल वर्तमान backend के अनुसार सीमित होती हैं। ADB-backed सेशनों पर, इसका अर्थ है कि प्रभावी attack surface वही है जो उस Android build पर com.android.shell को एक्सपोज़ किया गया है, साथ ही जो कुछ भी SELinux अनुमति देता है।
  4. सत्र रीबूट के बाद बनी नहीं रहतीं जब तक डिवाइस rooted न हो और Shizuku को startup daemon के रूप में कॉन्फ़िगर न किया गया हो।
  5. OEM “security” लेयर्स अक्सर Shizuku की कार्यक्षमता को तोड़ देते हैं या चुपचाप कम कर देते हैं। यदि कोई कमांड सीधे adb shell से काम करती है पर Shizuku के माध्यम से फेल होती है, तो वर्तमान backend UID (Shizuku.getUid()), OEM debugging toggles, और यह देखें कि क्या डिवाइस ने shell permissions ट्रिम किए हैं।

5. रोकथाम

  • प्रोडक्शन डिवाइसों पर USB/Wireless debugging को अक्षम करें।
  • उन Binder सेवाओं की निगरानी करें जो moe.shizuku.privileged.api को एक्सपोज़ कर रही हों।
  • ऐसी work-profile या MDM प्रतिबंध लागू करें जो managed users से debugging सुविधाएँ हटा दें।
  • थ्रेट मॉडलिंग के दौरान Shizuku-compatible tooling को ADB-equivalent मानें; यह एक post-exploitation force multiplier है भले ही डिवाइस rooted न हो।

संदर्भ

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 का समर्थन करें