КАН моталка. Принцип работы., Как обмануть CAN. Опции

[galjoen]

Путешествуя по автомобильным сайтам, я был очень удивлён. Оказывается бывают такие девайсы, и их у нас продают, которые позволяют изменять информацию читаемую с автомобильной CAN шины. Чаще всего, как я понял, они используются водителями для "коррекции" пробега, чтобы списать побольше топлива. Но наверное можно и перед продажей установить, чтобы скрутить пробег. Ну и для того, чтобы информацию о машине изменить, тоже использовать можно.

Я предполагаю, что дело происходит примерно так:
1. В CAN сеть подключается специальный девайс.
2. Этот девайс портит посылки, содержащие информацию о пробеге. Но нужно перед этим прочесть имеющуюся посылку, чтобы из неё вынуть данные о реальном пробеге.
3. Этот девайс выдаёт в сеть свою посылку, содержащую скорректированную информацию.

Испортить посылку по п.2, на мой взгляд, лучше всего установив доминанту во время передачи CRC. Тогда и реальный пробег можно прочесть (мы ведь знаем, что ошибка CRC - это наших рук дело). Понятно, что для этого придётся влезть в CAN протокол програмно, т.к. CAN контроллеры на такое не рассчитаны. Но проблем там быть не должно, т.к. скорость 250 или 500 кбод. ATmega48 вполне справится. При тактовой 16 мГц будет 64 или 32 такта на бит. Вполне достаточно чтобы CRC на лету подсчитать. Лучше всего вход захвата таймера для приёма данных использовать.

Ну и противодействовать этому легко. Просто смотреть испорченные посылки.

Хотя м.б. я не прав, а там ребята просто знают команду для изменения пробега...

А сейчас подумал, что м.б. ребята так не заморачиваются. Просто забивают всю шину своими левыми сообщениями. А когда происходит реальная передача, то у неё ID такой же. Арбитража из-за этого нет. Появляется ошибка в данных и CRC. А счётчик ошибок у ребят постоянно сбрасывается. А у настоящего - Bus Off.

[syoma]

Так в том то и вопрос - мотать в какую сторону вам нужно? Вперед, чтобы пробег увеличить и топливо списать? Если первое, то это делалось еще в докановские времена с помощью любого сервис тула. Там всегда есть опция калибровки спидометра. То есть задаешь скорость и смотришь на стрелку - туда ли она встала. Естественно счетчик тоже считал что машина едет. Делалось все просто симуляцией генерации импульсов от датчика скорости. Ну и КАН посылкой это тоже делается легко в настоящее время.
А вот как смотать назад, например для продажи, да чтобы никто не заметил (например коллизии или ошибки CRC обнаруживаются легко) это интересней.
В любом случае передатчик не обязательно "давить", а просто достаточно сделать так чтобы он думал, что его сообщение приняли. А в сеть совсем другое сообщение отсылать. Синхронность сдесь не нужна, но 2 CAN-контроллера желательно.

[galjoen]

...
Синхронность сдесь не нужна, но 2 CAN-контроллера желательно.

Так в том и идея, чтобы ATmega48 за $0.5 с софтовым CAN-ом использовать. Все другие варианты (в т.ч. MCP2515) значительно дороже. А к MCP2515 всё равно процессор нужен. А LPC с двумя CAN-ами вроде от $7 начинаются... Ну и по размерам/потреблению мега тоже вне конкуренции. Можно и 2 ATmega48 поставить, в случае не синхронного повторителя, но тогда связь между ними проблемой будет. Да и вообще, зачем не синхронно делать, если можно (и проще) синхронно?

Я посмотрел, ATmega48 до 20 мГц работает. Т.е. при 500 кбод 40 тактов на бит у неё будет. Вроде должна успевать и CRC и битстаффинг на лету считать. Хотя простейшую логику таки придётся добавить. Но можно, наверное, и диодами/резисторами обойтись...