- Android boot img recovery img
- Android boot img recovery img
- Android boot img recovery img
- Как получить образ Recovery из boot.img? Учимся работать с applypatch.
- Копаем глубже. Как работают механизмы прошивки, рутинга и восстановления Android
- Содержание статьи
- Aboot, fastboot и tamper-бит
- Xakep #200. Тайная жизнь Windows 10
- Раздел boot и ядро
- Recovery, Edify и Aroma Installer
- Root insecure adb
- Выводы
- Евгений Зобнин
Android boot img recovery img
/ramdisk# gzip -dc ../boot.img-ramdisk.gz | cpio -i
986 блок
[email protected]:
#
В папке ramdisk 18 объектов, всего 514,6 КБ
Где все остальное ?? где файлы ядра ?
Какие еще файлы ядра??
boot.img-kernel — это zImage-образ ядра. Если ты имеешь ввиду исходники ядра, то с образа их никак не получишь.
boot.img-ramdisk.gz — cpio/gz архив рамдиска с init.rc и прочей хренью. Его содержимое распаковано в папку ramdisk.
А больше ничего в буте и нету. То же самое касается и recovery.img
system.img (и userdata.img) — образ файловой системы в формате yaffs2. Распаковывается утилитой unyaffs под линухом. Ну или могу под винду утилиту подкинуть.
Ну что же, мысль здравая, если знаете что к чему.
1 Скачайте/найдите в интернете исходники для своего устройства. Если устройство htc, то developer.htc.com, если другое, ищите в интернете.
2 Ввнесите нужные изменения в файл arch/arm/mach-msm/acpuclock.c,
3 Скачайте к примеру NDK с андроидовского сайта (нужно для кросс-компиляции). Как я понял, у вас убунту. Тогда дальше все просто.
4 ARCH=arm CROSS_COMPILE=/путь_куда_установили_ndk/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- make zImage
5 mkbootimg —kernel arch/arm/boot/zImage —ramdisk ваш_рамдиск.gz —cmdline то_что_писало_когда_вы_извлекали_рамдиск -o boot.img
6 adb push boot.img /cache/ && adb shell flash_image boot /cache/boot.img
Нельзя ли поподробней с компиляцией ?
Вот эту строку которую вы указали, ка я понял надо вписывать в Makefile ? И вообщем у последнего NDK совсем другой путь папок ! Может дадите ссылку на ваш NDK ?
И еще можно ли делать компиляцию через arm-2007q3 как написано тут http://www.anddev.org/learning_porting_and. step-t3252.html .
Или через windows компиляцию сделать можно ?
Сообщение отредактировал bobjob — 17.02.11, 17:33
unyaffs под винду.
При распаковке:
— теряются owners, permissions и даты создания/изменения/доступа
— симлинки заменяются на файлы в фигурных скобках <>, внутри — путь куда указывает симлинк
Просто для извлечения данных этого вполне достаточно.
Написано на коленке в делфях.
Использование: unyaffs.exe файл.img
Cygwin не нужен.
Скачать: unyaffs.zip ( 12.23 КБ )
Источник
Android boot img recovery img
winXP — НЕ ПОДДЕРЖИВАЕТСЯ. — у меня даже дистрибутивов таких уже нет, все железо которое у вас есть — без труда будет работать и на win7, не будьте впертыми ретроградами.
Краткое описание:
Разбирает, собирает boot и recovery БЕЗ установки сторонних програм типа CygWin или VM с линуксом.
Описание:
Утилита для распаковки/упаковки boot.img или recovery.img под WINDOWS!
Отныне не требуется установка дополнительных сторонних программ типа Cygwin или VM с убунтой для осуществления этого по-сути несложного процесса. Подключение телефона и проведение каких-либо манипуляций с ним также не требуется (в отличии от предыдущего способа).
Все исполняемые файлы (половина *.exe от Cyqwin) лежат в папочке bin + 2 батника.
Немного теории и вообще о процессе создания.
Как известно boot (recovery то же самое) состоит из нескольких частей:
— header
— kernel header
— kernel
— ramdisk_header
— ramdisk
Собственно разбирается только ramdisk — в нем структура папок и исполняемые файлы. Остальное не разбирается. Вообще т.е. никак.
Ramdisk — это gzip архив внутри которого cpio архив внутри которого папки и файлы.
Т.е. процесс разборки выглядит так:
— ищем offset для всех блоков
— режем файл на куски
— ramdisk распаковываем 2мя разными архиваторами.
Обратный процесс аналогичен, но еще нужно в ramdisk_header вставить новый размер нового ramdisk.
Проблем было очень много.
1. Отсутствие в windows инструментария (команд у command.com) — никаких команд по поиску offset, работы с HEX, разделением/склеиванием файлов, поиска внутри файлов и т.п. и т.д. там нет. В общем это давно всем известно. В линуксе они есть — а в винде — нету.
Поэтому были привлечены сторонние утилиты, а также частично утилиты из cygwin — например find, dd, cpio, gzip и также одна универсальная утилита для windows — Swiss File Knife — A Command Line Tools Collection. http://stahlforce.com/dev/swiss-file-knife.html
Само собой все это работает как ему хочется и увязать с батником дело не простое, но.
2. Основная засада из-за которой не получалось раньше пересобрать boot под windows — при работе с cpio и gz архивами терялись симлинки (symliink) а также (!) права. Если симлинки удалось починить почти сразу (cpio от cygwin в отличии от сторонних архиваторов с поддержкой cpio) прекрасно их сохраняет и восстанавливает, то вот с правами была полная засада. причем очень интересный момент — выяснил почти случайно.
Права на сами файлы и папки из директории rmdisk оставались такими как и было нужно, а вот на папку rmdisk права НЕ сохранялись при упаковке. В моем случае для создания архива использовалась функция «find .» — которая выводит список файлов внутри директории — и надо же так получится, что корневая папка тоже участвует в процессе — хотя ведь ее нет в архиве.
и отображается в cpio архиве как точка бл. с правами. вот когда я это увидел — попробовал прямо в cygwin сделать chmod на папку — и чудо чудное — бут загрузился и тело включилось! Затем недолго думая я выдернул chmod из пингвина и вставил в скрипт.
Каким образом это работает в windows — я хз если честно. Думаю что уровне NTFS.
Ну в общем вот как-то так.
Требования:
— к структуре boot.img http://android-dls.com/wiki/index.php?titl. ack_Boot_Images
— к Windows — не ниже XP и тип файловой системы — NTFS
— установленная Java JRE или JDK (а может и не нужно оно. )
Телефоны, на которых получилось препаковать boot.img:
Standart:
Samsung Galaxy S i9001, S III, Note II
HTC Evo, Desire V
MTK:
— пока не попадалось таких чтобы не разобралось
КРЯКОЗЯБРЫ — правой мышкой клик на заголовке окна, выбрать шрифт — TT (любой)
В путях к рабочим папкам НЕ ДОЛЖНО БЫТЬ РУССКИХ И КИТАЙСКИХ БУКВ. ПРОБЕЛОВ И прочего.
Скачать:
версия: 4.0 Boot_Recovery_Repack_Util_v4_win7-8_x64.rar ( 2.53 МБ )
Сообщение отредактировал Slav_nsk — 06.06.16, 19:12
Источник
Android boot img recovery img
A tool for reverse engineering Android ROM images.
install required packages
Linux: sudo apt install git device-tree-compiler lz4 xz-utils zlib1g-dev openjdk-11-jdk gcc g++ python3 python-is-python3
Mac: brew install lz4 xz dtc
Mac: Make sure you have JDK9+ properly installed.
Windows Subsystem for Linux(WSL): sudo apt install git device-tree-compiler lz4 xz-utils zlib1g-dev openjdk-11-jdk gcc g++ python
Windows: Make sure you have python3 , JDK9+ and openssl properly installed. An easy way is to install Anaconda and Oracle JDK 11, then run the program under anaconda PowerShell. Or install them with chocolate: choco install openssl dtc-msys2
Parsing and packing
Put your boot.img to current directory, then start gradle ‘unpack’ task:
Your get the flattened kernel and /root filesystem under ./build/unzip_boot:
Then you can edit the actual file contents, like rootfs or kernel. Now, pack the boot.img again
You get the repacked boot.img at $(CURDIR):
Well done you did it! The last step is to star this repo :smile
Supported ROM image types
Image Type | file names | platforms |
---|---|---|
boot images | boot.img, vendor_boot.img | all |
recovery images | recovery.img, recovery-two-step.img | all |
vbmeta images | vbmeta.img, vbmeta_system.img etc. | all |
dtbo images | dtbo.img | linux & mac |
sparse images | system.img, vendor.img, product.img etc. | linux & mac |
Please note that the boot.img MUST follows AOSP verified boot flow, either Boot image signature in VBoot 1.0 or AVB HASH footer (a.k.a. AVB) in VBoot 2.0.
Device Model | Manufacturer | Compatible | Android Version | Note |
---|---|---|---|---|
ADT-3 (adt3) | Askey/Google | Y | 12 (spp2.210219.010) | amlogic inside, Android TV |
Pixel 3 (blueline) | Y | 12 (spp2.210219.008, 2021) | ||
Pixel 3 (blueline) | Y | 11 (RP1A.200720.009, 2020) | more . | |
Pixel 3 (blueline) | Y | Q preview (qpp2.190228.023, 2019) | more . | |
Redmi K30 4G (phoenix[n]) | XiaoMi | Y | 10 | verified by @eebssk1 |
TS10 | Topway | Y | 10 | car headunit, @mariodantas |
Pixel XL (marlin) | HTC | Y | 9.0.0 (PPR2.180905.006, Sep 2018) | more . |
K3 (CPH1955) | OPPO | Y for recovery.img N for boot.img | Pie | more |
Z18 (NX606J) | ZTE | Y | 8.1.0 | more. |
Nexus 9 (volantis/flounder) | HTC | Y(with some tricks) | 7.1.1 (N9F27M, Oct 2017) | tricks |
Nexus 5x (bullhead) | LG | Y | 6.0.0_r12 (MDA89E) | |
Moto X (2013) T-Mobile | Motorola | N | ||
X7 (PD1602_A_3.12.8) | VIVO | N | ? | Issue 35 |
Please remember to clean the work directory first.
If your vbmeta.img contains hash of boot.img, you MUST update vbmeta image together.
Your boot.img.signed and vbmeta.img.signd will be updated together, then you can flash them to your device.
working with vendor_boot.img + vbmeta.img (Pixel 5 etc.) Most devices include hash descriptor of vendor_boot.img in vbmeta.img, so if you need to modify vendor_boot.img, you need to update vbmeta.img together.
Please note that to use ‘gradle flash’, your host machine must be connectted to your DUT with adb, and you already ‘adb root’.
How to disable AVB verification
The idea is to set flag=2 in main vbmeta.
Then flash vbmeta.img.signed to your device.
Read layout of Android boot.img and vendor_boot.img.
References and Acknowledgement
This project is developed with products by Jetbrains.
Источник
Как получить образ Recovery из boot.img? Учимся работать с applypatch.
В этом посте я вкратце расскажу вам о том как получить образ recovery.img из boot.img, при условии что у нас на руках имеется только update.zip от прошивки телефона. Собственно на написание этого гайда меня сподвиг один из читателей моего блога, который умудрился зашить в Билайн Смарт Dual recovery от абсолютно другого аппарата и попросил о помощи. Прошивок под SP Flash Tool для данного аппарата мне найти не удалось (в этом случае все было бы намного проще, так как там образ стокового recovery уже лежит отдельно), но зато был найден update.zip от данного аппарата.
Вообщем все не просто, а очень просто. Единственное для работы нам понадобится любой телефон на Android с root-доступом и adb. Первое что мы делаем это извлекаем из архива с прошивкой update.zip следующие файлы:
- boot.img — образ раздела boot
- recovery-resource.dat (можно взять в system\etc) — набор ресурсов для добавления в образ recovery, так называемый bonus-file.
- recovery-from-boot.p (в update\recovery) — файл патча (diff), который собственно и поможен нам преобразовать boot.img в recovery.img
- install-recovery.sh (update\recovery\etc) — скрипт который используется ОС Android в штатном режиме, для восстановления раздела recovery из boot.
После чего копируем boot.img в recovery.img, например так — cp /data/local/tmp/boot.img /data/local/tmp/recovery.img . и выполняем следующую команду, уже через ADB на Android устройстве:
- bonus-file: -b /data/local/tmp/recovery/recovery-resource.dat
- src-file: /data/local/tmp/recovery/boot.img
- tgt-file: /data/local/tmp/recovery/recovery.img
- tgt-sha1: 3e9baf0e1ef24480a92d92c5566244a240480fcc
- tgt-size: 4634624
- :
Где src-sha1 — это SHA1 хеш исходного файла, tgt-sha1 — это SHA1 хеш результирующего файла, который должен получиться в результате применения патча.
Источник
Копаем глубже. Как работают механизмы прошивки, рутинга и восстановления Android
Содержание статьи
Тот, кто когда-либо прошивал свой смартфон или хотя бы разблокировал загрузчик, наверняка имел дело если не с инструментами командной строки, то хотя бы со специальными графическими приложениями для Windows, которые делают всю магию. Но как на самом деле происходит разблокировка загрузчика, установка новой прошивки или сброс до заводских настроек? Что скрыто, так сказать, под капотом?
Я расскажу, как это все работает изнутри, и поясню происходящее на примерах. Для простоты и лучшего понимания все повествование будет вестись в том же порядке, в котором компоненты получают управление на реальном устройстве: ROM -> загрузчик aboot -> ядро -> система Android . Плюс, конечно же, recovery, который может быть запущен загрузчиком вместо Android.
Aboot, fastboot и tamper-бит
Если не брать в расчет небольшой код инициализации, располагающийся в ROM-памяти устройства и специфичный для каждого чипа, то загрузка Android начинается с aboot. Это стандартный загрузчик устройств на базе Android, разработкой которого занимается сама Google. Задача aboot — выполнить первичную инициализацию железа и передать управление либо коду, расположенному в разделе boot (это ядро Linux), либо, если юзер включил смартфон с зажатой клавишей увеличения (или уменьшения, где как) громкости, в recovery.
Ключевая особенность aboot в том, что это модульный загрузчик и к нему при сборке можно подключать разные сопрограммы, каждая из которых будет исполняться в отдельном потоке (что делает aboot миниатюрной ОС). Одна из таких сопрограмм — fastboot, реализация протокола и механизмов для записи разделов внутренней NAND-памяти. В среде энтузиастов fastboot обычно используется для установки кастомного recovery. Для этого достаточно включить смартфон с зажатыми клавишами управления громкостью (на большинстве смартфонов), затем с их же помощью выбрать в меню пункт Fastboot, подключить смартфон с помощью USB-кабеля к компу и выполнить такую команду (она входит в комплект Android SDK):
Причем recovery можно даже не прошивать, а запустить прямо с компа (эту функцию, кстати, использует инструмент CF-Auto-Root, но о нем позже):
Справка по командам fastboot
Xakep #200. Тайная жизнь Windows 10
Однако эти команды не сработают, если загрузчик залочен. Чтобы его разблокировать, на смартфонах линейки Nexus и OnePlus достаточно выполнить такую команду (все, что начинается с oem, — это команды, встроенные производителем смартфона):
Что делает эта команда? В нексусах она выполняет сброс до заводских настроек и записывает один бит в специальный раздел в памяти устройства, служащий индикатором разлочки для самого загрузчика. В Nexus 4 и 5 это раздел misc и адрес 16400, в других нексусах это может быть раздел param (Nexus 10) или даже aboot (Nexus 7/2013 и OnePlus One). Начиная с Nexus 6 и 9, Google навела в этом бардаке порядок и ввела понятие Persistent-раздела для хранения не зависящих от Android настроек. Имя этого раздела хранится в системной переменной ro.frp.pst, и его в любой момент можно получить с помощью такой команды (запускать на самом устройстве):
Как видно, все довольно просто, и, если говорить о нексусах, здесь «залоченный загрузчик» — это просто защита от дурака (собственно, как и должно быть в референсных смартфонах). Загрузчики в обычных смартфонах разработки Samsung, HTC, LG, Motorola и других серьезных контор защищены гораздо лучше, и с помощью команды oem unlock или записи бита по определенному адресу их не вскроешь. Сам бит записывается в недоступную пользователю память, а разблокировка возможна только с помощью цифрового ключа, полученного на сайте производителя (ну или взлома загрузчика, если это возможно).
И в нексусах, и в смартфонах других компаний при разблокировке загрузчика всегда устанавливается так называемый tamper-бит. Сервисные центры смотрят именно на него, решая, признать ли случай гарантийным: даже если впоследствии загрузчик был заблокирован, tamper-бит однозначно свидетельствует о факте разблокировки. Однако иногда этот бит можно сбросить. В нексусах все решается опять же простой записью бита по нужному адресу в нужный раздел, в других смартфонах это либо вообще невозможно сделать, либо приходится использовать специальные инструменты типа приложения Triangle Away (для Samsung’ов без KNOX).
Выясняем, установлен ли загрузчиком tamper-бит
Чтобы окончательно тебя запутать, скажу, что производители часто используют модульную архитектуру aboot для встраивания в него собственных средств прошивки и управления, работающих совместно с fastboot или даже вместо него. Наиболее яркий пример — это Odin в смартфонах Samsung. А некоторые производители идут еще дальше и вообще отказываются от aboot, заменяя его собственным или сторонним загрузчиком.
Например, в чипах Allwinner опенсорсный загрузчик uboot, который принято использовать в разного рода встраиваемых системах, например для роутеров. У MTK загрузчик собственного изготовления, разделенный на два компонента: preloader.bin , с которым работают фирменные утилиты прошивки SP Tools, и lk.bin , отвечающий за инициализацию оборудования. HTC использует загрузчик hboot, не так уж и сильно отличающийся от aboot. У Rockchip также свой собственный загрузчик, интересная особенность которого в том, что инфа о разметке NAND-памяти не вшита в него намертво, а находится в начале самой памяти. Благодаря этому изменить размеры разделов в устройствах на базе Rockchip проще простого.
Исследуем таблицу разделов планшета на базе Rockchip 3066
С загрузчиками закончим и перейдем к следующему компоненту загрузки.
Раздел boot и ядро
Если во время включения устройства ты не зажимал клавишу увеличения громкости либо не перезагружал смартфон в режим recovery намеренно (например, с помощью расширенного меню перезагрузки в кастомных прошивках), на последнем этапе своей работы aboot загружает в память устройства ядро Linux и RAM-диск из раздела boot, а после этого передает управление ядру.
Сам раздел boot не содержит никакой файловой системы, а представляет собой сжатые с помощью gzip и записанные друг за другом ядро и RAM-диск, предваренные небольшим заголовком размером в два килобайта (он содержит опции загрузки ядра, а также адреса расположения образов и другую информацию). RAM-диск, в свою очередь, представляет собой небольшую виртуальную файловую систему, содержащую набор каталогов, к которым Android подключит файловые системы других разделов (system, data, sdcard), а также систему и скрипт инициализации и init.rc . RAM-диск загружается прямо в оперативку и продолжает существовать все время, пока смартфон включен.
Благодаря простой структуре образ раздела boot (boot.img) довольно легко распаковать. Это можно сделать даже с помощью HEX-редактора, но проще воспользоваться инструментом imgtool. Пример для Linux (x86_64):
Запакованные ядро и RAM-диск окажутся в каталоге extracted, а содержимое RAM-диска — в подкаталоге ramdisk_ext. Это в идеале. На самом деле, как и в случае с загрузчиком, никакого стандарта для формата раздела boot нет, и производитель может проявить фантазию. Нередко ядро и RAM-диск располагаются на разных разделах. Такую конфигурацию можно найти в старых моделях Samsung и устройствах на базе Rockchip.
Тем не менее в 95% формат раздела boot стандартный, и если ты когда-либо прошивал на свой аппарат кастомное ядро, то наверняка внутри ZIP-архива с ядром был именно образ boot.img, так что вместе с ядром ты прошивал также и RAM-диск. Когда ты это делал, тебе приходилось быть осторожным, ведь RAM-диск стоковой прошивки отличается от RAM-диска того же CyanogenMod. Прошив ядро для AOSP в CyanogenMod, ты мог получить bootloop и много других неприятностей.
Чтобы обойти эту проблему, разработчик CyanogenMod и автор ClockworkMod Recovery Кушик Дутта (Koushik Dutta, или Koush) создал систему AnyKernel, которая позволяет устанавливать ядра отдельно от RAM-диска (путем пересборки раздела boot на лету). Сегодня ее используют многие разработчики кастомных ядер, но далеко не все. Так что перед прошивкой ядра рекомендую либо найти его версию для того кастома, который установлен у тебя, либо убедиться, что оно использует механизм AnyKernel.
Какое бы ядро ты ни выбрал, тебе в любом случае понадобится кастомный recovery для его установки.
Recovery, Edify и Aroma Installer
Обнаружив зажатую клавишу увеличения громкости, aboot делает почти то же самое, что и при обычной загрузке, но использует вместо boot раздел recovery. Разделы идентичны по своему формату и зачастую включают в себя одно и то же ядро, однако содержимое RAM-диска существенно отличается. Если в случае с разделом boot назначение RAM-диска — создать начальные условия для дальнейшей загрузки системы, то recovery — это мини-ОС, способная работать обособленно.
Стоковый recovery очень прост. Все, что содержит его RAM-диск, — это исполняемый файл /sbin/recovery и (не всегда) набор фоновых изображений в каталоге /res или любом другом. При загрузке ядро Linux запускает /sbin/recovery , а тот выводит на экран простенькое меню, с помощью которого можно установить прошивку, подписанную цифровым ключом производителя, или произвести сброс до заводских настроек.
Кастомные recovery намного сложнее. Это уже не просто меню с фоновым рисунком, но целая операционная система, способная устанавливать какие угодно прошивки, делать бэкап, форматировать разделы и многое другое. Современные версии TWRP так и вообще поддерживают управление с помощью тач-интерфейса, сменные шкурки, полностью изменяющие внешний вид recovery, пароль для входа и эмулятор терминала вместе с экранной клавиатурой. Плюс ко всему кастомные recovery включают в себя BusyBox (набор утилит командной строки Linux) и сервер ADB, работающий с правами root. Так что режим recovery очень удобно использовать для отладки и таких операций, как, скажем, дамп разделов. Например, раздела boot (пример для чипов Qualcomm):
Но главная задача recovery — это, конечно же, установка прошивок. Точнее, она была бы главной задачей, если бы в recovery была такая функция. На самом деле все, что делает recovery, когда ты нажимаешь «Install ZIP. » и выбираешь прошивку, — распаковывает ZIP-файл (обычно в раздел cache) и запускает файл /META-INF/com/google/android/update-binary внутри него. Именно update-binary выполняет установку прошивки, руководствуясь инструкциями из файла updater-script (он лежит рядом).
Сами инструкции написаны на языке Edify, включающем в себя набор команд, которые могут понадобиться при установке: mount, unmount, package_extract_file, symlink, run_program и другие. Мы не будем обсуждать здесь все эти команды, они достаточно просты, и, чтобы ознакомиться с ними, достаточно распаковать любую прошивку и открыть updater-script в текстовом редакторе. Скажу лишь, что обычно такие файлы генерируются автоматически при сборке системы из исходников и только авторы узкоспециализированных прошивок (содержащих только ядро, например) пишут их самостоятельно.
Фрагмент updater-script из CyanogenMod 12.1
Recovery не накладывает никаких ограничений на файл update-binary — главное, чтобы его можно было запустить. Это дает производителям возможность использовать вместо него любое приложение, способное запуститься поверх ядра Linux. Совсем не обязательно, чтобы оно вообще выполняло установку прошивки. В рамках проекта Aroma Installer развивается вариант update-binary, который позволяет создателям кастомных прошивок реализовать графический инсталлятор с выбором тех или иных вариантов и опций установки.
Автор Aroma Installer также создал Aroma Filemanager — полноценный менеджер файлов со встроенным эмулятором терминала. Чтобы его запустить, необходимо перезагрузиться в recovery и «прошить» ZIP-файл. Естественно, никакая прошивка выполнена не будет, ведь update-binary внутри ZIP-файла — это только файловый менеджер, он не выполняет никаких операций установки.
Эмулятор терминала, встроенный в Aroma Filemanager
«Фиктивный» update-binary часто используется для распространения разного рода скриптов. Гораздо проще переименовать скрипт в update-binary, запаковать в ZIP-файл и попросить человека «прошить» его, чем объяснять, как запускать скрипты с помощью ADB. Именно так поступил osm0sis со своим скриптом разблокировки загрузчика аппаратов линейки Nexus. Если ты скачаешь его ZIP-файл и взглянешь внутрь, то найдешь updater-binary, внутри которого обычный sh-скрипт.
Root insecure adb
Ну и в конце пара слов о том, что такое root. Начнем со всем известных азов: в Linux root — это имя пользователя с безграничными правами в системе (типа администратора в Windows). Root может вообще все, вплоть до удаления всей системы с диска (именно это делает знаменитая команда «rm -rf /*), поэтому обычно никто не сидит, так сказать, под рутом, а использует непривилегированный аккаунт.
Чтобы иметь возможность выполнять операции с правами root (например, устанавливать софт или управлять сервисами), можно использовать разные приложения (команды), одна из которых носит имя su. Она позволяет получить права root или любого другого пользователя в системе, пароль которого тебе известен. И все благодаря специальному SUID-биту, который позволяет su работать с правами root, даже если оно было запущено обычным пользователем.
В Android с правами root работает исключительно сама система (и то далеко не вся), тогда как сервер ADB и приложения исполняются с правами непривилегированных пользователей (по одному пользователю Linux на каждое приложение, серьезно), а команды su нет вообще. Поэтому единственный способ получить права root в такой ситуации — воспользоваться уязвимостью в одном из системных компонентов, работающих с правами root. Таким образом можно не просто временно заполучить права root, но и использовать их, чтобы разместить в системе бинарник su (скопировать в /system/xbin, например) и поставить на него SETUID-бит. Именно так работают все наиболее популярные инструменты рутинга, от Super One Click до framaroot.
Второй вариант — прошить бинарник su с помощью кастомной консоли восстановления. Известный Android-разработчик Chainfire уже много лет занимается разработкой и поддержкой инструмента для управления root-доступом SuperSU, а также ZIP-архива, прошив который, ты получишь рутованный смартфон (при установке он копирует в систему su и приложение SuperSU.apk ). Кстати, инструменты типа Framaroot вместе с бинарником su также устанавливают SuperSU или его аналог SuperUser, чтобы пользователь мог управлять тем, каким приложениям следует давать права root, а каким нет.
SuperSU собственной персоной
Есть у Chainfire и другой интересный проект — CF-Auto-Root. Он тоже устанавливает в систему su и SuperSU, но делает это весьма оригинальным способом: без задействования recovery. Инструмент CF-Auto-Root существует в двух вариантах, для Odin и для fastboot, причем в последнем случае он представляет собой модифицированную версию recovery, которую не надо прошивать. Ее следует запускать с помощью описанной в начале статьи команды fastboot boot. Пример для Nexus 4:
При загрузке «поддельный recovery» запускает не /sbin/recovery , а бинарник /sbin/cfautoroot , который просто копирует в систему su и SuperSU и затем перезагружает устройство. Зачем использовать такой извращенный способ, когда можно установить кастомный recovery и прошить стандартный SuperSU.zip? Ну например, это пригодится тем, кто не хочет по каким-то причинам устанавливать кастомный recovery.
Последнее, о чем хотелось бы сказать, — разные виды root. В Android root-доступ принято разделять на «пользовательский» и «root уровня ядра» (kernel root). Это довольно глупые определения, но нам придется иметь с ними дело. «Пользовательский root» — это то, что я описал выше: приложение запрашивает права root с помощью запуска /system/xbin/su , а SuperSU показывает тебе окошко с запросом прав root. Все просто. Так называемый «root уровня ядра» — это когда с правами root работает сервер ADB. Рутом уровня ядра он называется по причине необходимости править boot.img , а точнее содержащийся в нем init.rc (необходимо присвоить переменной property:service.adb.root значение 1 и запустить adbd с флагом —root_seclabel=u:r:su:s0 ).
Подавляющему большинству пользователей root уровня ядра никогда не понадобится. Однако его могут использовать некоторые скрипты и графические инструменты, работающие со смартфоном по ADB (яркий пример: PatchROM от MIUI). В CyanogenMod и многих других кастомных прошивках по умолчанию доступны все виды root (их можно выбрать в «Настройках для разработчиков»). Для получения root уровня ядра в других прошивках можно использовать приложение adbd Insecure за авторством все того же Chainfire.
Adbd Insecure и стоковая прошивка HTC
Выводы
Надеюсь, эта статья помогла тебе разобраться в том, как работают механизмы разблокировки, прошивки и восстановления Android. В целом в этом нет ничего сложного, и, поняв, как именно все это работает, ты избежишь многих проблем, связанных с разблокировкой и перепрошивкой устройства. И даже если они возникнут — теперь ты сможешь их решить без посторонней помощи.
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Источник