Shizuku Привілейований API

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Shizuku — це сервіс з відкритим кодом, який запускає привілейований Java-процес з app_process і відкриває вибрані Android system APIs через Binder. Оскільки процес працює з тими самими можливостями UID shell, які використовує ADB, додаток, явно авторизований користувачем, може проксувати Binder-виклики до системних сервісів без root-доступу до пристрою.

На практиці це означає, що додаток з підтримкою Shizuku часто може виконувати ті ж примітиви, що й adb shell: управління пакетами, appops, settings, cmd connectivity, збір логів та багато інших Binder-транзакцій, дозволених shell. Він все одно не є root і все ще обмежений Android permissions, Linux UID checks, SELinux policy, Android version, and OEM-specific restrictions.

Типові випадки використання:

  • Аудит безпеки з пристрою без root
  • Управління пакетами на пристрої, debloating та встановлення split-APK
  • Збір логів, метаданих пакетів та стану мережі/процесів, видимого shell
  • Створення PoC або допоміжних інструментів, які потребують ADB-grade доступу, але не повного root chain

1. Starting the privileged service

moe.shizuku.privileged.api можна запустити трьома різними способами. Binder-інтерфейс, відкритий для клієнтських додатків, однаковий, але ефективні привілеї залежать від того, чи бекенд працює через ADB/shell або root.

1.1 Бездротовий ADB (Android 11+)

  1. Увімкніть Developer Options -> Wireless debugging та спаруйте пристрій.
  2. У додатку Shizuku виберіть “Start via Wireless debugging”.
  3. Сесія зберігається до перезавантаження, якщо тільки OEM ROM не вимкне wireless debugging або не відкличе авторизацію для налагодження.

1.2 USB / local ADB one-liner

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

Той самий скрипт можна виконати через network ADB connection (adb connect <IP>:5555).

1.3 Рутовані пристрої

Якщо пристрій вже рутований, виконайте:

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

1.4 Особливості OEM, що важливі під час тестування

  • MIUI / HyperOS часто вимагають USB debugging (Security settings) крім звичайного перемикача USB debugging.
  • ColorOS / OxygenOS зазвичай вимагають вимкнути Permission monitoring або еквівалентні захисні оболонки.
  • На Android 11+ Disable adb authorization timeout зменшує випадкові відключення Shizuku під час довгих тестових сесій.
  • Якщо бездротовий запуск постійно не вдається, дозвольте Shizuku працювати у фоні; кілька OEM ROMs призупиняють виявлення локальної мережі, коли додаток знаходиться у фоновому режимі.

1.5 Перевірка, що він запущений

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

Успішний запуск повертає працюючий сервіс і експонує Binder-сервіс, пов’язаний з moe.shizuku.privileged.api.

2. Підключення з додатку

Додаток з підтримкою Shizuku не використовує сирий Binder, який повертається Shizuku, як ніби це IPackageManager. Звичайний порядок дій:

  1. додати дозвіл Shizuku API та ShizukuProvider,
  2. дочекатися появи Shizuku Binder,
  3. запросити у користувача runtime-подібну авторизацію Shizuku,
  4. обгорнути Binder цільового системного сервісу за допомогою ShizukuBinderWrapper.

Вимоги до маніфесту:

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

Мінімальний приклад Binder-wrapper:

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

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

Ця обгортка спричиняє, що Binder transactions пересилаються процесом сервісу Shizuku замість виконання з нормальним UID додатка-ініціатора.

2.1 UserService: коли потрібно більше, ніж один Binder виклик

Для всього, що складніше за прямі Binder transactions, сучасна розробка Shizuku віддає перевагу UserService замість старого помічника newProcess. UserService запускає your own Java/JNI code в окремому процесі під UID 2000 (shell) коли Shizuku запускався через ADB, або під UID 0 коли він працює з root.

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

Shizuku.bindUserService(args, conn);

Це корисно для offensive tooling, яке потребує довготривалого стану, JNI-помічників або повторюваних Binder-операцій без витрат на постійний запуск shell-команд. Пам’ятайте, що сервіс не є звичайним процесом додатка: деякі методи Context поводяться не так, як у звичайному Android-додатку.

2.2 Межі, що все ще діють

  • ADB/shell і root — різні рівні привілеїв. Shizuku.getUid() повертає 2000 для сесій, що працюють від shell, і 0 для сесій, що працюють від root.
  • Права shell змінюються між релізами Android і також можуть бути урізані виробниками (OEMs).
  • Shell все ще не може безпосередньо читати приватну пісочницю іншого додатка, таку як /data/user/0/<package>.
  • Обмеження hidden API все ще застосовуються до коду, що виконується в звичайному процесі додатка; якщо вам потрібні non-SDK interfaces у великому обсязі, перемістіть логіку в UserService або використайте спеціальний hidden-API bypass.

