Современный автомобиль - это от 70 до 150 электронных блоков управления (ECU), связанных шинами CAN, LIN, FlexRay и Automotive Ethernet. За каждой функцией - от впрыска топлива до адаптивного круиз-контроля - стоит отдельный контроллер с собственной прошивкой, диагностическим стеком и набором уязвимостей. Пентест автомобильных ECU - не абстрактный «взлом машины», а последовательная работа с конкретными интерфейсами, протоколами и бинарниками. Примерно как реверс обычной embedded-железки, только цена ошибки - не кирпичный роутер, а две тонны металла на скорости.
В русскоязычном пространстве тема покрыта крайне поверхностно: пересказы глав «Car Hacker's Handbook» да маркетинговые описания сервисов. Между тем англоязычные исследования - от академических работ на SECURWARE 2025 до firmware extraction techniques из Университета Бирмингема - содержат конкретные методологии, hex-уровневые примеры и стратегии детектирования. Здесь я собираю практический опыт аудита ECU, опираясь на реальные сценарии работы с UDS-протоколом, CAN-шиной и физическими debug-интерфейсами.
Требования к окружению и оборудованию
Прежде чем отправлять первый диагностический запрос - убедитесь, что стенд собран правильно. Тестирование безопасности ECU на рабочем автомобиле - паршивая идея: случайная инъекция CAN-фрейма в HS-CAN может привести к срабатыванию подушек безопасности или блокировке трансмиссии. Работайте на стенде: ECU, запитанный от лабораторного блока на 12 В, с подключённой CAN-шиной, терминированной резисторами 120 Ом на каждом конце.Минимальный набор оборудования:
- CAN-адаптер: Peak PCAN-USB, CANable Pro или любой SocketCAN-совместимый. Для J2534 подойдёт OpenPort 2.0
- Логический анализатор: Saleae Logic Pro 8 или аналог с декодерами CAN, UART, SPI, JTAG
- Debug-пробники: SEGGER J-Link или ST-Link для ARM-контроллеров, OpenOCD-совместимый адаптер
- Паяльная станция: для доступа к test pads, UART-пинам, снятия микросхем флэш-памяти
can-utils (candump, cansend, cangen), python-can, Scapy с модулем automotive, Ghidra или IDA Pro для реверса прошивок. Режим работы - полностью offline. ECU на стенде не требует сетевого подключения.
Уязвимости OBD-II: что скрывается за 16-пиновым разъёмом
OBD-II - стандартизированный физический разъём (SAE J1962), обязательный для всех автомобилей в Европе и Северной Америке. Расположен в радиусе вытянутой руки от водителя - обычно под приборной панелью слева. С точки зрения MITRE ATT&CK подключение к этому порту - классический Hardware Additions (T1200, Initial Access): атакующий получает физический доступ к внутренней шине автомобиля через штатный интерфейс.Тут важно разделять два уровня, и путаница между ними - одна из главных проблем, которую я постоянно вижу в статьях для начинающих. OBD-II - это физический и канальный уровень: тип разъёма, расположение пинов (CAN High на пине 6, CAN Low на пине 14, питание на пине 16). А UDS - протокол прикладного уровня, который работает поверх CAN (или DoIP/Ethernet в новых архитектурах). Грубо говоря, OBD-II - это розетка, UDS - то, что через неё течёт.
В старых архитектурах OBD-II давал прямой доступ ко всем ECU на шине. Современные автомобили используют gateway-ECU, который фильтрует диагностические запросы и ограничивает маршрутизацию между доменами. Согласно исследованию dissec.to, «OBD connectors accessible to consumers or workshops - accessibility is limited by gateways/segmentation; not all ECUs are exposed over OBD». На практике через OBD-порт вы увидите 5–15 ECU вместо потенциальных 80+. Но даже этот ограниченный набор включает критичные блоки: двигатель, трансмиссию, ABS, подушки безопасности.
Первый шаг аудита - пассивный мониторинг шины. Подключаете адаптер, поднимаете интерфейс командой
ip link set can0 up type can bitrate 500000 и запускаете candump can0. В потоке фреймов видны арбитражные ID и данные - реальный трафик между блоками. На этом этапе - Network Sniffing (T1040, Discovery): собираете карту активных ID и определяете, какие блоки общаются и с какой периодичностью. Уже по одному этому дампу можно многое сказать об архитектуре.UDS протокол безопасность: диагностический стек изнутри
Unified Diagnostic Services (ISO 14229) - основной диагностический протокол автомобильной индустрии, по данным исследования, принятого на SECURWARE 2025. UDS определяет набор сервисов (SID - Service Identifier), каждый из которых выполняет конкретную функцию: от чтения кодов ошибок до перепрошивки ECU. Именно UDS - главный объект при пентесте автомобильных ECU, потому что через него можно получить полный контроль над блоком.DiagnosticSessionControl (0x10) и переключение сессий
Любая диагностическая коммуникация начинается с выбора сессии. Сервис DiagnosticSessionControl (SID 0x10) определяет уровень доступа. По умолчанию ECU сидит в defaultSession (0x01) - тут доступны только базовые операции: чтение DTC (Diagnostic Trouble Codes), чтение текущих параметров. Для серьёзной работы нужно переключиться:- extendedDiagnosticSession (0x03) - расширенная диагностика, доступ к дополнительным DID (Data Identifiers), часть сервисов записи
- programmingSession (0x02) - режим прошивки, доступ к RequestDownload (0x34), TransferData (0x36), RequestTransferExit (0x37)
02 10 03 на диагностический ID блока (например, 0x7E0 для двигателя), получаете положительный ответ 02 50 03 или отрицательный 03 7F 10 XX, где XX - код ошибки (NRC, Negative Response Code). NRC 0x22 - conditionsNotCorrect: ECU отказался переключать сессию, потому что, например, автомобиль движется.Типичная ошибка реализации, которая встречается чаще, чем хотелось бы: некоторые ECU позволяют переключение в programmingSession без проверки состояния автомобиля. Это открывает путь к записи модифицированной прошивки даже в полевых условиях.
SecurityAccess (0x27): обход seed/key на практике
Извлечение прошивки автомобиля: практическое руководство
Прошивка ECU - конечная цель при глубоком аудите. Имея бинарник, можно выполнить реверс-инжиниринг прошивки ECU: найти алгоритмы SecurityAccess, обнаружить захардкоженные ключи шифрования, бэкдоры и недокументированные UDS-сервисы. По MITRE ATT&CK получение прошивки - Firmware (T1592.003, Reconnaissance), модификация - Patch System Image (T1601.001, Defense Evasion) или Component Firmware (T1542.002, Persistence). Примечание: эти техники из Enterprise/Network Device матриц как ближайшее приближение; в ATT&CK for ICS точнее T0857 (System Firmware) и T0839 (Module Firmware), отдельная automotive-матрица пока отсутствует.Извлечение через UDS: ReadMemoryByAddress и RequestUpload
Самый «чистый» способ - штатные диагностические сервисы. Если SecurityAccess пройден, два сервиса дают прямой доступ к памяти ECU:ReadMemoryByAddress (SID 0x23) - чтение произвольного адреса. Формат запроса:
0x23 [addressAndLengthFormatIdentifier] [memoryAddress] [memorySize]. Например, 23 14 00 80 00 00 10 00 читает 4096 байт (0x1000) начиная с адреса 0x008000. Итеративно вычитывая блоки по 4 КБ, получаете полный дамп флэш-памяти. Медленно, зато без паяльника.RequestUpload (SID 0x35) - инициирует передачу данных от ECU к тестеру. Работает в связке с TransferData (0x36) и RequestTransferExit (0x37). Этот метод эффективнее для больших объёмов - ECU сам порционно отдаёт данные через ISO-TP (ISO 15765) сегментацию.
Не все ECU поддерживают оба сервиса. Часть блоков отвечает NRC 0x31 (requestOutOfRange) или 0x33 (securityAccessDenied) даже после прохождения Security Access - конкретный уровень доступа не даёт права на чтение памяти. В таком случае нужно либо искать другой security level (subfunctions 0x03/0x04 вместо 0x01/0x02), либо переходить к физическим методам.
Физический доступ: JTAG, UART и chip-off
Когда диагностический протокол автомобиля не даёт нужного доступа - переходим к плате. Вскрываем корпус ECU и ищем debug-интерфейсы.UART - практически всегда присутствует на плате в виде test pads. Определяем пины логическим анализатором: подключаем Saleae, ищем линию с активностью на стандартных бодрейтах (115200, 9600, 38400). Часто UART выводит отладочный лог ОС (Linux, QNX, AUTOSAR OS), а иногда - открывает root shell без аутентификации. Мне попадались блоки, где на UART сыпался полный boot log с адресами загрузки - бери и реверси.
JTAG/SWD - debug-интерфейс процессора. Для автомобильных ECU (Infineon TriCore AURIX, ARM Cortex-R/M, NXP PowerPC/e200) используем OpenOCD или специализированные инструменты (Infineon DAS/Memtool для TriCore). Для ARM STM32 подключение:
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg, затем dump_image firmware.bin 0x08000000 0x100000 для снятия дампа. Защита чтения (Read-Out Protection, RDP) может быть включена - уровень 1 обходится на некоторых чипах через voltage glitching, уровень 2 обычно необратим.Chip-off - крайний метод. Физически демонтируем микросхему флэш-памяти (обычно NOR Flash) с платы и считываем программатором (ChipProg, Xeltek). Разрушающий для конкретного экземпляра, но даёт гарантированный полный дамп. После получения бинарника загружаем его в Ghidra, определяем архитектуру (TriCore, ARM, PowerPC) и начинаем реверс-инжиниринг прошивки ECU - ищем обработчики UDS-сервисов, криптографические функции и таблицы маршрутизации CAN-фреймов.
Телематический блок: удалённый attack surface
Если OBD-II - физический вектор, то телематический модуль (TCU, Telematic Control Unit) - потенциальный удалённый. TCU обычно оснащён LTE/5G-модемом, Bluetooth, Wi-Fi и имеет выход в CAN-шину автомобиля. Взлом телематического блока открывает путь от интернета напрямую к safety-critical ECU - при условии, что gateway между доменами не фильтрует трафик как положено.Атака на TCU обычно начинается с его прошивки: анализ FOTA (Firmware-over-the-Air) обновлений, поиск открытых портов на сетевом интерфейсе, проверка TLS-конфигурации при соединении с backend-серверами OEM. Согласно описанию Embitel, «penetration testing targets embedded components like ECUs, gateways, and telematics units, along with connected mobile apps and backend cloud infrastructure».
Что я наблюдаю при аудите TCU:
- Неподписанные прошивки - обновления по FOTA без верификации цифровой подписи. Позволяет тупо подменить образ
- Открытые debug-порты - SSH или telnet на сетевом интерфейсе TCU со стандартными учётными данными (да, root:root в 2025 году - всё ещё реальность)
- Плоская сетевая топология - TCU подключён к той же CAN-шине, что и safety-critical ECU, без gateway-сегментации
- Слабое шифрование backend-канала - сертификаты не пиннятся, возможна MitM-атака на канал обновлений
Маппинг автомобильных атак на MITRE ATT&CK
Automotive cybersecurity пентест выигрывает от систематизации через MITRE ATT&CK - это единый язык для описания атак между исследователями, OEM и регуляторами. Ниже - маппинг типичных шагов аудита ECU:| Этап атаки | Техника MITRE ATT&CK | Тактика | Пример в контексте ECU |
|---|---|---|---|
| Подключение к OBD-II | Hardware Additions (T1200) | Initial Access | Физическое подключение CAN-адаптера |
| Пассивный захват CAN-трафика | Network Sniffing (T1040) | Discovery, Credential Access | candump, перехват seed/key |
| Сбор информации о прошивке | Firmware (T1592.003) | Reconnaissance | Чтение версий через RDBI 0x22 |
| Дамп flash-памяти | Data from Local System (T1005) | Collection | ReadMemoryByAddress 0x23 |
| Перебор SecurityAccess | Brute Force (T1110) | Credential Access | Подбор key для SID 0x27 |
| Модификация прошивки | Patch System Image (T1601.001) | Defense Evasion | Внедрение бэкдора в бинарник (в ATT&CK for ICS точнее T0857 System Firmware) |
| Запись модифицированной прошивки | Component Firmware (T1542.002) | Persistence | RequestDownload 0x34 + TransferData 0x36 (в ATT&CK for ICS точнее T0839 Module Firmware) |
| Деструктивное воздействие | Firmware Corruption (T1495) | Impact | Запись невалидного образа, brick ECU |
Эта таблица - не теоретическое упражнение. Каждый automotive cybersecurity пентест должен формировать отчёт с привязкой к конкретным ATT&CK-техникам. Это требование вытекает из ISO/SAE 21434, где TARA (Threat Analysis and Risk Assessment) требует формализованного описания угроз. Без этого маппинга отчёт - просто записка, а не документ.
Обнаружение атак на диагностический протокол автомобиля
Пентестер обязан понимать не только как атаковать, но и как обнаружить атаку. Исследование, принятое на SECURWARE 2025 (arXiv:2510.25375), предлагает стратегию мониторинга UDS на уровне VSOC (Vehicle Security Operations Center): ECU логирует security events локально, а backend анализирует их в контексте fleet-данных.Что должен логировать ECU для обнаружения UDS-атак:
- Множественные неудачные SecurityAccess - NRC 0x35 (invalidKey) более 3 раз за сессию. Прямой индикатор brute-force
- Переключение в programmingSession вне сервисного интервала - ECU не на подъёмнике, а кто-то запрашивает режим прошивки
- ReadMemoryByAddress на нестандартные диапазоны - попытка дампа всей flash-памяти, а не чтение конкретного DID
- CommunicationControl (0x28) с подавлением TX - атакующий глушит нормальную коммуникацию ECU, чтобы скрыть свои действия
- ControlDTCSetting (0x85) - отключение записи диагностических ошибок, маскировка вмешательства
Для пентестера это практический вывод: при составлении отчёта недостаточно указать «обнаружена уязвимость SecurityAccess». Нужно рекомендовать конкретные detection rules - какие events логировать, какие пороги выставлять, какие корреляции между событиями считать индикатором компрометации. Иначе вы нашли дыру, но не помогли её закрыть.
Вопрос к читателям
При SecurityAccess-аудите на реальных блоках один из ключевых параметров - порог блокировки: после скольких неудачных попыток ECU возвращает NRC 0x36 (exceededNumberOfAttempts) или 0x37 (requiredTimeDelayNotExpired) и на какой таймаут уходит в lockout. На блоках Bosch EDC17 у меня порог стабильно 3 попытки с lockout в 10 секунд, а вот на Continental VDO встречал варианты от 5 попыток без lockout до полной блокировки до перезагрузки ECU. Какие пороговые значения SecurityAccess (количество попыток и длительность lockout) вы фиксировали на блоках, с которыми работаете? Укажите family/generation ECU и subfunction - соберём карту реализаций.
Последнее редактирование модератором:
