Реверс-инжиниринг трафика на шине CAN
Необработанный сигнал шины CAN
Шина CAN (Controller Area Network) стала стандартом в автомобилестроении: все новые автомобили обязаны поддерживать CAN (с 2001 в Европе и с 2008 в США). Кроме автомобилей, CAN применяется и в широком ряде других устройств. Производители диагностического оборудования для CAN рекламируют его применение, кроме разнообразной автомобильной техники, в мотоциклах, автопогрузчиках, судах, шахтных поездах, батискафах, беспилотных самолетах и пр. Давайте разберемся, что из себя представляет CAN.
В автомобилях используется несколько CAN; например, в Ford Focus таких шин четыре — три высокоскоростных (500 kbps) для управления мотором, тормозами, приборной панелью и т.п., и одна низкоскоростная (125 kbps) для управления дверьми, фарами, подушками безопасности, аудиосистемой, кондиционером и всем прочим. Подключившись к CAN, можно имитировать сигналы от любых устройств в автомобиле — например, управлять кондиционером с приложения на телефоне или накручивать одометр без движения автомобиля. Подключив к шине Arduino и реле, можно управлять с приборной панели дополнительной парковочной камерой. Даже стартапы, работающие над беспилотными автомобилями, такие как Voyage, начинают создание прототипа с того, что в обычном серийном автомобиле подключаются к CAN и учатся имитировать сигналы от педалей и руля.
Для подключения к CAN в автомобиле обычно возле руля имеется разъем OBD-II (On-Board Diagnostics).
Адаптеры OBD2-USB для подключения компьютера к CAN стоят от $5, и позволяют отслеживать весь трафик внутри автомобиля. Иногда разъем OBD-II защищен «аппаратным фаерволом», позволяющим принимать пакеты от устройств, подключенных к CAN, но не позволяющим передавать пакеты обратно на шину. В этом случае достаточно вывинтить разъем, и подключиться к проводам CAN вместо него.
Каждый пакет, передаваемый по шине CAN, состоит из ID передающего устройства (11 либо 29 бит), и до 8 байт передаваемых данных. Трафик, проходящий по шине при включении зажигания, может выглядеть как-то так:
Для анализа трафика CAN существует большое число инструментов — как коммерческих, так и OpenSource. Пакет can-utils для Linux включает утилиту cansniffer , которая отображает для каждого CAN ID только последний отправленный пакет, и тем самым позволяет отслеживать изменения показаний каждого датчика на шине:
Для реверс-инжиниринга трафика CAN сингапурские исследователи, из доклада которых я взял этот трейс, записали на видео приборную доску подопытного автомобиля, и затем соотнесли изменения на приборной доске с одновременными изменениями в трафике. Определив таким образом CAN ID датчика скорости и формат передаваемых им данных, они научились «подделывать» его пакеты, передавая на спидометр и на тахометр показания, не соответствующие действительности.
Надо понимать, что параллельно с передачей «поддельных» пакетов по шине продолжают передаваться и настоящие сигналы от датчика скорости. Чтобы тахометр показывал сфабрикованные показания, надо отслеживать передачу по шине настоящих показаний, и каким-либо образом их подавлять — например, сразу после обнаружения передачи CAN ID датчика скорости физически «глушить» шину, закорачивая линии данных. Более простой, чисто программный метод подавления настоящих показаний — сразу же после их передачи, пока тахометр еще не успел отреагировать, передавать «поддельные» пакеты. Например, следующий простой шелл-скрипт отслеживает передачу с CAN и сразу же после нее передает сфабрикованный пакет при помощи утилиты cansend из состава все тех же can-utils:
Даже хотя все устройства в автомобиле подключены к CAN, далеко не все их функции управляются через CAN. Например, на CAN в Ford Escape передаются сигналы о степени нажатия педалей газа и тормоза — но используются эти сигналы только блоком ABS, тогда как приводы дроссельной заслонки и тормозов соединены с педалями напрямую, минуя CAN.
C точки зрения безопасности ни о какой уязвимости в докладе сингапурцев речи не идет, потому что для передачи «поддельных» CAN-пакетов нужен физический доступ к шине. Кроме того, пакеты могут быть защищены контрольной суммой — например, в автомобилях Toyota последний байт каждого пакета должен равняться сумме всех предыдущих (по модулю 256). Кроме этого, в Toyota для защиты от нежелательных пакетов используется фильтрация получателем — например, игнорируются повороты руля более чем на 5% от текущего значения.
Тем не менее исследователям безопасности удавалось получить к CAN и удаленный доступ: вначале на небольшом расстоянии — через уязвимости в Bluetooth-модуле, подключенном к той же самой шине; а затем через сотовую сеть Sprint, через которую внедорожники нескольких американских производителей получали данные о пробках на дорогах. Исследователи, продемонстрировавшие перехват управления Jeep Cherokee с расстояния в несколько миль, получили от Управления перспективных исследовательских проектов Министерства обороны США (DARPA) вознаграждение в 80 тысяч долларов. С тех пор многие автопроизводители объявили о собственных bounty-программах, обещающих выплаты от $1500 за каждую обнаруженную уязвимость. Таким образом, реверс-инжиниринг трафика на шине CAN может не только добавить вашему автомобилю новые возможности, но и существенно пополнить ваш кошелек.
Источник
Модуль трансляции данных can шины в формат fms
Есть множество датчиков, все они собирают информацию о состоянии автомобиля и передают её на своём языке контроллерам, которые понимают их. Каждый контроллер переводит полученные данные на единый, принятый в CAN-шине, язык и «выпускает» информацию дальше в систему.
Все контроллеры связаны между собой теми самыми двумя проводами. Возможен и обратный процесс: из единой системы — к датчикам. В итоге сотни датчиков по всей машине могут обмениваться друг с другом информацией.
По сути CAN — это сеть для передачи данных, но со своими особенностями и топологией. Но для того, чтобы организовать автоматическое распределение имён (идентификаторов) между узлами и датчиками, стандартизировать и привести к единообразию управление устройствами различных типов и производителей на разных автомобилях, на рынке стали разрабатываться протоколы более высокого уровня для CAN. Одним из таких стандартов (протоколов) и является J1939.
Изначально он был придуман для грузовиков, но в настоящее время он широко применяется в легковых автомобилях, в сельскохозяйственной технике, автобусах и так далее.
Главная его идея — это стандартизировать «имена» (идентификаторы/адреса) и «правила общения» (запросов и ответов) между сегментами сети CAN.
The Fleet Management Systems Interface (FMS) представляет собой стандартный протокол для работы с данными коммерческого транспорта разных производителей.
Его разработали (договорились между собой и согласовали) шесть европейских производителей: Daimler AG, MAN AG, Scania, Volvo (включая Renault), DAF Trucks и IVECO в 2002 году. Они преследовали цель — сделать процесс считывания данных и диагностики ошибок более простым и универсальным. Как итог, теперь на разных машинах, например Scania и Volvo, можно одинаково «прочитать» в CAN-шине текущую скорость или обороты двигателя.
Есть несколько поколений данного стандарта, в рамках которых меняется количество доступных стандартных, единых параметров. Сейчас их уже около 30. Наличие этой функции у многих производителей опционально при заказе нового автомобиля и «включение» её в комплектацию является платным.
Это устаревший и предшествующий J1939 протокол с очень схожим смыслом и функционалом. И про него никто бы не вспоминал, не будь нашего желания экономить 🙂
Дело в том, что некоторые производители, например Volvo, ряд параметров FMS-стандарта открывали для свободного чтения, а самые интересные из них, топливные например, скрывали. Получить их можно было либо приобретая специальный FMS-шлюз, либо «открывая» параметры на сервисе, естественно, не бесплатно.
Тогда наши смекалистые соседи из Литвы вспомнили про устаревший J1708, проверили — и да, здесь ничего не «скрывали», поэтому можно было достать те самые актуальные топливные параметры. По этой причине на рынке было важным и популярным, чтобы GPS трекер «умел читать» J1708.
Это быстро прикрыли, и производители автомобилей окончательно отказались от J1708. Теперь это неактуально.
Здесь, к сожалению, производителям договориться о каком-то стандарте не удалось. Их много, жёсткая конкуренция, общих задач нет, большое количество выпускаемых моделей, высокая скорость изменений и модернизации датчиков и так далее.
В результате в большинстве случаев протокол, по которому происходит обмен данными в CAN-шине легкового автомобиля, неизвестен либо нигде не описан. А потребность видеть и получать данные с бортового компьютера легкового автомобиля ничуть не меньше. Расход топлива, текущий пробег, обороты двигателя и многие другие параметры важны для контроля эффективности эксплуатации машины водителем.
К слову, на рынке есть ряд так называемых переходников. Их создатели либо добились от производителей автомобилей, либо самостоятельно подобрали нужные «правила общения» и «имена» (идентификаторы, ID) датчиков во многих моделях автомобилей. Переходники «переводят» их на язык J1939 или другие, понятные GPS трекерам, протоколы.
В своей работе мы используем такие, а в последнее время учимся подбирать протоколы самостоятельно.
Источник
Спутниковый мониторинг транспорта и контроль расхода топлива
CAN (англ. Controller Area Network — сеть контроллеров) — стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Режим передачи — последовательный, широковещательный, пакетный.
Локальная сеть контроллеров CAN это стандарт серийной шины, разработанный в 80-х годах Robert Bosch GmbH, для соединения электронных блоков управления. CAN был специально разработан для устойчивой работы в насыщенной помехами окружающей среде с применением разносторонне сбалансированной линии, такой как RS-485. Соединение может быть более устойчивым к помехам при использовании витой пары. Первоначально создавалась для автомобильного назначения, но в настоящее время используется в разнообразных системах управления, в т.ч. индустриальных, работающих в насыщенной помехами окружающей среде.
Скорость обмена данными до 1Mbit/s возможна в сетях протяженностью не более 40м. Снижение скорости обмена позволяет увеличить протяженность сети, например — 250 Kbit/s при 250м.
CAN протокол связи стандартизирован согласно ISO 11898-1 (2003). Этот стандарт главным образом описывает слой обмена данными состоящий из подраздела логического контроля (LLC) и подраздела контроля доступа (MAC), и некоторых аспектов физического слоя ISO/OSI модели. Остальные слои протокола оставлены на усмотрение разработчика сети.
На базе технологии CAN построен протокол FMS.
FMS (Fuel Monitoring System) — система, которая позволяет регистрировать и контролировать основные параметры использования транспортного средства. Протокол FMS поддерживается большинством европейских автопроизводителей, начиная с 2004 года.
Протокол FMS предоставляет следующие данные:
- Расход топлива: в движении / на стоянке / мгновенный;
- Сколько топлива израсходовано от включения зажигания (текущий цикл ВВЗ);
- Скорость автомобиля в текущей точке трека (это более точная величина, чем получаемая при усреднении с трекеров);
- Ускорение: разгон, торможение (рывок) — оценка стиля вождения (как водитель тормозит и разгоняется, как часто происходят «рывки» автомобиля);
- Обороты двигателя;
- Нагрузка на двигатель;
- Положение педали газа;
- Температура: охлаждающей жидкости / во впускном коллекторе;
- Давление: масла / наддува;
- Момент на валу;
- Уровень масла;
- Уровень топлива в баке;
- Ошибки, которые выдает ЭБУ (активные, неактивные);
- Устройства, обнаруженные в сети.
Источник
Модуль трансляции данных can шины в формат fms
Яркость разнообразия беспроводных решений
Яркость разнообразия беспроводных решений
Получение данных с CAN-шины автомобиля
Получение данных с CAN-шины автомобиля
Когда заходит речь о мониторинге таких параметров, как скорость транспортного средства и расход топлива, надежным и отработанным решением является установка автотрекера и датчика уровня топлива. Если же необходим доступ к такой информации, как обороты двигателя, пробег, температура охлаждающей жидкости и другим данным с бортового компьютера – эта задача уже больше похожа на творческую.
Инновации или уже реальность?
Задача: Получить доступ к показаниям штатных датчиков автомобиля без установки дополнительных.
Решение: Считывание данных с CAN-шины автомобиля.
Когда заходит речь о мониторинге таких параметров, как скорость транспортного средства и расход топлива, надежным и отработанным решением является установка автотрекера и датчика уровня топлива.
Если же необходим доступ к такой информации, как обороты двигателя, пробег, температура охлаждающей жидкости и другим данным с бортового компьютера – эта задача уже больше похожа на творческую.
Казалось бы, что может быть логичнее: если в автомобиле уже есть все необходимые датчики, то зачем устанавливать новые? Практически все современные автомобили (особенно, если речь идет о личных автомобилях бизнес-класса и дорогостоящей спецтехнике) штатно оборудованы датчиками, информация с которых поступает в бортовой компьютер.
Вопрос состоит только в том, как получить доступ к этой информации. Долгое время эта задача оставалась нерешенной. Но сейчас на рынке спутникового мониторинга работает все больше высококвалифицированных инженеров, которым все-таки под силу найти решение задачи корректного получения таких данных, как:
- обороты двигателя;
- уровень топлива в баке;
- пробег автомобиля;
- температура охлаждающей жидкости двигателя ТС;
- и т.д.
Решение, о котором мы будем говорить в данной статье, состоит в считывании данных с CAN-шины автомобиля.
• Что такое CAN-шина?
CAN (англ. Controller Area Network — сеть контроллеров) — популярный стандарт промышленной сети, ориентированный на объединение в единую сеть различных исполнительных устройств и датчиков, широко используемый в автомобильной автоматике. На сегодняшний день практически все современные автомобили оснащены так называемой цифровой проводкой – автомобильной CAN-шиной.
• Откуда появилась задача считывания данных с CAN-шины?
Задача считывания данных с CAN-шины появилась как следствие задачи оптимизации расходов на эксплуатацию автотранспорта.
В соответствии с типовыми запросами заказчиков, автомобили и спецтехника оснащаются системой спутникового ГЛОНАСС или GPS мониторинга и системой контроля оборота топлива (на базе погружных либо ультразвуковых датчиков уровня топлива).
Но практика показала, что заказчики все чаще интересуются более экономичными способами получения данных, а также такими, которые не требовали бы серьезного вмешательства в конструкцию, а также электрику автомобиля.
Именно таким решением стало получение информации с CAN-шины. Ведь оно имеет целый ряд характерных преимуществ:
1. Экономия на дополнительных устройствах
Не нужно нести значительных расходов на приобретение и установку различных датчиков и устройств.
2. Сохранение гарантии на автомобиль
Обнаружение производителем стороннего вмешательства в конструкцию либо электрику автомобиля грозит практически гарантированным снятием транспортного средства с гарантии. А это явно не входит в сферу интересов автовладельцев.
3. Получение доступа к информации со штатно установленных электронных устройств и датчиков.
В зависимости от электронной системы в автомобиле может быть штатно реализован определенный набор функций. Ко всем этим функциям, теоретически, мы можем получить доступ через CAN-шину. Это может быть пробег, уровень топлива в бензобаке, датчики открытия/закрытия дверей, температура за бортом и в салоне, обороты двигателя, скорость движения, и т.д.
Техническими специалистами компании для тестирования данного решения был выбран прибор Galileo ГЛОНАСС. Он имеет встроенный дешифратор FMS и может считывать информацию напрямую с CAN-шины автомобиля.
• Какие достоинства и недостатки влечет за собой решение со считыванием данных с CAN-шины?
Достоинства:
- Возможность работы в режиме жёсткого реального времени.
- Простота реализации и минимальные затраты на использование.
- Высокая устойчивость к помехам.
- Надёжный контроль ошибок передачи и приёма.
- Широкий диапазон скоростей работы.
- Большое распространение технологии, наличие широкого ассортимента продуктов от различных поставщиков.
Недостатки:
- Максимальная длина сети обратно пропорциональна скорости передачи.
- Большой размер служебных данных в пакете (по отношению к полезным данным).
- Отсутствие единого общепринятого стандарта на протокол высокого уровня.
Стандарт сети предоставляет широкие возможности для практически безошибочной передачи данных между узлами, оставляя разработчику возможность вложить в этот стандарт всё, что туда сможет поместиться. В этом отношении CAN-шина подобна простому электрическому проводу. Туда можно «затолкать» любой поток информации, который сможет выдержать пропускная способность шины.
Известны примеры передачи звука и изображения по шине CAN. Известен случай создания системы аварийной связи вдоль автодороги длиной несколько десятков километров (Германия). (В первом случае нужна была большая скорость передачи и небольшая длина линии, во втором случае — наоборот).
Изготовители, как правило, не афишируют, как именно они используют полезные байты в пакете. Поэтому FMS прибор не всегда может расшифровать данные, которые «отдает» CAN-шина. Кроме того, не все марки автомобилей имеют CAN-шину. И даже не все автомобили одной марки и модели могут выдавать одинаковую информацию.
Пример реализации решения:
Большой проект по мониторингу автотранспорта. В парке были различные грузовые автомобили иностранного производства. В частности, грузовые автомобили Scania p340.
Для того, чтобы проанализировать процесс получения данных с CAN-шины мы, по солгасованию с заказчиком, провели соответствующие исследования на трех автомобилях Scania p340: один 2008 года выпуска, второй начала 2009 и третий конца 2009 года.
Результаты оказались следующими:
- с первого данные получены так и не были;
- со второго был получен только пробег;
- с третьего были получены все интересующие данные (уровень топлива, температура охлаждающей жидкости, обороты двигателя, общий расход, общий пробег).
На рисунке отображен фрагмент сообщения из информационной системы Wialon, где:
Fuel_level – уровень топлива в баке в %;
Temp_aqua – Температура охлаждающей жидкости в градусах Цельсия;
Taho — Данные с тахометра (об/мин).
Регламент реализации решения был следующий:
1. Навигационный прибор Galileo ГЛОНАСС/GPS был подключен к CAN-шине грузовиков.
Данная модель автотрекера была выбрана из-за оптимального сочетания функционала, надежности и стоимости. Кроме того, она поддерживает FMS (Fuel Monitoring System) — систему, которая позволяет регистрировать и контролировать основные параметры использования транспортного средства, т.е. подходит для подключения к CAN-шине.
Схему подключения к CAN-шине со стороны прибора Galileo можно найти в руководстве пользователя. Для подключения со стороны автомобиля необходимо, в первую очередь, найти свитую пару проводов, подходящую к диагностическому разъёму. Диагностический разъем всегда в доступности и располагается вблизи от рулевой колонки. В 16 контактном разъёме по стандарту OBD II это 6-CAN high, 14-CAN low. Обратите внимание, что у проводов High напряжение примерно 2,6-2,7В, у проводов Low оно, как правило на 0,2В меньше.
Еще одним уникальным решением, которое было использовано для снятия данных с CAN-шины, стал бесконтактный считыватель данных CAN Crocodile (производство СП Технотон, г. Минск). Он отлично подходит для работы с приборами Galileo.
Преимущества технологии CAN Crocodile:
- CAN Crocodile позволяет получать данные о работе автомобиля из шины CAN без вмешательства в целостность самой шины.
- Считывание данных происходит без механического и электрического контакта с проводами.
- CAN Crocodile применяется для подключения к шине CAN систем GPS/ГЛОНАСС мониторинга, которые получают информацию о режимах работы двигателя, состоянии датчиков, наличии неисправностей и т.д.
- CAN Crocodile не нарушает изоляцию проводов CAN и «слушает» обмен по шине с помощью специального беспроводного приемника.
- Применение CAN Crocodile абсолютно безопасно для автомобиля, незаметно для работы бортового компьютера, диагностического сканера и других электронных систем. Особенно актуально применение CAN Crocodile для гарантийных автомобилей, в которых подключение каких-либо электронных устройств к шине CAN часто служит поводом для снятия с гарантии.
2. Если провода обнаружены и идентифицированы верно, можно приступать к запуску CAN-сканера в приборе Galileo.
3. Выбирается стандарт FMS, скорость для большинства автомобилей 250 000.
4. Запускается сканирование.
5. После окончания сканирования совершается переход на главную страницу конфигуратора. Если сканирование завершено успешно, мы получаем доступ к расшифрованным данным.
6. Если ничего, кроме «end scan» Вы не увидели, тут есть несколько вариантов. Либо было неправильно осуществлено подключение, либо автомобиль по каким-то причинам не выдает данные, либо прибору неизвестен шифр данной CAN-шины. Как уже было сказано, такое случается довольно часто, поскольку пока не существует единого стандарта для передачи данных и их обработки по CAN. К сожалению, как показывает практика, получить полные данные с CAN-шины не всегда удается.
Именно поэтому не каждый запрос на считывание данных с CAN-шины может быть в полной мере реализован. Мы рекомендуем своим партнерам-интеграторам предупреждать об этом заказчиков заранее, для того чтобы в дальнейшем избежать неоправданных ожиданий.
Но есть еще один момент, который важно затронуть.
Чаще всего основной целью клиентов является контроль уровня и расхода топлива.
Даже если данные со штатных датчиков будут успешно получены с CAN-шины, какова их практическая ценность?
Дело в том, что основное назначение штатных датчиков уровня топлива – дать оценку с той степенью точности, которая кажется правильной производителю ТС. Эта точность не может быть ставнима с точностью, которую дает погружной датчик уровня топлива (ДУТ) производства Омникомм или, например, Технотон.
Одна из главных задач, которую решает штатный ДУТ, это чтобы топливо внезапно не закончилось, и водитель понимал общую ситуацию с уровнем топлива в баке. От простого по своему устройству штатного поплавкового датчика сложно ожидать большой точности. Кроме того, бывают случаи, когда штатный датчик искажает данные (например, когда транспорт располагается на склоне).
Выводы
По ряду вышеназванных причин, мы рекомендуем не полагаться полносьтю на показания штатных датчиков уровня топлива, а рассматривать каждую ситуацию индивидуально. Как правило, подходящее решение может быть найдено только совместно с техническими специалистами. У разных производителей ТС разная точность показаний. У всех заказчиков также разные задачи. И только под конкретную задачу целесообразно подбирать средства решения. Кому-то вполне подойдет решение с получением данных с CAN-шины, так как оно в разы дешевле и не требует никаких изменений топливной системы ТС. А вот заказчикам с высокими требованиями по точности разумно рассматривать вариант с погружным ДУТом.
Источник