Сразу скажу, что т.к. аппарат построен на базе Nougat, то собирать TWPR для него обязательно на базе исходников из ветки 7.1 OmniROM (можно конечно собрать android_bootable_recovery и в составе CyanogenMod / LineageOS), но опять же, "платформа" 7.1 обязательна. Почему? Если опустить аргумент об идеологической правильности подобного подхода, скажу, что на базе Marshmallow TWRP также прекрасно соберется, но при попытке запуска под его управлением любых стоковых бинарников, например, vold, logcat и т.п. вы неизбежно получите ошибку cannot locate symbol "__write_chk", т.к. все стоковые бинарники используются экспортируемую функцию __write_chk из libc, которой в Marshmallow просто нет. Таким образом собирая TWRP на исходниках от 6.0 вы автоматически собираете libc без __write_chk, что приведет к неработоспособности части бинарников собранных под Nougat внутри получившегося TWRP. Поэтому если вы часто собираете TWRP для различных устройств и еще не успели склонировать репозитарий того же OmniROM 7.1 - сейчас самое время сделать это, т.к. по всей видимости устройств с Nougat на Mediatek будет появляться все больше и вам рано или поздно придется это сделать.
Других особенностей, касающихся именно процесса сборки TWRP - вообщем-то нет, все штатно, также как и в случае с 6.0. Собранный у меня кастомный recovery отлично запустился на аппарате, но вот как раз тут и начались "приключения". Как известно, раздел userdata в Android N является шифрованным, т.к. объявлен в fstab'е как forceencrypt с хранением ключей шифрования в metadata. Вот как раз это и послужило началом всей истории. Загрузившись в только что собранный TWRP я обнаружил что он запрашивает пароль для дешифровки userdata и не монтирует его. При этом пароль в устройстве, т.е. ни PIN-код для разблокировки, либо загрузки Android, ни графический ключ не был явно задан.
Т.е. фактически TWRP по каким-то причинам не смог расшифровать раздел с помощью default_password. Включение отладочных средств TARGET_USES_LOGD и TWRP_INCLUDE_LOGCAT в BoardConfig.mk при сборке также не помогло установить причину проблемы. Вывод logcat и dmesg в этом плане был малоинформативен.
Конечно в данной ситуации можно было поступить проще (подобное решение можно увидеть в многочисленных сборках TWRP, в котором разработчикам было лень разбираться с шифрованием), например, просто разобрав boot и изменив forceencrypt на encryptable с последующим форматированием раздела userdata и потерей всех данных. Но это ведь не наш путь, т.к. в моем понимании у пользователя устанавливающего TWRP на аппарате уже есть какие-то данные и терять их из-за того что TWRP не может справиться с расшифровкой раздела, как минимум не хотелось бы. Другими словами, TWRP должен монтировать существующий на устройстве раздел userdata, все другие варианты (отключение шифрования и т.п.) являются "полумерами", к тому же еще и снижающими безопасность устройства.
Тогда я вспомнил, что начиная с определенной версии TWPR в нем появилась возможность использования стоковых бинарников vold с помощью включения TW_CRYPTO_USE_SYSTEM_VOLD в сборку, информация об этом есть в этом коммите - crypto: Use system's vold for decryption. Бегло изучив все что там говорится, а также проанализировав содержимое исходников в /bootable/recovery/crypto/vold_decrypt/ я включил этот флаг в BoardConfig.mk и пересобрал recovery. Т.е. теперь уже TWRP использовал бинарник vold находящийся в system ... Однако дешифрование раздела и его монтирование все равно не происходило, т.к. при сборке vold в стоковой прошивке разработчиками была включена проверка boot_mode. Что она из себя представляет?
Для лучшего понимания приведу следующий исходник:
int get_boot_mode(void)
{
int fd;
ssize_t s;
char boot_mode[4] = {'0'};
char boot_mode_sys_path[] = "/sys/class/BOOT/BOOT/boot/boot_mode";
fd = open(boot_mode_sys_path, O_RDONLY | O_NOFOLLOW | O_CLOEXEC);
if (fd < 0)
{
SLOGE("fail to open %s: %s", boot_mode_sys_path, strerror(errno));
return 0;
}
s = read(fd, boot_mode, sizeof(boot_mode) - 1);
close(fd);
if(s <= 0)
{
SLOGE("could not read boot mode sys file: %s", strerror(errno));
return 0;
}
boot_mode[s] = '\0';
return atoi(boot_mode);
}
Здесь get_boot_mode возвращает текущий режим загрузки устройства, который она читает из /sys/class/BOOT/BOOT/boot/boot_mode . Так вот стоковый vold вызывает некий аналог этой get_boot_mode и если устройство загружено в режиме отличном от system, т.е. в recovery mode или в любом другом доступном режиме, то монтирование / дешифрование userdata невозможны в принципе. В логах вы увидите нечто вроде <5>fs_mgr: %s: bootmode(%d) is NOT normal mode, disable 'default encrytion', flag=(0x%x -> 0x%x)". Скачав и установив бесплатную demo версию IDA v6.95.160810 мы можем увидеть эту проверку самостоятельно:
Где в дальнейшем используются результаты этой проверки и как именно - разбираться досконально я не стал, однако, факт отключения default encryption в vold при загрузке в режиме recovery, естественно, нас не устраивал. Из этой сложившейся ситуации есть несколько выходов:
- Непосредственный патч vold для обхода этой проверки.
- Написание собственной библиотеки с размещением ее в LD_PRELOAD, которая перехватывала бы попытки обращения в цепочке open("/sys/class/BOOT/BOOT/boot/boot_mode") -> __read_chk -> close от любых приложений и всегда возвращала бы нужное значение (т.е. 0 = normal_mode).
- Сборка vold из исходников Android N для MT6737M от Mediatek с корректировкой всех проверок в исходниках.
Любая из этих реализаций должна привести к успеху, поэтому какой именно воспользоваться - не имеет большого значения. Здесь главное не забыть, что собранный из исходников или модифицированный vold должен корректно загружаться из init.recovery.vold_decrypt.rc, например так:
service sys_vold /path_to_your_vold/vold \
--blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
--fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
socket vold stream 0660 root mount
socket cryptd stream 0660 root mount
setenv PATH /system/bin
setenv LD_LIBRARY_PATH /system/lib64:/system/lib
disabled
oneshot
Однако, даже решив эту проблему - мы не получим полноценного решения по дешифрованию userdata в TWRP, т.к. платформа использует еще и teei_daemon для поддержки шифрования. Изучить как он запускается и работает можно посмотрев внутрь init.microtrust.rc из boot'а. И наконец последний шаг на пути к успеху, это обеспечение корректного запуска и работы этого демона при дешифровании, "красивым" и правильным шагом здесь, на мой взгляд, является помещение его инициализации в соответствующий init.recovery.vold_decrypt.$(item).rc (разобраться с этим подробнее вам поможет /bootable/recovery/crypto/vold_decrypt/Android.mk).
В качестве результата проделанной работы я получил незаменимый опыт (что главное), а также полноценной работающий TWRP 3.1.1-0:
Как видно из фото - раздел userdata успешно расшифрован и примонтирован (Data succefully decrypted, new block device: '/dev/block/dm-0') created). Mission accomplished ;)
p.s. Во-избежание наболевшего вопроса "а где можно скачать готовую сборку TWRP" - скажу сразу что дата public релиза пока не определена. Однако все необходимые для сборки моменты уже рассмотрены в этой статье и любой желающий, ориентируясь на мои наработки может пройти тем же путем.
В качестве результата проделанной работы я получил незаменимый опыт (что главное), а также полноценной работающий TWRP 3.1.1-0:
Как видно из фото - раздел userdata успешно расшифрован и примонтирован (Data succefully decrypted, new block device: '/dev/block/dm-0') created). Mission accomplished ;)
p.s. Во-избежание наболевшего вопроса "а где можно скачать готовую сборку TWRP" - скажу сразу что дата public релиза пока не определена. Однако все необходимые для сборки моменты уже рассмотрены в этой статье и любой желающий, ориентируясь на мои наработки может пройти тем же путем.
