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

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

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

— user974896
источник

Ответы:

Двоичный файл 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.

— eldarerathis
источник

Так что это единственное, что предотвращает рутирование, тот факт, что / sdcard не является исполняемым, и вы не можете использовать chmod? После того, как su находится в соответствующем месте, где он может быть chmodded исполняемый файл ваш золотой. Я бы подумал, что будет какой-то уровень безопасности, чтобы помешать кому-то просто запустить su. На моем сервере и в Debian я не могу просто запустить su как обычный пользователь, мне предлагается ввести пароль. Я предполагаю, что если кто-то может установить su, он может перезаписать теневой файл, чтобы сменить пароль?

— user974896

@ user974896: Ну, не для пользователя, не являющегося системным пользователем, нигде не сказано, что он может быть выполнен, а у Android даже нет passwdshadow файлов или файлов. Вам в буквальном смысле нужно, чтобы root поместил suв исполняемый каталог , поэтому методы рутинга либо включают эксплойт с повышением привилегий, либо переходят в пользовательское восстановление (где все ставки в основном отключены).

— Eldarerathis

Да. Это ответ.

— Android Quesito

@ user974896: в дополнение к / sdcard, монтируемому noexec, системный вызов setuid может быть вызван только в том случае, если в исполняемом файле установлен бит разрешения suid, а системный вызов chown и chmod позволит root только установить бит setuid файла принадлежит root (фактически, только root может создать исполняемый файл, который может работать с привилегиями root). Любой может вызвать su, но если вызывающей стороне не разрешено делать это в базе данных Superuser (или в традиционном Linux, в базе данных passwd / shadow), вызов не будет успешным. Только приложение Superuser (и привилегированные процессы) могут изменять базу данных Superuser.

— Ли Райан

@ user974896: Это, в дополнение к обычной системе безопасности в Android, в которой каждое приложение dalvik запускается как собственный пользователь, означает, что приложения, которые только приложение в белом списке Superuser может эскалировать в корень без запроса, все остальные получат отказ (если это в черный список), или заставит Superuser запросить у пользователя разрешение.

— Ли Райан

Root включает в себя использование слабости в зависимости от версии Android, следовательно, " прыгать через все обручи, чтобы получить root права на телефон "

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

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

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

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

— t0mm13b
источник

Спасибо за ссылки, я буду читать их позже. Таким образом, даже если бы sdcard был chmodded 777 с завода, я все равно не мог бы получить root, просто загрузив и выполнив его?

— user974896

верный! Не уходи! Не имеет значения ни на йоту, и так как ПЗУ, установленное на заводе-изготовителе, будет защищено, вам нужен root, чтобы добиться этого chmod- с разрешениями SDcard, чтобы сделать это! :)

— t0mm13b

Что делает su таким особенным, если он находится в / system / xbin? Если вы входите в оболочку adb (или запускаете приложение как обычный пользователь), вы являетесь непривилегированным пользователем. Почему выполнение su, когда оно находится в / system / xbin, делает вас рутом, а не запускает его в нашей теоретически chmod 777 / sdcard?

— user974896

/system/xbinкаталог, в который входят утилиты busybox, и ... в рутированном телефоне, выдача которого echo $PATHприведет к / sbin: / vendor / bin: / system / sbin: / system / bin: / system / xbin <- обратите внимание! Это в пути! Для того, чтобы иметь это там, вам нужен root, следовательно, много ситуаций с курицей и яйцами ...: D

— t0mm13b

Да, я знаю, что по умолчанию. Я имею в виду то, что такого особенного в том, чтобы запустить его там. Почему выполнение ./su в / sdcard /, / data / или любом другом каталоге, не являющемся нужным, не работает, если фабрика поставила ПЗУ с каталогом chmodded на 777. Я имею в виду, что единственное, что мешает скачиванию и работает ./su - это тот факт, что каталоги, в которых пользователь, не имеющий прав доступа, может сделать это, не являются исполняемыми или имеют более широкую картину.

— user974896