Shizuku Privileged API

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Shizuku is ’n oopbron-diens wat ’n bevoorregte Java-proses met app_process begin en geselekteerde Android-stelsel-API’s oor Binder blootstel. Omdat die proses met dieselfde shell UID-vermoëns wat ADB gebruik loop, kan ’n app wat uitdruklik deur die gebruiker gemagtig is Binder-oproepe na stelsel-dienste proxy sonder om die toestel te root.

In die praktyk beteken dit dat ’n Shizuku-gekoppelde app dikwels dieselfde primitives as adb shell kan gebruik: pakketbestuur, appops, settings, cmd connectivity, log-insameling, en baie ander Binder-transaksies wat deur die shell toegelaat word. Dit is steeds nie root nie en dit word steeds beperk deur Android-permissies, Linux UID-ondersoeke, SELinux-beleid, Android-weergawe, en OEM-spesifieke beperkings.

Tipiese gebruiksgevalle:

  • Sekuriteitsoudits vanaf ’n nie-geroote toestel
  • Pakketbestuur op die toestel, debloating en split-APK-installasie
  • Insameling van logs, pakket-metadata en netwerk-/prosesstatus wat deur die shell sigbaar is
  • Bou van PoCs of hulp-hulpmiddels wat ADB-grade toegang benodig maar nie ’n volledige root-ketting nie

1. Begin van die bevoorregte diens

moe.shizuku.privileged.api kan op drie verskillende maniere begin word. Die Binder-koppelvlak wat aan kliënt-apps blootgestel word is dieselfde, maar die effektiewe voorreg hang af of die backend ADB/shell of root is.

1.1 Wireless ADB (Android 11+)

  1. Skakel Ontwikkelaarsopsies -> Draadlose foutopsporing in en koppel die toestel.
  2. In die Shizuku-app kies “Begin via Draadlose foutopsporing”.
  3. Die sessie bly bestaan tot ’n herbegin, tensy die OEM-ROM draadlose foutopsporing beëindig of die foutopsporingsmagtiging intrek.

1.2 USB / local ADB one-liner

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

Dieselfde script kan oor ’n network ADB-verbinding uitgevoer word (adb connect <IP>:5555).

1.3 Rooted toestelle

As die toestel reeds rooted is, voer uit:

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

1.4 OEM-eienaardighede wat tydens toetsing saak maak

  • MIUI / HyperOS vereis dikwels USB debugging (Security settings) benewens die gewone USB debugging-skakelaar.
  • ColorOS / OxygenOS vereis gewoonlik die deaktivering van Permission monitoring of ekwivalente sekuriteitsomhulsels.
  • Op Android 11+, Disable adb authorization timeout verminder toevallige Shizuku-verlies tydens lang toetsessies.
  • As draadlose opstart aanhou misluk, laat Shizuku in die agtergrond loop; verskeie OEM ROMs skort plaaslike-netwerk-ontdekking op wanneer die app in die agtergrond is.

1.5 Verifieer dat dit aan die gang is

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

’n suksesvolle opstart gee ’n lopende diens terug en maak ’n Binder-diens beskikbaar wat verband hou met moe.shizuku.privileged.api.

2. Binding vanaf ’n toepassing

’n Shizuku-ingeskakelde toepassing gebruik nie die rou Binder wat deur Shizuku teruggegee word asof dit IPackageManager is nie. Die normale vloei is:

  1. voeg die Shizuku API-permissie en ShizukuProvider by,
  2. wag dat die Shizuku Binder verskyn,
  3. versoek Shizuku se runtime-agtige magtiging van die gebruiker,
  4. wikkel die teiken-stelsel-diens Binder met ShizukuBinderWrapper.

Manifest-vereistes:

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

Minimale Binder-wrapper voorbeeld:

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

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

Daardie wrapper veroorsaak dat Binder-transaksies deur die Shizuku-diensproses voorgestuur word in plaas daarvan om met die roepende toepassing se normale UID uitgevoer te word.

2.1 UserService: wanneer jy meer as ’n enkele Binder-aanroep nodig het

Vir enigiets meer kompleks as direkte Binder-transaksies, verkies moderne Shizuku-ontwikkeling UserService in plaas van die ou newProcess helper. ’n UserService voer jou eie Java/JNI code in ’n afsonderlike proses uit as UID 2000 (shell) wanneer Shizuku via ADB begin is of as UID 0 wanneer dit deur root gesteun word.

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

Shizuku.bindUserService(args, conn);

Dit is nuttig vir offensiewe tooling wat ’n langlewende toestand benodig, JNI helpers, of herhaalde Binder-operasies sonder om telkens die koste te betaal om shell-opdragte te spawn. Onthou dat die diens nie ’n normale app-proses is nie: sommige Context-metodes gedra hulle nie soos binne ’n gewone Android-toepassing nie.

