Идем по приборам / forpes.ru

Главная
Идем по приборам

Идем по приборам +69

06.11.2020 08:36

embeduin 29 13700 Источник

Много ли нужно, чтобы изменить пробег или залезть в память приборной панели?

Есть только один способ узнать — попробовать сделать это самому.

Постановка задачи

В данной статье мы покопаемся в механизмах диагностики нескольких приборных панелей и посмотрим, насколько далеко можно зайти без специализированного дилерского оборудования. Основными инструментами будут скрипты на Python и обычный CAN-USB адаптер. Все воздействия будут сводиться к сообщениям на CAN-шине. Так будет сложнее, но интереснее, так как все сделанное таким способом теоретически можно повторить на настоящем автомобиле через OBDII-разъем. В первую очередь нас будет интересовать доступ к памяти устройства где хранятся его конфигурация и пробег.

Немного дисклеймеров:
Работая с CAN-шиной реального автомобиля есть риск вывести его из строя. Ни в коем случае не беритесь за работу с CAN-шиной без должного опыта, инструментов и мер предосторожности.

Корректировка пробега с корыстной целью — занятие для редисок.

Поиск испытуемых

Чтобы разнообразить эксперимент, мы будем использовать три приборных панели от автомобилей разных производителей. С этой целью на Авито и авторазборках были закуплены три б/у панели согласно следующим критериям:

низкая цена детали (возможно с дефектом);
популярность автомобиля в прошедшем десятилетии;
доступность автомобиля на вторичном рынке;
в выборке панелей не должно быть родственных автопроизводителей (например, Hyundai и Kia, Mitsubishi и Citroen и т.п.)

Итак, в порядке закупки и повествования:

Приборная панель Hyundai Solaris 2013 г.в.
Партномер: 94003-4l715
Установлен сегментый экран с фиксированным количеством символов и обозначений. По сравнению с остальными просто набита разъемами, целых 4 штуки. Много сигналов поступает не по CAN-шине, а "аналоговым" методом по отдельным проводам.

Приборная панель Ford Focus 3 2012 г.в.
Партномер: BM5T-10849-BAE
Стоит монохромный экран малого разрешения. При подаче питания находится в состоянии спячки, чтобы увидеть экран и побаловаться со стрелками нужно периодически будить CAN-сообщениями.

Приборная панель Mitsubishi Lancer X 2008 г.в.
Партномер: 8100A117A

Оказалась достаточно распространенной и устанавливалась сразу на ряд моделей Mitsubishi, Citroen и Peugeout. Самая шумная из всех, при каждой подаче питания громко пищит и дает понять, что существовать отдельно от автомобиля ей не нравится.

Ни одним из данных автомобилей я не владел, поэтому в случае неточностей в описании прошу понять и простить.

Основы диагностики

Прежде чем идти дальше, сделаем короткую остановку и ознакомимся с используемыми диагностическими протоколами. Большинство систем диагностики строятся на двух схожих между собой протоколах: KWP2000 (Keyword Protocol 2000) и UDS (Unified Diagnostic Services). Первым появился KWP2000, затем на его базе был создан UDS, как более современная реализация. Применение этих протоколов предоставляет следующие возможности для автопроизводителей и автосервисов:

чтение кодов неисправностей;
запись/чтение прошивки;
запись/чтение конфигурации и отдельных настроек;
чтение данных с датчиков;
приведение в действие актуаторов.

Например, автопроизводитель может пользоваться этими механизмами, чтобы сконфигурировать ЭБУ под конкретную комплектацию собранного автомобиля, а в автосервисе могут использовать команду разжатия колодок при обслуживании тормозной системы.

В обоих протоколах основными участниками процесса являются две сущности: клиент и сервер. Клиент представляет интересы тестового оборудования, а сервер — интересы ЭБУ. Работа с каждым из ЭБУ ведется отдельно и для налаживания взаимодействия по CAN нужно знать адресную пару клиент-сервер. Упрощенно такую систему можно представить так:

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

Для защиты важных сервисов могут использоваться разные уровни доступа. Как правило, для заполучения нужного уровня доступа нужно запросить у сервера "семя" и подготовить корректный ответ с помощью заранее известного алгоритма.

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

Получается, чтобы составить беглое представление о неизвестном модуле и возможных операциях над ним, нужно совершить следующие шаги:

Определить адреса клиента и сервера;
Найти все доступные сессии (стандартные, расширенные, диагностические и т.д.);
Для каждой из сессий найти все существующие уровни доступа (0x01, 0x03, 0x05 и т.д.);
Для каждой из сессий найти все доступные сервисы (чтение/запись по адресу, управление рутинами и т.д.)

Инструментарий

Начнем с программной составляющей.
Для взаимодействия с устройством использовались Python-библиотеки:

python-udsoncan (диагностический клиент, предоставлет возможность пользоваться сервисами);
python-can-isotp (транспортный уровень ISO 15765-2, позволяет передавать данные длиной более 8 байт);
python-can (API для общения по CAN-шине).

Они интересны по нескольким причнам:

подробная документация с множеством примеров;
широкая поддержка железа + не так сложно добавить новое;
их можно подключать по мере надобности, начиная с голого CAN и поднимаясь выше;
из них можно собрать полноценный стек для UDS-диагностики.

Использованный набор библиотек отчасти и мотивировал меня написать данную статью, поскольку показался любопытным и полезным для быстрых экспериментов. Связка в виде скриптов на Python и адаптера CAN-USB дают гибкость и способность на лету прикидывать последовательности обмена данными. Можно автоматизированно подбирать пароли к уровням доступа, притворяться дилерским диагностическим оборудованием, просто слушать CAN-шину и многое другое.

Об отрицательном опыте использования: не всегда получалось добиться отклика в заданных временных рамках, например, скрипт мог не успеть отправить flow-control сообщение и тем самым обрывал пересылку большого куска данных. Также были случаи, когда CAN-сообщения отправлялись в неправильном порядке, но разбор полетов показал, что корень проблемы находился не в библиотеках. В конечном счете данные проблемы получилось обойти, главное всегда помнить, что настольный ПК это все-таки не real-time устройство.

