• Партнер

  • Мы систематизировали самые распространенные способы получить права суперпользователя в актуальных версиях 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. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

    Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

    Вариант 2. Открой один материал

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


    Подписаться
    Уведомить о
    11 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии