Почему «adb root» ничего не делает?

У меня OnePlus 6T. Есть рут через TWRP и Magisk. Я установил ro.debuggableна 1. Но когда я печатаю adb root, он делает это:

C:\Users\ituser> adb root

C:\Users\ituser> adb remount
Not running as root. Try "adb root" first.

введите описание изображения здесь

Я даже не могу использовать adb pullсистемные файлы.

Интересно, он не выдает сообщение об ошибке. Насколько мне известно, adb rootне работает с «производственными сборками» (например, со стандартными ПЗУ, даже если они рутированы). Поэтому, если у вас нет «ПЗУ разработчика», шансы, что это что-то сделает, довольно малы.

Ответы (1)

На производстве — userсборка ПЗУ — вы не можете запускаться adbdс правами root, если ПЗУ или хотя бы adbdдвоичный файл не пересобраны с необходимыми изменениями. Причина — ALLOW_ADBD_ROOTфлаг сборки ( 1 , 2 ) .
Именно поэтому был разработан adbd Insecure , заменивший adbdбинарник на модифицированный.

В сборке userdebugили eng(или с небезопасным adbdдвоичным файлом, извлеченным из любого из этих типов сборки):

  • Если ro.secure=0, adbdзапускается от имени пользователя root, если он включен в настройках (параметры разработчика) ( 3 ) . Однако adb rootне будет работать ( 4 ) .
  • Если ro.debuggable=1, adb rootперезапустится adbdкак root ( 5 , 6 ) .

Однако adbdможно собрать из модифицированного исходного кода, чтобы пропустить все эти проверки. Кроме того, следует позаботиться о SELinux, если он находится в enforcingрежиме. adbdдолжен быть разрешен запуск в неограниченном контексте суперпользователя: u:r:su:s0 ( 7 , 8 ) , что не относится к userсборкам ( 9 , 10 , 11 ) . Смотрите этот ответ для более подробной информации.

Свойства Android могут быть перезаписаны с помощью /data/local.propon userdebug/ engbuilds, т. е. если ALLOW_LOCAL_PROP_OVERRIDEустановлен флаг сборки ( 12 , 13 ) . Но это не работает для ro.*свойств ( 14 ) и то же самое верно для setpropинструмента командной строки. Однако файл default.prop/ prop.default, который может быть расположен в нескольких возможных местах в зависимости от конфигурации сборки устройства ( 15 ) , может быть изменен для изменения свойств, доступных только для чтения (если они еще не установлены из какого-либо другого файла или *.rcфайла свойств). Если файл находится в ramdisk, boot.imgего необходимо изменить.

Инструмент Magisk resetprop может сбросить свойства только для чтения, даже если они уже установлены. ro.secureи ro.debuggableоба, возможно, были изменены как часть политики MagiskHide ( 16 ) , которую вы можете вернуть обратно, чтобы разрешить adbdзапуск от имени пользователя root.

Другим связанным свойством является ro.adb.secure, которое управляет аутентификацией с открытым ключом. При установке ro.adb.secure=0на userdebug/ engbuilds аутентификация пропускается (никаких device unauthorizedсообщений никогда) ( 17 , 18 , 19 ) ; связанный: место хранения «adb_keys» .

В качестве дополнительной информации, тип сборки рома можно найти, глядя наro.build.type
Почему «adb root» ничего не делает?
СпросиСетьПолитика конфиденциальности1y, 0v