Для некоторых задач, например подбора адресов клиента и сервера, нам пригодится утилита caringcaribou, которая тоже использует python-can.

Что касается аппаратной части и адаптеров CAN-USB, то в ход шло все, что удавалось раздобыть и одолжить, библиотеки это позволяют. В данном конкретном случае, работа была проделана с помощью Vector VN1610 и VN1611, а также адаптера на базе протокола Lawicel.
Что до последнего, то он сравнительно прост и предcтавляет из себя виртуальный COM-порт, который преобразует по определенным правилам строки в CAN-сообщения и наборот. При некотором желании похожий девайс можно сделать своими силами, на хабре есть интересная статья "CAN-USB адаптер из stm32vldiscovery" на эту тему.

Для работы с приборными панелями на столе достаточно иметь блок питания, способный выдать 12 В. В обзоре на каждую панель будут приведены краткие справки по железу, распиновке и настройке CAN.

Приборная панель Hyundai Solaris

Обзор

Железо:

Распиновка панели и конфигурация CAN:

Замечание: у панели Solaris сзади 4 разъема, поэтому они обозначены слева направо как A, B, C, D.

Сессии и уровни доступа:

Таблица сервисов:

Знаки вопросов указывают на предполагаемое имя сессии, поскольку точной информации нет.
Нумерация сессий почему-то перемешана, 0x03 взят из UDS, а 0x85 и 0x90 взяты из KWP2000.
Из результатов сканирования видно, что панель достаточно демократично относится к чтению и записи в память, эти операции доступны во всех сессиях, в том числе сразу после подачи питания. В таком случае, можно не терять время и сразу приступить к сканированию адресов и типов памяти.

В поисках памяти

Для чтения памяти и в KWP2000 и в UDS используется сервис ReadMemoryByAddress (0x23), есть только некоторые отличия по формату запроса. Для KWP2000 он будет выглядеть вот так:

Byte #	Value	Parameter
0	23	Service ID
1-3	XX	memoryAddress[3]
4	XX	memorySize

Все просто, указывается ID сервиса, адрес чтения и сколько байт нужно прочитать. В некоторых системах старший байт может быть использован как memoryIdentifier, чтобы выбирать из какой именно памяти произодится чтение (EEPROM, flash), но при этом ширина адреса уменьшается до 16 бит.

Теперь про UDS:

Byte #	Value	Parameter
0	23	Service ID
1	XX	addressAndLengthFormatIdentifier
~	XX	memoryAddress[]
~	XX	memorySize[]

Здесь ширина адреса и размера памяти может меняться, это настраивается байтом addressAndLengthFormatIdentifier, в котором старший ниббл определяет ширину memorySize, а младший — memoryAddress. Например, для 32-битного memoryAddress и 16-битного memorySize этот байт будет равен 24. Старший байт адреса так же может быть использован как memoryIdentifier.

С этими знаниями, можно наконец приступать к чтению памяти и обнаружить, что они не совсем работают. Вернее, вообще не работают, в обоих случаях. Провозившись с этим некоторое время, было принято решение отойти от стандартов и поиграться с телом запроса, меняя ширину полей и их значения. И вот, получился рабочий вариант:

Byte #	Value	Parameter
0	23	Service ID
1-4	XX	memoryAddress[4]
5	XX	memorySize[2]

То есть нечто промежуточное: поля шире, чем в KWP2000, но при этом addressAndLengthFormatIdentifier из UDS не применяется. Далее перебираем адреса и находим, что старший байт адреса выбирает тип памяти: 0x00 для флеш-памяти микроконтроллера (виден кусочек таблицы векторов прерываний):

TX: <7C6> (8)    07 23 00 00 00 00 00 04
RX: <7CE> (8)    05 63 80 07 00 07 00 00

и 0x04 для внешней EEPROM.

TX: <7C6> (8)    07 23 04 00 00 00 00 04
RX: <7CE> (8)    05 63 0d a8 00 00 00 00

Скрипт чтения флеш-памяти и EEPROM

import can
import isotp
import logging
import time
import argparse

def process_stack_receive(stack, timeout=1):
    t1 = time.time()
    while time.time() - t1 < timeout:
        stack.process()
        if stack.available():
            break
        time.sleep(stack.sleep_time())
    return stack.recv()

def process_stack_send(stack, timeout=1):
    t1 = time.time()
    while time.time() - t1 < timeout:
        stack.process()
        if not stack.transmitting():
            break
        time.sleep(stack.sleep_time())

def my_error_handler(error):
    logging.warning('IsoTp error happened : %s - %s' % (error.__class__.__name__, str(error)))

def print_frame(frame):
    if frame:
        print(''.join(format(x, '02x') for x in frame))
    else:
        print("None")

bus = can.interface.Bus(bustype='slcan', 
                        channel="COM3", 
                        ttyBaudrate=115200, 
                        bitrate=500000)
addr = isotp.Address(isotp.AddressingMode.Normal_11bits, rxid=0x7ce, txid=0x7c6)
stack = isotp.CanStack(bus, address=addr, error_handler=my_error_handler, params = {'tx_padding':0})

parser = argparse.ArgumentParser()
parser.add_argument("-e", "--eeprom", help="read EEPROM", action="store_true")
parser.add_argument("-f", "--flash", help="read Flash", action="store_true")
args = parser.parse_args()

if args.eeprom:
    for addr in range(0x00000000, 0x000007ff, 0x10):
        addr0 = (addr >>  0) & 0xff
        addr1 = (addr >>  8) & 0xff
        array = [0x23, 0x04, 0x00, addr1, addr0, 0x00, 0x10]

        stack.send(bytearray(array))
        process_stack_send(stack)
        print_frame(process_stack_receive(stack))

if args.flash:
    for addr in range(0x00000000, 0x0003ffff, 0x10):
        addr0 = (addr >>  0) & 0xff
        addr1 = (addr >>  8) & 0xff
        addr2 = (addr >> 16) & 0xff
        array = [0x23, 0x00, addr2, addr1, addr0, 0x00, 0x10]

        stack.send(bytearray(array))
        process_stack_send(stack)
        print_frame(process_stack_receive(stack))

bus.shutdown()

