Возвращение блока управления ABS от VAG из состояния “кирпич”
Изначально блок управления обновляли на автомобиле с использованием системы ODIS. Это была одна из последних версий блока управления ABS с номером 80A907379AF, однако для программирования использовали ODX-файл для блока ABS 80A907379AN. Номера совпадали, но различие в буквах привело к ошибке. Использование прошивки, предназначенной для другого номера, недопустимо, так как ODX-файлы содержат бинарные патчи, которые модифицируют части кода. Неправильное применение таких патчей может вызвать непредсказуемые последствия, что и произошло: блок управления перестал выходить на связь, и клиент обратился к нам за помощью.
Первое что мы сделали: произвели вскрытие крышки блока управления посредством нагревания компаунда на столе подогрева, сняли образ ПЗУ из EEPROM 95256, считали и сохранили FLASH программой JLinkZReader через точки подключения к процессору TMS570LS31. В нашей лаборатории это стандартная процедура: она выполняется для того, чтобы избежать дополнительных ошибок при подключении к ЭБУ на столе.
Понимание того, как произошла ошибка, дало нам шанс восстановить оригинальную прошивку. Мы изучили, как выглядит ODX-файл, написали код на Python для анализа различий между ODX-файлом, используемым для патча, и оригинальной версией. Скрипт сравнивает оба файла, находит различия, затем определяет их во FLASH, и заменяет изменённые участки кода на оригинальные. Несмотря на возникновение «шума» из-за наложения патча, нам удалось заменить большую часть флеш-памяти с помощью нашего скрипта odx.py, который получил дальнейшее применение в других проектах.
Благодаря проделанной работе нам удалось восстановить связь с блоком управления. Подключение проводилось через интерфейс VW Gateway к шине FlexRay. Это было вторичное подключение, первый раз мы подключались к блоку в начале ремонта, после снятия образов FLASH и EEPROM с «кирпича», несмотря на то, что результат был известен заранее.
Связь с ЭБУ восстановить удалось, но блок функционировал некорректно, запросы на сохранённые ошибки (DTC) не поддерживались, некоторые ID не возвращались, что указывало на неполную работоспособность.
Мы попытались перепрограммировать блок с использованием оригинального ODX-файла посредством VAG CAN PRO, но процесс остановился на этапе авторизации. Вывод напрашивался сам собой: это происходит из-за того, что мы очистили флеш, но EEPROM не трогали, он остался обновлённым патчем.
Не имея оригинального EEPROM, мы подобрали его из донорских блоков ABS. Подходящий дамп мы нашли, но потратили на это немало времени. Изначально искали образ дампа, испробовали много вариантов, но все попытки закончились ничем. Донорский дамп мы взяли из блока с номером 4M6907379AC, этот блок оказался в конце немаленького списка.
Находка нас не только обрадовала, но и немало удивила, надежды на это было немного. Тем не менее блок управления начал корректнее отзываться и отображать ошибки, что позволило провести перепрошивку. Заливка оригинального ODX-файла завершилась с ошибкой подписи, но, в целом, прошла успешно.
Таким образом, функционирование блока управления было восстановлено, правда он стал своеобразным гибридом из двух разных устройств. ЭБУ заработал, но у него чужие кодировки и защита компонентов. Мало того, теперь в ЭБУ ABS с номером 80A907379AF стал отображаться номер детали аппаратного обеспечения 4M6907379…
Всё это говорило о том, что, такой блок управления машина не примет, донорский EEPROM имеет свои настройки, свою компонентную защиту и т.д. Попытки изменить несоответствия напрямую прошли неудачно, например, при изменении ECU ID, возникали сбои: блок переставал видеть эту информацию и выводил пустое значение при диагностике. Стало понятно, что в системе предусмотрена проверка целостности — либо контрольная сумма, либо другая защита, но выявить эту закономерность не удалось.
После таких выводов и экспериментов было решено заняться оригинальным дампом, который изначально находился в блоке. Мы сняли его при первом знакомстве с ЭБУ. Для этого необходимо было бы применить реверс-инжиниринг, на что пока не было времени.
Частичный реверс всё же понадобился, чтобы понять, как соотносятся идентификаторы блоков с их длинами, так как без него эту информацию невозможно получить. В рамках другого проекта мы создали скрипт на Python для разбора EEPROM и доработали его для данного случая, чтобы понять, какие блоки содержатся в дампе и к чему они относятся.
В структуре дампа вначале хранится список указателей на фрагменты различных блоков данных. В этих списках содержится тип блока данных и смещение (offset) внутри EEPROM, где находятся данные этого блока. Мы нашли нужные нам фрагменты и сравнили их с аналогичными в дампе-доноре.
В итоге были отредактированы несколько блоков. Восстановлен номер, заменили 80A907379AN на 80A907379AF. Номер 931, номер программного обеспечения, был заменён на 871. Эти и другие блоки были скопированы в оригинальный дамп из дампа-донора, запрограммированного на нашем блоке управления. Мы также определили блок ошибок и очистили его.
С восстановленным ПЗУ, блок управления запустился и стал корректно отвечать на диагностические запросы, за исключением кодировок, которые отображались как 00.
Посоветовавшись с профессиональным диагностом, мы решили завершить ремонт блока. По его словам, все кодировки примутся, когда блок будет закодирован, для этого потребуется кодировать ЭБУ ABS непосредственно на автомобиле и вводить его в эксплуатацию. Более того, необходимо будет синхронизировать его с оригинальным автомобилем из-за защиты компонентов.
