Про production build и root. Часть 1.

Android girl

В сети легко найти как получить рут доступ для почти любого устройства на Android. Программы для этого и методики отличаются, но вариант всегда есть. Большинство, получив рут, даже не задумываются о том, как он был получен. Я не смогу рассказать про все способы и как они работают. Но я смогу рассказать про одну интересную вещь, которая связана с получение root доступа.

Я предполагаю, что читатели хотя бы поверхностно знаю об утилите для Android - ADB. Если кто-то еще не слышал, можете легко поиском найти что это такое. Это утилита для отладки устройств. С её помощью можно получить доступ к командной строке (shell) устройства на Android, передавать и принимать файлы и делать много интересных вещей. В большинстве скриптов для получения рута или всяких модов для вашего устройства так или иначе используется ADB.

У ADB есть команда root. Она должна перевести режим работы в root доступ. Казалось бы так можно элементарно получить рут на любом устройстве. Но работает она не всегда. Часто, даже на устройстве с уже полученными root правами при попытке выполнить "adb root" можно получить следующую ошибку:

adb cannot run as root in production builds

Что значит, что ADB не будет запускаться из-под root'а в продакшен (финальном) билде (речь о прошивке). Если у вас есть рут, вы можете и без этого зайти в шелл (adb shell), и уже там получить root права, набрав su. При этом adb root упорно не будет работать, сетуя на продакшен билд.

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

Раз работает по разному в разных прошивках, догадливый читатель поймет, что это может регулироваться какой-то настройкой. И если эту настройку сменить, то можно будет получить root просто через adb root. Конечно же так и есть. Но конечно же эта настройка храниться в "недрах" прошивки и просто так её поменять не дадут. Во всяком случае в современных прошивках без наличия root прав заранее точно не получится "на лету".

Настройки эти являются обычными свойствами (prop), навроде тех, что хранятся в build.prop. Называются ro.debuggable и ro.secure. Только хранятся они в /default.prop. Т.е. в отличии от build.prop, которых хранится в /system, эти хранятся прямо в корне. Проблема в том, что даже если при наличии root прав отредактировать этот файл, то изменения не вступят в силу, а после перезагрузки содержимое файла вернется назад.

Дело в том, что default.prop, как и вся корневая файловая система в Android не является обычной. Это специально подготовленный образ ramdisk. Т.е. он загружается из прошивки в память (ОЗУ) и все изменения происходят только в памяти. Следовательно после перезагрузки все изменения теряются. Для их редактирования нужно снять образ раздела BOOT, распаковать его, достать оттуда образ ramdisk'а (initramfs) и отредактировать в нём default.prop. Далее проделать всё в обратном порядке. Но как записать данные назад, если нет доступа? Хорошо, если root у нас уже есть и мы просто хотим напрямую разрешить adb root по каким-то причинам. А если root еще нет? Получается проблема - чтобы получить root, нужно иметь root. cheeky

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

Метки: 
Оцените статью: 
В среднем: 3.6 (проголосовало 118)

Про production build и root. Часть 2.

Android girl

Продолжаем первую часть статьи. Ссылка на первую часть есть выше.

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

Первый и очевидный - отредактировать файл самой прошивки специальным образом и прошить её в устройство с компьютера. Так собственно и работают некоторые "рутовалки", которые прошивают "скрипт" из рекавери режима (на деле прошивают часть раздела).

Второй - очень старый эксплоит, он работал только в Android версий до 2.2 включительно. Он использует ошибку в ADB. Изначально ADB всегда запускается от root'а. А затем права сбрасываются. Вот кусок кода из этого старого ADB:

Код ADB

Из него следует, что он читает значение ro.secure. Если там стоит 1 (production build), только дальше по тексту кода права сбрасываются до уровня пользователя (setgid/setuid).

Эксплоит использовал простую особенность функций setuid/setgid - если нет ресурсов для смены владельца процесса, смена владельца не происходит. А проверки на это в коде ADB нет! Следовательно эксплоит просто занимал все ресурсы и потом перезапускал ADB. Бах, и он не смог понизить привилегии и остался с правами root. Получен временный root - можно дальше уже и постоянный делать.

Конечно второй метод уже давно устарел, но как говориться для исторической справки, да и вообще полезно будет знать как оно устроено в целом. Тем более, что про такие вещи по русски вы нигде не прочитаете. smiley

Надеюсь вам было интересно, а вопросы и подробности вы как всегда сможете сможете выяснить в комментариях!

Оцените статью: 
В среднем: 3.4 (проголосовало 742)