Собрал патч (CN vela_ap + гибридный resource 132МБ под 140-раздел + русский), подписал testkey, упаковал Deflate как оригинал. Notify принимает (“файл правильный”), уходит на 100%, браслет ребутится в recovery и откатывается: “Обновление не удалось, восстановлено до предыдущей версии”.
Разобрал почему — в vela_ota.bin (recovery) скрипт: miwear_recovery_ota & zip_verify /data/ota.zip /etc/key.avb zip_verify.c проверяет “APK Sig Block 42” (APK Sig Scheme v2/v3) через avb_rsa.c против пришпиленного /etc/key.avb. При провале: “zip_verify ota.zip failed, will reboot to the old system”.
То есть весь ota.zip пинится к /etc/key.avb, не только vela_ota.bin. Наша testkey-подпись (+ только v1 JAR, без v2/v3 блока) это не проходит — отсюда откат, ещё до записи разделов. Так что romfs/упаковка ни при чём, стена — на zip_verify.
Разобрал recovery-скрипт (rcS) из vela_ota.bin целиком:
mount /dev/resource → /resource ← читает то, что УЖЕ на флешке
Ни одной ветки обхода zip_verify. Ни persist.*, ни system_mode, ни debug-флага. Recovery жёсткий.
По вашему опыту “обход через ota.sh на другой модели” — да, там rcS, вероятно, был без zip_verify, шёл сразу к sh /ota/ota.sh. На 10 Pro эту дыру закрыли.
Пробовал найти УДАЛЁННЫЕ векторы включения userdebug (чтобы через lc_proto потом писать файлы) — ноль:
factory_set_mode_cb (FACTORY::SET_MODE) — функция существует, читает persist.system_mode, пишет новое, просит reboot. Никакого challenge/подписи. НО: ни в GL, ни в CN не подписана на BLE-события. factory_do_subscribe в user-режиме регистрирует только get_mode + self_check_request. SET_MODE достижим только через AT^ по UART.
lc_proto GATT service (UUID 0x3802) содержит check_open_user_debug, принимает строку “00AT^USERDEBUG=ON” plaintext без криптографии, пишет persist.system_mode, “please reboot”. Но lc_proto_start_ble_adv в user-режиме не вызывается — сервис не рекламируется, недоступен по BLE. Web Bluetooth проверил вживую: у браслета видны 180A/180F/FDAB/FE95, 0x3802 нет.
SET_ATTP (FactoryID=128) обработчика в GL вообще нет.
AT^USERDEBUG=ON, AT^MR_WRITE, AT^MKDIR (284 AT-команды в bl2) — приходят через lc_gatts_write_request_callback, то есть через тот же lc_proto. Круг замкнут.
Вопрос: правильно ли я понимаю, что на 10 Pro без UART-заливки (BES ROM download / SecondStage от atc1441) вообще никак? И если да — залитый мимо OTA CN ap + гибридный resource должны стартовать (AVB0-footer на ap нет, bl2 его подпись не чекает), верно?
Спасибо, всё встало на места — особенно про флеш: это ровно объясняет, почему у меня прошивка китайки на глобал стабильно рвётся на 54%. CN resource 164 МБ просто не лезет в глобальный раздел 140 МБ.
Трюк с последним dword проверил — да, base там 0x280C0000, а мой анализ шёл по 0x2C0C0000. XOR ровно 0x04000000, то есть это cache/uncached-алиас одной флешки (0x0C… raw из бэктрейсов лога, 0x28… из трейлера, 0x2C… в ldr =const). Спасибо, полезно.
Попробовал собрать ровно то, что вы предложили — CN vela_ap.bin + пересобранный resource под глобальный раздел 140 МБ. Может пригодится как заготовка:
База — CN vela_resource.bin. Изменения: — /i18n заменил на глобальный (41 язык + русский вместо CN-шного zh/en); — выкинул мёртвые в global китай-сервисы: voice/aivs/alipay/wxpay/mijia/nfccard/car_control (~6.4 МБ) и /app/demo (~3.9 МБ); — выкинул 2 самых жирных встроенных циферблата 120917392537 (21.4) и 120917392528 (13 МБ). CN ap выбирает дефолт динамически («set the first watchface as default»), оставил 9 циферблатов + aod — должен грузиться.
Итог 132.4 МБ, влезает. Собрал своим romfs-упаковщиком, формат стандартный -rom1fs-: volume checksum 0, все 6456 per-file checksum валидны, round-trip читается идентично, байты файлов сверил (шрифты/циферблаты = CN, ru_RU/messages.mo = global). Но примет ли это монтирование Vela — проверить не на чем, у меня нет UART-восстановления.
Два момента, где нужен ваш опыт по разметке global:
Раздел /dev/ap. CN ap = 13.2 МБ, global = 9.8 МБ (+3.4). Если раздел ap на глобалке жёстко под ~10 МБ — CN ap не влезет. Реальные размеры разделов 256-МБ флешки только у вас.
Разница ap 10 vs 13 МБ — вырезана явно не только служба快应用; CN ap может тянуть зависимости, которых в global-окружении нет.
Если поможет — пощупайте мои наработки (https://disk.yandex.ru/d/GZ9VulTRK8ORlA). Подпись, как вы и говорите, не проблема: AVB висит только на vela_ota.bin, всё остальное — testkey AOSP через ota.sh.
Сам прошивать я не рискну, нет нужной аппаратуры для восстановления
Спасибо за статью — редкий случай, когда про эту железку пишут по существу.
Я на днях разбирал ту же платформу с другой стороны и, кажется, нашёл кое-что полезное для вашей темы с recovery.
Распаковал два официальных OTA для p67: глобальный 3.201.016 и китайский 3.101.042. Выяснилось, что AVB покрывает только vela_ota.bin — в vbmeta ровно один hash-дескриптор, на сам себя. vela_ap.bin, vela_resource.bin и vela_bl2.bin криптографически не защищены вообще, для них в ota.sh стоит просто dd … verify. А сам zip подписан тестовым ключом AOSP (CN=Android, android@android.com), приватная часть которого лежит в открытых исходниках. AVB-ключ у глобальной и китайской сборок при этом побайтово одинаковый.
То есть модифицированный vela_ap.bin или vela_resource.bin в пересобранном и переподписанном пакете проходит проверку. Для вашей затеи с подменой загрузчика и упаковкой recovery-OTA это, по-моему, снимает главный вопрос.
Заодно: база загрузки vela_ap.bin — 0x2C0C0000 (определил гистограммой указателей на строки, сходится 95%), исполняемый алиас 0x0C0C0000 — он и виден в бэктрейсах из /data/offlinelog.
Два вопроса, если найдётся минута.
Первый. Пробовал накатить китайскую 3.101.042 на глобальный 10 Pro. Передача проходит на 100%, дальше ota.sh стабильно обрывается на 54% и перезагрузка — это запись vela_resource.bin (фаза 45→95%), примерно 31 МБ. bl2 при этом прошивается успешно, до ap дело не доходит. Китайский раздел ресурсов весит 171,7 МБ при 122 МБ хранилища на браслете — подозреваю нехватку места при распаковке, но откуда ровно 31 МБ, не понимаю. Не сталкивались?
Второй. В глобальной прошивке есть рантайм快应用 — QuickJS вкомпилирован, install_quickapp по 0x2C7ADF4C рабочий, с разбором rpk_info.json. Но протокольной службы THIRDPARTY_APP нет: браслет молча игнорирует команды типа 20, проверено четырьмя клиентами включая саму Mi Fitness. Все вызовы install_quickapp идут только из загрузчика ресурсов. Насколько реально дописать в глобальный образ диспетчер, который принимал бы эти команды и дёргал существующую функцию?
Собрал патч (CN vela_ap + гибридный resource 132МБ под 140-раздел + русский), подписал testkey, упаковал Deflate как оригинал. Notify принимает (“файл правильный”), уходит на 100%, браслет ребутится в recovery и откатывается: “Обновление не удалось, восстановлено до предыдущей версии”.
Разобрал почему — в vela_ota.bin (recovery) скрипт: miwear_recovery_ota & zip_verify /data/ota.zip /etc/key.avb zip_verify.c проверяет “APK Sig Block 42” (APK Sig Scheme v2/v3) через avb_rsa.c против пришпиленного /etc/key.avb. При провале: “zip_verify ota.zip failed, will reboot to the old system”.
То есть весь ota.zip пинится к /etc/key.avb, не только vela_ota.bin. Наша testkey-подпись (+ только v1 JAR, без v2/v3 блока) это не проходит — отсюда откат, ещё до записи разделов. Так что romfs/упаковка ни при чём, стена — на zip_verify.
Разобрал recovery-скрипт (rcS) из vela_ota.bin целиком:
mount /dev/resource → /resource ← читает то, что УЖЕ на флешке
mount /dev/nand_data → /data
cp -rf /resource/recovery → /data/recovery
if [ ! -e /data/ota.zip ] then reboot fi
miwear_recovery_ota &
zip_verify /data/ota.zip /etc/key.avb ← абсолютная стена
mount -t zipfs /data/ota.zip /ota
sh /ota/ota.sh > /dev/log ← только после verify
Ни одной ветки обхода zip_verify. Ни persist.*, ни system_mode, ни debug-флага. Recovery жёсткий.
По вашему опыту “обход через ota.sh на другой модели” — да, там rcS, вероятно, был без zip_verify, шёл сразу к sh /ota/ota.sh. На 10 Pro эту дыру закрыли.
Пробовал найти УДАЛЁННЫЕ векторы включения userdebug (чтобы через lc_proto потом писать файлы) — ноль:
factory_set_mode_cb (FACTORY::SET_MODE) — функция существует, читает persist.system_mode, пишет новое, просит reboot. Никакого challenge/подписи. НО: ни в GL, ни в CN не подписана на BLE-события. factory_do_subscribe в user-режиме регистрирует только get_mode + self_check_request. SET_MODE достижим только через AT^ по UART.
lc_proto GATT service (UUID 0x3802) содержит check_open_user_debug, принимает строку “00AT^USERDEBUG=ON” plaintext без криптографии, пишет persist.system_mode, “please reboot”. Но lc_proto_start_ble_adv в user-режиме не вызывается — сервис не рекламируется, недоступен по BLE. Web Bluetooth проверил вживую: у браслета видны 180A/180F/FDAB/FE95, 0x3802 нет.
SET_ATTP (FactoryID=128) обработчика в GL вообще нет.
AT^USERDEBUG=ON, AT^MR_WRITE, AT^MKDIR (284 AT-команды в bl2) — приходят через lc_gatts_write_request_callback, то есть через тот же lc_proto. Круг замкнут.
Вопрос: правильно ли я понимаю, что на 10 Pro без UART-заливки (BES ROM download / SecondStage от atc1441) вообще никак? И если да — залитый мимо OTA CN ap + гибридный resource должны стартовать (AVB0-footer на ap нет, bl2 его подпись не чекает), верно?
Спасибо, всё встало на места — особенно про флеш: это ровно объясняет, почему у меня прошивка китайки на глобал стабильно рвётся на 54%. CN resource 164 МБ просто не лезет в глобальный раздел 140 МБ.
Трюк с последним dword проверил — да, base там 0x280C0000, а мой анализ шёл по 0x2C0C0000. XOR ровно 0x04000000, то есть это cache/uncached-алиас одной флешки (0x0C… raw из бэктрейсов лога, 0x28… из трейлера, 0x2C… в ldr =const). Спасибо, полезно.
Попробовал собрать ровно то, что вы предложили — CN vela_ap.bin + пересобранный resource под глобальный раздел 140 МБ. Может пригодится как заготовка:
База — CN vela_resource.bin. Изменения: — /i18n заменил на глобальный (41 язык + русский вместо CN-шного zh/en); — выкинул мёртвые в global китай-сервисы: voice/aivs/alipay/wxpay/mijia/nfccard/car_control (~6.4 МБ) и /app/demo (~3.9 МБ); — выкинул 2 самых жирных встроенных циферблата 120917392537 (21.4) и 120917392528 (13 МБ). CN ap выбирает дефолт динамически («set the first watchface as default»), оставил 9 циферблатов + aod — должен грузиться.
Итог 132.4 МБ, влезает. Собрал своим romfs-упаковщиком, формат стандартный -rom1fs-: volume checksum 0, все 6456 per-file checksum валидны, round-trip читается идентично, байты файлов сверил (шрифты/циферблаты = CN, ru_RU/messages.mo = global). Но примет ли это монтирование Vela — проверить не на чем, у меня нет UART-восстановления.
Два момента, где нужен ваш опыт по разметке global:
Раздел /dev/ap. CN ap = 13.2 МБ, global = 9.8 МБ (+3.4). Если раздел ap на глобалке жёстко под ~10 МБ — CN ap не влезет. Реальные размеры разделов 256-МБ флешки только у вас.
Разница ap 10 vs 13 МБ — вырезана явно не только служба快应用; CN ap может тянуть зависимости, которых в global-окружении нет.
Если поможет — пощупайте мои наработки (https://disk.yandex.ru/d/GZ9VulTRK8ORlA). Подпись, как вы и говорите, не проблема: AVB висит только на vela_ota.bin, всё остальное — testkey AOSP через ota.sh.
Сам прошивать я не рискну, нет нужной аппаратуры для восстановления
Спасибо за статью — редкий случай, когда про эту железку пишут по существу.
Я на днях разбирал ту же платформу с другой стороны и, кажется, нашёл кое-что полезное для вашей темы с recovery.
Распаковал два официальных OTA для
p67: глобальный3.201.016и китайский3.101.042. Выяснилось, что AVB покрывает толькоvela_ota.bin— в vbmeta ровно один hash-дескриптор, на сам себя.vela_ap.bin,vela_resource.binиvela_bl2.binкриптографически не защищены вообще, для них вota.shстоит простоdd … verify. А сам zip подписан тестовым ключом AOSP (CN=Android,android@android.com), приватная часть которого лежит в открытых исходниках. AVB-ключ у глобальной и китайской сборок при этом побайтово одинаковый.То есть модифицированный
vela_ap.binилиvela_resource.binв пересобранном и переподписанном пакете проходит проверку. Для вашей затеи с подменой загрузчика и упаковкой recovery-OTA это, по-моему, снимает главный вопрос.Заодно: база загрузки
vela_ap.bin—0x2C0C0000(определил гистограммой указателей на строки, сходится 95%), исполняемый алиас0x0C0C0000— он и виден в бэктрейсах из/data/offlinelog.Два вопроса, если найдётся минута.
Первый. Пробовал накатить китайскую
3.101.042на глобальный 10 Pro. Передача проходит на 100%, дальшеota.shстабильно обрывается на 54% и перезагрузка — это записьvela_resource.bin(фаза 45→95%), примерно 31 МБ.bl2при этом прошивается успешно, доapдело не доходит. Китайский раздел ресурсов весит 171,7 МБ при 122 МБ хранилища на браслете — подозреваю нехватку места при распаковке, но откуда ровно 31 МБ, не понимаю. Не сталкивались?Второй. В глобальной прошивке есть рантайм快应用 — QuickJS вкомпилирован,
install_quickappпо0x2C7ADF4Cрабочий, с разборомrpk_info.json. Но протокольной службыTHIRDPARTY_APPнет: браслет молча игнорирует команды типа 20, проверено четырьмя клиентами включая саму Mi Fitness. Все вызовыinstall_quickappидут только из загрузчика ресурсов. Насколько реально дописать в глобальный образ диспетчер, который принимал бы эти команды и дёргал существующую функцию?Полная выкладка со всеми адресами и логами: https://github.com/atc1441/MiBand10-BES2700iMP-BEST1503-Hacking/issues/3