Shizuku API με προνόμια

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Το Shizuku είναι μια open-source υπηρεσία που ξεκινά μια privileged Java διεργασία με app_process και εκθέτει επιλεγμένα Android system APIs μέσω Binder. Επειδή η διεργασία τρέχει με τις ίδιες shell UID δυνατότητες που χρησιμοποιεί το ADB, μια εφαρμογή που έχει ρητά εξουσιοδοτηθεί από τον χρήστη μπορεί να προωθήσει κλήσεις Binder προς system services χωρίς να γίνει rooting της συσκευής.

Στην πράξη, αυτό σημαίνει ότι μια εφαρμογή με Shizuku συχνά μπορεί να χρησιμοποιήσει τα ίδια primitives με το adb shell: package management, appops, settings, cmd connectivity, συλλογή logs, και πολλές άλλες Binder συναλλαγές που επιτρέπονται στο shell. Δεν έχει ακόμη root και εξακολουθεί να περιορίζεται από Android permissions, Linux UID checks, SELinux policy, Android version, και περιορισμούς ειδικούς του OEM.

Τυπικές χρήσεις:

  • Έλεγχος ασφάλειας από συσκευή χωρίς root
  • Διαχείριση πακέτων επί της συσκευής, debloating και εγκατάσταση split-APK
  • Συλλογή logs, metadata πακέτων και κατάστασης δικτύου/διεργασιών ορατής από το shell
  • Κατασκευή PoCs ή βοηθητικών εργαλείων που χρειάζονται ADB-grade πρόσβαση αλλά όχι πλήρη root chain

1. Εκκίνηση της υπηρεσίας με προνόμια

moe.shizuku.privileged.api μπορεί να ξεκινήσει με τρεις διαφορετικούς τρόπους. Η Binder διεπαφή που εκτίθεται στις client εφαρμογές είναι η ίδια, αλλά το πραγματικό προνόμιο εξαρτάται από το αν το backend είναι ADB/shell ή root.

1.1 Ασύρματο ADB (Android 11+)

  1. Ενεργοποιήστε Developer Options -> Wireless debugging και κάντε pairing της συσκευής.
  2. Μέσα στην εφαρμογή Shizuku επιλέξτε “Start via Wireless debugging”.
  3. Η συνεδρία διαρκεί μέχρι reboot εκτός κι αν το OEM ROM τερματίσει το wireless debugging ή ανακαλέσει την εξουσιοδότηση debugging.

1.2 USB / local ADB one-liner

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

Το ίδιο script μπορεί να εκτελεστεί μέσω σύνδεσης network ADB (adb connect <IP>:5555).

1.3 Συσκευές με root

Αν η συσκευή είναι ήδη 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 ή ισοδύναμων security wrappers.
  • Σε Android 11+, η επιλογή Disable adb authorization timeout μειώνει την τυχαία απώλεια του Shizuku κατά τη διάρκεια μεγάλων συνεδριών δοκιμών.
  • Αν η ασύρματη εκκίνηση συνεχίζει να αποτυγχάνει, επιτρέψτε στο Shizuku να τρέχει στο παρασκήνιο· αρκετά OEM ROMs αναστέλλουν την ανίχνευση τοπικού δικτύου όταν η εφαρμογή βρίσκεται στο παρασκήνιο.

1.5 Verifying that it is running

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

Μια επιτυχημένη εκκίνηση επιστρέφει μια ενεργή υπηρεσία και εκθέτει μια υπηρεσία Binder σχετική με moe.shizuku.privileged.api.


2. Σύνδεση από μια εφαρμογή

Μια εφαρμογή με Shizuku δεν χρησιμοποιεί τον ακατέργαστο Binder που επιστρέφει το Shizuku σαν να ήταν IPackageManager. Η κανονική ροή είναι:

  1. προσθέστε το Shizuku API permission και ShizukuProvider,
  2. περιμένετε να εμφανιστεί ο Shizuku Binder,
  3. ζητήστε από τον χρήστη την runtime-style authorisation του Shizuku,
  4. τυλίξτε τον target 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 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

Για οτιδήποτε πιο σύνθετο από απευθείας Binder transactions, η σύγχρονη ανάπτυξη Shizuku προτιμά το UserService αντί του παλιού helper newProcess. Ένα UserService τρέχει your own Java/JNI code σε ξεχωριστή διαδικασία ως 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);

Αυτό είναι χρήσιμο για επιθετικά εργαλεία που χρειάζονται μακροχρόνια κατάσταση, JNI helpers, ή επαναλαμβανόμενες Binder operations χωρίς να χρειάζεται να εκκινείτε συνεχώς εντολές shell. Θυμηθείτε ότι η υπηρεσία δεν είναι μια κανονική διαδικασία εφαρμογής: μερικές Context μέθοδοι δεν συμπεριφέρονται όπως μέσα σε μια κανονική Android εφαρμογή.

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 - προνομιακό shell μέσα στο 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

Χρήσιμη λεπτομέρεια για ροές εργασίας με έντονη χρήση του Termux: όταν το Shizuku τρέχει ως ADB/shell, το rish αποφεύγει σκόπιμα να διατηρεί το περιβάλλον του Termux από προεπιλογή επειδή ο χρήστης shell συνήθως δεν μπορεί να διασχίσει διαδρομές ιδιωτικές του Termux.

