BMW mulitmap

shariz124 сказал(а):

кто-нибудь пробовал эти bmw multimap с tunerpro из github? не совсем понимаю, как работает multimap? и ...

Нажмите, чтобы раскрыть...

Да, в репозиториях GitHub обычно есть XDF для TunerPro и патчи на ассемблере (ASM), которые нужны, чтобы внедрить логику multimap в бинарник.

В общих чертах multimap работает так:

• Патч кода перехватывает определённые вызовы функций внутри DME (обычно связанные с расчётами Load, Boost или Timing).
• Он отслеживает входной параметр, обычно кнопки круиз-контроля или переключатель режима вождения (Eco/Sport).
• В зависимости от выбранного режима код применяет смещение в памяти к указателям карт, заставляя ECU читать из "Map slot 2", "Map slot 3" и т. д. вместо таблиц по умолчанию.

Что касается прошивки через OBD с такими инструментами, как Flex, Kess3 или Autotuner:
Будьте очень осторожны.

Эти инструменты предназначены для исправления контрольных сумм (CS/RSA/CVN) для стандартных структур прошивки. Поскольку multimap включает внедрение пользовательского кода (добавление кода туда, где обычно есть пустое место, или перезапись существующих процедур), автоматическое исправление контрольных сумм в универсальных инструментах часто не срабатывает или повреждает патч, что приводит к «кирпичу» ECU или машине, которая не заводится.

Если хотите использовать универсальные OBD-инструменты:

• Вам нужно рассчитать контрольные суммы отдельно до загрузки файла в инструмент.
• Нужно убедиться, что инструмент не пытается заново рассчитать контрольные суммы

автоматически (отключите автоматический расчёт контрольной суммы, если в инструменте это можно сделать).
PCMFlash

Большинство тех, кто использует эти открытые определения, применяют специальные флешеры (например, приложение MHD flasher или программы для прямой записи бинарника, такие как PCMFlash), которые, как известно, корректно обрабатывают или игнорируют пользовательские блоки кода.

понял. и на GitHub для каждой версии софта, как я понимаю, есть отдельная папка? одна — это xdf, оригинальный bin, а потом bin для переключения карт. не совсем понимаю, как это работает, если я делаю чтение по OBD своим инструментом? мне нужно сопоставить считанный файл с одним из оригинальных bin, а потом вместо него использовать bin для переключения карт, отредактировать его и залить обратно?

ты уверен? как только flex подключается к моей машине, я сохраняю CAFD, потом считываю данные, правлю файл, а когда записываю его обратно, CAFD автоматически записывается

TunerPro почему-то не применяет патч: нажимаю patch bin -> from s-record и выбираю правильный multimap bin с тем же SW, а он пишет, что не удалось применить патч.

но mapswitchbase — это .bin, и исходный файл тоже .bin

можно ли это сделать в winols5

Gemini сказал(а):

Да, абсолютно. WinOLS на самом деле гораздо лучше и безопаснее для этой задачи, чем HxD, потому что он лучше визуализирует структуры данных.

Вот самый безопасный порядок действий для этого в WinOLS 5:

1. Создайте проект

• Перетащите свой Original OBD Read в WinOLS, чтобы создать новый проект.
• Пусть WinOLS определит карты и контрольные суммы (если у вас есть модули).

2. Импортируйте файл раtсh

• Когда проект открыт, перетащите MapSwitchBase.bin в окно WinOLS.
• WinOLS спросит, как его импортировать. Выберите "As a version".
• Это позволит вам мгновенно переключаться между вашим оригинальным файлом и файлом раtсh, чтобы сравнивать их.

3. Перенесите раtсh

• Нажмите Ctrl+D (или перейдите в Window -> Differences), чтобы подсветить изменения.
• Вы увидите "кучи" различий.
• Игнорируйте мелкие различия в областях карт (это просто данные настройки).
• Ищите большой сплошной блок данных, который есть в версии раtсh, но пуст (FF или 00) в вашей оригинальной версии. Это и есть Multimap Code.
• Выделите весь этот блок кода.
• Щелкните правой кнопкой по выделению -> Transfer selection -> to "Original" (или создайте 3-ю версию called "Patched" и перенесите туда и ваши оригинальные данные, и раtсh).

4. Критическая проверка безопасности (ISN)

• Просматривая различия, прокрутите в начало файла (или в область boot/eeprom).
• Убедитесь, что вы НЕ переносите любые различия, найденные в header/ID area.
• Если у MapSwitchBase другой VIN или ISN, WinOLS это подсветит. Оставьте там свои исходные значения.

5. Контрольные суммы (CS)

• Если у вас есть официальный модуль WinOLS Checksum OLS для вашего ECU, он может исправить CS, но часто для таких кастомных патчей нужен особый расчёт "Custom CS", который стандартные модули не понимают.
• Если WinOLS попытается исправить контрольную сумму и скажет "Checksum block not found" или выдаст ошибку по поводу пропатченной области, не позволяйте ему это исправлять.
• Экспортируйте файл (Project -> Экспорт и импорт -> Экспортировать файл -> двоичный файл).
• Используйте внешний инструмент (например, lols1337 tool или что-то подобное), чтобы исправить контрольные суммы перед прошивкой.

Нажмите, чтобы раскрыть...

Так что просто прочитайте эту тему. Я тоже пытался заставить переключение карт работать. Проблема в том, что MHD делает патч уже при прошивке. Так что если прошиваете через Mhd, все в порядке. Мне это стало интересно только потому, что я не использую Mhd. В MHD XDF есть только таблицы для разных слотов карты и таблица для ее активации. Но без прошивки через Mhd патч не будет вставлен.

Я уже несколько дней ковыряю это в Ghidra, так что скоро отпишусь здесь о своих находках, я уже почти разобрался.

Я уже сделал патч и для M2 brap, а когда разберусь с переключением карт, займусь flex патчем топлива вместе с уже готовыми таблицами flex топлива

e92jonah сказал(а):

Просто пролистал эту тему. Я тоже пытался заставить переключение карт работать. Вот...

Нажмите, чтобы раскрыть...

Это очень интересное замечание насчёт MHD! Если MHD применяет патч во время процесса прошивки, это сильно упрощает всё для пользователей именно этого инструмента. То есть им не нужно вручную патчить .bin файл.

Для тех, кто НЕ использует MHD, ручной способ патча (как мы и обсуждали с TunerPro/HxD/WinOLS) по-прежнему остаётся правильным вариантом.

Отлично, что ты копаешься в Ghidra. Реверс-инжиниринг процесса патчинга — это лучший способ точно понять, что именно нужно менять. Твои находки будут очень полезны для сообщества.

Основные выводы из твоего поста:

• Метод MHD: MHD встраивает патч multimap *во время* процесса прошивки. Поэтому их XDF могут показывать только карты и таблицу активации, а сам патч коду обрабатывает уже прошивальщик.
• Пользователям без MHD: Нам по-прежнему нужно вручную патчить .bin файл перед прошивкой.
• Анализ в Ghidra: Твоя работа в Ghidra критически важна для понимания *точного* кода, который вставляет MHD (или другие инструменты). Это поможет определить правильные адреса и фрагменты кода для ручного патча.
• Будущие патчи: Жду твоих находок по переключению карт и особенно по патчу Flex Fuel — для многих это было бы настоящим прорывом!

Держи нас в курсе по результатам в Ghidra. Точно определить участок кода, который включает multimap, и место, куда он встраивается, — это святой Грааль для ручного патчинга.

e92jonah сказал(а):

Так что я только что прочитал всю тему. Последние несколько дней я тоже работал над тем, чтобы заработало переключение карт. Проблема в том, что MHD делает раtсh при прошивке. Так что если шьёшь через MHD, всё ок. Меня это заинтересовало только потому, что я не пользуюсь MHD. В MHD XDF есть только таблицы для разных слотов карты и таблица, чтобы её активировать. Но без прошивки через MHD раtсh не вставится.

Последние несколько дней я над этим тоже работал в Ghidra, так что скоро отпишусь о своих находках здесь, я уже почти всё понял.

Я уже сделал патч для M2 brap тоже, а после того как разберусь с переключением карт, займусь flex топливным патчем с уже готовыми MHD flex топливными таблицами

Нажмите, чтобы раскрыть...

Интересно, я тоже работал над этим и сравнивал с Vrs, которые снимал своими инструментами, - заинтересован также в m2 brap, так как это не pops map, а скорее als decel patch?

e92jonah сказал(а):

Так что просто прочитал эту ветку. Я тоже уже работаю над тем, чтобы заставить работать карту переключения. Проблема в том, что MHD применяет патч при прошивке. Так что если прошьёшь через MHD, всё будет в порядке. Мне это стало интересно только потому, что я не пользуюсь MHD. В MHD XDF есть только таблицы для разных слотов карт и таблица, чтобы их активировать. Но без прошивки через MHD патч не будет вставлен.

Я уже несколько дней ковыряю это в Ghidra, так что скоро выложу здесь свои находки, почти уже разобрался.

Я уже сделал патч для M2 brap тоже, а после того как разберусь с картой переключения, буду работать над топливным патчем flex с уже готовыми топливными таблицами MHD flex

Нажмите, чтобы раскрыть...

есть какие-нибудь новости по этому патчу, чтобы проверить, работает ли он?

Эй, ребята, я бы хотел присоединиться к обсуждению и, возможно, добавить несколько полезных мыслей

Суть моей проблемы: я снял логи на штатной MHD Stage 2+ 102RON карте, но заливаю «только» 100 RON топливо (у MHD есть только карты 95, 98 и 102 RON) -> и, как и ожидалось, на высокой нагрузке есть небольшая коррекция угла зажигания. Я хотел сделать кастомные карты для каждого слота карты, откорректированные и основанные на логах, НО:

Я заметил, что, хотя в TunerPro всё настроено правильно в части логики MultiMap (разумеется, я работаю с корректным файлом определения XDF и редактирую свой стоковый 4MB .bin, который скачал через приложение MHD (экспорт выдал мне два файла, VIN.bin и VIN_mapswitch.bin, изменения я вношу в файл mapswitch.bin, так как в нём уже заполнены карты в Map Slots)) — но когда я прошиваю машину своим кастомным .bin, я теряю функциональность мультимапа — удержание кнопки cruise LIM больше ничего не делает.

MHD делает что-то после прошивки, что либо блокирует функции, которые он сам не записывал, либо не включает их для не-MHD bin'ов.

Что я ОБНАРУЖИЛ , запустив терминал и сниффер в фоне на своём рутованном телефоне во время прошивки карт через MHD: сопоставляя PCAP захваты (MHD Stage2+ flash vs MHD Custom bin flash):

Основной блок прошивки: identical — тот же адрес, тот же размер, тот же TransferData

Единственное отличие: DID 0xF15A post-flash write

Custom bin: 2E F15A 26 03 18 8F 04 D2 01 00 00 00 10
MHD Stage2+: 2E F15A 26 03 17 8F 04 D2 01 00 00 00 10

Этот один байт (0x18 vs 0x17) — почти наверняка флаг функции/битовое поле режима, которое говорит приложению MHD, показывать ли mapswitch, burble, advanced options и т. д.

Сейчас я собираю python proxy, который могу запускать в фоне, и он будет работать так:

1. Весь трафик MHD просто пересылается байт-в-байт без изменений — без риска сломать прошивку по ходу
2. Отслеживает положительный ответ SA 67 02 (MHD получает доступ на этапе финализации)
3. Когда MHD отправляет финальный 11 01 ECUReset, proxy перехватывает его
4. Отправляет WDBI 0x3300 со значением с multimap-enabled из Stage2+ PCAP
5. Ждёт положительный ответ 6E 33 00 от ECU
6. Затем нормально пропускает ECUReset дальше

Я уже экспериментировал с какими-то примитивными proxy примерно месяц назад, но тогда это привело к брикнутому ECU - пришлось тащить ECU out и восстанавливать его на стенде через KTAG.. этот proxy должен быть безопаснее, но пока не могу сказать наверняка, буду тестировать.

ОБНОВЛЕНИЕ / ИСПРАВЛЕНИЕ - пожалуйста, не учитывайте мою прежнюю теорию о DID 0xF15A

Всем привет, должен внести поправку. После того как я потратил заметно больше времени на анализ PCAP-снимков, XDF definitions и реальное тестирование прошивок - мой предыдущий пост о том, что байт DID 0xF15A был включателем multimap, оказался ошибочным.

Что на самом деле происходит:

Запись DID 0xF15A — это просто отпечаток / идентификационная метка прикладного ПО, она показывает MHD, какой вариант прошивки был прошит последним. Разница между 0x17 и 0x18 просто отражает "Stage 2+" и "Custom bin" - это учет, а не переключатель функции.

Настоящий механизм мультимапа находится внутри самих данных прошивки. В области калибровки bin встроена область наложения мультимапа. Там находятся логика map-slot переключение, смещения таблиц для каждого слота и, что критично, два конфигурационных байта:

• EMS (ECU-карта Switch) - в фиксированном смещении в overlay
• AMS (Active Map Selector) - по умолчанию определяет, какой слот активен

Когда я прошивал свой "custom" bin, multimap overlay region либо был обнулен, либо содержал неверные значения EMS/AMS. ECU didnне потерял multimap из-за того, что MHD заблокировал его после прошивки - он потерял multimap потому, что этих данных просто не было в том, что я прошивал.

Исправление: убедитесь, что ваш custom bin содержит полный multimap overlay с корректной конфигурацией EMS/AMS. Когда я это поправил, я прошил через MHD обычным образом - никакого специального proxy не нужно, никакой post-flash injection, cruise LIM button переключение работает идеально.

Чтобы было ясно:

• DID 0xF15A - это feature flag, который управляет multimap Неверно
• MHD блокирует функции для non-MHD bins Неверно
• Вам нужен proxy, чтобы inject WDBI после прошивки Неверно, и это опасно - именно так я и превратил свой ECU в кирпич
• Именно данные multimap overlay в самом bin имеют значение

Извините за вводящую в заблуждение информацию. Подход с proxy не нужен и рискован. Если в вашем custom bin есть правильная структура multimap, MHD его прошьет, и map переключение просто работает.