СТАТЬЯ ЕЩЕ СЫРАЯ
Приемы, работы с образами описанные тут актуальны, однако, для получения root достаточно просто корректно собрать TWRP.
Я собирал его так: Сборка TWRP из исходников для любого аппарата
В данной статье я пытаюсь получить root для телефона Nomu S30 mini, на базе MTK6735.
https://forum.xda-developers.com/showthread.php?t=2684210
http://whiteboard.ping.se/Android/Rooting
http://andrew.bogdanovs.com/post/flashing_mt65xx_phones.html
Разблокировка бутлоадера
Для того, чтобы в телефон можно было заливать модифицированные образы нужно разблокировать бутлоадер.
ВНИМАНИЕ!! при разблокировке или блокировке бутлоадера пользовательские данные теряются!!!!
Устанавливаем adb-tools
sudo apt-get install android-tools-adb android-tools-fastboot
Включаем в Developer Options опцию USB Debugging.
В Developer Options включаем OEM Unlocking.
Включаем телефон и подключаем к компу. Телефон спросит - можно ли использовать с этим компьютером USB Debug - отвечаем Yes.
Теперь перезагружаем телефон в режим бутлоадера. Для этого при подключенном к компу телефоне (включенном) выполняем
adb reboot-bootloader
Либо выключаем телефон, зажимаем Vol+ и PowerButton. Появится меню, в котором кнопкой Vol+ нужно выбрать fastboot и нажать Vol-.
После того, как на телефоне появится надпись FASTBOOT MODE на компе выполняем:
fastboot oem unlock
В результате компьютер скажет:
(bootloader) Start unlock flow OKAY
То есть теперь бутлоадер разлочен и мы можем прошивать новые прошивки через него.
Прошивка с помощью bootloader
Перезагружаем телефон в режим бутлоадера (fastboot):
adb reboot-bootloader
Например, для того, чтобы прошить flash-блок system (в котором лежит собственно android) - подключаем аппарат к компу и выполняем:
fastboot flash system system.img
Эта команда прошьет блок с названием system файлом-образом system.img из текущего каталога. Аналогично прошиваются recovery и boot:
fastboot flash boot boot.img fastboot flash recovery recovery.img
Перезагружаем телефон:
fastboot reboot
Или перезагружаем его в recovery
fastboot reboot recovery
Отключение dm-verity и включение userdebug
Для того, чтобы можно было загружать модицицированный system.img, нужно отключить проверку образа dm-verity. Это делается путем редактирования образа boot.img.
Распаковываем boot.img с помощью AIK-Linux:
./unpackimg.sh ./boot.img
Из распакованного ramdisk удаляем файл verity_key
sudo rm ./ramdisk/verity_key
В файле ./ramdisk/fstab.mt6735 отключаем verify:
sudo sed -i '/\/system/ s/,verify//' ./ramdisk/fstab.mt6735
В файле ./ramdisk/default.prop меняем значение параметра ro.secure=1 на 0, меняем ro.debuggable=0 на 1 и добавляем строку ro.config.dmverity=false:
sudo sed -i '/ro.secure/ s/1/0/' ./ramdisk/default.prop sudo sed -i '/ro.debuggable/ s/0/1/' ./ramdisk/default.prop echo 'ro.config.dmverity=false' | sudo tee -a ./ramdisk/default.prop
Упаковываем обратно:
sudo ./repackimg.sh
И прошиваем в телефон:
adb reboot-bootloader fastboot flash boot ./image-new.img fastboot reboot
Всё, что написано ниже, неактуально, но может кому-то пригодиться
Перепаковка boot.img
https://unix.stackexchange.com/questions/64628/how-to-extract-boot-img
https://source.android.com/security/verifiedboot/verified-boot - про very_key. В файлике fstab.mt6735 в строке где монтируется /system надо убрать verify.
https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606 - про то как подписать boot.img
https://android.googlesource.com/platform/bootable/recovery/+/android-4.4.2_r2/testdata/testkey.x509.pem
Распаковка
wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/android-serialport-api/android_bootimg_tools.tar.gz tar -xvf ./android_bootimg_tools.tar.gz mkdir ./boot ./unpackbootimg -i ./boot.img -o ./boot/
В результате в папке ./boot будут файлики. И среди них два:
- boot.img-zImage —→ kernel
- boot.img-ramdisk.gz —→ ramdisk
Чтобы распаковать ram-диск делаем так:
gunzip -c boot.img-ramdisk.gz | cpio -i
Упаковка initramfs
cd
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Отключение verify для раздела system
./unpackbootimg -i ./boot.img -o ./boot cd boot mkdir ./ramdisk cp ./boot.img-ramdisk.gz ./ramdisk/ cd ramdisk/ gunzip -c boot.img-ramdisk.gz | cpio -i rm -f ./boot.img-ramdisk.gz sed -i '/\/system/ s/,verify//' ./fstab.mt6735 rm -f ../boot.img-ramdisk.gz find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.gz
Получение root в adb
В файлике default.prop нужно сделать так:
ro.secure=0 ro.debuggable=1 persist.service.adb.enable=1
Упаковка
Выполняется как-то так:
./mkbootimg --kernel ./boot.img-zImage --ramdisk ./boot.img-ramdisk.gz --base 40078000 --cmdline 'bootopt=64S3,32N2,64N2' --pagesize 2048 -o ../newboot.img
Перепаковка boot.img с помощью abootimg
boot.img перепакованый таким образом нормально загружается, (даже не подписаный сертификатом) только в том случае, если не вносились изменения (не перепаковывался) initrd.img. Это значит, что secureboot проверяет initrd.img.
sudo apt-get install abootimg abootimg -x ./boot.img abootimg-unpack-initrd
Команда abootimg-unpack-initrd распакует файл initrd.img из текущей директории в папку ramdisk. После внесения изменений в файлы можно упаковать все обратно.
rm ./initrd.img abootimg-pack-initrd
Команда abootimg-pack-initrd упакует содержимое папки ramdisk в файл ./initrd.img
Теперь можно всё собрать обратно в newboot.img.
abootimg --create newboot.img -f ./bootimg.cfg -k ./zImage -r ./initrd.img
Перепаковка с подписью сертификатом
В сертификате указывал такие данные: C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com
Подписанный (но не измененный) boot.img НЕ загружается.
abootimg -x ./boot.img
abootimg-unpack-initrd
#sed -i '/\/system/ s/,verify//' ./ramdisk/fstab.mt6735
rm ./initrd.img
abootimg-pack-initrd
abootimg --create newboot.img -f ./bootimg.cfg -k ./zImage -r ./initrd.img
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
java -jar BootSignature.jar /boot newboot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img
adb reboot-bootloader
fastboot flash boot ./boot_signed.img
fastboot reboot
Перепаковка system.img
Скачиваем отсюда super-su: https://download.chainfire.eu/supersu-stable
http://www.mtkfirmware.com/content/linux-commands-instructions-tools-unpacking-and-repacking-system-images-mtk-devices-ext4-and
http://www.mtkfirmware.com/sites/default/files/dev-tools/img-tools_0.zip
http://4pda.ru/forum/lofiversion/index.php?t660562-40.html
https://www.tinkerboarding.co.uk/forum/thread-347-post-1216.html
https://tinkerboarding.co.uk/forum/archive/index.php/thread-264.html
https://nelenkov.blogspot.ru/2014/05/using-kitkat-verified-boot.html#!/2014/05/using-kitkat-verified-boot.html - вот тут про verity.
https://forum.xda-developers.com/android/general/cofface-filecontexts-bin-filecontexts-t3669824
При внедрении в образ system.img файлов SuperSU нужно прописать их в SELinux. База данных SELinux хранится в образе boot.img, в файлике file_contexts.bin. После извлечения, файл file_contexts.bin нужно распаковать для внесения в него изменений с помощью утилиты sefcontext, а затем запаковать обратно и пересобрать образ boot.img.
Образ system.img нужно распаковать с помощью img-tools, смонтировать образ и добавить в него файлы SuperSU, а затем запаковать его обратно.
Итак.
В отдельную папку (меня это пака ~/AIK-Linux)распаковываем Android Image Kitchen кладем туда boot.img и распаковываем его:
./unpackimg.sh ./boot.img
Из папки ./ramdisk забираем файлик file_contexts.bin и кладем его в папку с утилитами img-tools, sefcontext и образом system.img - у меня это папка ~/s30mini/.
cp ./ramdisk/file_contexts.bin ../s30mini/
Теперь с помощью скрипта перепаковываем system.img и вносим изменения в file_contexts.bin:
#!/bin/bash
SuperSU_PATH="/mnt/hdd/Downloads/UPDATE-SuperSU-v2.82-20170528234214"
cd ~/img-tools/
./simg2img ./system.img ./system.raw
sudo mkdir /system
sudo mount -t ext4 -o loop ./system.raw /system/
mkdir boot
cp ./boot.img ./boot/
cp ./unpackbootimg ./boot/
cd ./boot
./unpackbootimg -i ./boot.img -o ./
gunzip -c boot.img-ramdisk.gz | cpio -i
cd ..
./sefcontext -o ./file_contexts ./boot/file_contexts.bin
sudo mkdir --parents /system/app/SuperSU && sudo cp $SuperSU_PATH/common/Superuser.apk /system/app/SuperSU/SuperSU.apk
sudo chmod 0644 /system/app/SuperSU/SuperSU.apk
echo "/system/app/SuperSU/SuperSU.apk u:object_r:system_file:s0" >> ./file_contexts
sudo cp $SuperSU_PATH/common/install-recovery.sh /system/etc/install-recovery.sh
sudo chmod 0755 /system/etc/install-recovery.sh
echo "/system/etc/install-recovery.sh u:object_r:toolbox_exec:s0" >> ./file_contexts
sudo cp $SuperSU_PATH/arm64/su /system/xbin/su
sudo chmod 0755 /system/xbin/su
sed -i '/^\/system\/xbin\/su/d' ./file_contexts
echo "/system/xbin/su u:object_r:system_file:s0" >> ./file_contexts
sudo mkdir /system/bin/.ext
sudo cp $SuperSU_PATH/arm64/su /system/bin/.ext/.su
sudo chmod 0755 /system/bin/.ext/.su
echo "/system/bin/.ext/.su u:object_r:system_file:s0" >> ./file_contexts
sudo cp /system/xbin/su /system/xbin/daemonsu
echo "/system/xbin/daemonsu u:object_r:system_file:s0" >> ./file_contexts
sudo cp /system/xbin/su /system/xbin/sugote
echo "/system/xbin/sugote u:object_r:zygote_exec:s0" >> ./file_contexts
sudo cp $SuperSU_PATH/arm64/supolicy /system/xbin/supolicy
sudo chmod 0755 /system/xbin/supolicy
echo "/system/xbin/supolicy u:object_r:system_file:s0" >> ./file_contexts
sudo cp $SuperSU_PATH/arm64/libsupol.so /system/lib64/libsupol.so
sudo chmod 0755 /system/lib64/libsupol.so
echo "/system/lib\(64\)/libsupol.so u:object_r:system_file:s0" >> ./file_contexts
sudo touch /system/etc/.installed_su_daemon
sudo chmod 0644 /system/etc/.installed_su_daemon
echo "/system/etc/.installed_su_daemon u:object_r:system_file:s0" >> ./file_contexts
sudo cp /system/bin/sh /system/xbin/sugote-mksh
sudo chmod 0755 /system/xbin/sugote-mksh
echo "/system/xbin/sugote-mksh u:object_r:system_file:s0" >> ./file_contexts
sudo cp /system/bin/app_process32 /system/bin/app_process32_original
sudo chmod 0755 /system/bin/app_process32_original
echo "/system/bin/app_process32_original u:object_r:zygote_exec:s0" >> ./file_contexts
sudo mv /system/bin/app_process /system/bin/app_process_original
sudo chmod 0755 /system/bin/app_process_original
echo "/system/bin/app_process_original u:object_r:zygote_exec:s0" >> ./file_contexts
sudo mv /system/bin/app_process32 /system/bin/app_process_init
sudo chmod 0755 /system/bin/app_process_init
echo "/system/bin/app_process_init u:object_r:system_file:s0" >> ./file_contexts
sudo mv /system/bin/app_process64 /system/bin/app_process64_original
sudo chmod 0755 /system/bin/app_process64_original
echo "/system/bin/app_process64_original u:object_r:zygote_exec:s0" >> ./file_contexts
sudo ln -s /system/xbin/daemonsu /system/bin/app_process
sudo ln -s /system/xbin/daemonsu /system/bin/app_process32
sudo ln -s /system/xbin/daemonsu /system/bin/app_process64
sudo rm -f /system/bin/install-recovery.sh
sudo ln -s /system/etc/install-recovery.sh /system/bin/install-recovery.sh
SYSTEM_RAW_SIZE=$(stat --printf="%s" ./system.raw)
sudo ./make_ext4fs -s -l $SYSTEM_RAW_SIZE -S ./file_contexts -a system newsystem.img /system/
sudo umount /system
sudo chmod a+rw ./newsystem.img
sudo rm -f ./system.raw
sudo rm -Rf ./boot
sudo rm -f ./file_contexts
sudo rm -Rf /system
Переносим новый file_contexts.bin в рамдиск boot.img и упаковывавем boot.img.
echo '' | sudo tee ~/AIK-Linux/ramdisk/file_contexts.bin sudo dd if=./new_file_contexts.bin of=~/AIK-Linux/ramdisk/file_contexts.bin
Discussion
поможет ли отключение dm-verity. если прошить boot.img и заблокировать загрузчик средствами fastboot? всмысле не получится ли кирпич..
Кирпич из телефона на базе чипа MTK сделать очень сложно. Даже если прошить левый preloader. Из любого состояния телефон можно прошить. Я пробывал. Кстати, root на этом телефоне я получил и без манипуляций с dm-verity. Оказалось достаточно было собрать TWRP. Вот таким образом : https://wiki.autosys.tk/doku.php?id=android:build_twrp_from_source_ubuntu_16.04
А можно ли этим способом, отключить drm verify на смартфоне Sony?
А почему же не загрузился подписанный boot.img??? Вам знаком сам механизм проверки этой самой подписи? И что именно за компонент эту проверку проводит? LK, TEE, или может сам Preloader?
Не знаю, почему не загрузился подписанный boot.img. Дальше не разбирался.
Очень жаль, я хотел бы разобраться в тонкостях того как правильно собирать и подписывать свои образы, чтобы они успешно грузились в девайсе в Yellow State без разблокировки загрузчика. У меня на руках LeEco Le Pro 3 AI, модель x7, в билдах прошивок пишут версию от х650 до х658. Китайцы так его устроили, что при разблокировке загрузчика (чтобы можно было ставить всё что угодно модифицированное неподписанное) блокируется работа модема (baseband). Если есть какие-то идеи, или хотя бы есть куда послать за прочтением доков или лучше чьего-то опыта, то пожалуйста сообщите.
Вообще, моей задачей было рутирование девайса. Эту задачу удалось выполнить, собрав только TWRP и подобрав версию SuperSU, скрипты которого все сделали правильно и смогли установиться без перепаковки образов boot и system. Моми манипуляции по сборке TWRP описаны тут: https://wiki.autosys.tk/doku.php?id=android:build_twrp_from_source_ubuntu_16.04
Соответственно, если вы хотите собрать свой system, скорее всего вам стоит посмотреть в установочные скрипты SuperSU. Ведь он как-то вносит изменения в system, что после этого все работает. Я вам даже больше скажу - конкретные куски установочных скриптов, ответственных за корректное изменение system можно обнаружить, сравнивая различные версии SuperSU. В моем случае - 2.72 не устанавливался, а 2.82 - устанавливался.
В принципе, о подписывании образов немного теории написано тут: https://source.android.com/security/verifiedboot/verified-boot
и практики тут: https://forum.xda-developers.com/android/software-hacking/signing-boot-images-android-verified-t3600606
ну и вообще: https://www.google.com/search?newwindow=1&ei=zf8xW-r5E8yZsAGuopvwAQ&q=android+boot+image+signing&oq=android+boot+image+signing&gs_l=psy-ab.3...67477.70656.0.70770.13.9.4.0.0.0.75.599.9.9.0....0...1c.1.64.psy-ab..0.2.78...0i19k1.0.IYnazcwo4qQ