Разборка прошивки электросамоката Xiaomi M365

[quote="Тарас"]все прошивки которые сдесь выложены, на MAIN плату,не рабочие! При прошивке контроллера - ноль![/quote]

[quote="Ed01"]Процесс обновления этих данных - есть Активация[/quote]

[quote="demonizer"]

Если залить прошивку в голый камень, скорее всего, результат и будет нулевым.

Вариантов программной защиты может быть много, даже с корректным бинарником.

[/quote]

На примере прошивки БМС, как части общей прошивки, как раз это и выяснялось. Клонировать все данные (включая пользовательские) в новый чип легко. Но чтобы получить рабочий вариант этого недостаточно.

Клонированная БМС, сама по себе работает, но если подключить её к контроллеру, начинает мигать красным. А контроллер выдает "BMS ошибкa пароля" https://electro.club/f/3171

Серийный номер не имеет особого значения и его можно менять. Но существует привязка к  аппаратному "чип ID" самого контроллера. А сформировать пользовательские данные под этот ID не зная алгоритма, все равно что отгадать серийник к Фотошопу).

[quote="demonizer"]По поводу прошивки контроллера, появилась мысль написать свою, в сущности, задача довольно тривиальная[/quote]

Тут, еще проблема может возникнуть на этапе тестирования. Выявляя ошибки и подстраивая режимы, рулить прошивку можно бесконечно). Малая задача - произвольный откат прошивок (БМС теперь можно). И возможно, обход проверки батареи. У АП - разработчика кастомной прошивки такое намечалось. Но видимо есть подводные камни и теперь в разработке у него аппаратная обманка v3.0.

Сконвертировал HEX в BIN (ранее слитый с БМС). В дампе содержится больше данных, т.к он перекрывает всё адресное пространство Flash-памяти. Данные состоят из трех частей:

1). С адреса 0x8000 - вероятно, Boot-загрузчик. Он одинаков в обоих BMS и не обновляется при штатной перепрошивке.

2). C адреса 0x9000 - собственно сама прошивка. Сравнил по содержимому с известным файлом прошивки. И он полностью совпадает. Это говорит о том, что бинарники с сервера не используют шифрование или сжатие.

3). C адреса 0xC800 - вторая копия прошивки. Не знаю зачем. Встречал такое в TV Самсунг.

Если, конечно, проверка заводского номера, находится не в загрузчике, а в программе.

Поставил чип контроллера STM32F103C8T6 в программатор...

И да, к сожалению защита ROP на нем активна. Лить прошивку можно только вслепую.

Я лил в пустой камень, толку нет, возможно, серийный номер контролера, отображаемый в приложении (он там числовой), и есть серийник камня (96 бит).

Возможно копия на случай сбоя при перепрошивке.

[quote="Бася"]Возможно копия на случай сбоя при перепрошивке.[/quote]

Возможно. В телевизорах было примерно так: при обновлении, новая версия шилась на новое место, а старая оставалась. При следующем обновлении, уже затиралась первая версия. и.т.д Это позволяло откатить прошивку в "один клик". Позже, когда пошла мода на принудительное обновление без возможности отката, кнопку переключения убрали из меню. Но принцип остался. Для надежности.

Может перехватить прошивку непосредственно при обновлении ? Или врезаться в uart Rx Tx на плате двумя уартами Rx ?

Я так когда-то клонировал протокол))

[quote="Тарас"]Может перехватить прошивку непосредственно при обновлении ? Или врезаться в uart Rx Tx на плате двумя уартами Rx ?[/quote]

Сама по себе прошивка есть. Вернее, обновляемая ее часть. Не хватает важной части - boot загрузчика.

Он зашит на заводе, не обновляется и сидит в начальных адресах Flash (0x08000000).  При старте передает управление на точку входа основной прошивки (обновляемой части). Поэтому, размещая перехваченную прошивку в любой части чистого чипа, мы никогда ее не запустим без бута.

Boot можно получить из чипа, считав дамп всего адресного пространства Flash. Но этому препятствует защита ROP.

