Shizuku Ayrıcalıklı API

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Shizuku, app_process ile ayrıcalıklı bir Java süreci başlatan ve seçilmiş Android system API’lerini Binder üzerinden açan açık kaynaklı bir servistir.
Çünkü süreç, ADB’nin kullandığıyla aynı shell UID yetenekleriyle çalıştığı için, kullanıcı tarafından açıkça yetkilendirilmiş bir uygulama, cihazı root’lamadan sistem servislerine yapılan Binder çağrılarını vekil olarak iletebilir.

Uygulamada bu, Shizuku-aktif bir uygulamanın sıklıkla adb shell ile aynı ilkelere erişebilmesi anlamına gelir: paket yönetimi, appops, settings, cmd connectivity, log toplama ve shell tarafından izin verilen birçok diğer Binder işlemi. Yine de root değildir ve hâlâ Android izinleri, Linux UID kontrolleri, SELinux politikası, Android sürümü ve OEM’e özgü kısıtlamalar ile sınırlıdır.

Tipik kullanım senaryoları:

  • Rootlanmamış bir telefonda güvenlik denetimi
  • Cihaz üzerinde paket yönetimi, debloat ve split-APK yükleme
  • Loglar, paket meta verileri ve shell tarafından görülebilen ağ/process durumunun toplanması
  • ADB-dereceli erişime ihtiyaç duyan ama tam bir root zinciri gerektirmeyen PoC’lar veya yardımcı araçların oluşturulması

1. Ayrıcalıklı servisin başlatılması

moe.shizuku.privileged.api üç farklı şekilde başlatılabilir. İstemci uygulamalara açılan Binder arayüzü aynıdır, ancak etkin ayrıcalık backend’in ADB/shell mı yoksa root mu olduğuna bağlıdır.

1.1 Wireless ADB (Android 11+)

  1. Geliştirici Seçenekleri -> Wireless debugging’i etkinleştirin ve cihazı eşleştirin.
  2. Shizuku uygulaması içinde “Start via Wireless debugging” seçeneğini seçin.
  3. Oturum, OEM ROM wireless debugging’i sonlandırmadığı veya debugging yetkilendirmesini geri çağırmadığı sürece yeniden başlatmaya kadar devam eder.

1.2 USB / local ADB tek satır

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

Aynı script ağ ADB bağlantısı üzerinden çalıştırılabilir (adb connect <IP>:5555).

1.3 Rootlu cihazlar

Cihaz zaten rootluysa şu komutu çalıştırın:

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

1.4 OEM quirks that matter during testing

  • MIUI / HyperOS genellikle normal USB debugging anahtarına ek olarak USB debugging (Güvenlik ayarları) gerektirir.
  • ColorOS / OxygenOS genellikle Permission monitoring veya eşdeğer güvenlik sarmalayıcılarını devre dışı bırakmayı gerektirir.
  • Android 11+’te, Disable adb authorization timeout, uzun test oturumları sırasında rastgele Shizuku kopmalarını azaltır.
  • Kablosuz başlatma sürekli başarısız oluyorsa, Shizuku’nun arka planda çalışmasına izin verin; bazı OEM ROM’ları uygulama arka plana alındığında yerel ağ keşfini askıya alır.

1.5 Verifying that it is running

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

Başarılı bir başlatma, çalışan bir hizmet döndürür ve moe.shizuku.privileged.api ile ilişkili bir Binder servisini açığa çıkarır.

2. Bir uygulamadan bağlanma

Shizuku-etkin bir uygulama, Shizuku tarafından döndürülen ham Binder’ı IPackageManager imiş gibi kullanmaz. Normal akış şudur:

  1. Shizuku API iznini ve ShizukuProvider’ı ekleyin,
  2. Shizuku Binder’ın görünmesini bekleyin,
  3. kullanıcıdan Shizuku’nun çalışma zamanı tarzı yetkilendirmesini isteyin,
  4. hedef sistem-servis Binder’ını ShizukuBinderWrapper ile sarmalayın.

Manifest gereksinimleri:

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

Minimal Binder-wrapper örneği:

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

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

Bu wrapper, Binder işlemlerinin çağıran uygulamanın normal UID’si ile yürütülmek yerine Shizuku service process tarafından iletilmesine neden olur.

2.1 UserService: tek bir Binder çağrısından daha fazlasına ihtiyaç duyduğunuzda

Doğrudan Binder işlemlerinden daha karmaşık durumlar için, modern Shizuku geliştirme eski newProcess yardımcı yerine UserService’i tercih eder. Bir UserService, Shizuku ADB üzerinden başlatıldığında ayrı bir süreçte your own Java/JNI code’u UID 2000 (shell) olarak çalıştırır; root tarafından desteklendiğinde ise UID 0 olarak çalıştırır.

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

Shizuku.bindUserService(args, conn);

Bu, uzun ömürlü durum, JNI yardımcıları veya shell komutlarını tekrar tekrar spawn etme maliyetini ödemeden tekrarlanan Binder işlemleri gerektiren offensive tooling için faydalıdır. Servisin normal bir uygulama süreci olmadığını unutmayın: bazı Context yöntemleri normal bir Android uygulaması içindekiler gibi davranmaz.

2.2 Hâlâ geçerli sınırlar

  • ADB/shell ve root farklı ayrıcalık seviyeleridir. Shizuku.getUid() shell-backed oturumlar için 2000, root-backed oturumlar için 0 döndürür.
  • Shell izinleri Android sürümleri arasında değişir ve OEM’ler tarafından da kısıtlanabilir.
  • Shell hâlâ doğrudan başka bir uygulamanın özel sandbox’ını, ör. /data/user/0/<package>, okuyamaz.
  • Gizli API sınırlamaları normal uygulama sürecinde çalışan kod için hâlâ geçerlidir; non-SDK arayüzlerine yoğun olarak ihtiyaç duyuyorsanız mantığı bir UserService’e taşıyın veya özel bir hidden-API bypass kullanın.

3. Rish - Termux içinde yükseltilmiş shell

Shizuku ayarlar ekranı “Use Shizuku in terminal apps” seçeneğini gösterir. Etkinleştirmek rish’i indirir; bu, Shizuku tarafından desteklenen uzak ayrıcalıklı bir shell açar.

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-ağırlıklı iş akışları için faydalı bir detay: Shizuku ADB/shell olarak çalıştığında, rish varsayılan olarak Termux’un ortamını korumaktan kasıtlı olarak kaçınır çünkü shell kullanıcısı genellikle Termux’a özel dizinlere erişemez.

3.1 Useful commands from the rish shell

  • Belirli bir pakete ait çalışan süreçleri listele:
ps -A | grep com.facebook.katana
  • Dinleyen soketleri sıralayıp bunları paketlere eşleştir:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Shell’e açılan tüm uygulama günlüklerini dök:
logcat -d | grep -iE "(error|exception)"
  • Toplu debloat (örnek):
pm uninstall --user 0 com.miui.weather2
  • Çoklu kullanıcı suistimali öncesinde kullanıcıları ve profil düzenini incele:
pm list users
dumpsys user

3.2 Modern abuse patterns enabled by shell-backed Shizuku

AppOps and special-permission tampering

Shizuku destekli yöneticiler (App Ops veya App Manager gibi) aslında shell tarafından yetkilendirilmiş appops ve package-manager Binder çağrılarını sarar. rish üzerinden aynı primitive doğrudan kullanılabilir:

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

Bu, pentests sırasında bir uygulamanın veya MDM ajanının gerçekten agresif AppOps manipülasyonlarını root gerektirmeden tolere edip etmediğini doğrulamak için kullanışlıdır.

VPN veya root olmadan uygulama başına ağ izolasyonu

Son zamanlarda Shizuku tabanlı araçlar, örneğin ShizuWall, seçili paketler için ağ erişimini engellemek üzere connectivity servisinin chain-3 kontrollerini kullanıyor:

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

Değerlendirmeler için, bu, hedef uygulamanın cihazın geri kalanı çevrimiçi kalırken rakip bir güvenlik, telemetry veya yönetim paketinin ağdan seçici olarak kesildiğinde nasıl davrandığını hızlıca test etmenizi sağlar. Durum yeniden başlatmada temizlenir.

Cihaz üzerinde gelişmiş yüklemeler ve split APK iş akışları

InstallWithOptions veya InstallerX-Revived gibi modern Shizuku kurucuları, normal bir uygulamadan zor olan işlemleri gerçekleştirmek için shell yetkili PackageInstaller erişimini kullanır: split APK yüklemeleri, sadece test paketleri, toplu yüklemeler ve bazı Android 14 paket-yükleme bayrakları.

Ofansif testler açısından önemli olan GUI değil, temel işlemdir: Shizuku paket kurulumu tekrar cihaz üzerinde shell tarafından yetkilendirilmiş bir eyleme dönüştürür, bu da persistence tests, downgrade checks ve non-rooted handset üzerinde helper payloads’ın hızlı dağıtımı için faydalıdır.

İş profili ve ikincil kullanıcı sınırları

Shell yetkili Shizuku hâlâ Android’in kullanıcı kısıtlamalarına tabidir. Yönetilen profillerde genellikle şu tür hatalarla karşılaşırsınız:

INSTALL_FAILED_USER_RESTRICTED
Shell does not have permission to access user X

If you are specifically testing work-profile bypasses or required-app replacement, keep that material in the dedicated page instead of duplicating it here: Android Enterprise Work Profile Required-App Replacement

4. Güvenlik hususları / tespit

  1. Shizuku öncelikle ADB debugging veya root gerektirir; bu yüzden rootlu olmayan cihazlarda Developer Options -> USB/Wireless debugging etkinleştirilmiş olmalıdır.
  2. Servis kendini moe.shizuku.privileged.api adıyla kaydeder. adb shell service list | grep shizuku ve adb shell dumpsys activity service moe.shizuku.privileged.api güvenilir hızlı kontrollerdir.
  3. Yetkiler, mevcut backend ile sınırlıdır. ADB-backed oturumlarda bu, etkili saldırı yüzeyinin o Android build’inde com.android.shell tarafından açığa çıkan alan olduğunu ve ayrıca SELinux’un izin verdiği şeyleri kapsadığını ifade eder.
  4. Cihaz rootlu olmadıkça oturumlar yeniden başlatmayı survive etmez; cihaz rootlu ve Shizuku bir startup daemon olarak yapılandırılmışsa istisna vardır.
  5. OEM “güvenlik” katmanları genellikle Shizuku işlevselliğini bozabilir veya sessizce azaltabilir. Bir komut doğrudan adb shell ile çalışıp Shizuku üzerinden başarısız oluyorsa, mevcut backend UID’sini (Shizuku.getUid()), OEM debugging seçeneklerini ve cihazın shell izinlerini kısaltıp kısaltmadığını karşılaştırın.

5. Mitigation

  • Production cihazlarda USB/Wireless debugging’i devre dışı bırakın.
  • moe.shizuku.privileged.api açığa çıkaran Binder servislerini izleyin.
  • Yönetilen kullanıcılardan debugging özelliklerini kaldıran work-profile veya MDM kısıtlamalarını uygulayın.
  • Shizuku-uyumlu araçları tehdit modellemesi sırasında ADB-equivalent olarak değerlendirin; cihaz rootlu olmasa bile post-exploitation aşamasında bir güç çarpanı olabilir.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin