Shizuku Uprzywilejowane API

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Shizuku to otwartoźródłowa usługa, która uruchamia uprzywilejowany proces Java przy użyciu app_process i udostępnia wybrane API systemu Android przez Binder. Ponieważ proces działa z tymi samymi shell UID capabilities that ADB uses, aplikacja wyraźnie autoryzowana przez użytkownika może proxy’ować wywołania Binder do usług systemowych bez rootowania urządzenia.

W praktyce oznacza to, że aplikacja z obsługą Shizuku często może wykonywać te same operacje co adb shell: zarządzanie pakietami, appops, settings, cmd connectivity, zbieranie logów i wiele innych transakcji Binder dozwolonych dla shell. Nadal nie jest root i jest ograniczona przez uprawnienia Androida, sprawdzanie UID w Linux, politykę SELinux, wersję Androida oraz ograniczenia specyficzne dla OEM.

Typowe przypadki użycia:

  • Audyt bezpieczeństwa z nie-rootowanego urządzenia
  • Zarządzanie pakietami na urządzeniu, usuwanie bloatware i instalacja split-APK
  • Zbieranie logów, metadanych pakietów oraz stanu sieci/procesów widocznego z poziomu shell
  • Tworzenie PoCów lub narzędzi pomocniczych, które potrzebują dostępu klasy ADB-grade, ale nie pełnego łańcucha roota

1. Uruchamianie usługi uprzywilejowanej

moe.shizuku.privileged.api można uruchomić na trzy różne sposoby. Interfejs Binder udostępniany aplikacjom klienckim jest taki sam, ale efektywne uprawnienia zależą od tego, czy backend to ADB/shell czy root.

1.1 ADB bezprzewodowy (Android 11+)

  1. Włącz Developer Options -> Wireless debugging i sparuj urządzenie.
  2. W aplikacji Shizuku wybierz “Start via Wireless debugging”.
  3. Sesja przetrwa do restartu, chyba że ROM producenta wyłączy wireless debugging lub cofnie autoryzację debugowania.

1.2 USB / lokalne ADB one-liner

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

Ten sam skrypt można wykonać przez połączenie network ADB (adb connect <IP>:5555).

1.3 Rooted devices

Jeśli urządzenie jest już rooted, uruchom:

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

1.4 Dziwactwa OEM istotne podczas testów

  • MIUI / HyperOS często wymaga USB debugging (Security settings) oprócz zwykłego przełącznika USB debugging.
  • ColorOS / OxygenOS zwykle wymaga wyłączenia Permission monitoring lub równoważnych nakładek zabezpieczeń.
  • Na Androidzie 11+ wyłączenie Disable adb authorization timeout zmniejsza losowe zaniki Shizuku podczas długich sesji testowych.
  • Jeśli uruchamianie przez sieć bezprzewodową ciągle się nie udaje, pozwól Shizuku działać w tle; kilka ROM-ów OEM wstrzymuje wykrywanie sieci lokalnej, gdy aplikacja jest w tle.

1.5 Weryfikacja, czy działa

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

Pomyślne uruchomienie zwraca działającą usługę i udostępnia usługę Binder związaną z moe.shizuku.privileged.api.

2. Wiązanie z aplikacji

Aplikacja obsługująca Shizuku nie używa surowego Binder zwróconego przez Shizuku tak, jakby był IPackageManager. Typowy przebieg jest następujący:

  1. dodaj uprawnienie Shizuku API i ShizukuProvider,
  2. poczekaj na pojawienie się Bindera Shizuku,
  3. zażądaj od użytkownika autoryzacji w stylu runtime Shizuku,
  4. opakuj docelowy Binder usługi systemowej za pomocą ShizukuBinderWrapper.

Wymagania manifestu:

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

Minimalny przykład Binder-wrapper:

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

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

To właśnie ten wrapper powoduje, że transakcje Binder są przekazywane przez proces usługi Shizuku zamiast być wykonywane pod normalnym UID aplikacji wywołującej.

2.1 UserService: gdy potrzebujesz więcej niż jedno wywołanie Binder

Dla wszystkiego, co bardziej złożone niż bezpośrednie transakcje Binder, współczesny rozwój Shizuku preferuje UserService zamiast starego pomocnika newProcess. UserService uruchamia twój własny kod Java/JNI w osobnym procesie jako UID 2000 (shell) gdy Shizuku został uruchomiony przez ADB lub jako UID 0 gdy jest wspierany przez root.

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

Shizuku.bindUserService(args, conn);

To przydatne dla narzędzi ofensywnych, które potrzebują długotrwałego stanu, JNI helperów lub powtarzanych operacji Binder bez konieczności ciągłego uruchamiania poleceń shell. Pamiętaj, że serwis nie jest normalnym procesem aplikacji: niektóre metody Context nie zachowują się tak, jak wewnątrz zwykłej aplikacji Android.

2.2 Granice, które nadal obowiązują

  • ADB/shell i root to różne poziomy uprawnień. Shizuku.getUid() zwraca 2000 dla sesji wspieranych przez shell i 0 dla sesji wspieranych przez root.
  • Uprawnienia shell zmieniają się między wydaniami Androida i mogą być również ograniczane przez OEM.
  • Shell nadal nie może bezpośrednio odczytać prywatnego sandboxu innej aplikacji, takiego jak /data/user/0/<package>.
  • Ograniczenia Hidden API nadal dotyczą kodu uruchamianego w normalnym procesie aplikacji; jeśli potrzebujesz szerokiego użycia interfejsów non-SDK, przenieś logikę do UserService lub użyj dedykowanego hidden-API bypass.

3. Rish - podwyższony shell w Termux

Ekran ustawień Shizuku udostępnia opcję “Użyj Shizuku w aplikacjach terminalowych”. Włączenie jej pobiera rish, który otwiera zdalny uprzywilejowany shell obsługiwany przez 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

Przydatna uwaga dla przepływów pracy intensywnie używających Termux: gdy Shizuku działa jako ADB/shell, rish celowo nie zachowuje środowiska Termux domyślnie, ponieważ użytkownik shell zazwyczaj nie ma uprawnień do dostępu do prywatnych ścieżek Termux.

3.1 Przydatne polecenia z powłoki rish

  • Wypisz uruchomione procesy dla określonego pakietu:
ps -A | grep com.facebook.katana
  • Wyświetl nasłuchujące gniazda i powiąż je z pakietami:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Zrzut logów wszystkich aplikacji widocznych dla powłoki:
logcat -d | grep -iE "(error|exception)"
  • Hurtowe debloat (przykład):
pm uninstall --user 0 com.miui.weather2
  • Przeanalizuj użytkowników i układ profili przed nadużyciami w środowisku multi-user:
pm list users
dumpsys user

3.2 Nowoczesne wzorce nadużyć umożliwione przez Shizuku z obsługą shell

AppOps and special-permission tampering

Menedżery z obsługą Shizuku, takie jak App Ops czy App Manager, w istocie opakowują shell-autoryzowane wywołania appops i wywołania Binder menedżera pakietów. Z poziomu rish ten sam prymityw można wykorzystać bezpośrednio:

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

Jest to przydatne podczas pentests, aby sprawdzić, czy aplikacja lub agent MDM faktycznie toleruje agresywną manipulację AppOps bez konieczności użycia root.

Izolacja sieciowa dla poszczególnych aplikacji bez VPN ani root

Nowsze narzędzia oparte na Shizuku, takie jak ShizuWall, wykorzystują kontrole chain-3 serwisu connectivity do blokowania łączności dla wybranych pakietów:

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

Dla ocen daje to szybki sposób na sprawdzenie, jak docelowa aplikacja zachowuje się, gdy konkurencyjny pakiet zabezpieczeń, telemetry lub zarządzania jest selektywnie odcinany od sieci, podczas gdy reszta urządzenia pozostaje online. Stan jest czyszczony po ponownym uruchomieniu.

On-device advanced installs and split APK workflows

Nowoczesne instalery Shizuku, takie jak InstallWithOptions czy InstallerX-Revived, używają dostępu oparty na shellu do PackageInstaller, aby wykonać operacje, które z poziomu zwykłej aplikacji są niewygodne: instalacje split APK, pakiety tylko-do-testów, instalacje wsadowe oraz niektóre flagi instalacji pakietów w Android 14.

Z punktu widzenia testów ofensywnych ważna nie jest GUI, lecz prymityw: Shizuku przywraca instalację pakietów do działania autoryzowanego przez shell na urządzeniu, co jest przydatne do testów utrzymania dostępu, sprawdzeń downgrade’ów oraz szybkiego wdrażania pomocniczych payloadów na urządzeniu bez roota.

Work-profile and secondary-user boundaries

Shell-backed Shizuku wciąż podlega ograniczeniom użytkowników Androida. W managed profiles często napotkasz błędy takie jak:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

Jeśli konkretnie testujesz obejścia work-profile lub wymianę required-app, trzymaj ten materiał na dedykowanej stronie zamiast duplikować go tutaj: Android Enterprise Work Profile Required-App Replacement

4. Rozważania dotyczące bezpieczeństwa / wykrywanie

  1. Shizuku wymaga najpierw ADB debugging lub root, więc Developer Options -> USB/Wireless debugging musi być włączone na urządzeniach bez roota.
  2. Usługa rejestruje się pod nazwą moe.shizuku.privileged.api. adb shell service list | grep shizuku i adb shell dumpsys activity service moe.shizuku.privileged.api to wiarygodne, szybkie sposoby sprawdzenia.
  3. Możliwości są ograniczone do tego, co oferuje aktualny backend. W sesjach opartych na ADB oznacza to, że efektywna powierzchnia ataku to ta udostępniona procesowi com.android.shell na tej wersji Androida, plus to, co pozwala SELinux.
  4. Sesje nie przetrwają restartu, chyba że urządzenie ma root i Shizuku jest skonfigurowane jako demon startowy.
  5. Warstwy “bezpieczeństwa” producenta (OEM) często powodują awarie lub ciche ograniczenia funkcjonalności Shizuku. Jeśli polecenie działa przez bezpośrednie adb shell, ale nie przez Shizuku, porównaj aktualne UID backendu (Shizuku.getUid()), przełączniki debugowania OEM oraz czy urządzenie nie ograniczyło uprawnień shell.

5. Środki zaradcze

  • Wyłącz USB/Wireless debugging na urządzeniach produkcyjnych.
  • Monitoruj usługi Binder ujawniające moe.shizuku.privileged.api.
  • Wymuszaj ograniczenia work-profile lub MDM, które usuwają funkcje debugowania dla zarządzanych użytkowników.
  • Traktuj narzędzia zgodne z Shizuku jako ADB-equivalent podczas modelowania zagrożeń; to mnożnik siły post-exploitation nawet gdy urządzenie nie ma roota.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks