02.05.2015

Управление датчиками транспортного средства через шину CANBus – Часть 1

image

После выпуска утилит для работы с сетью контроллеров (CAN, Controller Area Network), думаю, настало время поподробнее рассказать о схеме коммуникаций внутри транспортного средства. В первой части мы поговорим о том, что такое CANBus, OBDII и есть ли разница между этими «сущностями».

Автор: Corey Thuen

После выпуска утилит для работы с сетью контроллеров (CAN, Controller Area Network), думаю, настало время поподробнее рассказать о схеме коммуникаций внутри транспортного средства. В первой части мы поговорим о том, что такое CANBus, OBDII и есть ли разница между этими «сущностями».

Я постараюсь объяснять настолько просто, насколько это возможно. Мы не будем касаться электрической части, формата пакетов и скучной теории в целом, а сразу перейдем к тому, как проанализировать трафик, передаваемый по стандарту CAN. В качестве подопытной машины будет выступать моя Toyota Tundra, выпущенная 2013 года.

На рисунке ниже показана схема шины, работающей по стандарту CAN:


Рисунок 1: Схема подсоединения контроллеров к шине

К двухпроводной шине подсоединено несколько контроллеров. За каждым закреплена определенная функция. Если речь идет о транспортном средстве, это может быть контроллер двигателя, приборная панель или датчик давления воздуха в шинах. Стандарт CAN также используется в управлении промышленным оборудованием.

Трафик, передаваемый внутри сети контроллеров, выглядит примерно так:

630 [8] 17 00 00 00 00 00 00 00
638 [8] 13 00 1E 00 00 00 00 00
440 [8] 42 02 00 00 00 00 00 00

Первое число (0x630, 0x638) – идентификатор или адрес устройства, отсылающего сообщения (нечто схожее с IP- или MAC- адресом). Далее идут информационные байты (до 8-ми байт на каждое сообщение).

КАЖДОЕ устройство в сети стандарта CAN может считывать и отсылать сообщения к ЛЮБОМУ ДРУГОМУ устройству, что является основной брешью в системе безопасности транспортного средства. Отсутствует аутентификация, верификация, проверка «репутации» и вообще любые средства безопасности. Согласно спецификации каждое устройство может замаскироваться и отсылать сообщения от имени любого другого элемента системы. Кроме того, у нас всего 8 информационных байт и добавление чего-то хотя бы отдаленно напоминающего шифрование представляется непростой задачей. То есть, чтобы обезопасить наше транспортное средство, мы должны огородить его трехметровой стеной или закопать глубоко под землю.

Ок, мы коротко рассмотрели стандарт CAN. Перейдем к OBDII. OBDII – вспомогательный протокол для шины CANBus. По идее, должен существовать стандартный набор идентификаторов, поддерживаемый всеми производителями. Однако на практике каждый производитель проектирует автомобиль на свой манер. Например, в одном случае количество оборотов может выдаваться в шину внутри идентификатора ID 0x2C4 как 16-ти битное целое, находящееся в первых двух байтах. В другом случае производитель может выдавать количество оборотов в шину внутри идентификатора ID 0x310, находящееся в 7-м и 8-м байтах. Протокол OBDII проектировался с целью создания стандартного метода для получения подобной информации. Вместо того чтобы стандартизировать идентификаторы, была создана система запросов/ответов.

Алгоритм получения информации об оборотах двигателя через протокол OBDII выглядит следующим образом:

1. Средство диагностики отсылает сообщение на идентификатор ID 0x7DF (это стандартный идентификатор протокола OBDII, предназначенный специально для запросов). Сообщение содержит дополнительный набор информационных байтов, содержащих в том числе поля «Mode» и «PID». При запросе информации об оборотах поле Mode = 1, поле PID = 0x0C. Полное сообщение выглядит так: 0x7DF [8] 02 01 0C 00 00 00 00 00.

2. Модули транспортного средства отвечают на эти диагностические сообщения. Идентификатор для ответа зависит от модуля, но значения начинаются от 0x7DF + 0x8 (то есть первый идентификатор на 0x8 больше, чем значение стандартного идентификатора). Таким образом, ответ на запрос о количестве оборотов будет отослан на идентификатор 0x7E8. Сообщение содержит информационные байты: Mode + 0x40, PID и количество оборотов. В нашем случае поле Mode будет равно 0x41, а PID останется неизменным. Конечное сообщение будет выглядеть примерно так: 0x7E8 [8] 03 41 0C 09 C4 00 00 00.

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

Однако злоумышленнику неинтересна информация, предоставляемая протоколом OBDII, также как и неинтересны запросы для получения диагностических сведений. Злоумышленник хочет понять, возможно ли управление отдельными компонентами транспортного средства посредством записи идентификаторов в шину.

В следующей статье мы проведем исследование информации, передаваемой по шине для того, чтобы выяснить, какие сообщения представляют для нас интерес, если мы хотим управлять датчиками транспортного средства.