API privilegiata di Shizuku

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Shizuku è un servizio open-source che avvia un processo Java privilegiato con app_process ed espone selezionate API di sistema Android via Binder. Poiché il processo gira con le stesse capabilities UID shell che usa ADB, un’app autorizzata esplicitamente dall’utente può inoltrare le chiamate Binder ai servizi di sistema senza effettuare il root del dispositivo.

In pratica, questo significa che un’app abilitata a Shizuku può spesso utilizzare gli stessi primitivi di adb shell: gestione dei package, appops, settings, cmd connectivity, raccolta dei log e molte altre transazioni Binder permesse alla shell. Non è comunque root e rimane vincolata da permessi Android, controlli UID Linux, policy SELinux, versione di Android e restrizioni specifiche OEM.

Esempi d’uso tipici:

  • Audit di sicurezza da un dispositivo non rootato
  • Gestione dei package sul dispositivo, debloating e installazione di split-APK
  • Raccolta di log, metadati dei package e stato di rete/processo visibile alla shell
  • Sviluppo di PoC o strumenti di supporto che necessitano di accesso di livello ADB ma non di una catena di root completa

1. Avviare il servizio privilegiato

moe.shizuku.privileged.api può essere avviato in tre modi diversi. L’interfaccia Binder esposta alle app client è la stessa, ma il privilegio effettivo dipende dal backend: ADB/shell oppure root.

1.1 Wireless ADB (Android 11+)

  1. Abilitare Opzioni sviluppatore -> Wireless debugging e associare il dispositivo.
  2. Nell’app Shizuku selezionare “Start via Wireless debugging”.
  3. La sessione sopravvive fino al riavvio a meno che la ROM OEM non disattivi il wireless debugging o non revochi l’autorizzazione al debugging.

1.2 USB / local ADB one-liner

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

Lo stesso script può essere eseguito tramite una connessione network ADB (adb connect <IP>:5555).

1.3 Rooted devices

Se il dispositivo è già rooted, esegui:

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

1.4 Particolarità OEM rilevanti durante i test

  • MIUI / HyperOS spesso richiede USB debugging (Security settings) oltre al normale toggle di USB debugging.
  • ColorOS / OxygenOS comunemente richiede di disabilitare Permission monitoring o wrapper di sicurezza equivalenti.
  • Su Android 11+, Disable adb authorization timeout riduce le perdite casuali di Shizuku durante lunghe sessioni di test.
  • Se l’avvio wireless continua a fallire, consenti a Shizuku di funzionare in background; diverse ROM OEM sospendono la local-network discovery quando l’app è in background.

1.5 Verificare che sia in esecuzione

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

Un avvio riuscito restituisce un servizio in esecuzione ed espone un Binder relativo a moe.shizuku.privileged.api.

2. Binding da un’applicazione

Un’app compatibile con Shizuku non usa il Binder grezzo restituito da Shizuku come se fosse IPackageManager. Il flusso normale è:

  1. aggiungere il permesso API di Shizuku e ShizukuProvider,
  2. attendere che appaia il Binder di Shizuku,
  3. richiedere all’utente l’autorizzazione in stile runtime di Shizuku,
  4. incapsulare il Binder del servizio di sistema di destinazione con ShizukuBinderWrapper.

Manifest requirements:

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

Esempio minimo di wrapper Binder:

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

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

Quel wrapper è ciò che fa sì che le Binder transactions vengano inoltrate dal processo di servizio di Shizuku invece di essere eseguite con l’UID normale dell’app chiamante.

2.1 UserService: quando ti serve più di una singola chiamata Binder

Per qualsiasi cosa più complessa delle transazioni Binder dirette, lo sviluppo moderno di Shizuku preferisce UserService invece del vecchio helper newProcess. Un UserService esegue il tuo codice Java/JNI in un processo separato come UID 2000 (shell) quando Shizuku è stato avviato via ADB o UID 0 quando è supportato da root.

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

Shizuku.bindUserService(args, conn);

Questo è utile per tooling offensivi che necessitano di stato persistente, helper JNI, o operazioni Binder ripetute senza pagare il costo di lanciare comandi shell continuamente. Ricorda che il servizio non è un normale processo app: alcuni metodi di Context non si comportano come all’interno di una normale applicazione Android.

2.2 Confini che ancora si applicano

  • ADB/shell e root sono livelli di privilegio differenti. Shizuku.getUid() restituisce 2000 per le sessioni avviate tramite shell e 0 per le sessioni avviate con root.
  • I permessi della shell cambiano tra le release di Android e possono anche essere ridotti dagli OEM.
  • La shell non può ancora leggere direttamente la sandbox privata di un’altra app come /data/user/0/<package>.
  • Le restrizioni delle Hidden API si applicano ancora al codice in esecuzione nel normale processo dell’app; se hai bisogno di interfacce non-SDK in modo esteso, sposta la logica in un UserService o usa un hidden-API bypass dedicato.