Раз уж получилось прочесть, почему бы не попробовать и записать что-нибудь? Берем сервис WriteMemoryByAddress (0x3d) и, наученные прошлым опытом, поменьше верим стандартам и побольше — собственным догадкам. Рабочим вариантом зароса оказывается:

Byte #	Value	Parameter
0	3d	Service ID
1-4	XX	memoryAddress[4]
5-N	XX	dataRecord

то есть не нужно даже указывать memorySize, достаточно просто указать адрес и сами байты.

Теперь пишем один байт и тут же читаем назад для проверки. Запрос записи во флеш-память подтверждается успешным ответом 0x7d, но по факту память остается нетронутой:

TX: <7C6> (8)    06 3d 00 00 00 00 81 00
RX: <7CE> (8)    01 7d 00 00 00 00 00 00

TX: <7C6> (8)    07 23 00 00 00 00 00 04
RX: <7CE> (8)    05 63 80 07 00 07 00 00

что в принципе ожидаемо, т.к. просто так изменить прошивку без применения загрузчика вряд ли получится.

А вот запись в EEPROM прошла успешно:

TX: <7C6> (8)    06 3d 04 00 00 00 0e 00
RX: <7CE> (8)    01 7d 00 00 00 00 00 00

TX: <7C6> (8)    07 23 04 00 00 00 00 04
RX: <7CE> (8)    05 63 0e a8 00 00 00 00

байт 0x0d поменял значение на 0x0e.

Этого достаточно, чтобы переходить к следующему этапу: поиску и изменению значений пробега.

Загадка со змейкой

Сейчас нам необходимо понять какие именно из байт EEPROM отвечают за хранение пробега. Для этого применяется очень простой подход: посылаем на панель сигнал скорости, пока она не увеличивает пробег на 1 км, снова читаем EEPROM и сравниваем с предыдущим дампом. Для симуляции сигнала скорости необходимо найти CAN-сообщение, отвечающее за скорость и отправлять его с определенным периодом. Впрочем, бывают и исключения, как в случае с данной панелью: она оказалась от автомобиля с МКПП, где скорость передается отдельным импульсным сигналом.

Итак, 1 км пройден, давайте сравнивать:

Из всего EEPROM поменялся только один байт и его значение уменьшилось на 0x20? Явно надо идти глубже.

"Накатываем" еще 23 км:

И начинаем наблюдать некоторые закономерности:

для хранения используются 64 байта
pост пробега = вычитание значений
таблица проходится зигзагом в 2 отдельных прохода:
вычитаемое определяется номером столбца:

0,1	2,3	4,5	6,7	8,9	A,B	C,D	E,F
-0x01	-0x02	-0x04	-0x08	-0x10	-0x20	-0x40	-0x80

Более подробный разбор спрятан под спойлер, так как он занимает много места.

Разгадка

Итак, начнем с исходных данных для пробега 64890 км, для удобства разбитых на четыре группы:

[13, F8, 27, F0, 4F, E0, 9F, C0, 3F, 81, 7F, 02, FE, 04, FC, 09]
[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 9F, 05, 3E, 0A, 7C]
[13, F8, 27, F0, 4F, E0, 9F, C0, 3F, 81, 7F, 02, FE, 04, FC, 09]
[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 9F, 05, 3E, 0A, 7C]

Далее для 0-ой и 2-ой строк попарно меняем значения в столбцах:

[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 7F, 04, FE, 09, FC]
[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 9F, 05, 3E, 0A, 7C]
[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 7F, 04, FE, 09, FC]
[F8, 13, F0, 27, E0, 4F, C0, 9F, 81, 3F, 02, 9F, 05, 3E, 0A, 7C]

Вычитаем каждый байт из FF, чтобы заменить разности суммами:

[07, EC, 0F, D8, 1F, B0, 3F, 60, 7E, C0, FD, 80, FB, 01, F6, 03]
[07, EC, 0F, D8, 1F, B0, 3F, 60, 7E, C0, FD, 60, FA, C1, F5, 83]
[07, EC, 0F, D8, 1F, B0, 3F, 60, 7E, C0, FD, 80, FB, 01, F6, 03]
[07, EC, 0F, D8, 1F, B0, 3F, 60, 7E, C0, FD, 60, FA, C1, F5, 83]

Попарно объединяем значения в каждой строке, чтобы получить 2-ух байтные:

[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD80, FB01, F603]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD60, FAC1, F583]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD80, FB01, F603]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD60, FAC1, F583]

Для переполненных значений переносим младшие разряды в старшие:

[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD80, 1FB00, 3F600]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD60, 1FAC0, 3F580]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD80, 1FB00, 3F600]
[07EC, 0FD8, 1FB0, 3F60, 7EC0, FD60, 1FAC0, 3F580]

Теперь нормализуем значения, чтобы получить набор простых счетчиков; не забываем, что делитель зависит от номера столбца:

[07EC, 07EC, 07EC, 07EC, 07EC, 07EC, 07EC, 07EC]
[07EC, 07EC, 07EC, 07EC, 07EC, 07EB, 07EB, 07EB]
[07EC, 07EC, 07EC, 07EC, 07EC, 07EC, 07EC, 07EC]
[07EC, 07EC, 07EC, 07EC, 07EC, 07EB, 07EB, 07EB]

Наконец, суммируем все счетчики и получаем ожидаемые FD7A (64890).

Осталось только преобразовать желаемый пробег в соответствующую таблицу, записать ее обратно в EEPROM и:

Шалость удалась!

Приборная панель Ford Focus 3

Обзор

Железо:

Распиновка панели и конфигурация CAN:

Замечание: к панели Focus подключаются 2 CAN-шины: MS (Medium Speed) и MM (Multimedia). Нам понадобится MS CAN.

Сессии и уровни доступа:

Таблица сервисов:

По результатам сканирования видно, что реализация диагностического сервера придерживается стандарта UDS вплоть до нумерации сессий. Сессия 0x01 используется по умолчанию при каждой подаче питания, сессия 0x02 используется для изменения прошивки и сессия 0x03 применяется для изменения настроек. Прямого доступа к памяти посредством ReadMemoryByAddress/WriteMemoryByAddress нет ни в одной из сессий, поэтому начинаем с чтения всех возможных DID с помощью сервиса ReadDataByIdentifier.

