Прошивка многих современных ЭБУ защищена процедурой Security Access (часть UDS/ISO 14229): прежде чем разрешить запись памяти, блок присылает «seed» (случайное число), а инструмент обязан вернуть корректный «key», рассчитанный по алгоритму производителя. Когда официальной документации на алгоритм нет, а сторонний флеш-тул уже умеет его пройти, самый практичный способ разобраться — не гадать по документации, а посмотреть на реальный трафик между тулом и блоком.
Зачем нужен MITM-режим снифера
MITM (man-in-the-middle) снифер CAN встаёт логическим слоем между работающим флеш-тулом и ЭБУ: тул думает, что общается с адаптером напрямую, а снифер прозрачно пропускает трафик через себя и параллельно пишет каждый кадр в лог — с таймстампом и разметкой по сессиям. В отличие от обычного пассивного логгера шины, такой снифер видит именно тот обмен, который реально прошёл успешную авторизацию — а не просто «шум» шины.
Что даёт разметка по сессиям
Сырой дамп CAN без структуры почти бесполезен — сотни кадров подряд трудно сопоставить с конкретной операцией. Разметка по диагностическим сессиям (запрос seed → ответ → отправленный key → результат авторизации) позволяет:
- быстро найти именно обмен Security Access среди остального трафика диагностики;
- сравнить несколько сессий подряд и увидеть, меняется ли seed каждый раз (почти всегда да) и как эволюционирует key;
- отделить операции чтения от операций записи по характерным сервисным ID внутри лога.
Зачем это реверс-инженеру и мастеру
Легальные сценарии применения такого лога — разработка и валидация собственных прошивочных алгоритмов для оборудования, которое вы обслуживаете, диагностика причин отказа прошивки на конкретном экземпляре ЭБУ, и исследовательская работа над протоколами блоков, где производитель не предоставляет документацию независимым сервисам. Использование против чужого оборудования без разрешения владельца или для обхода защиты в незаконных целях — не наша тема, и не то, для чего этот функционал задуман.
Ограничения подхода
Снифер показывает только то, что реально прошло по шине — если алгоритм генерации key считается на стороне защищённого аппаратного модуля флеш-тула (а не просто в софте), лог даст пары seed/key, но не сам алгоритм их связи. В таких случаях требуется собрать значительно больше пар seed/key для статистического анализа, либо искать альтернативный путь (например, через встроенный самотест ЭБУ).
Интересно посмотреть на снифер в интерфейсе DiagExt?
🎮 Открыть демо