Root-доступ и его применение

[android_roman]

Root это работа от имени суперпользователя на устройстве. Без него ADB упирается в права обычного shell-аккаунта (uid 2000), и половина системных каталогов закрыта на запись, а некоторые и на чтение. В этой главе разберём два разных способа получить повышенные права: штатный adb root для отладочных сборок и su через Magisk на боевых устройствах. Это принципиально разные механизмы, и путать их не надо.

adb root и почему он часто не работает:

Команда adb root перезапускает демон adbd на устройстве с правами root. Это не рутирование телефона, это переключение режима уже работающего демона.

Код: Выделить всё

adb root
restarting adbd as root

После этого adb shell сразу даёт приглашение с решёткой (#), то есть вы уже root внутри shell, su вызывать не нужно. Вернуть обычный режим:

Код: Выделить всё

adb unroot
restarting adbd as unrooted

Подвох в том, что adb root работает только на сборках userdebug и eng. Решает это свойство ro.debuggable. Проверить:

Код: Выделить всё

adb shell getprop ro.debuggable
1

Если вернулось 1, adb root доступен. На розничном телефоне (сборка user) там 0, и вы получите:

Код: Выделить всё

adb root
adbd cannot run as root in production builds

Обойти это сменой prop на боевом устройстве нельзя, демон собран в production-режиме. userdebug-сборки встречаются на эмуляторе Android (AVD без Google Play образа), на инженерных семплах и на части кастомных прошивок (LineageOS в варианте eng). Разблокированный загрузчик сам по себе adb root не включает, он лишь позволяет прошить такую сборку или Magisk. То есть adb root и unlocked bootloader связаны косвенно.

Ещё одна частая ошибка: adb root есть, а запись в /system всё равно запрещена. Раздел смонтирован read-only. На userdebug помогает remount:

Код: Выделить всё

adb root
adb remount
remount succeeded

Если remount ругается на verity, сначала отключаем проверку целостности и перезагружаемся:

Код: Выделить всё

adb disable-verity
adb reboot

disable-verity трогает dm-verity/AVB, после этого штатные OTA-обновления ломаются, помните об этом.

su из shell на боевом устройстве:

На розничном телефоне путь другой. Устройство рутируется заранее (обычно патчем boot.img через Magisk), а потом в shell вызывается su.

Код: Выделить всё

adb shell
star2lte:/ $ su
star2lte:/ #

Смена $ на # означает, что вы стали root. В первый раз Magisk покажет на экране телефона диалог Grant/Deny, шелл провайдер надо разрешить вручную. Если экран заблокирован или вы тапнули Deny, su молча зависнет или выдаст отказ. Разовая команда без интерактивного шелла:

Код: Выделить всё

adb shell su -c id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

Magisk против SuperSU:

Magisk (автор topjohnwu, сейчас поддерживается сообществом, актуальные релизы серии v27+) это systemless-root. Он не пишет в /system, а патчит ramdisk внутри boot-образа, root живёт поверх системы через оверлеи. Отсюда плюсы: проще ставить и снимать, штатные OTA реальнее пережить, есть модули, есть DenyList для сокрытия root от выбранных приложений (банки, госуслуги, антифрод). Бинарь su у Magisk лежит не в /system, а предоставляется демоном magiskd.

SuperSU (автор Chainfire) это старая система-зависимая схема, su прописывался в /system. Проект заброшен примерно с 2017 года, под Android 10+ с system-as-root и динамическими разделами он толком не живёт. На новых устройствах его не используют, рассматривайте только как историю. Для всего, что новее Android 9, ставьте Magisk.

Модификация системных файлов:

build.prop лежит в /system/build.prop. Прямое редактирование на современном Android (14/15) проблемно: раздел read-only, плюс AVB/dm-verity проверяет хэш, изменённый файл уронит загрузку. Поэтому свойства меняют в рантайме через resetprop из Magisk, без правки файла:

Код: Выделить всё

adb shell su -c "resetprop ro.product.model Pixel_8_Pro"

Изменение действует до перезагрузки. Чтобы пережило ребут, кладут строки в /data/adb/modules/<module>/system.prop через модуль Magisk. Если очень нужно отредактировать сам файл на userdebug:

Код: Выделить всё

adb root
adb remount
adb shell
emulator:/ # vi /system/build.prop

hosts для блокировки рекламы и трекеров. Файл /system/etc/hosts. На розничном устройстве правьте не его, а systemless hosts от Magisk (включается в настройках Magisk, файл уезжает в /data/adb/hosts, /system не трогается, дружит с AdAway). Просмотр и проверка:

Код: Выделить всё

adb shell cat /system/etc/hosts
127.0.0.1       localhost
::1             ip6-localhost
0.0.0.0 ads.example.com

Удаление системных приложений. Самый безопасный способ вообще без root разбирали в главе 7, он удаляет пакет только для пользователя 0:

Код: Выделить всё

adb shell pm uninstall -k --user 0 com.vendor.bloatware
Success

Это не трогает раздел, переживает работу с большинством устройств и легко откатывается через pm install-existing. С root можно физически снести APK из /system/app или /system/priv-app, но на динамических разделах это требует remount, ломает verity и часто не имеет смысла. Чаще достаточно отключить:

Код: Выделить всё

adb shell su -c "pm disable-user --user 0 com.vendor.bloatware"

SELinux:

Проверить текущий режим:

Код: Выделить всё

adb shell getenforce
Enforcing

Enforcing значит политика применяется, Permissive значит нарушения только логируются. Переключить в permissive (нужен root):

Код: Выделить всё

adb shell su -c "setenforce 0"

setenforce 1 возвращает enforcing. На многих устройствах 2024-2025 ядро собрано так, что setenforce заблокирован даже из-под root, и команда тихо ничего не делает либо возвращает Permission denied. Глобально гасить SELinux это плохая идея: вы снимаете защиту со всей системы. Если приложение что-то не может, ищите конкретный отказ.

Контексты безопасности. У файлов они видны через ls -Z, у процессов через ps -Z:

Код: Выделить всё

adb shell su -c "ls -Z /system/bin/sh"
u:object_r:shell_exec:s0 /system/bin/sh

Формат это user:role:type:level. Отказы пишутся в лог как avc: denied, ловить их удобно так:

Код: Выделить всё

adb shell su -c "dmesg | grep 'avc: denied'"

или через logcat по тегу. Изменить контекст файла (после remount на rw) можно через chcon:

Код: Выделить всё

adb shell su -c "chcon u:object_r:system_file:s0 /system/etc/myfile"

Риски и предосторожности:

Кратко по граблям. adb disable-verity и патч системы ломают штатные OTA, готовьтесь обновляться вручную. Запись в /system на boot-критичные файлы при включённой verity это кирпич, на новых устройствах Fastboot и заводская прошивка через Odin/fastboot ваш единственный путь назад. Root отключает часть гарантий безопасности: банковские приложения через Play Integrity увидят рут и откажут (отсюда DenyList в Magisk). Никогда не давайте su незнакомым приложениям через диалог Magisk, это полный контроль над устройством. Разблокировка загрузчика на большинстве телефонов делает wipe всех данных, бэкап делайте заранее (глава 18). И самое практичное: setenforce 0 на постоянку оставлять нельзя, это снимает изоляцию приложений целиком.

[Denyse]

Подскажите по моменту:

adbd cannot run as root in production builds

у меня Redmi с разблокированным загрузчиком, а ошибка все равно вылазит. То есть unlock загрузчика тут вообще не при делах и нужна именно userdebug сборка? Правильно понял?

[mlakers322]

По SuperSU соглашусь полностью, накатывал на старый Samsung под Android 7 и забыл как страшный сон. На десятке вообще не взлетело. А вот вопрос: resetprop ставит ro.product.model, оно слетает после ребута. Через system.prop в модуле Magisk норм держится, проверял на Pixel 8, Play Integrity при этом не падал если model оставлять в рамках реального устройства.

[zcruizer00]

setenforce 0 у меня на Android 14 молча игнорится, getenforce так и показывает Enforcing. Это как раз тот случай когда ядро блокирует переключение? Как тогда отдельный avc denied чинить, через sepolicy.rule в Magisk модуле?

[mmedicoff]

Маленькая поправка для новичков: pm uninstall --user 0 без флага -k сносит и кэш с данными, а с -k оставляет. В уроке флаг есть, но я бы прям выделил, потому что потом install-existing восстанавливает пакет, а данные если их грохнул уже не вернешь.