3.1 Χρήσιμες εντολές από το shell rish

  • Λίστα διεργασιών σε εκτέλεση για ένα δεδομένο πακέτο:
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)"
  • Μαζικό debloat (παράδειγμα):
pm uninstall --user 0 com.miui.weather2
  • Επιθεώρηση χρηστών και διάταξης προφίλ πριν από κατάχρηση σε περιβάλλον πολλαπλών χρηστών:
pm list users
dumpsys user

3.2 Σύγχρονα πρότυπα κατάχρησης που ενεργοποιούνται από το Shizuku με υποστήριξη shell

AppOps και παραποίηση ειδικών αδειών

Διαχειριστές που ενεργοποιούνται από Shizuku, όπως το App Ops ή το App Manager, ουσιαστικά τυλίγουν κλήσεις appops εξουσιοδοτημένες από το shell και κλήσεις Binder του package-manager. Από το rish, η ίδια βασική λειτουργία μπορεί να χρησιμοποιηθεί απευθείας:

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 αντέχει πραγματικά επιθετική χειραγώγηση των 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

Για αξιολογήσεις, αυτό σου δίνει έναν γρήγορο τρόπο να δοκιμάσεις πώς συμπεριφέρεται μια στοχευμένη εφαρμογή όταν ένα ανταγωνιστικό πακέτο ασφάλειας, τηλεμετρίας ή διαχείρισης αποκόπτεται επιλεκτικά από το δίκτυο ενώ το υπόλοιπο της συσκευής παραμένει online. Η κατάσταση διαγράφεται μετά από επανεκκίνηση.

On-device advanced installs and split APK workflows

Σύγχρονοι installers του Shizuku όπως οι InstallWithOptions ή InstallerX-Revived χρησιμοποιούν πρόσβαση shell-backed PackageInstaller για να εκτελέσουν ενέργειες που διαφορετικά είναι δύσχρηστες από μια κανονική εφαρμογή: split APK installs, test-only packages, batch installs, και μερικά Android 14 package-install flags.

Από την άποψη του offensive-testing, το σημαντικό μέρος δεν είναι το GUI αλλά το primitive: Shizuku turns package installation back into an on-device shell-authorised action, το οποίο είναι χρήσιμο για persistence tests, downgrade checks και ταχεία ανάπτυξη βοηθητικών payloads σε μη-rooted συσκευή.

Work-profile and secondary-user boundaries

Το shell-backed Shizuku εξακολουθεί να υπόκειται στους περιορισμούς χρηστών του Android. Σε διαχειριζόμενα προφίλ συχνά θα συναντήσεις σφάλματα όπως:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

Αν δοκιμάζετε συγκεκριμένα work-profile bypasses ή required-app replacement, διατηρήστε αυτό το υλικό στη σχετική σελίδα αντί να το αναπαράγετε εδώ: Android Enterprise Work Profile Required-App Replacement


4. Επισημάνσεις ασφάλειας / ανίχνευση

  1. Το Shizuku χρειάζεται πρώτα ADB debugging ή root, οπότε Developer Options -> USB/Wireless debugging πρέπει να είναι ενεργοποιημένο σε συσκευές χωρίς root.
  2. Η υπηρεσία καταχωρείται με το όνομα moe.shizuku.privileged.api. adb shell service list | grep shizuku και adb shell dumpsys activity service moe.shizuku.privileged.api είναι αξιόπιστοι γρήγοροι έλεγχοι.
  3. Οι δυνατότητες περιορίζονται σε όσα παρέχει ο τρέχων backend. Σε συνεδρίες με ADB-backed sessions, αυτό σημαίνει ότι η πραγματική επιφάνεια επίθεσης είναι αυτή που εκτίθεται στο com.android.shell σε εκείνη την έκδοση Android, συν όσα επιτρέπει το SELinux.
  4. Οι συνεδρίες δεν επιβιώνουν μετά από επανεκκίνηση, εκτός αν η συσκευή είναι rooted και το Shizuku έχει ρυθμιστεί ως startup daemon.
  5. Τα OEM “security” επίπεδα συχνά σπάνε ή μειώνουν σιωπηρά τη λειτουργικότητα του Shizuku. Αν μια εντολή λειτουργεί μέσω απευθείας adb shell αλλά αποτυγχάνει μέσω Shizuku, συγκρίνετε το τρέχον backend UID (Shizuku.getUid()), τους διακόπτες OEM debugging, και αν η συσκευή περιόρισε τα δικαιώματα του shell.

5. Μετριασμός

  • Απενεργοποιήστε το USB/Wireless debugging σε συσκευές παραγωγής.
  • Παρακολουθείτε για Binder services που εκθέτουν moe.shizuku.privileged.api.
  • Εφαρμόστε περιορισμούς work-profile ή MDM που αφαιρούν τις δυνατότητες debugging από διαχειριζόμενους χρήστες.
  • Θεωρήστε τα Shizuku-compatible εργαλεία ως ADB-equivalent κατά το threat modelling· είναι πολλαπλασιαστής ισχύος post-exploitation ακόμη και όταν η συσκευή δεν είναι rooted.

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks