Все для root устройств

Вы сможете избавиться от рекламы и мусорных программ, а также расширить возможности своего устройства.

Нужно получить рут-доступ? С этим приложением вы станете обладателем прав суперпользователя практически на любом устройстве.

Хотите быстро получить рут-доступ на своем мобильном устройстве? Это приложение – одно из самых удобных!

Нужно быстро, просто и с большой долей вероятности получить рут-доступ на своем устройстве? Сделайте это с помощью DingDong Root!

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

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

Как быстро и безопасно получить рут-доступ на Андроид? Воспользуйтесь приложением Kingo Root!

Многофункциональный инструмент для получения рут-прав.

Получили рут-права, но не знаете, как ими правильно пользоваться? Установите эту программу, чтобы защитить свое устройство от несанкционированного доступа!

Давно хотели установить рут-права на свое мобильное устройство, работающее на базе ОС Андроид? Данная программа поможет вам в этом!

Root Checker Pro

Не знаете, установлены ли на вашем устройстве рут-права? С этим приложением вы очень быстро выяснит это.

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

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

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

Когда нужно получить рут-права на мобильном устройстве, работающем под управлением ОС Андроид, пользователи долго не выбирают, а сразу скачивают 360 Root. Программа все сделает за вас – нужно лишь установить ее на свой смартфон или планшет и нажать кнопку

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

One Click Root

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

С помощью этой универсальной программы пользователь может получить Root-права на своем мобильном устройстве или планшете на платформе Андроид. Русскоязычный интерфейс приложения и удобные подсказки сделают этот процесс более удобным и простым.

Ищете способ безвозвратно удалить рут-права на мобильном устройстве? С этим приложением вы сможете избавиться от прав супер-пользователя в один клик!

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

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

Что такое root-права?

Сразу оговорюсь — я не буду вдаваться в технические детали реализации самого процесса рутирования телефона, поскольку недостаточно компетентен в этом, да и статья не про это.

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

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

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

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

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

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

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

Кому НЕ нужны root-права

Именно так. Если вы сидите на данном ресурсе и дочитали до этого момента, полагаю, вы настроены решительно и будет проще перечислить все ПРОТИВ, нежели все ЗА. Преимуществ у расширенных прав действительно много, но это силой надо уметь управлять. Таким образом, список пользователей, которым я бы не рекомендовал получать root, можно сформулировать примерно так:

• Ваш телефон на гарантии (при получении root гарантия почти всегда снимается)

• Вы не можете сформулировать, зачем они вам нужны

• Вы работаете на телефоне с информацией содержащую банковскую/государственную/иную тайну

• У вас нет возможности сделать полный backup всех разделов системы, равно как и нет возможности восстановить устройство в случае утраты работоспособности из-за root-прав

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

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

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

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

• King Root (не путать с Kingo Root)

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

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

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

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

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

Как получить 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», которое при первом запуске обновится и будет работать. Самое важно и интересное кроется в настройке.

Настройка 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.

Опасности root-прав

Не буду утверждать, что root-права это безопасно — любой необкатанный magisk модуль может привести систему в нерабочее состояние, при неумелом редактировании системных файлов система также придет в негодность, а функционал программ, запрашивающих root не всегда прозрачен. Не давайте root права приложениям, которым, по вашему мнению, они не нужны! Периодически такие права запрашивают Яндекс Карты, статистики ради или для чего-то еще — неизвестно, но проверять не хочется.

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

Самое опасное, наверное — потеря гарантии производителя, что логично.

Выводы

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

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

• Busybox — дает доступ приложениям к встроенному busybox от Magisk

• No Storage Restricts — убирает ограничения в выборе папок в файловом менеджере

• LuckyPatcher — его модуль нужен для переноса приложений в системный раздел

• Move Certificates — перенос пользовательских сертификатов в систему

• NFC Screen Off — работа NFC при выключенном экране

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

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

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

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

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

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

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

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

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

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

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

Вступление

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

• Физический доступ к смартфону. Нескольких минут будет достаточно.

• Загрузчик на смартфоне уже находится в разблокированном состоянии. Это главное условие. Оно в 95% случаев справедливо для устройств, на которых получены root-права или установлены сторонние сборки ОС, на что и намекает название статьи, но вполне возможно что пользователь по каким-то странным причинам решил разблокировать загрузчик и без этого. Нам не принципиально, загрузчик разблокирован — можно атаковать, версия android не имеет значения, наличие или отсутствие рута также не имеет значения. Именно о возможностях, которые даёт атакующему с физическим доступом разблокированный загрузчик, и будет вся суть статьи.

• Для устройства существует возможность организовать sideload. Например, для устройства есть TWRP или иной образ recovery дающий возможность перевести устройство в режим sideload. Для большинства популярных устройств, поддерживающих разблокировку загрузчика, существуют готовые образы TWRP.

Если задуматься, то ситуация с физическим доступом к смартфону не такая уж и невероятная. Например, последние годы набирает тенденция проверки мобильных устройств пограничниками при въезде в страну. Количество подобных проверок увеличивается в разы с каждым годом и вскоре может стать повсеместно распространённой практикой. С одной стороны это вопиющий произвол, нарушение законов и вторжение в частную жизнь, с другой стороны, законы большинства стран в этом моменте очень скользкие, плюс, например, на границе вы ещё не попали на территорию страны, поэтому и законы защищающие вашу частную жизнь ещё могут не действовать. В общем, «отжать мобилу» у вас смогут в подавляющем большинстве случаев. В журнале Хакер есть отличная статья обозревающая эту проблему. Если по каким-либо причинам вас задержит полиция, то все ваши электронные устройства также будут изъяты и, как и на границе, могут быть незаметно для вас пробэкдорены.  

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

Итак, представим ситуацию, мы – злоумышленник, получивший на некоторое время в свои руки смартфон. Устройство – смартфон на базе 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 но не для разработчиков приложений, а для разработчиков устройств. Там хорошо описана работа ОС, системных компонентов, и т.д. Очень рекомендую, вряд ли где-то можно найти более структурированную информацию по устройству системы.

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

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

• На плату устройства подаётся питание

• Выполняется первичный загрузчик (primary bootloader, PBL). Он хранится в ПЗУ чипа. Он производит инициализацию памяти некоторого минимального набора для работы с железом, например с физическими кнопками устройства и партициями.

• Далее исполняется aboot. Он собирает информацию для того, чтобы понять что и как именно нужно запустить. На этом этапе он смотрит на флаги записанные в специальной памяти, на зажатые физические кнопки, и принимает решение в каком режиме продолжить загрузку системы: в штатном режиме, в режиме восстановления (recovery), в режиме прошивки (fastboot). Загрузчик может также загружать другие специальные режимы, которые зависят от конкретного чипа или устройства, например EDL на чипах Qualcomm который используется для экстренного восстановления устройства путём загрузки прошивки образа подписанного ключами Qualcomm публичная часть которых зашита внутрь чипа. Мы будем рассматривать штатный процесс загрузки.

• Некоторые устройства используют механизм seamless updates, его также называют A/B partitions. В этом случае загрузчик обязан выбрать правильный текущий слот для загрузки. Суть этого механизма в том что некоторые разделы представлены в двух экземплярах, например вместо обычного /system на устройстве будут /system_a и /system_b, вместо /vendor — /vendor_a и vendor_b. Цель этого — более быстрые и защищённые от окирпичивания устройства обновления системы, т.е. например вы загружены в систему используя слот A, вы собираетесь обновить устройство, выбираете соответсвующий пункт в настройках и продолжаете спокойно работать с системой. Пакет обновления скачивается, но вместо перезагрузки в специальный режим обновления и ожидания прошивки, оно сразу шьётся, но не на запущенную систему (это и не получится сделать) а в разделы второго слота B: /system_b, /vendor_b и, если необходимо, в другие. После прошивки система отмечает флаги что следующая загрузка системы должна быть штатной и должна использовать слот B и предлагает перезагрузиться. Вы перезагружаете устройство, загрузчик выбирает слот B и продолжает загрузку, всего через несколько секунд ожидания ваша новая ОС загружена, отмечаются флаги что загрузка прошла успешно, текущий образ системы работает, с ним всё хорошо, а значит можно продублировать текущую систему во второй слот. В случае если загрузка не закончится успехом, то система не поставит флаги об успехе и загрузчик поймёт что новая система не работает, нужно загрузиться в старый слот, повреждённое обновление на него не накачено и вы продолжите работать с устройством как ни в чём не бывало.

• Продолжается штатная загрузка. Загрузчик ищет в подключённых устройствах раздел /boot. Этот раздел содержит две необходимые для запуска системы составляющие: ядро ОС — kernel, и начальный образ файловой системы — initramfs (в android он практически везде называется ramdisk и я далее буду называть его именно так). Вот здесь начинают работать механизмы защиты ОС от модификации или наоборот, их работа отключается в том случае если наш загрузчик был разблокирован. При загрузке считается хэш сумма данных содержащихся в /boot разделе и сравнивается с эталонным хэшом который рассчитан и подписан приватным ключом производителя устройства в момент сборки системы, эта подпись должна быть успешно верифицирована AVB ключом хранящимся в TEE. В случае разблокированного загрузчика этой проверки не производится, т.е. система будет запускать любые ядро и ramdisk, даже если они не подписаны производителем устройства.

• Механизмы защиты продолжают работу. Далее проверяется что целостность загружаемого раздела с системой также не нарушена. Ramdisk хранит публичный ключ verity_key, приватной частью которого подписан корневой хэш в таблице dm-verity хешей для системного раздела. Осуществляется проверка подписи после чего происходит переход к загрузке системы. Если загрузчик нашего устройства разблокирован, то эта проверка также пропускается.

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

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

• green state — загрузчик заблокирован, используется embedded root of trust, т.е. публичный ключ avb поставляется в аппаратном TEE. Целостность ядра и системы не нарушена. Никаких сообщений пользователю не показывается. Система загружается. Так происходит всегда когда мы пользуемся обычным, не модифицированным устройством.

• orange state — загрузчик разблокирован, root of trust игнорируется. Целостность ядра и системы не проверяется. Пользователю на 10 секунд показывается большой оранжевый предупреждающий знак и сообщается что целостность разделов устройства не проверяется, и система может быть модифицирована. После этого система загружается. Так происходит на устройствах с установленными root-правами или альтернативной сборкой ОС, именно этот случай нас интересует.

• red state — загрузчик заблокирован, используется любой root of trust, целостность системы нарушена при заблокированном загрузчике, либо система повреждена (что для dm-verity в общем-то одно и тоже, как описано в документации). Пользователю показывается сообщение о том, что система повреждена. Система не загружается.

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

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

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

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

# ls -la /dev/block/by-name
total 0
drwxr-xr-x 2 root root 1480 1973-02-10 03:40 .
drwxr-xr-x 4 root root 2160 1973-02-10 03:40 ..
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 LOGO -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 abl -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 ablbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 apdp -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 bluetooth -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 boot -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 boot_aging -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 cache -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib64 -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlib64bak -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 cmnlibbak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 config -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 devcfg -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 devinfo -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dip -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dpo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 dsp -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 frp -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 fsc -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4g9n4 -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4j1ed -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_4t0n8 -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 fw_8v1ee -> /dev/block/sde44
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 hyp -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 hypbak -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 keystore -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 limits -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 logdump -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 logfs -> /dev/block/sde37
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 md5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtp -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtpsecapp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 mdtpsecappbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 minidump -> /dev/block/sde47
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 misc -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 modem -> /dev/block/sde10
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 msadp -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 oem_dycnvbk -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 oem_stanvbk -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 param -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 pmic -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 pmicbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 recovery -> /dev/block/sde22
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 reserve -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 reserve1 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 reserve2 -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 reserve3 -> /dev/block/sdf7
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 rpm -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 rpmbak -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 sec -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 splash -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 sti -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 storsec -> /dev/block/sde41
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 storsecbak -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 system -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 toolsfv -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 tz -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 tzbak -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1973-02-10 03:40 userdata -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 vendor -> /dev/block/sdf6
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1973-02-10 03:40 xblbak -> /dev/block/sdc1

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

• Раздел boot содержит ядро операционной системы. 

• Раздел system содержит саму операционную систему, все её исполняемые файлы, неизменяемые конфиги, системные библиотеки, android-фреймворк и другие jar файлы необходимые для работы виртуальной машины, в которой исполняются android приложения. Начиная с android 10 на многих устройствах вместо обычного system раздела используется раздел system-as-root, он отличается точкой монтирования, но его суть та же – он содержит файлы ОС.

• Раздел vendor содержит проприетарные компоненты ОС от производителя устройства. Например, драйвера Qualcomm и т д

Данные приложений, «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.

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

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

• FDE – full-device-encryption – полнодисковое шифрование. Это значит что всё устройство хранения зашифровано, и даже загрузка операционной системы невозможна до его расшифровки. Поэтому в этом случае владельцу устройства для работы с ним сначала, ещё до загрузки операционной системы, необходимо ввести ключ с помощью которого хранилище будет расшифровано и только потом произойдёт загрузка системы. Такой подход требовал «двойной» загрузки системы, сначала в минимальном варианте для показа формы ввода пароля, а потом в полноценном, после расшифровки хранилища. Он применялся на некоторых устройствах с версиями android 5-7, однако на современной версии ОС и современных устройствах не используется

• FBE – file-based-encryption – шифрование отдельных частей файловой системы. Применительно к android зашифрованы только те части системы, где хранятся данные пользователя. Незашифрованным остаются ядро, системный раздел, и т.д. Строго говоря, проще перечислить то, что зашифровано, а зашифрованы только /data/data и /data/media. Все остальные части системы остаются незашифрованными. Это позволяет операционной системе успешно загружаться до экрана авторизации пользователя, стартовать системные сервисы и accessibility сервисы, принимать SMS. Начиная с android 7 и переходом на FBE появилось Directboot API, которое даёт приложениям возможность запускаться и в ограниченном режиме работать до ввода кода разблокировки и расшифровки файловой системы. FBE позволяет сочетать высокие стандарты защиты данных в хранилище и отличный пользовательский опыт. Пользователь не отвлекается на ввод дополнительного пароля до запуска системы, система не тратит ресурсы на шифрование и расшифровку частей файловой системы где не содержится личных данных владельца. Это современный подход, который используется на современных устройствах и является обязательным для всех новых устройств, начиная с android 9.

• BFU (before first unlock) – до первого ввода кода разблокировки

• AFU (after first unlock) – после первого ввода кода разблокировки

До первого ввода кода разблокировки данные пользователя всегда зашифрованы, после первого ввода – всегда расшифрованы. Даже когда пользователь в дальнейшем нажимает кнопку питания или система сама уходит в сон, то данные, с точки зрения ОС, больше не переходят в зашифрованное состояние, теперь их защищает только экран блокировки. В 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

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

• Во-первых, получать доступ к личным файлам пользователя в любом случае придётся только после ввода кода разблокировки. 

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

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

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

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

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

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

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

• Будучи обычным приложением она будет попадать под управление жизненным циклом, система в лучшем случае будет отправлять её в сон в doze-mode, в худшем – просто убьёт и перезапустить её будет некому. Умер процесс приложения – умер и процесс агента, поскольку является дочерним процессом приложения. 

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

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

• Ядро и ramdisk распаковывается в оперативную память, и загрузчик запускает ядро.

• Ядро стартует, инициализирует устройства, драйверы и т.д. и монтирует ramdisk в корень файловой системы. Ramdisk содержит минимальный набор файлов необходимых для запуска пользовательской части системы. Бинарник init, минимальный скрипт init.rc для него, точки монтирования разделов: /system, /vendor и др. и информацию об устройствах которые необходимо в них смонтировать. Вот тут описаны примеры содержания ramdisk для разных версий android. 

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

• Первое что делает процесс init сразу после запуска — загружает скомпилированные политики SELinux и применяет их. SELinux — это механизм ядра для принудительного контроля доступа, пришедший в android из RedHat-подобных дистрибутивов. Мы ещё вернёмся к нему и рассмотрим его более подробно.

• Далее процесс init парсит скрипт init.rc из ramdisk, который содержит список действий которые необходимо совершить для успешной загрузки системы, а также какие ещё .rc скрипты необходимо загрузить. Android использует свой формат скриптов для загрузки компонентов системы.

• После отработки всех скриптов мы получаем полностью запущенную систему.

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

Исходный 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 сообщит нам что-то похожее на это:

avc: denied { transition } scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0