Мы систематизировали самые распространенные способы получить права суперпользователя в актуальных версиях Android; разобрались в различиях между SuperSU, phh SuperUser, Magisk, KingRoot и Kingo Root; протестировали различные способы скрыть root; изучили систему безопасности Android 7 и узнали, чем может грозить получение root на новых версиях Android. Ну а потом закрылись в комнате без окон и произвели на свет этот текст.
 

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

Обладатели ранних версий 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 в Android 7

Особняком стоят устройства, выпущенные с Android 7 на борту (впрочем, то, о чем мы сейчас будем писать, относится и ко многим устройствам, которые получают Android 7 в качестве обновления).

Как ты, наверное, знаешь, механизм безопасной загрузки (Verified Boot) был реализован в Android давным-давно, еще в версии 4.4 KitKat. Его цель — защитить пользователя от атак, направленных на модификацию системы и внедрение в нее кода еще до начала загрузки системы. Для этого он использует скрытый в модуле TEE ключ, чтобы сверить цифровую подпись загрузчика, далее загрузчик сверяет цифровую подпись раздела boot, а он, в свою очередь, проверяет целостность системного раздела с помощью механизма dm-verity (Device Mapper verity).

Такая цепочка проверок (называемая root of trust) позволяет удостовериться в целостности и отсутствии модификаций в любом компоненте загрузки, начиная от загрузчика и заканчивая самой ОС. Но если большинство устройств под управлением Android 4.4–6.0 (за редкими исключениями вроде смартфонов BlackBerry и Samsung с активированным Knox) в случае неуспешной проверки просто выводили предупреждение, но продолжали загрузку, то в Android 7.0 ситуация изменилась и новая-старая функция проверки целостности системы стала обязательной.

Verified Boot позволяет загрузить модифицированный boot-образ в случае, если загрузчик разблокирован (слева), но откажет в загрузке, если он был модифицирован при залоченном загрузчике
Verified Boot позволяет загрузить модифицированный boot-образ в случае, если загрузчик разблокирован (слева), но откажет в загрузке, если он был модифицирован при залоченном загрузчике
Verified Boot позволяет загрузить модифицированный boot-образ в случае, если загрузчик разблокирован (слева), но откажет в загрузке, если он был модифицирован при залоченном загрузчике
Verified Boot позволяет загрузить модифицированный boot-образ в случае, если загрузчик разблокирован (слева), но откажет в загрузке, если он был модифицирован при залоченном загрузчике
Verified Boot позволяет загрузить модифицированный boot-образ в случае, если загрузчик разблокирован (слева), но откажет в загрузке, если он был модифицирован при залоченном загрузчике

Чем это грозит? Тем, что старый метод получения root через эскалацию привилегий в Android 7 просто не работает. Даже если приложения класса KingRoot, Kingo Root и им подобные смогут рутануть девайс (а в данный момент они не могут), устройство после этого просто не загрузится.

Как это обойти? Разблокировать загрузчик штатными средствами и установить SuperSU или Magisk. В этом случае загрузчик просто отключит механизм Verified Boot. Однако не стоит даже пытаться взломать загрузчик на устройствах, не предполагающих такую возможность. Даже если это удастся сделать, взломанный загрузчик не пройдет проверку цифровой подписи — и смартфон превратится в кирпич.

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

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

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


8 комментариев

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Windows 10 против шифровальщиков. Как устроена защита в обновленной Windows 10

Этой осенью Windows 10 обновилась до версии 1709 с кодовым названием Fall Creators Update …