**Shizuku не ломает Android. Он работает как задумано — и это главная проблема**
**Shizuku не ломает Android. Он работает как задумано — и это главная проблема** Pradeo проверила Shizuku на Android 16: после авторизации обычное приложение получает права системной оболочки shell с UID 2000. Никакого эксплойта, никакой уязвимости — просто механизм, который делает ровно то, для чего его написали. Вопрос в том, что именно вы ему разрешаете. **Что выяснили** Тестировали Shizuku 13.6 в режиме ADB без root. Приложение не имело никаких разрешений Android, кроме доступа к Shizuku. Из 41 проверенной команды 27 через Shizuku возвращали больше данных или открывали дополнительные возможности. Причина простая: сервер выполняет команды от имени shell, а не от имени приложения. Одно согласие — и дальше приложение говорит голосом системной оболочки. Цифры наглядные. Без Shizuku тестовое приложение видело 98 установленных пакетов, два собственных процесса и 284 строки системного журнала. После подключения — 261 пакет, 382 процесса и 1978 строк logcat. Пять команд не сработали в обоих режимах, остальное — пожалуйста. **Четыре сценария злоупотребления** Pradeo воспроизвела следующее: - чтение секретов, которые другая программа оставила в logcat; - тихая установка тестового APK без окна установщика — то есть без единого видимого подтверждения; - выдача себе доступа к контактам без системного запроса; - сбор сведений об аккаунтах, сетевых соединениях и использовании приложений. Выглядит как `pm install /data/local/tmp/test.apk`, выполненный от shell. Пользователь ничего не нажимал. **Важная оговорка** Shizuku не даёт shell-процессу прямого доступа к `/data/data` чужих приложений, если пакет не помечен как отладочный. Это не уязвимость Android и не баг Shizuku. Риск появляется в момент, когда пользователь разрешает стороннему приложению выполнять команды через уже запущенный сервис. Одно согласие действует сразу для всех команд — и отозвать его выборочно нельзя. **RedHook — более неприятный вариант той же схемы** Реальный троян RedHook пошёл дальше. Получив Accessibility через социальную инженерию, он сам включает режим разработчика и беспроводную отладку, подключается к локальному ADB и разворачивает собственный сервер на основе Shizuku. После перезагрузки RedHook может снова включить отладку и вернуть привилегии за считаные секунды. Shizuku здесь — не дыра, а готовый инструмент, который вредонос ставит себе на службу. **На что смотреть** Авторы проверки советуют обращать внимание на неожиданно включённые Developer options и USB/Wireless debugging, неизвестные приложения с Accessibility и запущенный Shizuku-сервис. При этом сам по себе Shizuku — не признак заражения: легитимные программы используют его для управления пакетами, резервного копирования, автоматизации и настройки системы. 🛠 **Мнение DevGeek.IT:** Shizuku — отличный инструмент, но его модель безопасности — «одно разрешение = shell для всего». Это не баг, это дизайн. Проблема в том, что пользователи воспринимают его как волшебную кнопку «дать доступ» и не думают, какое приложение получает ключи. RedHook показывает реальную угрозу: не Shizuku сам по себе, а цепочка Accessibility → режим разработчика → ADB → Shizuku. Если вы подключили приложение к Shizuku — считайте, что доверяете ему на уровне системной оболочки. Случайным программам такие права не выдают. И да, Android 16 это не «починил», потому что чинить здесь нечего — только голову пользователя.