Зашита перекрывает все команды доступа к памяти через встроенные в  ROM интерфейсы UART и SWD.

Она оставляет лишь одну команду - снять защиту. В этом случае вся память затирается вместе с бутом, успешно и быстро) Чип открыт, но считывать с него нечего.

Поэтому программатор оказался бесполезен. А чтобы снять защиту, всего-то нужно было заменить число 0xFF на 0xA5 в адресе 0x1FFFF800.

Перехват во время обновления - это конечно мысль. Но не с целью получить прошивку, а получить образец команды записи. Зная ее, через голову  можно заменить то число и разлочить чип. Или применить команду чтения. Но интерфейс там явно не UART.

p.s На момент создания, тема будучи актуальной, сейчас несет больше экспериментальный и познавательный характер.

Всё ИМХО.

Тема по-прежнему актуально, но потребуется жертва. А именно:

1 не обновлённый контроллер, который не жалко

2 логический анализатор

3 время

Собственно, у меня есть только второе))))

Ну, кстати, моё мнение такое: бут есть бут, он обязан быть стандартным. Учитывая, что в прошивке, что предоставлена в теме, есть серийник, он передаётся на сервер, и в файл прошивки добавляется ключ для конкретного контроллера.

Учитывая, что МАХ прошивка основана на 1.3.0 (совпадение?), вполне реально этот ключ вычленить, т.к. один раз это уже сделано.

Почему для прошивки на МАХ требуется отправлять контроллер? Ничего сложного в том, чтобы написать своё приложение, прошивающее сяо по воздуху через штатный загрузчик, не вижу. Для коммерции - оплата-ключ для одноразовой прошивки.

И ещё: можно попробовать заливать прошивку на конкретную страницу флеш, вдруг, программа, действительно, проверяет адрес вектора загрузки. Надо попробовать

Вот для БМС, легко вызвать обновление:

Достаточно в обманке или в терминалке прописать версию bms, допустим 0.01. И приложение сразу предлагает обновится. Не уходя со станицы обновления переключится на реальную БМС. И можно шить с 1.1.5 на 1.1.5)

Но это нужно еще уточнять. До конца не делал.

А с контроллером, даже не знаю. А что там за шина, если не секрет?

Контроллер с блютусом общается по однопроводной шине, там тот же уарт, только по одному проводу. Как lin-шина, но не совсем.

Бут может использоваться для защиты прошивки, проверки подписи, контрольной суммы и, например, расшифровывать прошивку при загрузке в чип. Ну или обеспечивать загрузку по воздуху (OTA/FOTA). И такой бут может быть весьма нестандартным.

Прошивка очень врядли зашифрована, ибо в ней незашифрованный серийник.

Безусловно, протокол свой, и, естественно, с контрольной суммой. Но это не проблема.

Принцип примерно следующий: в контроллер отправляется некая последовательност байт, означающая начало обновления. Потом, например, передаётся 128 байт и crc, бут считает crc сам и сравнивает с той, что прилетела. Если ок, сохраняет во флешь. Если нет-повтор. После нескольких неудач-отменяем обновление и перезаливаем из резервной области, как было

Кстати, это и объясняет необходимость дублирования прошивки. Видимо, в начале обновления, записывается флаг, означающий начало записи во флеш. Если все байты получены, флаг снимается. Таким образом, если даже отключить питание физически при обновлении, при включении, бут увидит поднятый флаг, т.е. недописанный флеш и перезальет из резервной области.

[quote="demonizer"]Прошивка очень врядли зашифрована, ибо в ней незашифрованный серийник.[/quote]

Нет, нет, не зашифрована. В БМС, что не закрыта ROP, файл совпал с дампом чипа байт в байт. А модуль прошивки контроллера в том же пакете.

Ну и океюшки, значит, надо ковырять

Очень интересная тема! Если бы пол года  - мес 8 назад начал читать подобное - вправда поверил бы, что это возможно.

Сейчас, когда "в курсе" как это было на самом деле у Лехи - всем желаю огромной удачи и успехов от всей души.

держитесь парни - я с вами!

Всем добра! :))