Первая попытка

Перебирая DID, читаем значения одно за другим, пока на глаза не попадается DID 0x61BB размером в 3-байта, в котором содержится значение пробега:

RX: <720> (8)    03 22 61 bb 00 00 00 00
RX: <728> (8)    06 62 61 bb 00 e9 20 00

Просто так перезаписать это значение вызовом WriteDataByIdentifier не вышло, для этого необходимо перейти в расширенную диагностическую сессию и получить уровень доступа 0x03.

Краткое отступление по поводу алгоритма. При запросе нужного уровня доступа сервер вернет "семя" длиной 3 байта, для которого нужно подобрать корректный ответ той же длины. Подсказки как правильно это сделать, можно найти в публикациях Beneath the Bonnet: a Breakdown of Diagnostic Security и Adventures in Automotive Networks and Control Units.

Получив уровень доступа 0x03, пробуем произвести запись еще раз, увеличив значение на 1 км:

RX: <720> (8)    02 10 03 00 00 00 00 00
RX: <728> (8)    06 50 03 00 32 01 f4 00

RX: <720> (8)    02 27 03 00 00 00 00 00
RX: <728> (8)    05 67 03 XX XX XX 00 00
RX: <720> (8)    05 27 04 XX XX XX 00 00
RX: <728> (8)    02 67 04 00 00 00 00 00

RX: <720> (8)    06 2e 61 bb 00 e9 21 00
RX: <728> (8)    03 6e 61 bb 00 00 00 00

Тут же читаем обратно, чтобы проверить:

RX: <720> (8)    03 22 61 bb 00 00 00 00
RX: <728> (8)    06 62 61 bb 00 e9 21 00

Все получилось. А если уменьшить значение?.. Пробуем:

RX: <720> (8)    02 10 03 00 00 00 00 00
RX: <728> (8)    06 50 03 00 32 01 f4 00

RX: <720> (8)    02 27 03 00 00 00 00 00
RX: <728> (8)    05 67 03 XX XX XX 00 00
RX: <720> (8)    05 27 04 XX XX XX 00 00
RX: <728> (8)    02 67 04 00 00 00 00 00

RX: <720> (8)    06 2e 61 bb 00 e9 20 00
RX: <728> (8)    03 7f 2e 31 00 00 00 00

Панель отвечает ошибкой 0x31 requestOutOfRange, то есть новое значение не проходит проверку. Что ж, значит нужно искать другой путь.

Вторичный загрузчик

Если вернуться к результатам сканирования, то можно найти в них reprogrammingSession. Обычно использование этой сессии подразумевает наличие вторичного загрузчика, и в случае с Ford его легко можно найти в открытом доступе. Поэтому мы попробуем его загрузить и посмотреть, что будет. Вдруг у него есть доступ к EEPROM?

Вторичный загрузчик (Secondary Bootloader) применяется для обновления прошивки ЭБУ следующим образом: SBL загружается в ОЗУ устройства, затем происходит передача управления SBL, после чего начинается чтение/запись флеш-памяти микроконтроллера. Упрощенно это можно представить так:

Для работы с прошивками Ford испольует формат VBF или Volvo Binary Format. Такой файл состоит из двух частей: человекочитаемого заголовка с адресом загрузки, типом данных и контрольной суммой; и бинарными данными для отправки в ЭБУ.

Последовательность загрузки SBL состоит из следующих шагов:

DiagnosticSessionControl: переход в сессию программирования 0x02;
SecurityAccess: получениe уровня доступа 0x01;
RequestDownload: адрес загрузки 0x03ff0000 (начало ОЗУ), размер передачи указывается как в VBF-файле;
TransferData: непосредственный процесс передачи данных;
RequestTransferExit: запрос завершения передачи данных;
RoutineControl: запуск рутины 0x0301, которая передает управление SBL.

После этого можно приступать к работе с флеш-памятью микроконтроллера: читать ее с помощью RequestUpload и записывать с помощью RequestDownload.

Скрипт чтения флеш-памяти (работает с извлеченным из VBF бинарником)

import can
import isotp
import time
import binascii
from udsoncan.connections import PythonIsoTpConnection
from udsoncan.client import Client
from udsoncan import Response, MemoryLocation, DataFormatIdentifier
from ford_glfsr import calculate_key

download_payload_size = 0xc8
upload_payload_size = 0x20

def my_error_handler(error):
   logging.warning('IsoTp error happened : %s - %s' % (error.__class__.__name__, str(error)))

bus = can.interface.Bus(bustype='slcan', 
                        channel="COM3", 
                        ttyBaudrate=115200, 
                        bitrate=125000)
tp_addr = isotp.Address(isotp.AddressingMode.Normal_11bits, txid=0x720, rxid=0x728)
stack = isotp.CanStack(bus=bus, 
                       address=tp_addr, 
                       params = {'tx_padding':0}, 
                       error_handler=my_error_handler)
conn = PythonIsoTpConnection(stack)

# wake up the IPC
ping_msg = can.Message(arbitration_id=0x080, 
                       data=[0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00], 
                       is_extended_id=False)
bus.send(ping_msg)
time.sleep(0.2)

with Client(conn) as client:
    # TesterPresent
    client.tester_present()

    # ChangeSession
    client.change_session(0x02)
    time.sleep(0.3)

    # SecurityAccess
    response = client.request_seed(0x01)
    seed_int = int.from_bytes(response.service_data.seed, "little")
    key_int = calculate_key(seed_int, 0x01)
    key_bytes = key_int.to_bytes(3, byteorder="big")
    client.send_key(0x01, key_bytes)

    # RequestDownload
    memloc = MemoryLocation(address=0x03ff0000, 
                            memorysize=0x54d4, 
                            address_format=32, 
                            memorysize_format=32)
    dfi = DataFormatIdentifier(compression=0, encryption=0)
    client.request_download(memory_location=memloc, dfi=dfi)

    # TransferData
    f = open("BM5T-14C025-AD.bin", "rb")
    ipc_sbl = f.read()
    f.close()

    end_block = 0x6d  # memorysize/upload_payload_size
    print("DOWNLOAD END BLOCK:", (hex(end_block)))
    # sequence should start with "0x01", not "0x00"
    for block_num in range(0x01, end_block + 0x01):
        print(hex(block_num))
        start_i = (block_num - 0x01) * download_payload_size
        end_i = start_i + download_payload_size
        client.transfer_data(block_num, ipc_sbl[start_i:end_i])

    # TransferExit
    client.request_transfer_exit()

    # StartRoutine
    client.start_routine(0x0301, data = b'\x03\xff\x00\x00')

    # RequestUpload
    memloc = MemoryLocation(address=0x00007000, 
                            memorysize=0x000f9000, 
                            address_format=32, 
                            memorysize_format=32)
    dfi = DataFormatIdentifier(compression=0, encryption=0)
    client.request_upload(memory_location=memloc, dfi=dfi)

    upload_result = bytearray()
    end_block = 0x7c80  # memorysize/upload_payload_size
    print("UPLOAD END BLOCK:", (hex(end_block)))
    # sequence should start with "0x01", not "0x00"
    for block_num in range(0x01, end_block + 0x01):
        print(hex(block_num))
        response = client.transfer_data(block_num % 0x100)
        upload_result.extend(response.service_data.parameter_records)

    f = open("flash_dump.bin", "wb")
    f.write(upload_result)
    f.close()

    # TransferExit
    try:
        client.request_transfer_exit()
    except:
        pass

    # ECUReset
    client.ecu_reset(1)

Тем не менее, оказалось, что у SBL нет доступа к внешней EEPROM. Было перепробовано несколько разных SBL, но все попытки закончились ничем. С положительной стороны — у нас теперь есть возможность читать и записывать прошивку микроконтроллера. Что мешает отредактировать ее и залить обратно?

Модификация прошивки

Получается, что есть отдельный DID для значений пробега, но запись работает только на увеличение; сам пробег лежит в EEPROM, куда прямого доступа у нас нет, ни из основной программы, ни из вторичного загрузчика. С такими входными данными нам стоит попробовать модифицировать родную прошивку таким образом, чтобы получить возможность мотать пробег назад. Для этого с помощью уже изученного процесса выкачивается содержимое флеш-памяти и изучается на предмет интересных функций.

Перед этим был экспериментально получен предел увеличения километража: по какой-то странной причине максимально возможное для установки значение составляет 4294967 км.

Этот "волшебное" число пригодилось для поиска операций с граничными значениями, в пределах которых можно изменять пробег в меньшую сторону. Найдя нечто похожее, заменяем одну из проверок на "nop":

затем заливаем прошивку обратно, повторяем эксперимент:

TX: <720> (8)    02 10 03 00 00 00 00 00
RX: <728> (8)    06 50 03 00 32 01 f4 00

TX: <720> (8)    02 27 03 00 00 00 00 00
RX: <728> (8)    05 67 03 XX XX XX 00 00
TX: <720> (8)    05 27 04 XX XX XX 00 00
RX: <728> (8)    02 67 04 00 00 00 00 00

TX: <720> (8)    03 22 61 bb 00 00 00 00
RX: <728> (8)    06 62 61 bb 01 e2 40 00

TX: <720> (8)    06 2e 61 bb 01 38 d5 00
RX: <728> (8)    03 6e 61 bb 00 00 00 00

TX: <720> (8)    03 22 61 bb 00 00 00 00
RX: <728> (8)    06 62 61 bb 01 38 d5 00

Теперь все работает и можно мотать пробег в меньшую сторону, как самый настоящий злодей:

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

Подмена битмапов

После того, как основная работа проделана, можно и с битмапами поиграться. Например, взять и поменять приветственное лого панели.

Начинается все снова с изучения дампа, но в этот раз нужно найти в нем графические данные. Для этого очень удобно визуализировать файл дампа целиком, пример такого анализа с помощью GIMP был взят отсюда.

Если вкратце, то нужно скормить GIMPу файл под видом raw-данных и, меняя цветовое представление и ширину поля, искать нечто похожее на изображения. Экран у выбранной панели монохромный (бинарный), поэтому тип изображения устанавливаем как "Ч/б 1 бит", а ширину подбираем экспериментально.

При ширине визуализации в 16 пикселей, обнаруживаются первые изображения (шрифт для 1, 2, 3, 4, 5, 6). Но при включении панели отображается логотип Ford, поэтому нужно продолжать поиски. Как оказалось, шрифты и маленькие иконки найти проще, чем крупное изображение, разбитое на куски. Поэтому логотип попался на глаза не с первой попытки:

Видите эти загогулины? Это два верхних участка буквы F в логотипе Ford. Если собрать все части воедино и склеить в картинку, то мы увидим следующий результат:

Битмап Ford

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 FC 00 FE 00 FF 80 E3 80 C1 C0 C0 40 C0 60 E0 60 E0 20 70 30 18 30 00 30 00 30 00 30 80 30 C0 20 F0 60 38 60 1C 60 0C 60 06 60 03 C0 C1 C0 20 C0 20 C0 C0 C0 00 C0 01 C0 01 80 01 80 01 80 03 80 03 80 03 80 07 80 07 80 07 80 07 80 0F 80 0F 80 0F 80 07 80 07 80 07 80 03 80 03 C0 01 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 C0 00 C0 00 C0 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 7E 00 FF 80 FF C0 E1 E0 C0 70 C0 30 80 10 80 00 80 01 C0 01 C0 03 E0 03 F0 01 F0 11 78 08 3C 04 1F 84 0F C4 07 E4 01 FE 80 3F C0 0F E0 07 78 03 FC 02 FF 82 CF C2 03 C2 01 E2 00 63 00 66 00 29 80 00 80 40 E0 60 F8 C0 7F C0 1F 00 06 00 07 80 83 C0 E1 E0 F0 60 FC 70 3E F0 1F E0 07 80 0F 80 39 C0 70 E0 70 F0 31 F0 31 E0 19 00 FC 00 FE 00 FF 80 1F 80 07 C0 01 E0 00 E0 00 70 80 70 C0 E0 E0 E0 FF 80 7F 80 3F E0 0F F0 07 FC 80 7E C0 1F E0 0F 60 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 00 03 00 03 00 07 00 07 00 07 00 07 00 03 00 03 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 00 00 00 00 00 01 00 03 00 07 00 07 00 07 00 07 00 07 00 03 00 03 00 03 00 01 00 00 00 00 00 00 00 04 00 07 00 07 00 07 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 07 00 0F 00 0E 00 0E 00 0E 00 06 00 07 00 03 00 07 00 0F 00 0F 00 0C 00 0C 00 06 00 07 00 03 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Получается, что размер лого составляет 114x48 пикселей, оно состоит из 6 фрагментов, а адрес можно приблизительно понять с помощью сетки координат GIMP. Нам остается только отредактировать этот участок прошивки, загрузить его обратно:

и получить новое стартовое лого.

Битмап Habr

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 00 FC 00 FC 00 FC 00 FC 00 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 00 FC 00 FC 00 FC 00 FC 00 FC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF F0 01 F8 00 7C 00 7C 00 FC 00 FC 01 FC FF FC FF F8 FF F0 FF E0 FF C0 FF 00 00 00 00 00 00 00 3C 80 FF C0 FF E0 FF F0 FF F8 FF F8 C3 F8 81 F8 00 F8 00 F8 00 F8 00 F0 81 E0 C3 F8 FF F8 FF F8 FF F8 FF F8 FF 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF E0 C3 F0 81 F8 00 F8 00 F8 00 F8 00 F8 81 F8 C3 F8 FF F0 FF E0 FF C0 FF 80 FF 00 3C 00 00 00 00 00 00 F8 FF F8 FF F8 FF F8 FF F8 FF F8 FF E0 03 F0 01 F8 00 78 00 7C 00 FC 00 F8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 00 00 00 00 00 00 00 00 01 00 03 00 07 00 0F 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 0F 00 07 00 1F 00 1F 00 1F 00 1F 00 1F 00 00 00 00 00 00 00 00 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 07 00 0F 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 0F 00 07 00 03 00 01 00 00 00 00 00 00 00 00 00 1F 00 1F 00 1F 00 1F 00 1F 00 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Приборная панель Mitsubishi Lancer X

Обзор

Железо:

Замечание: точно определить модель микроконтроллера не получилось, т.к. маркировка не соответствует модели.

Распиновка панели и конфигурация CAN:

Сессии и уровни доступа:

Таблица сервисов:

Сканирование показало, что доступны только две сессии: сессия по умолчанию и расширенная диагностическая. Установить точные наименования сессий и внести некоторую ясность помогла удачная находка. На просторах интернета можно найти обрывки документации начала 2000-х, в которой описаны основы применения KWP2000 для диагностики автомобилей альянса DaimlerChrysler-Mitsubishi, а именно марок Dodge, Chrysler, Jeep, Mitsubishi, Mercedes-Benz и Smart. Этот альянс уже давно распался, что добавляет нашим экспериментам немного автомобильной археологии.

Возвращаясь к доступным сервисам — их очень мало в defaultSession, по сути доступны только чтение ошибок, идентификационных данных и некоторых настроек. Записывать ничего нельзя, доступ к памяти отсутствует. В extenedDiagnosticSession открываются возможности запуска рутин и записи данных по идентификатору, но доступа к памяти все равно нет. В таком случае остается только перебирать доступные для чтения значения с помощью ReadDataByLocalIdentifier и попытаться изменить некоторые из них.

Не все коту масленица

В этот раз перебор значений закончился гораздо быстрее, т.к. сервис ReadDataByLocalIdentifier может адресовать только 0xFF уникальных идентификаторов, в отличии от ReadDataByIdentifier где их может быть до 0xFFFF.

Значения пробега были обнаружены под DID 0xAD в виде трех байт:

TX: <6A0> (8)    02 21 ad 00 00 00 00 00
RX: <514> (8)    05 61 ad d0 18 03 00 00

Если попробуем использовать сервис WriteDataByLocalIdentifier и записать значение на 1 км больше, то сервер ответит отказом:

TX: <6A0> (8)    05 3b ad d1 18 03 00 00
RX: <514> (8)    03 7f 3b 12 00 00 00 00

Код ошибки 0x12 в ответном сообщении означает "Sub Function Not Supported" — то есть сервис записи по идентификатору работает корректно, но запись для него невозможна.

У нас осталось еще несколько непроверенных уровней доступа: вдруг если мы их получим, то операция станет возможной или откроются другие способы корректировки? Но для этого надо знать, как правильно это сделать. Поиск информации привел к очень полезной статье на хабре "Что можно сделать через разъем OBD в автомобиле", где автор смог извлечь алгоритм из более свежей цветной панели Mitsubishi с микроконтроллером другой архитектуры внутри. Оказалось, что алгоритм работает и для панели постарше, с помощью этой информации удалось подобрать и получить все три уровня доступа (0x01, 0x07 и 0x09). Самое время для повторной попытки:

TX: <6A0> (8)    02 10 92 00 00 00 00 00
RX: <514> (8)    02 50 92 d0 18 03 1e 00

TX: <6A0> (8)    02 27 01 00 00 00 00 00
RX: <514> (8)    06 67 01 XX XX XX XX 00
TX: <6A0> (8)    06 27 02 XX XX XX XX 00
RX: <514> (8)    03 67 02 34 1c ad 4f 00

TX: <6A0> (8)    02 27 07 00 00 00 00 00
RX: <514> (8)    06 67 07 XX XX XX XX 00
TX: <6A0> (8)    06 27 08 XX XX XX XX 00
RX: <514> (8)    03 67 08 34 36 74 26 00

TX: <6A0> (8)    02 27 09 00 00 00 00 00
RX: <514> (8)    06 67 09 XX XX XX XX 00
TX: <6A0> (8)    06 27 0a XX XX XX XX 00
RX: <514> (8)    03 67 0a 34 9f 1f f5 00

TX: <6A0> (8)    05 3b ad d1 18 03 00 00
RX: <514> (8)    03 7f 3b 12 9f 1f f5 00

которая снова возвращает ошибку. Кстати, забавный момент, по какой-то причине в ответах сервера застревают байты от предыдущих сообщений. Кто-то из разработчиков забыл про очистку буфера?

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

Из упомянутой ранее документации можно узнать, что теоретически должна существовать еще одна сессия: ECUFlashReprogrammingSession (0x85) в которой открываются возможности для загрузки прошивки, но найти способ попасть в нее так и не удалось.

На этом этапе можно было бы взять программатор EEPROM, разобрать панель и просто перезаписать значения, но это отходит от диагностической темы данной статьи.

Впрочем, вполне вероятно, что-то было упущено и истина была где-то рядом.

Извлеченный урок

Тем не менее, время потраченное на изучение панели Mitsubishi не пропало зря, поскольку в процессе получилось изучить отличия KWP2000 и UDS поближе, а также составить сравнительную таблицу:

Для сравнения были использованы подмножество KWP2000 DaimlerChrysler-Mitsubishi, которое немного отличается от "чистого" KWP2000 и стандарт UDS 2006 года.

Сравнение интересно тем, что можно увидеть эволюцию, которую прошли протоколы диагностики. Например, избыточные сочетания сервисов были заменены одним сервисом, но с выбором подфункций: DisableNormalMessageTransmission / EnableNormalMessageTransmission заменены на CommunicationControl. То же касается и тройки StartRoutineByLocalIdentifier / StopRoutineByLocalIdentifier / RequestRoutineResultsByLocalIdentifier, которая превратилась в RoutineControl.

Если присмотреться внимательнее, то можно заметить, что в KWP2000 не хватает пары для StartDiagnosticSession, которая называлась бы StopDiagnosticSession и сбрасывала бы сервер в сессию по умолчанию. На самом деле, такой сервис может существовать, но он не входит в стандарт ISO 14230-3, и легко заменятся обычным вызовом StartDiagnosticSession с указанием перейти в сессию 0x81.

Поменялась логика чтения кодов неисправностей, добавлен сервис AccessTimingParameter для настройки продолжительности устанавливаемого соединения, SecuredDataTransmission для защиты сессии от прослушивания, LinkControl для настройки скорости соединения во время сессии.

Ну и самое заметное отличие — это упразднение ReadECUIdentification, который использовался для чтения идентификационных параметров модуля: VIN, серийный номер и т.д. В UDS вся эта информация читается обычным ReadDataByIdentifier, а для стандартных DID добавляется префикс 0xF1. Например для чтения VIN KWP2000 использует команду 0x1A90, а UDS — 0x22F190. Этим удобно пользоваться, когда в руки попал незнакомый модуль и нужно быстро понять, какой из протоколов применять.

Заключение

На основании проведенных экспериментов, можно сделать простой вывод — добиться необходимого результата можно если не средствами диагностики, то редактированием прошивки или EEPROM. Для разграничений уровней доступа применяются относительно несложные алгоритмы, подсказки к решению которых можно найти в диагностическом ПО, самой прошивке или прослушанной сессии. В некоторых случаях производитель может использовать проприентарный подход для сокрытия важной информации, который тоже можно обойти.

Тем не менее, ситуация может изменится к лучшему, совсем недавно вышла новая редакция стандарта UDS 14229-1:2020, в которой был добавлен отдельный сервис Authentication (0x29) для применения более сложных методов аутентификации. Также все больше автомобилей комплектуются телематикой и IoT услугами, откуда могут перекочевать ~~новые дыры в безопасности~~ разнообразные механизмы защиты, например secure boot, anti-rollback прошивки и т.п.

Так что вполне вероятно, что провернуть похожий трюк лет 10 спустя станет сложнее.

Комментарии (29)

voxy2
06.11.2020 13:07
#22270018
В своё время (лет 20-ть назад) при выборе б\у иномарки поверил журналу «За рублём» об самых честных аукционах в Японии. Давно уже не читаю подобные «рекламные вестники», но с правого руля так и не слез…
1. amarao
  06.11.2020 13:21
  #22270088
  Аукционы в Японии очень честные. На Кипре, например, очень любят скручивать пробег, так что доступ к аукционным листам очень полезная вещь при выборе машины. Там же отметки про аварии, сколы и т.д.

eurol
06.11.2020 15:04
#22270642
+2
по какой-то странной причине максимально возможное для установки значение составляет 4294967 км

Ну если знать, что 2^32 = 4294967296, можно предположить, что пробег может измеряться в метрах, а записываться с шагом в километр. В любом случае число сразу бросается в глаза.
1. sterr
  07.11.2020 00:35
  #22272952
  У VW Golf 3/Vento всего 299 000. Поэтому определить точный пробег, даже если он реальный практически невозможно. Можно лишь догадываться о номере круга.
1. embeduin Автор
  07.11.2020 02:59
  #22273172
  Хм, действительно, в метрах это имеет смысл.
  1. esaulenka
    08.11.2020 15:17
    #22277142
    Так оно и есть. У Вас в том самом кусочке новое значение сравнивается с неким r17, делённым на 1000. Откуда берётся r17, на том кусочке не видно.

Raimon
06.11.2020 15:59
#22270950
я так понимаю, что официальных руководств по протоколам и кодам для машин нетю это всегда реверс инжиринг? или все же есть в недрах гитхаба репа где собрана информация по разным командам?
1. Javian
  06.11.2020 17:40
  #22271444
  Это отдельный неплохой бизнес — продажа адаптеров и ПО для конфигурации систем автомобиля.
1. embeduin Автор
  07.11.2020 02:56
  #22273166
  Нет, таких руководств нету.
  В UDS и KWP2000 есть некоторая стандартизированная составляющая, например, процедуры чтения VIN или серийного номера ЭБУ, остальное все производители делают по-разному.
  
  Между автопроизводителем и поставщиком ЭБУ обычно применяется некое ТЗ, в котором описана специфика диагностики. Эта же документация используется для разработки марочного диагностического комплекса, который потом можно продавать в автосервисы. Как правило, заводы не заинтересованы в распространении этой документации.
  1. nikolayv81
    08.11.2020 13:10
    #22276830
    С учётом того что сейчас диагностический комплекс не продаётся а сдаётся в аренду (иногда с онлайн авторизацией) то производителю это точно не выгодно :)

lonelymyp
06.11.2020 18:03
#22271548
Боюсь такая скрутка будет работать только «на столе», т.к. при установке в автомобиль, пробег в приборке перезаписывается правильным, хранящимся в разных других блоках авто. С таким подходом надо править прошивку чтобы на экран выводился пробег с заданной отрицательной поправкой.
Можно по идее к времени суток привязать, чтобы только в полночь, на одну минуту, на приборке отображался правильный пробег))).

И у вас ошибка на гифке которая иллюстрирует смотку пробега у форда, было 80 тыщ, а стало 123 тыщи =)
1. Astroscope
  06.11.2020 20:41
  #22272122
  пробег в приборке перезаписывается правильным, хранящимся в разных других блоках авто
  
  Да. В разных машинах по-разному, что в общем-то отлично отображено в статье, но у большинства пробег прописывается в нескольких различных блоках. Не знаю, насколько это обстоятельство затрудняет «скручивание» для тех, кто занимается этим за деньги, но если «скручивать» кустарно, то можно легко попасться на разном пробеге в разных блоках.
  
  embeduin, скажите, в Ford'овской приборке вы не находили данные о моточасах?
  1. embeduin Автор
    07.11.2020 02:34
    #22273144
    Нет, данных о моточасах специально не искал и не находил, к сожалению.
  1. kababok
    10.11.2020 01:20
    #22283280
    Думаю (практически уверен), что данные о моточасах забиваются в ECU двигателя (MCU или Motor Control Unitкак вариант названия).
    
    И до них можно вполне спокойно достучаться через OBD-разъём через UDS-команды.
    
    Astroscope
    12.11.2020 00:23
    #22293828
    Forscan показывает и моточасы, и пробег, во всех модулях, в которых они прописаны (в машинах, где этот параметр в принципе поддерживается, он прописывается во все те же модули, в которые прописывается и пробег), но это неспортивно, в смысле в отличие от автора статьи я говорю об использовании готового решения вместо достойно поковыряться самому.
1. embeduin Автор
  07.11.2020 02:45
  #22273156
  Да, наслышан о такой синхронизации, но поэкспериментировать с этим еще не довелось.
  Для этого нужен либо автомобиль целиком, либо макет на столе со всеми необходимыми ЭБУ.
  
  Гифка форда не очень наглядная получилась, там происходит следующее:
  Пробег 123456 км -> перезагрузка панели (черный экран) -> пробег 80085 км.
  1. rencom66
    07.11.2020 09:59
    #22273562
    Чисто из практики. Синхронизация происходит не моментально.
    А спустя несколько часов / количество запусков.
    И бывают такие приколы. Купили фару VAG на разборке, поставили, а через неделю пробег сильно иной…
    
    3aBulon
    08.11.2020 15:27
    #22277184
    ЧТо, прям таки фару?
    
    rencom66
    08.11.2020 15:43
    #22277244
    Угу.
    Туарег вроде был.
    Свежий
    Фара с мозгами, ну и…
    Сейчас куда только пробег не пишут....
    
    lonelymyp
    09.11.2020 10:24
    #22279702
    Фары разные бывают, светодиодные с управляемой зоной освещения/затемнения без своего эбу уже не могут.

kolyandex
06.11.2020 20:24
#22272074
Последняя приборка из статьи деревянная в плане KWP2000. В ней нет сессии репрограмминга, не реализован SID 0x3D. Митсу приборки для таких экспериментов надо брать от 2010 года. habr.com/ru/post/474718
1. embeduin Автор
  07.11.2020 03:25
  #22273190
  Спасибо за информацию!
  Да, эта приборка оказалась скучноватой.

Amihailov
07.11.2020 11:52
#22273878
Пасхалочка с 80085 (BOOBS) хорошая)

lonelymyp
07.11.2020 13:05
#22274064
А насчёт редактирования функционала не думали?
Вывести на панель температуру двигателя в градусах, или напряжение аккумулятора в вольтах.
Например на странице с пробегом за поездку заменить цифру пробега на температуру.
Или даже добавить отдельный пункт меню с бортовым компьютером, на котором бы выводить подобные данные кучей.
1. kolyandex
  09.11.2020 04:36
  #22279022
  Сделать это можно, но стоит ли оно потраченных сотен часов?

esaulenka
08.11.2020 15:25
#22277168
Очень интересно, спасибо. Местами, правда, очень напоминает "теперь рисуем оставшуюся часть совы", но в любом случае большое спасибо.

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

Я просто чуть-чуть интересовался работой блоков управления двигателем — там контролька на контрольке, и, вроде как, сверху ещё и подписью прикрыто (на самых последних разработках).
1. kolyandex
  09.11.2020 04:40
  #22279026
  В приборках редко встречается кс, ее сверка идет только после обновления (CRC32 загруженного образа). В ЭБУ моторов проверка кс идет в процессе работы (в некоторых постоянно), ибо узел ответственный, и то, она бывает элементарной, что-то наподобие суммы всех байт.

iShrimp
11.11.2020 18:36
#22292584
Спасибо за разбор! Порой возникает ощущение, что качество разработки автоэлектроники отстаёт на 5-10 лет от современного уровня развития IT, а её безопасность в основном держится на проприетарных протоколах, по принципу security through obscurity.
1. kolyandex
  12.11.2020 18:21
  #22297102
  Потому что новую платформу начинают разрабатывать как раз за 5-10 лет до выхода первых моделей. Оттуда и отставание.

Идем по приборам +69

Постановка задачи

Поиск испытуемых

Основы диагностики

Инструментарий

Приборная панель Hyundai Solaris

Обзор

В поисках памяти

Загадка со змейкой

Приборная панель Ford Focus 3

Обзор

Первая попытка

Вторичный загрузчик

Модификация прошивки

Подмена битмапов

Приборная панель Mitsubishi Lancer X

Обзор

Не все коту масленица

Извлеченный урок

Заключение

Комментарии (29)

embeduin Автор

embeduin Автор

embeduin Автор

embeduin Автор

embeduin Автор