3. Rish — elevated shell inside Termux

Екран налаштувань Shizuku показує “Use Shizuku in terminal apps”. Увімкнення завантажує rish, який відкриває віддалений привілейований shell, що працює через 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

Корисна деталь для робочих процесів, орієнтованих на Termux: коли Shizuku запускається як ADB/shell, rish навмисне уникає збереження оточення Termux за замовчуванням, оскільки користувач shell зазвичай не може отримати доступ до приватних шляхів Termux.

3.1 Корисні команди з shell rish

  • Показати запущені процеси для вказаного пакета:
ps -A | grep com.facebook.katana
  • Перелічити прослуховуючі сокети і зіставити їх з пакетами:
netstat -tuln
for pid in $(lsof -nP -iTCP -sTCP:LISTEN -t); do
printf "%s -> %s\n" "$pid" "$(cat /proc/$pid/cmdline)";
done
  • Вивести логи всіх додатків, доступні для shell:
logcat -d | grep -iE "(error|exception)"
  • Bulk debloat (example):
pm uninstall --user 0 com.miui.weather2
  • Перевірити користувачів і структуру профілів перед зловживанням multi-user:
pm list users
dumpsys user

3.2 Сучасні схеми зловживань, які стають можливими завдяки Shizuku з доступом shell

AppOps та маніпуляції зі спеціальними дозволами

Менеджери на базі Shizuku, такі як App Ops або App Manager, фактично обгортають shell-авторизовані виклики appops та Binder-виклики менеджера пакетів. З rish той самий примітив можна використовувати безпосередньо:

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

Це корисно під час pentests, щоб перевірити, чи додаток або MDM-агент дійсно витримує агресивну маніпуляцію AppOps без потреби в root.

Ізоляція мережі на рівні додатка без VPN або root

Останні інструменти на базі Shizuku, такі як ShizuWall, використовують контролі chain-3 сервісу connectivity для блокування мережевого доступу для вибраних пакетів:

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

Для оцінювання це дає швидкий спосіб перевірити, як цільовий додаток поводиться, коли конкуруючий пакет безпеки, телеметрії або пакет управління вибірково відключено від мережі, тоді як решта пристрою залишається онлайн. Стан очищується після перезавантаження.

On-device advanced installs and split APK workflows

Сучасні інсталятори Shizuku, такі як InstallWithOptions або InstallerX-Revived, використовують shell-backed PackageInstaller доступ для виконання операцій, які інакше незручні для звичайного додатка: split APK installs, test-only packages, batch installs, і деякі Android 14 package-install flags.

З точки зору offensive-testing, важлива частина — не GUI, а примітив: Shizuku turns package installation back into an on-device shell-authorised action, що корисно для persistence tests, downgrade checks та rapid deployment of helper payloads на non-rooted handset.

Work-profile and secondary-user boundaries

Shell-backed Shizuku все ще підпорядкований обмеженням користувачів Android. На managed profiles ви часто натрапите на помилки, такі як:

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. Міркування щодо безпеки / виявлення

  1. Shizuku потребує спочатку ADB debugging або root, тому Developer Options -> USB/Wireless debugging має бути ввімкнено на non-rooted пристроях.
  2. Сервіс реєструється під іменем moe.shizuku.privileged.api. adb shell service list | grep shizuku і adb shell dumpsys activity service moe.shizuku.privileged.api — надійні швидкі перевірки.
  3. Можливості обмежуються тим, що має поточний бекенд. У ADB-backed сесіях це означає, що ефективна поверхня атаки — та, що відкрита для com.android.shell в цій збірці Android, плюс те, що дозволяє SELinux.
  4. Сесії не виживають після reboot, якщо пристрій не rooted і Shizuku не налаштовано як демон автозапуску.
  5. OEM “security” шари часто ламають або мовчки обмежують функціональність Shizuku. Якщо команда працює через прямий adb shell, але не виконується через Shizuku, порівняйте поточний backend UID (Shizuku.getUid()), OEM debugging toggles, і чи пристрій не обрізав shell permissions.

5. Заходи пом’якшення

  • Вимкніть USB/Wireless debugging на production devices.
  • Моніторте Binder services, що експонують moe.shizuku.privileged.api.
  • Застосовуйте обмеження work-profile або MDM, які видаляють debugging features у керованих користувачів.
  • Розглядайте інструменти сумісні з Shizuku як ADB-equivalent під час threat modelling; це post-exploitation множник потужності навіть коли пристрій не rooted.

References

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks