Если до того как вы наткнулись на этот пост вы уже пробовали искать что-то подобное на форумах, например xda-developers и др., то наверняка заметили что вопросов по Idol 4 на данный момент больше чем ответов:
Никому до сих пор так и не удалось получить root на него, не говоря уже о сборке кастомных recovery или прошивок. Несмотря на то MSM8952 на котором построен Idol 4 достаточно распространенный чипсет и аппарат уже успел получить широкое распространение - результата все равно нет. Во-первых это связано с тем что в релизных прошивках аппарата заблокирован bootloader. Более того, даже не смотря на все присутствующие опции разблокировать его штатным образом нельзя (на XDA даже кто-то из США писал в support Alcatel'я, в стиле, прошу выслать инструкцию по разблокировке bootloader'а на Idol 4 для создания кастомных прошивок и т.д. и т.п. - support ответил, что к сожалению на территории США данная возможность не поддерживается и они ничем не могут помочь) ... хотя бы потому что aboot (emmc_appsboot) в релизных прошивках для Idol 4 собран без поддержки команды fastboot oem unlock. Т.е. режим fastboot'а в нем конечно же есть, но aboot в нем собран с флагом DISABLE_FASTBOOT_CMDS , т.е. всего вот этого удовольствия:
#ifndef DISABLE_FASTBOOT_CMDS
/* Register the following commands only for non-user builds */
{"flash:", cmd_flash},
{"erase:", cmd_erase},
{"boot", cmd_boot},
{"continue", cmd_continue},
{"reboot", cmd_reboot},
{"reboot-bootloader", cmd_reboot_bootloader},
{"oem unlock", cmd_oem_unlock},
{"oem unlock-go", cmd_oem_unlock_go},
{"oem lock", cmd_oem_lock},
{"oem verified", cmd_oem_verified},
{"oem device-info", cmd_oem_devinfo},
{"preflash", cmd_preflash},
{"oem enable-charger-screen", cmd_oem_enable_charger_screen},
{"oem disable-charger-screen", cmd_oem_disable_charger_screen},
{"oem select-display-panel", cmd_oem_select_display_panel},
#if UNITTEST_FW_SUPPORT
{"oem run-tests", cmd_oem_runtests},
#endif
в нем попросту нет. Т.е. из fastboot нельзя прошивать разделы, стирать их, загружать свой образ boot'а, разблокировать bootloader и т.п., т.к. всех этих команд просто нет. Во-вторых, обычно большинство пользователей на новых девайсах получает root-права с помощью KingRoot и аналогичных приложений (ну а где есть root доступ - понятно что есть доступ ко всему и на основе имеющегося ядра аппарата можно довольно быстро собрать какой-нибудь кастомный recovery, тот же TWRP) ... с Idol 4 этот способ тоже не проходит, т.к. даже самая первая версия прошивки получила последние обновления безопасности Android и в ней фактически отсутствуют все те уязвимости за счет которых KingRoot получает root права. С одной стороны это конечно хорошо, т.к. чем меньше уязвимостей в аппарате - тем он лучше, надежнее, и защищеннее. С другой - мы получили "полностью закрытый аппарат" и соответственно все пути для моддинга в нем, казалось бы, обрезаны.
Однако, если задуматься ... ведь тот же самый Mobile Upgrade успешно прошивает гаджет, т.е. фактически заливает в него все разделы, включая boot, recovery, system и т.п. Однако как принято считать подобного рода утилиты работают "на самом низком уровне" (чья-то цитата из диалогов на одном из форумов) и у пользователей вряд-ли получится пойти этим путем. Именно поэтому где-то с месяц назад я вплотную стал заниматься изучением протоколов Sahara и Firehose чтобы хотя бы немного приблизиться к пониманию как все это работает. Результатом стал этот пост - Sahara & Firehose Test. Изучаем методику работы с Qualcomm-аппаратами. и утилита Sahara & Firehose Test, разработкой которой я и занимался в последнее время (правда тут надо отметить что текущий public-релиз не поддерживает работу с Idol 4, т.к. фактически за месяц с выпуска первого билда никто не проявил к ней никакого интереса, а следовательно "продолжение" я делал исключительно для себя).
Итогом практически месячной работы стало то, что я все-таки смог слить со своего Idol 4 образы boot и recovery и благодаря этому смог заняться компиляцией TWRP.
Что из этого получилось в конечном итоге вы можете посмотреть в следующем видео:
Скажу честно, что после получения образов разделов boot и recovery с аппарата сборка рабочего образа TWRP на базе исходников OmniROM и CM13 заняла в общей сложности несколько суток. Естественно, что можно было просто взять имеющийся zImage ядра и портировать TWRP с другого аппарата на таком же чипсете. Именно так я и сделал изначально. Но в портированном recovery не работали множество фукций, например, не дешифровался раздел /userdata, не работало монтирование флешки, не распознавался adopted storage (флешка отформатированная во внутреннюю память) и т.п. Как сказал мне мой знакомый ruslan_3_ - якобы это нормально, т.к. в свое время он и еще несколько человек занимались проблемой создания TWRP для Xiaomi Mi5 ... и они столкнулись при разработке с той же проблемой. В результате они пошли более простым путем и отключили принудительное шифрование раздела userdata пересобрав boot. В принципе здесь можно было бы пойти тем же путем. Но ... лично я не люблю незаконченных решений. Более того я не раз давал себе слово не экспериментировать с рабочим телефоном, хотя бы потому что полное удаление всех данных или перепрошивка - это всегда болезненно (в том плане, что на аппарате который уже "настроен под себя" удаление раздела userdata неизбежно ведет к тому что все надо переустанавливать и т.п., а это время), а в случае замены в boot'е флага forceencrypt=footer на encryptable=footer для /dev/block/bootdevice/by-name/userdata неизбежно привело бы к форматированию этого раздела, т.к. расшифровать уже имеющиеся на нем данные было бы нельзя.
Поэтому я решил что это не мой путь и решил все-таки понять, что такого сложного в дешифровке данных раздела data на Android M. В этом мне помогли несколько ссылок, какие-т о в большей степени, какие-то в меньшей, однако все это пришлось изучить (и при этом не факт что досконально понять ;)
Для начала нужно было понять какой же тип шифрования используется в Idol 4. Для того чтобы это понять необходимо было получить последние 16384 байт раздела userdata, а именно тот самый footer. Вот он:
Однако после сборки (в процессе которой я решил еще ряд проблем, например то что при синхронизации с последней версией репозитария OmniROM TWRP просто не собирался, прямо как тут) я столкнулся с проблемой, которую описал здесь. Т.е. TWRP у меня уже знал про аппаратное шифрование, но при попытке инициализации keymaster'а просто зависал. Вернее зависал UI, т.е. как только в логе мы видели:
Больше ничего не происходило. На решение этой проблемы ушли примерно сутки и большей частью здесь мне помогли труды пользователя steadfasterX. Он столкнулся примерно с такой же проблемой при попытке компиляции TWRP для LG G4 H815 - TWRP for h815 2.8.7.0 and 2.8.6.1 can NOT decrypt LG G4 H815. Как он сказал мне в личной беседе, ему помогли разобраться на IRC-канале TWRP, собственно он мне дал ссылку на мануал к подготовке к общению в IRC ... Однако мне "повезло" и до этого не дошло, т.к. большую часть времени помог сэкономить анализ вот этого дерева android_device_lge_h815 (именно за эти труды, пользуясь случаем и хочется выразить отдельную благодарность steadfasterX'у).
Оказалось что у меня не стартовал сервис qseecomd ... правда причина была не в отсутствии symlink'а в bootdevice, а в другом, но все же. Я много почерпнул из этого дерева и через сутки добился желаемого результата. В итоге теперь моя сборка TWRP для Idol 4 6055K умеет:
На все про все (имеются ввиду суммарно все работы, как по созданию флешера Sahara & Firehose Test, так и по сборке TWRP) у меня ушло чуть больше месяца. А на "допиливание" TWRP и попытки разобраться что к чему вечер пятницы и практически целые сутки в субботу (семья в выходной меня не видела, а видела только мою спину за компьютером). Но ... поставленная цель достигнута, результат получен. А это всегда приятно.
Ну а у меня на этом наверное всё ... сейчас выложу еще немного скриншотов / фото того что получилось и с чувством глубокого морального удовлетворения завалюсь спать, все-таки 06:55 утра на часах ;)
p.s. Кстати, интересный вопрос, который наверное зададут многие ... а куда Backup'иться если SD-карта используется как adopted storage, т.е. отфоматирована как внутренняя память? В этом случае вам поможет USB-OTG и обычная флешка:
К слову ... если вы прочитали эту статью выше, то наверное поняли, что если microSD у вас используется как adopted storage, то ключ шифрования от microSD карты хранится в /data/misc/vold , у меня это выглядело так:
Таким образом, если вставить эту флешку в ПК с Linux'ом и сделать что-то вроде:
dmsetup create crypt1 --table "0 `blockdev --getsize /dev/sdb2` crypt aes-cbc-essiv:sha256 <Put the 16-byte hex key here> 0 /dev/sdb2 0"
Где /dev/sdb2 - это непосредственно флешка. То потом можно будет ее примонтировать, как обычный ext4 раздел: mount -t ext4 /dev/mapper/crypt1 /mnt/1/ , правда я пока не пробовал. Но думаю что получится, т.к. ключ-то есть ;)
Таким образом если мы сделали backup раздела userdata, то соответственно и backup ключей от adopted storage (/data/misc/vold/expand_%s.key) и если вдруг телефон у нас по каким-то причинам канет в лету, то мы легко сможем расшифровать содержимое флешки при наличии ключа.
p.p.s. Кстати, выяснил один интересный момент. Итак. если у вас был установлен тип блокировки именно пароль, а не PIN - то раздел userdata шифруется аппаратно с вашим паролем. Если в настройках безопасности вы указали именно PIN - то userdata будет зашифрован с default_password. Т.е. при старте TWRP он примонтируется без запроса PIN'а. Вот такая вот хитрая безопасность.
Обновлено 11.09.2016 07:51 (MSK)
(никак не улягусь) ... Примечательный факт. Если у кого-то из вас был Idol 3 6039Y, то вы наверняка помните что при создании Backup'а в TWRP аппарат имел свойство нагреваться до запредельной температура, да и даже в состоянии "простоя", просто когда запущен TWRP аппарат почему-то ощутимо грелся. В случае же с Idol 4 такого нет в принципе. Т.е. при "простое" в TWRP температура - 28 градусов (если верить показаниям самого TWRP), а в процессе практически 15-минутного backup'а всех разделов на USB флешку подключенную через OTG температура поднялась только до 33 градусов. При этом наощупь аппарат ни нагрелся даже ни на один градус. Т.е. несмотря на то что процесс создания полного Backup'а довольно ресурсоемкий - на температуре гаджета это никак не отражается (вот прямо написал и еще раз порадовался за свой Idol 4 ;)
Ну и конечно же пару слов про root. С установленным TWRP получить его по описанному здесь методу, т.е. с установкой SuperSU как systemless не составляет никаких проблем. Вот результаты:
Кстати, ядро нашего аппарата не поддерживает модификацию TTL. Т.е. использовать на нем программы типа TTL Editor и т.п. добавляющие правило для фиксации TTL в iptables не получится, т.к. /proc/net/ip_tables_targets не содержит TTL.
Ну вот теперь, когда все увидели первый в мире Idol 4 6055K с полученным root'ом (ну за исключением разве что девелоперских версий, т.е. аппаратов разработчиков ПО в TCL) и узнали что "халявного тетеринга" с Idol 4 не получится без пересборки ядра, можно действительно отправляться отдыхать ;) Stay tuned, впереди еще много интересного.
Поэтому я решил что это не мой путь и решил все-таки понять, что такого сложного в дешифровке данных раздела data на Android M. В этом мне помогли несколько ссылок, какие-т о в большей степени, какие-то в меньшей, однако все это пришлось изучить (и при этом не факт что досконально понять ;)
- Password storage in Android M
- Hardware-accelerated disk encryption in Android 5.1
- Decrypting Android M adopted storage
- Extracting Qualcomm's KeyMaster Keys - Breaking Android Full Disk Encryption
А также следующие топики и проекты на Git'е:
- http://forum.xda-developers.com/showthread.php?p=68621748
- http://forum.xda-developers.com/showpost.php?p=68249027&postcount=3
- http://stackoverflow.com/questions/33779286/selinux-policy-definition-for-android-system-service-how-to-setup
- https://github.com/TeamWin/Team-Win-Recovery-Project/issues/477
- https://github.com/TeamWin/android_device_oneplus_oneplus2/issues/1
- http://forum.xda-developers.com/showthread.php?t=2794413
- https://github.com/omnirom/android_device_huawei_angler/blob/android-6.0/recovery/root/init.recovery.angler.rc
Для начала нужно было понять какой же тип шифрования используется в Idol 4. Для того чтобы это понять необходимо было получить последние 16384 байт раздела userdata, а именно тот самый footer. Вот он:
Даже без знания структуры footer'а, хотя ее описание тоже при желании можно найти, невооруженным взглядом видно, что здесь используется аппаратное шифрование FDE (full-disk-encryption), "тип шифра" - aes-xts essiv:sha256 . Может я немного путаюсь с терминологией, т.к. пишу этот пост уже под утро в воскресенье, после бессонной ночи, ну да знающие люди поймут про что, а те кто смотрит на все это впервые - поверят на слово. Так вот, все образы TWRP которые удалось найти от других аппаратов на схожей платформе были собраны без поддержки этого типа шифрования. Поэтому даже при успешном портировании на Idol 4 расшифровать такой раздел ну никак не могли. Для компиляции TWRP с поддержкой аппаратного шифрования, как можно вычитать из интернета или посмотрев device tree других устройств на Git'е используются два флага (всего два флага, Карл ... ;) Это:
# Encryption
TARGET_HW_DISK_ENCRYPTION := true
TW_INCLUDE_CRYPTO := true
Однако после сборки (в процессе которой я решил еще ряд проблем, например то что при синхронизации с последней версией репозитария OmniROM TWRP просто не собирался, прямо как тут) я столкнулся с проблемой, которую описал здесь. Т.е. TWRP у меня уже знал про аппаратное шифрование, но при попытке инициализации keymaster'а просто зависал. Вернее зависал UI, т.е. как только в логе мы видели:
Attempting to decrypt data partition via command line.
crypt_ftr->fs_size = 21589423
Using scrypt with keymaster for cryptfs KDF
Invalid hex string
Failed to convert passwd from hex, using passwd instead
keymaster module name is Keymaster QTI HAL
keymaster version is 256
Found keymaster1 module, using keymaster1 API.
Больше ничего не происходило. На решение этой проблемы ушли примерно сутки и большей частью здесь мне помогли труды пользователя steadfasterX. Он столкнулся примерно с такой же проблемой при попытке компиляции TWRP для LG G4 H815 - TWRP for h815 2.8.7.0 and 2.8.6.1 can NOT decrypt LG G4 H815. Как он сказал мне в личной беседе, ему помогли разобраться на IRC-канале TWRP, собственно он мне дал ссылку на мануал к подготовке к общению в IRC ... Однако мне "повезло" и до этого не дошло, т.к. большую часть времени помог сэкономить анализ вот этого дерева android_device_lge_h815 (именно за эти труды, пользуясь случаем и хочется выразить отдельную благодарность steadfasterX'у).
Оказалось что у меня не стартовал сервис qseecomd ... правда причина была не в отсутствии symlink'а в bootdevice, а в другом, но все же. Я много почерпнул из этого дерева и через сутки добился желаемого результата. В итоге теперь моя сборка TWRP для Idol 4 6055K умеет:
- Корректно монтировать раздел userdata зашифрованный aes-xts essiv:sha256. Естественно что пользователю необходимо указать свой пароль (имеется ввиду тот, который используется для экрана блокировки и для загрузки Android ... с графическим ключом я правда не пробовал, т.к. у меня на экране блокировки указан именно пароль, но думаю что с ним все тоже будет работать).
- Корректно монтировать SD-карту, отформатированную как внутреннюю память (adopted storage), думаю из видео - это видно.
- Корректно выставлять текущее время в recovery (да, да, мы живем в настоящем времени, а не в epoch0 ;)
На все про все (имеются ввиду суммарно все работы, как по созданию флешера Sahara & Firehose Test, так и по сборке TWRP) у меня ушло чуть больше месяца. А на "допиливание" TWRP и попытки разобраться что к чему вечер пятницы и практически целые сутки в субботу (семья в выходной меня не видела, а видела только мою спину за компьютером). Но ... поставленная цель достигнута, результат получен. А это всегда приятно.
Все свои наработки, которые касаются TWRP к Idol 4, в частности дерево девайса я выложил в Git'е - DeckerSU/idol4_6055k_device_tree, заоодно и немного научился с ним работать. Скажем так на базовом уровне, как сделать push, pull и checkout ;) Т.к. до этого, к моему большому сожалению, работать с чем-то типа GitHub'а не приходилось, т.к. не было необходимости. Это мой небольшой вклад в сообщество.
Готового же решения в виде бинарника recovery_twrp_3.0.2-0-decker.img для Idol 4 и "мурзилки" (пошаговой инструкции) как его прошить - я решил пока не выкладывать. Если тема вам интересна на данный момент вы можете:
- Попробовать самостоятельно собрать TWRP из выложенного мной дерева на базе репозитария OmniROM (repo init -u https://github.com/omnirom/android.git -b android-6/0), благо мануалов по сборке TWRP recovery для платформы Qualcomm из исходников в интернете предостаточно. Плюс возможность чему-то научиться - это всегда хорошо.
- Следить за развитием проекта Sahara & Firehose Test, а возможно даже поддержать его и помочь ему вырасти до полноценного флешера для девайсов на базе Qualcomm, ну или как альтернатива - найти свой способ заливки recovery в аппарат.
Ну а у меня на этом наверное всё ... сейчас выложу еще немного скриншотов / фото того что получилось и с чувством глубокого морального удовлетворения завалюсь спать, все-таки 06:55 утра на часах ;)
p.s. Кстати, интересный вопрос, который наверное зададут многие ... а куда Backup'иться если SD-карта используется как adopted storage, т.е. отфоматирована как внутренняя память? В этом случае вам поможет USB-OTG и обычная флешка:
К слову ... если вы прочитали эту статью выше, то наверное поняли, что если microSD у вас используется как adopted storage, то ключ шифрования от microSD карты хранится в /data/misc/vold , у меня это выглядело так:
Таким образом, если вставить эту флешку в ПК с Linux'ом и сделать что-то вроде:
dmsetup create crypt1 --table "0 `blockdev --getsize /dev/sdb2` crypt aes-cbc-essiv:sha256 <Put the 16-byte hex key here> 0 /dev/sdb2 0"
Где /dev/sdb2 - это непосредственно флешка. То потом можно будет ее примонтировать, как обычный ext4 раздел: mount -t ext4 /dev/mapper/crypt1 /mnt/1/ , правда я пока не пробовал. Но думаю что получится, т.к. ключ-то есть ;)
Таким образом если мы сделали backup раздела userdata, то соответственно и backup ключей от adopted storage (/data/misc/vold/expand_%s.key) и если вдруг телефон у нас по каким-то причинам канет в лету, то мы легко сможем расшифровать содержимое флешки при наличии ключа.
p.p.s. Кстати, выяснил один интересный момент. Итак. если у вас был установлен тип блокировки именно пароль, а не PIN - то раздел userdata шифруется аппаратно с вашим паролем. Если в настройках безопасности вы указали именно PIN - то userdata будет зашифрован с default_password. Т.е. при старте TWRP он примонтируется без запроса PIN'а. Вот такая вот хитрая безопасность.
Обновлено 11.09.2016 07:51 (MSK)
(никак не улягусь) ... Примечательный факт. Если у кого-то из вас был Idol 3 6039Y, то вы наверняка помните что при создании Backup'а в TWRP аппарат имел свойство нагреваться до запредельной температура, да и даже в состоянии "простоя", просто когда запущен TWRP аппарат почему-то ощутимо грелся. В случае же с Idol 4 такого нет в принципе. Т.е. при "простое" в TWRP температура - 28 градусов (если верить показаниям самого TWRP), а в процессе практически 15-минутного backup'а всех разделов на USB флешку подключенную через OTG температура поднялась только до 33 градусов. При этом наощупь аппарат ни нагрелся даже ни на один градус. Т.е. несмотря на то что процесс создания полного Backup'а довольно ресурсоемкий - на температуре гаджета это никак не отражается (вот прямо написал и еще раз порадовался за свой Idol 4 ;)
Ну и конечно же пару слов про root. С установленным TWRP получить его по описанному здесь методу, т.е. с установкой SuperSU как systemless не составляет никаких проблем. Вот результаты:
Кстати, ядро нашего аппарата не поддерживает модификацию TTL. Т.е. использовать на нем программы типа TTL Editor и т.п. добавляющие правило для фиксации TTL в iptables не получится, т.к. /proc/net/ip_tables_targets не содержит TTL.
Ну вот теперь, когда все увидели первый в мире Idol 4 6055K с полученным root'ом (ну за исключением разве что девелоперских версий, т.е. аппаратов разработчиков ПО в TCL) и узнали что "халявного тетеринга" с Idol 4 не получится без пересборки ядра, можно действительно отправляться отдыхать ;) Stay tuned, впереди еще много интересного.