3. Rish - shell elevata in Termux

La schermata delle impostazioni di Shizuku espone “Use Shizuku in terminal apps”. Attivandola scarica rish, che apre una remote privileged shell fornita da 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

Dettaglio utile per workflow pesanti su Termux: quando Shizuku è eseguito come ADB/shell, rish evita intenzionalmente di preservare l’ambiente di Termux per impostazione predefinita perché l’utente shell di solito non può attraversare i percorsi privati di Termux.

3.1 Comandi utili dalla shell rish

  • Elencare i processi in esecuzione di un dato pacchetto:
ps -A | grep com.facebook.katana
  • Enumerare le socket in ascolto e mapparle ai pacchetti:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Eseguire il dump dei log di ogni applicazione esposti alla shell:
logcat -d | grep -iE "(error|exception)"
  • Bulk debloat (esempio):
pm uninstall --user 0 com.miui.weather2
  • Ispezionare utenti e layout dei profili prima di abusi multi-utente:
pm list users
dumpsys user

3.2 Pattern di abuso moderni abilitati da Shizuku con backend shell

AppOps e manomissione dei permessi speciali

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

Questo è utile durante i pentests per verificare se un’app o un agente MDM tollera effettivamente manipolazioni aggressive di AppOps senza richiedere root.

Isolamento di rete per app senza VPN o root

Strumenti recenti basati su Shizuku come ShizuWall utilizzano i controlli chain-3 del servizio connectivity per bloccare l’accesso alla rete per pacchetti selezionati:

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

Per le valutazioni, questo ti offre un modo rapido per verificare come si comporta un’app target quando un pacchetto concorrente di sicurezza, telemetria o gestione viene selettivamente isolato dalla rete mentre il resto del dispositivo rimane online. Lo stato viene cancellato al riavvio.

Installazioni avanzate sul dispositivo e flussi di lavoro per split APK

Modern Shizuku installers such as InstallWithOptions or InstallerX-Revived use shell-backed PackageInstaller access to perform operations that are otherwise awkward from a normal app: split APK installs, test-only packages, batch installs, and some Android 14 package-install flags.

Dal punto di vista dei test offensivi, la parte importante non è l’interfaccia grafica ma la primitiva: Shizuku trasforma l’installazione dei pacchetti in un’azione autorizzata dalla shell sul dispositivo, utile per test di persistenza, verifiche di downgrade e distribuzione rapida di payload di supporto su un dispositivo non-rootato.

Confini del work-profile e degli utenti secondari

Shizuku basato sulla shell è comunque soggetto alle restrizioni utente di Android. Sui profili gestiti ti imbatterai spesso in errori come:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

Se stai testando nello specifico bypass del work-profile o required-app replacement, conserva quel materiale nella pagina dedicata invece di duplicarlo qui: Android Enterprise Work Profile Required-App Replacement

4. Considerazioni sulla sicurezza / rilevamento

  1. Shizuku needs ADB debugging or root first, so Developer Options -> USB/Wireless debugging must be enabled on non-rooted devices.
  2. Il servizio si registra con il nome moe.shizuku.privileged.api. adb shell service list | grep shizuku and adb shell dumpsys activity service moe.shizuku.privileged.api sono controlli rapidi affidabili.
  3. Le capacità sono limitate a quelle fornite dal backend corrente. In sessioni ADB-backed, ciò significa che la superficie di attacco effettiva è quella esposta a com.android.shell su quella build Android, più tutto ciò che SELinux permette.
  4. Le sessioni non sopravvivono a un reboot a meno che il dispositivo sia rooted e Shizuku sia configurato come daemon di avvio.
  5. I layer di “security” degli OEM spesso rompono o riducono silenziosamente la funzionalità di Shizuku. Se un comando funziona via adb shell diretto ma fallisce tramite Shizuku, confronta l’UID del backend corrente (Shizuku.getUid()), i toggle di debugging OEM, e se il dispositivo ha ridotto i permessi della shell.

5. Mitigazioni

  • Disabilitare USB/Wireless debugging sui dispositivi di produzione.
  • Monitorare i servizi Binder che espongono moe.shizuku.privileged.api.
  • Applicare restrizioni work-profile o MDM che rimuovono le funzionalità di debugging dagli utenti gestiti.
  • Trattare gli strumenti compatibili con Shizuku come ADB-equivalent durante il threat modelling; è un moltiplicatore di forza post-exploitation anche quando il dispositivo non è rooted.

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks