Shizuku Privilegovani API

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Shizuku je open-source servis koji pokreće privilegovani Java proces pomoću app_process i izlaže odabrane Android sistemske API-je preko Binder-a. Pošto proces radi sa istim shell UID capabilities koje ADB koristi, aplikacija koju je korisnik eksplicitno autorizovao može proslediti Binder pozive sistemskim servisima bez root pristupa uređaju.

U praksi, ovo znači da aplikacija sa podrškom za Shizuku često može koristiti iste primitive kao i adb shell: upravljanje paketima, appops, settings, cmd connectivity, prikupljanje logova i mnoge druge Binder transakcije dozvoljene shelom. I dalje nije root i i dalje je ograničena od strane Android dozvola, Linux UID provera, SELinux politike, Android verzije i OEM-specifičnih ograničenja.

Tipični slučajevi upotrebe:

  • Bezbednosni audit na uređaju bez root pristupa
  • Upravljanje paketima na uređaju, debloating i instalacija split-APK-ova
  • Prikupljanje logova, metapodataka paketa i stanja mreže/procesa vidljivog shel-u
  • Izrada PoC-ova ili pomoćnih alata kojima treba ADB-grade pristup, ali ne puna root eskalacija

1. Pokretanje privilegovanog servisa

moe.shizuku.privileged.api se može pokrenuti na tri različita načina. Binder interfejs izložen klijentskim aplikacijama je isti, ali efektivne privilegije zavise od toga da li backend radi pod ADB/shell ili root.

1.1 Wireless ADB (Android 11+)

  1. Omogući Developer Options -> Wireless debugging i upari uređaj.
  2. U Shizuku aplikaciji izaberi “Start via Wireless debugging”.
  3. Sesija traje dok se uređaj ne restartuje, osim ako OEM ROM ne isključi wireless debugging ili ne opozove autorizaciju za debugging.

1.2 USB / lokalni ADB one-liner

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

Isti skript se može izvršiti preko network ADB veze (adb connect <IP>:5555).

1.3 Rooted devices

Ako je uređaj već rooted, pokrenite:

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

1.4 OEM specifičnosti važne tokom testiranja

  • MIUI / HyperOS često zahteva USB debugging (Security settings) pored uobičajenog prekidača za USB debugging.
  • ColorOS / OxygenOS obično zahteva onemogućavanje Permission monitoring ili ekvivalentnih sigurnosnih omotača.
  • Na Android 11+, Disable adb authorization timeout smanjuje nasumične prekide rada Shizuku tokom dugih test sesija.
  • Ako wireless startup stalno ne uspeva, dozvoli Shizuku da radi u pozadini; nekoliko OEM ROMs obustavlja otkrivanje lokalne mreže kada je aplikacija u pozadini.

1.5 Verifying that it is running

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

Uspešan start vraća pokrenut servis i izlaže Binder servis povezan sa moe.shizuku.privileged.api.

2. Povezivanje iz aplikacije

Aplikacija omogućena za Shizuku does not use the raw Binder returned by Shizuku as if it were IPackageManager. Normalan tok je:

  1. dodajte dopuštenje za Shizuku API i ShizukuProvider,
  2. sačekajte da se pojavi Shizuku Binder,
  3. zatražite Shizuku autorizaciju u runtime stilu od korisnika,
  4. omotajte Binder ciljanog sistemskog servisa koristeći ShizukuBinderWrapper.

Zahtevi manifesta:

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

Minimalan primer Binder-wrapper:

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

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

Taj wrapper uzrokuje da Binder transakcije budu prosleđene procesom servisa Shizuku umesto da se izvrše sa uobičajenim UID pozivajuće aplikacije.

2.1 UserService: kada vam treba više od jednog Binder poziva

Za sve što je složenije od direktnih Binder transakcija, moderni razvoj Shizuku-a preferira UserService umesto starog newProcess helpera. A UserService pokreće your own Java/JNI code u zasebnom procesu kao UID 2000 (shell) kada je Shizuku pokrenut putem ADB-a ili UID 0 kada je podržan root-om.

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

Shizuku.bindUserService(args, conn);

Ovo je korisno za offenzivne alatke koje trebaju dugotrajno stanje, JNI pomoćnike ili ponovljene Binder operacije bez troška stalnog pokretanja shell komandi. Imajte na umu da servis nije normalan proces aplikacije: neke Context metode se ne ponašaju kao u običnoj Android aplikaciji.

2.2 Granice koje i dalje važe

  • ADB/shell i root su različiti nivoi privilegija. Shizuku.getUid() vraća 2000 za session-e podržane od strane shell-a i 0 za session-e podržane od strane root-a.
  • Shell dozvole se menjaju između Android izdanja i takođe mogu biti skraćene od strane OEM-a.
  • Shell i dalje ne može direktno čitati privatni sandbox druge aplikacije kao što je /data/user/0/<package>.
  • Ograničenja Hidden API-ja i dalje važe za kod koji se izvršava u normalnom procesu aplikacije; ako vam trebaju non-SDK interfejsi u velikoj meri, premestite logiku u UserService ili koristite namenski hidden-API bypass.

3. Rish - povišen shell u Termux-u

Ekran podešavanja Shizuku prikazuje “Koristi Shizuku u terminal aplikacijama”. Uključivanjem se preuzima rish, koji otvara udaljeni privilegovani shell podržan od strane 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

Koristan detalj za Termux-heavy workflowe: kada Shizuku radi kao ADB/shell, rish namerno ne čuva Termux-ovo okruženje podrazumevano zato što shell korisnik obično ne može da pristupi Termux-privatnim putanjama.

3.1 Korisne komande iz rish shell-a

  • Prikaži pokrenute procese određenog paketa:
ps -A | grep com.facebook.katana
  • Prikaži slušajuće sokete i mapiraj ih na pakete:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Ispiši logove svih aplikacija dostupne shell-u:
logcat -d | grep -iE "(error|exception)"
  • Masovno debloat (primer):
pm uninstall --user 0 com.miui.weather2
  • Pregledaj korisnike i raspored profila pre zloupotrebe multi-user okruženja:
pm list users
dumpsys user

3.2 Moderne šeme zloupotrebe omogućene Shizuku-om sa shell pristupom

AppOps i manipulacija specijalnim dozvolama

Menadžeri zasnovani na Shizuku, poput App Ops ili App Manager, u suštini enkapsuliraju shell-autorizovane appops i package-manager Binder pozive. Iz rish, ista primitiva se može koristiti direktno:

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

Ovo je korisno tokom pentests da se proveri da li aplikacija ili MDM agent zaista toleriše agresivnu AppOps manipulaciju bez potrebe za root.

Izolacija mreže po aplikaciji bez VPN-a ili root-a

Nedavne alatke zasnovane na Shizuku, poput ShizuWall, koriste chain-3 kontrole connectivity servisa da blokiraju mrežnu komunikaciju za odabrane pakete:

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

Za procene, ovo vam daje brz način da testirate kako ciljna aplikacija reaguje kada je konkurentski paket za bezbednost, telemetriju ili upravljanje selektivno isključen sa mreže dok ostatak uređaja ostaje online. Stanje se briše pri reboot-u.

Napredne instalacije na uređaju i split APK radni tokovi

Moderni Shizuku instaleri kao što su InstallWithOptions ili InstallerX-Revived koriste shell-backed PackageInstaller pristup da izvrše operacije koje su inače nezgrapne iz normalne aplikacije: split APK instalacije, pakete samo za test, grupne instalacije i neke Android 14 package-install flagove.

Sa stanovišta ofanzivnog testiranja, važan deo nije GUI već primitiv: Shizuku pretvara instalaciju paketa ponovo u akciju ovlašćenu shell-om na uređaju, što je korisno za testove persistencije, provere downgrade-a i brzo raspoređivanje pomoćnih payload-ova na uređaju bez root-a.

Work-profile i granice sekundarnog korisnika

Shell-backed Shizuku je i dalje podložan Android-ovim ograničenjima korisnika. Na upravljanim profilima ćete često naići na greške kao što su:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

Ako posebno testirate work-profile bypasses ili required-app replacement, smestite taj materijal na posvećenu stranicu umesto da ga duplirate ovde: Android Enterprise Work Profile Required-App Replacement

4. Bezbednosne napomene / detekcija

  1. Shizuku zahteva prvo ADB debugging ili root, pa na uređajima koji nisu rooted mora biti omogućeno Developer Options -> USB/Wireless debugging.
  2. Servis se registruje pod imenom moe.shizuku.privileged.api. adb shell service list | grep shizuku i adb shell dumpsys activity service moe.shizuku.privileged.api su pouzdane brze provere.
  3. Mogućnosti su ograničene na ono što trenutni backend ima. Na ADB-backed sesijama, to znači da je efektivna površina napada ona koju izlaže com.android.shell na toj Android verziji, plus ono što SELinux dozvoljava.
  4. Sesije ne prežive reboot osim ako uređaj nije rooted i Shizuku nije konfigurisan kao startup daemon.
  5. OEM “security” slojevi često naruše ili tiho smanje funkcionalnost Shizuku. Ako komanda radi preko direktnog adb shell ali ne radi kroz Shizuku, uporedite trenutni backend UID (Shizuku.getUid()), OEM debugging postavke i da li je uređaj ograničio shell dozvole.

5. Mitigacije

  • Onemogućite USB/Wireless debugging na proizvodnim uređajima.
  • Pratite Binder servise koji izlažu moe.shizuku.privileged.api.
  • Sprovodite work-profile ili MDM restrikcije koje uklanjaju debugging funkcije iz upravljanih profila.
  • Smatrajte Shizuku-compatible alate kao ADB-equivalent tokom threat modelling; to je post-exploitation faktor koji povećava mogućnosti čak i kada uređaj nije rooted.

Reference

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks