Root nima

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

Присоединяйся к сообществу «Xakep. ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку!
Подробнее

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

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

Причина #1. Bloatware

Практически все устройства на базе Android поставляются с огромным количеством предустановленных приложений. Так, в прошивках HTC в каталогах /system/app и /system/priv-app находится около 400 пакетов, и это не только языковые пакеты и компоненты сервисов самой компании, но и приложения Google, которая требует, чтобы смартфон с предустановленным Google Play Market также содержал и несколько десятков других приложений компании (Gmail, Google Drive, Google Keep и другие).

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

Имея права root, удалить «блоат» очень просто. Для этого есть множество приложений, которые легко найти в маркете по запросу «system app remover». Придется, конечно, разобраться, какие приложения можно удалять, а какие лучше оставить, но эту информацию легко найти на форумах, в том числе русскоязычных.

Первый попавшийся System app remover

Причина #10. Тюнинг системы

Последняя причина, по которой стоит получить root, — это так называемая оптимизация системы. Я не просто так говорю «так называемая» и не случайно поставил эту причину на последнее место. Дело в том, что практически не существует способов повысить производительность системы на стоковой прошивке смартфона нормального производителя системы. Все, что ты выиграешь, — это максимум 1–2%.

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

Один из так называемых «оптимизаторов системы»

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

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

Как работают 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 в своём сервисе!

Причина #8. Полная отвязка от Google и других сервисов

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

1Mobile: анонимный маркет для Android

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

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

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

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

●     Мобильное приложения. Необходимо установить SuperSu или его аналог и в настройках выбрать функцию После завершения перезагрузите устройство.

●     Утилит для ПК. Метод считается более трудоемким из-за работы в нескольких программах. Дело для специалиста.

SELinux

Безопасность в android устроена сложнее чем хотелось бы злоумышленникам и представляет из себя многослойную систему. Unix DAC (discretionary access control), привычная нам система пользователей и назначения прав на файлы типа rwxrwxrwx является лишь частью мер по предотвращению злоупотребления операционной системой и устройством. Помимо неё есть ещё MAC (mandatory access control), в android это SELinux (Security Enhanced Linux). Суть MAC в возможности намного более гибко управлять доступом к различным ресурсам чем DAC, в том числе описывая для этого свои уникальные сущности и правила.

Уровни контроля доступа в android

Отсюда следует несколько неочевидный ранее вывод – на android root-права в привычном для других дистрибутивов linux понимании, т.е. когда uid пользователя в системе равен 0, вовсе не означают что мы можем делать всё что угодно. Несмотря на то, что процесс init запущен с uid=0, он не может запустить сторонний сервис. Дело в том что SELinux не оперирует понятиями системных пользователей и групп, и если какое-то действие не было явно разрешено, то он его запретит и ему безразлично пытается ли его совершить непривилегированный пользователь или root. Он работает «выше» DAC и может запретить любое действие, которое DAC разрешил.

Вот отличный пример в android с самим файлом, содержащим политики SELinux:

$ ls -laZ /sys/fs/selinux/policy
-r—r—r— 1 root root u:object_r:selinuxfs:s0 0 1970-01-01 03:00 /sys/fs/selinux/policy
$ cat /sys/fs/selinux/policy
cat: /sys/fs/selinux/policy: Permission denied

На нём стоит доступ для чтения для любых пользователей, но при попытке прочитать его мы получим Permission denied, потому что ни для процессов с контекстом u:r:shell:s0, ни для процессов с контекстом u:r:untrustedapp:s0 нет разрешения на чтение файлов u:objectr:selinuxfs:s0.

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

Контекст SELinux на процессах и файлах можно посмотреть, добавив к выполняемой команде флаг -Z. Например, для просмотра контекстов на файлах в текущей папке можно вызвать команду ls -laZ, а на процессах, соответсвенно, ps -efZ.

Как было упомянуто выше в секции про процесс загрузки системы, первое действие которое совершает процесс init – загружает и применяет политики SELinux, а одна из первых применяемых политик заключается в том что процессу с контекстом u:r:init:s0 запрещается делать transition в другой контекст. Политики SELinux специально строятся по принципу «запрещено всё что не разрешено», и создатели операционной системы, разумеется, позаботились о том, чтобы злоумышленник получивший возможность прописать запуск какого-то сервиса в автозапуск не смог это сделать. Контекст процесса init организован таким образом что он может запустить только те системные сервисы, для которых явно прописано разрешение на запуск во время загрузки системы, и после сборки системы это изменить нельзя.

SELinux может работает в трёх режимах:

В нормально работающей системе android версии от 5.0 SELinux всегда будет в режиме enforcing. Если по каким-то причинам он будет переведён в режим permissive, то пользователю ещё до ввода кода разблокировки покажут большое страшное уведомление об этом и о том что его система небезопасна. Мы точно не имеем права переводить SELinux в permissive режим, потому что это выдаст пользователю факт модификации его устройства, и он может предпочесть уничтожить данные.

В каждой версии android, начиная с 5 политики SELinux сильно ужесточаются и всё меньше и меньше всего остаётся разрешённым. Иронично, но начиная с android 8 даже если прошить в системный раздел исполняемый файл su и сделать его системным и принадлежащим root:root, он не сможет работать без специально назначенных ему политик.

Тем не менее инструменты для получения root-прав существуют, и они умеют обходить ограничения MAC, работать на самых свежих версиях android и даже на устройствах, которые помимо них дополнительно имеют отдельные механизмы контроля целостности системы (например устройства Samsung). Так как же тогда работает root в современных реалиях?

Причина #7. Двойная загрузка

Имея root, на смартфоне можно организовать двойную, тройную и какую угодно другую загрузку. Просто устанавливаем MultiROM Manager, нажимаем кнопку Install, перезагружаемся и получаем смартфон, на который можно установить сколько угодно прошивок, причем не только Android, но и Ubuntu Touch, Sailfish OS или Firefox OS.

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

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

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

Причина #5. Xposed

Xposed — это фреймворк, позволяющий приложениям вклиниваться в работу любого компонента системы или приложения и изменять его поведение (так же как это делает фреймворк MobileSubstrate для iOS). Простыми словами — Xposed позволяет устанавливать твики, так же как это позволяет делать Cydia в iOS.

Твиков для Xposed существует сотни, буквально на все случаи жизни. С их помощью можно изменять внешний вид системы (твики GravityBox и Android Theme Engine), тонко настраивать прошивки от производителей (Sense Toolbox, XTouchWiz), запускать приложения в плавающем окне (XHaloFloatingWindow), изменять системные настройки отдельно для каждого приложения (App Settings позволяет менять язык, DPI, ориентацию экрана и многое другое), отзывать полномочия на доступ к функциям системы у приложений (XPrivacy) и многое другое.

Инсталлятор твиков Xposed

Легальные 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, поэтому закрепиться в качестве системного демона подобным образом всё равно не получится, а значит для извлечения данных нам необходимо воспользоваться другим подходом.

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

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

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

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

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

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

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

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

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

Немного истории

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

Чтобы не повторять процесс каждый раз и чтобы предоставить возможность и другим приложениям использовать права суперпользователя, в системный раздел помещали файл su (как правило, в каталоге /system/xbin/) и приложение для обработки запросов прав root (в /system/app/). Чтобы получить права root, приложение запускало su, в этот момент срабатывал менеджер обработки запросов и запрашивал у пользователя подтверждение.

Такая схема прекрасно работала во всех версиях Android вплоть до пятой, а добытый с ее помощью root-доступ чаще всего не мешал получать обновления прошивок и даже иногда сохранялся после таких обновлений. Популярностью пользовались многочисленные приложения, эксплуатировавшие одну или несколько уязвимостей (например, Towelroot). Со временем большую аудиторию набрали китайские приложения KingRoot и Kingo Root, включавшие в себя большие коллекции эксплоитов, которые скачивались непосредственно в момент запуска с китайских серверов. В случае успешной эскалации привилегий эти приложения прописывали в системный раздел много интересного; удалить их можно было либо вместе с root-доступом, либо с помощью специального «чистильщика», сделанного разработчиком SuperSU Chainfire.

В Android 5.0 была введена новая система обновлений. Теперь в файле OTA изменения прописывались не на файловом, а на блочном уровне; чтобы не повредить файловую систему, инсталлятор обновления подсчитывал контрольную сумму системного раздела. Естественно, записанный в раздел /system файл su изменял контрольную сумму раздела, и обновление не устанавливалось (а в тех случаях, когда оно все-таки ставилось, был высокий шанс получить на выходе «кирпич»).

Шестая версия Android принесла и обновленную систему безопасности, которая (временно) сделала невозможным получение прав суперпользователя простой записью приложения в системный раздел. В результате появился обходной путь — так называемый systemless root, внедряющий su в ramdisk вместо модификации системного раздела. На некоторых устройствах с «бессистемным» root-доступом даже получалось устанавливать OTA-обновления; впрочем, гарантии тут никакой.

Как был получен root на HTC Dream G1

Впервые root был получен на первом в мире Android-устройстве HTC Dream G1, выпущенном в далеком 2008 году. На устройстве был запущен сервис Telnet с правами root и без аутентификации. Для получения временного root-доступа было достаточно подключиться к смартфону по Telnet, для постоянного — залить в системный раздел бинарный файл su.

Внедряемся в систему с установленными 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-прав.

Причина #4. Реклама

Но если у тебя есть root, проблема решается очень просто, причем раз и навсегда, на уровне всей системы. Достаточно установить AdAway, нажать кнопку «Загрузка файлов и применение блокировки рекламы» и перезагрузиться. В дополнение к полному избавлению от рекламы ты получишь сокращение потребления трафика, так как хосты, раздающие рекламу, жестко блокируются на самом низком уровне (если быть точным, они просто перенаправляются на localhost с помощью файла /system/etc/hosts).

Как проверить успешность загрузки

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

Причина #6. X-Tools

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

После получения root на смартфоне/планшете можно использовать огромное количество разнообразных инструментов, таких как сетевой сканер Nmap, представленный в маркете в нескольких вариантах (например Network Mapper), снифер tcpdump (Shark for Root), знаменитый инструмент для перехвата и анализа пакетов Intercepter-NG и даже легендарный Linux-дистрибутив Kali. В последнем случае, правда, понадобится один из Нексусов либо смартфон OnePlus One. О том, как его установить, читай в статье «Атака со смартфона».

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

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

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

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

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

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

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

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

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