2.2 Grense wat steeds van toepassing bly

  • ADB/shell en root is verskillende bevoegdheidsvlakke. Shizuku.getUid() gee 2000 vir shell-backed sessies en 0 vir root-backed sessies.
  • Shell-permissies verander tussen Android releases en kan ook deur OEMs ingekort word.
  • Shell kan steeds nie direk die private sandbox van ’n ander app lees nie, soos /data/user/0/<package>.
  • Hidden API-beperkings geld steeds vir kode wat in die normale app-proses loop; as jy intensief non-SDK interfaces benodig, skuif die logika na ’n UserService of gebruik ’n toegewyde hidden-API bypass.

3. Rish - verhoogde shell binne Termux

Die Shizuku-instellingskerm bied “Use Shizuku in terminal apps” aan. Deur dit te aktiveer word rish afgelaai, wat ’n afgeleë verhoogde shell oopmaak wat deur Shizuku gesteun word.

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 Nuttige opdragte vanaf die 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 Moderne misbruikpatrone moontlik gemaak deur shell-ondersteunde 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

Dit is nuttig tydens pentests om te verifieer of ’n app of MDM-agent werklik aggressiewe AppOps-manipulasie verdra sonder om root te benodig.

Per-app netwerk-isolasie sonder VPN of root

Onlangse Shizuku-gebaseerde gereedskap soos ShizuWall gebruik die connectivity diens se chain-3 beheer om netwerking vir geselekteerde pakkette te blokkeer:

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

Vir assessments gee dit jou ’n vinnige manier om te toets hoe ’n teiken-app optree wanneer ’n mededingende sekuriteit-, telemetrie- of bestuurspakket selektief van die netwerk afgesny word, terwyl die res van die toestel aanlyn bly. Die toestand word by herbegin gewist.

On-device advanced installs and split APK workflows

Moderne Shizuku-installeerders soos InstallWithOptions of InstallerX-Revived gebruik shell-backed PackageInstaller-toegang om operasies uit te voer wat andersins onhandig is vanuit ’n gewone app: split APK-installasies, test-only-pakkette, bondelinstallasies, en sommige Android 14 package-install vlae.

Vanuit ’n offensiewe-toetsing oogpunt is die belangrike deel nie die GUI nie maar die primitief: Shizuku maak pakketinstallasie weer ’n op-toestel shell-geauthoriseerde aksie, wat nuttig is vir persistence-toetse, downgrade-kontroles en vinnige ontplooiing van helper payloads op ’n non-rooted handset.

Work-profile and secondary-user boundaries

Shell-backed Shizuku is nog steeds onderhewig aan Android se gebruikersbeperkings. Op bestuurde profiele sal jy dikwels foute raakloop soos:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

If you is spesifiek besig om work-profile bypasses of required-app replacement te toets, hou daardie materiaal op die toegewyde blad in plaas daarvan om dit hier te dupliseer: Android Enterprise Work Profile Required-App Replacement

4. Sekuriteitsaspekte / opsporing

  1. Shizuku benodig eers ADB debugging of root, dus Developer Options -> USB/Wireless debugging moet geaktiveer wees op nie-rooted toestelle.
  2. Die diens registreer homself onder die naam moe.shizuku.privileged.api. adb shell service list | grep shizuku en adb shell dumpsys activity service moe.shizuku.privileged.api is betroubare vinnige kontroles.
  3. Vermoëns is beperk tot wat die huidige backend het. Op ADB-backed sessions beteken dit die effektiewe aanvaloppervlak is dié wat aan com.android.shell op daardie Android build blootgestel word, plus wat ook al SELinux toelaat.
  4. Sessions oorleef nie ’n reboot tensy die toestel rooted is en Shizuku gekonfigureer is as ’n startup daemon.
  5. OEM “security” lae breek dikwels of verminder stilweg Shizuku funksionaliteit. As ’n opdrag werk via direkte adb shell maar faal deur Shizuku, vergelyk die huidige backend UID (Shizuku.getUid()), OEM debugging toggles, en of die toestel shell-permissies getrim het.

5. Mitigasie

  • Deaktiveer USB/Wireless debugging op produksietoestelle.
  • Monitor vir Binder services wat moe.shizuku.privileged.api blootstel.
  • Handhaaf work-profile of MDM beperkings wat debugging features van bestuurde gebruikers verwyder.
  • Behandel Shizuku-kompatibele tooling as ADB-equivalent tydens threat modelling; dit is ’n post-exploitation krachtvermenigvuldiger selfs wanneer die toestel nie rooted is nie.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks