Почему нельзя просто скопировать двоичный файл su (технический ответ, пожалуйста)

Я рутировал несколько устройств Samsung, и основная «цель», так сказать, состоит в том, чтобы получить suдвоичный файл /system/xbinи установить Superuser.apk .

Мой вопрос: почему нужно прыгать через все эти обручи, чтобы рутировать телефон (устанавливать кастомное рекавери и прошивать предварительно рутированное ПЗУ или использовать текущую установку)? Нельзя ли просто скачать предварительно скомпилированный su, переместить его на SD-карту и запустить через adb? То, что, кажется, делает ПЗУ «предварительно рутированным», заключается в том, что у него есть суперпользователь и двоичный файл su в соответствующих системных путях. Я не понимаю, почему так важно, чтобы он запускался из /system/xbin.

Ответы (2)

Для бинарного файла su требуется как выполнение, так и установленный бит разрешения setuid. Первое необходимо для того, чтобы файл можно было запустить, а второе — чтобы он автоматически запускался с правами владельца файла (установленный идентификатор пользователя или setuid. В данном случае владельцем является root. Подробнее здесь ).

Файлы на внешнем хранилище не имеют установленных битов доступа к исполняемому файлу и setuid, и они не могут быть предоставлены без прав root. Также обратите внимание, что SD-карта монтируется с флагом «noexec», чтобы предотвратить выполнение в целом для загрузки:

shell@android:/sdcard $ ./su
/system/bin/sh: ./su: can't execute: Permission denied
126|shell@android:/sdcard $ chmod 4755 su
Unable to chmod su: Operation not permitted
10|shell@android:/sdcard $ mount | grep /mnt/sdcard
/dev/block/mmcblk0p1 /mnt/sdcard vfat [...],noexec,[...]

Вот почему вы не можете просто скопировать suна SD-карту, а затем запустить ее, чтобы получить root права.

Так что единственное, что мешает получить рут, это то, что /sdcard не является исполняемым и вы не можете выполнить chmod? Как только su окажется в соответствующем месте, где его можно будет chmodd исполнить, исполняемый файл Golden. Я бы подумал, что должен быть уровень безопасности, чтобы кто-то не мог просто запустить su. На моем сервере и в Debian я не могу просто запустить su как обычный пользователь, мне предлагается ввести пароль. Я предполагаю, что если можно установить su, они могут перезаписать теневой файл, чтобы изменить пароль?
@user974896: user974896: Ну, несистемному пользователю больше некуда указать, что он может быть выполнен, и в любом случае у Android даже нет файлов или passwd. shadowВам буквально нужен root, чтобы поместить suисполняемый файл, поэтому методы рутирования включают либо эксплойт для повышения привилегий, либо вход в пользовательское восстановление (где все ставки в основном отключены).
Да. Это ответ.
@ user974896: в дополнение к тому, что /sdcard монтируется noexec, системный вызов setuid может быть вызван только тогда, когда бит разрешения suid установлен в исполняемом файле, а системный вызов chown и chmod позволит только root установить бит setuid файла принадлежит root (по сути, только root может создать исполняемый файл, который может работать с привилегиями root). Любой может вызвать su, но если вызывающему не разрешено делать это в базе данных суперпользователя (или в традиционной Linux, в базе данных passwd/shadow), вызов не будет успешным. Только приложение суперпользователя (и привилегированные процессы) может изменять базу данных суперпользователя.
@ user974896: Это, в дополнение к обычной системе безопасности в Android, в которой каждое приложение dalvik запускается от имени своего пользователя, означает, что приложения, которые только приложение из белого списка суперпользователя может эскалировать до root без запроса, всем остальным будет отказано (если это в черном списке) или заставит суперпользователя запрашивать у пользователя разрешение.

Укоренение включает в себя использование слабости в зависимости от версии Android, поэтому « перепрыгните через все обручи, чтобы получить root права на телефон » .

Это курица и яйцо!

Чтобы использовать root, вам нужен незащищенный демон adb (т.е. возможность перемонтирования /system) на телефоне, а чтобы иметь незащищенный adb, вам нужен root! А еще нужен разблокированный загрузчик.

Взгляните на один эксплойт под названием zergRush, найденный на github; интересующая функция вызывается, do_fault()когда предпринимается попытка «сломать» кадр стека voldдемона ', подключившись к принадлежащему ему каналу, и вызвать его сбой, перезаписав указатель стека так, чтобы он указывал на скопированный версия оболочки boomsh, которая затем запускается из /data/local/tmp.

Прочитав исходный код, вы теперь поймете, почему копирования suбинарного файла недостаточно для «рутирования» телефона и почему нужно перепрыгивать через препятствия. А также, поскольку исполняемый бит на уровне файловой системы для SD-карты заблокирован, так что туда нельзя - это там по понятным причинам! :)

Спасибо за ссылки, я буду читать их позже. Так что, даже если SD-карта была chmodd 777 с завода, я все равно не мог стать root, просто загрузив и выполнив ее?
правильный! Нет! Это не имеет ни малейшего значения, и, поскольку установленное на заводе ПЗУ будет иметь эту защиту, вам нужен root, чтобы добиться этого chmod- динг разрешения SD-карты, чтобы сделать это! :)
Что же делает su таким особенным, если он находится в /system/xbin? Если вы входите в оболочку adb (или запускаете приложение как обычный пользователь), вы являетесь непривилегированным пользователем. Почему выполнение su, когда оно находится в /system/xbin, делает вас суперпользователем, а не запуском его в нашем теоретически chmod 777 /sdcard?
/system/xbin- это каталог, в который входят утилиты busybox, и... на телефоне с root-правами выполнение этого echo $PATHприведет к /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin <- обратите внимание! Это в пути! Чтобы иметь это там, вам нужен root, поэтому много ситуаций с курицей и яйцом ... : D
Да, я знаю, что он идет по умолчанию. Я имею в виду, что такого особенного в том, чтобы запустить его там. Почему выполнение ./su в /sdcard/, /data/ или любом другом требуемом каталоге без полномочий root не работает, если предположить, что фабрика поставила ПЗУ с каталогом, измененным на 777. В основном я имею в виду, что это единственное, что останавливает загрузку и запуск ./su заключается в том, что каталоги, в которых пользователь без полномочий root может это сделать, не являются исполняемыми, или есть более широкая картина.
Давайте пойдем в чат, чтобы пощадить все эти комментарии....
Почему нельзя просто скопировать двоичный файл su (технический ответ, пожалуйста)
СпросиСетьПолитика конфиденциальности1y, 0v