J2534 config app error reading version information

Альтернативный минимальный драйвер для mini-VCI J2534 (новая ветка?)
Причины написания данного текста — срабатывание VirusTotal на «стандартные» китайские драйвера для адаптера mini-VCI J2534.

1. Китайский бюджетный адаптер mini-VCI J2534 продается с ПО Toyota Techstream (в топку) и установщиком драйвера «MVCI Driver for TOYOTA.msi» (без которого «MMCodingWriter» не видит адаптера).

— При этом все установщики драйвера(ов) типа «MVCI Driver for TOYOTA.msi» (версий 1.4.8 — 2.0.1, которые есть в сети и на CD, и могут несколько отличаться друг от друга) вызывают подозрения: VirusTotal выдает 11 предостережений из 58.

— При запуске «MVCI Driver for TOYOTA.msi» (для WinXP SP3) драйвера (для USB-COM, устройство M-VCI, USB/VID_0403&PID_6001) устанавливаются, а в папке «c:Program Files» появляется папка «XHorse ElectronicsMVCI Driver for TOYOTA TIS» с драйвер для J2534 (которым виден из вкладки «Настройки» программы «MMCodingWriter» и успешно работает с ней).

— При этом в папке «c:Program FilesXHorse ElectronicsMVCI Driver for TOYOTA TIS» появляется файл
«MVCI32.DLL» для которого VirusTotal дает 15 предупреждений из 71.
В разных версиях установщика (1.4.8 — 2.0.1) идут такие файлы «MVCI32.DLL» с одним и тем же номером версии 1.0.0.1, но могут несколько отличаться содержимым. У меня VirusTotal ругался на все найденные в сети и на CD подобные файлы.

— Вопрос 1: на сколько опасен файл «MVCI32.DLL»? Были ли отмечены случаи какой-либо его зловредности?

2. Была сделана попытка найти альтернативные драйвера для J2534. Нашелся такой вариант:
«Drew Technologies, Inc. Mongoose MFC SAE-J2534 USB OBD-II Interface — driver id 1604517 — Download and install» (гугл в помощь, могу дать ссылку в личку). При этом предлагаются два файла:
«j2534toolbox.msi» (VirusTotal= 0/50) и «ISO_CAN_driver_disk_v01.02.10.zip» (VirusTotal= 0/42).

— Запуск установщика из архива «ISO_CAN_driver_disk_v01.02.10.zip» приводит к появлению драйвера «Mongoose ISO/CAN :: C:WINDOWSSYSTEM32MONGI432.DLL» (которым виден из вкладки «Настройки» программы «MMCodingWriter» но не работает с ней ?).

— Поиск альтернативных драйверов (не из китайских пакетов «MVCI Driver for TOYOTA») для устройства M-VCI, USB/VID_0403&PID_6001 привел к «FTDI FT4222H USB Serial Controller Drivers Version 2.12.18», установщик «ftdi_usb_2.12.18.exe» (VirusTotal 0/70). После установки в системе появляются файлы драйверов для данного устройства (чуть более новой версии по сравнению с аналогичными, появляющимися при установке драйверов данного системного устройства с помощью китайского установщика «MVCI Driver for TOYOTA»). Во всех случаях VirusTotal ничего подозрительного не находит.

— Вопрос 2: Возможна ли робота ПО «MMCodingWriter» с драйверами для системного устройства M-VCI, USB/VID_0403&PID_6001 (устанавливаемыми с помощью «ftdi_usb_2.12.18.exe») и с драйверами для контроллера J2534 (устанавливаемыми с помощью
«ISO_CAN_driver_disk_v01.02.10.zip» от Drew Technologies, Inc. Mongoose)? — Хотелось бы услышать ответ от разработчиков. Спасибо!

— Вопрос 3: Какой еще есть вариант (кроме заказного драйвера), на который не будет ругаться VirusTotal ?

P.S.
LOG попытки подключения «MMCodingWriter» к Outlander XL 2012 через адаптер mini-VCI J2534 с драйверами от FTDI и Mongoose:

18:29:10.1718750 Start… TO_FILE_ONLY
18:29:10.1718750 Start detect 2534 devices TO_FILE_ONLY
18:29:10.1718750 Found: Mongoose ISO/CAN :: C:WINDOWSSYSTEM32MONGI432.DLL TO_FILE_ONLY
18:29:10.1875000 Win XP found, skip OS and CPU detection TO_FILE_ONLY
18:29:10.1875000 ETACS: Start encoder TO_FILE_ONLY
18:29:10.1875000 ETACS: Encoder loaded TO_FILE_ONLY
18:29:10.2031250 Application loaded, current version is 0.0.1.9 TO_FILE_ONLY
18:29:13.5781250 TNDA TO_FILE_ONLY
18:29:15.5156250 Updater error: The remote name could not be resolved: ‘dev.kolyandex.su’ TO_FILE_ONLY
18:29:32.5781250 Connect pressed. TO_FILE_ONLY
18:29:32.7500000 Exchanger start… Connection type: J2534 TO_FILE_ONLY
18:29:32.8281250 Lib loaded: C:WINDOWSSYSTEM32MONGI432.DLL TO_FILE_ONLY
18:29:32.8281250 Name: Mongoose ISO/CAN TO_FILE_ONLY
18:29:32.8281250 Vendor: Drew Technologies Inc. TO_FILE_ONLY
18:29:32.8281250 PassThruOpen: ERR_DEVICE_NOT_CONNECTED TO_FILE_ONLY
18:29:32.8281250 Device not connected LOG_ERROR
18:29:32.8437500 Unable to start exchange session LOG_ERROR
18:29:42.4375000 Connect pressed. TO_FILE_ONLY
18:29:42.4375000 Exchanger start… Connection type: J2534 TO_FILE_ONLY
18:29:42.4375000 Lib loaded: C:WINDOWSSYSTEM32MONGI432.DLL TO_FILE_ONLY
18:29:42.4375000 Name: Mongoose ISO/CAN TO_FILE_ONLY
18:29:42.4375000 Vendor: Drew Technologies Inc. TO_FILE_ONLY
18:29:42.4375000 PassThruOpen: ERR_DEVICE_NOT_CONNECTED TO_FILE_ONLY
18:29:42.4375000 Device not connected LOG_ERROR
18:29:42.4375000 Unable to start exchange session LOG_ERROR
18:29:50.7187500 Connect pressed. TO_FILE_ONLY
1

P.P.S.
Если что не так делаю (правила и традиции форума?..) — подскажите.

Время прочтения
5 мин

Просмотры 16K

Давным-давно, когда деревья были большими и вариации комплектаций одной модели автомобиля можно было перечислить пальцами одной руки, был куплен диагностический адаптер, о котором сегодня пойдет речь. Творение неизвестного китайца получило название Mini-VCI J2534. Откуда он взялся доподлинно неизвестно, но позиционируется как интерфейс для работы с различными Тойотами, а так же как J2534 совместимый адаптер (спойлер — нет). В момент покупки его было достаточно для диагностики и ковыряния в мозгах автомобилей тех лет, но прогресс не стоит на месте и в нынешних реалиях он если так можно выразиться — «не вывозит». О том, можно ли с этим что-то сделать и пойдет речь ниже.

Итак, знакомьтесь — наш пациент снаружи и внутри:

Внутри него живет 16/32 bit ARM7TDMI-S™ CPU, пара CAN-контроллеров, 2 UART’а и еще кучка полезной и не очень периферии.

Суть проблемы

Если закрыть глаза на мелочи в виде почти полного несоответствия стандарту J2534, есть у него проблемы гораздо хуже, а именно невозможность отправлять данные по протоколу ISO-TP длиннее ~48 байт. С последним мириться было нельзя и в голове засела мысль, а что если получится сделать этот мир чуточку лучше.

Если кратко, как происходит передача данных длинной больше 8 байт по CAN-шине (длина сообщения CAN ограничена восемью байтами). Существует такой стандарт ISO15765, он же ISO-TP (Transport Protocol), который покрывает 2 модели OSI (сетевой и транспортный). Передача данных длиной более 7 байт выглядит так:

1. Источник отправляет First Frame (FF) с данными об общей длине передаваемых данных и первыми 6 байтами payload’а.

2. Приемник отвечает ему Flow Control фреймом, в котором говорит о минимальном допустимом времени между посылками CF (о них ниже) и количестве CF, после которого источник снова должен дождаться Flow Control фрейм.

3. Источник после приема Flow Control’а продолжает отправку данных фреймами Consecutive Frame (CF) с заданным интервалом о ожиданием следующего Flow Control (если об этом было сказано в пункте 2)

   https://en.wikipedia.org/wiki/ISO_15765-2

Что происходит на самом деле и почему ничего не работает нам поможет выяснить обычный анализатор CAN шины (Can Hacker/PEAK CAN и иже с ними). Итак, картина маслом — все смешалось, кони, люди. Приемник сказал жди от меня каждые 8 Consecutive Frame’ов Flow Control и шли мне каждый Consecutive Frame не менее чем через 10 мс, а шнурок мало того, что проигнорировал ожидание FC, так еще и на минимальную задержку между CF не обратил внимания.

Flow Control от приемника — 30 08 0A FFFFFFFFFF, где 08 — количество CF, после которого источник снова должен дождаться Flow Control фрейм, 0A — минимальное допустимое время между посылками CF.

Что мы имеем по факту — задержка около 1мс между CF, вместо желаемой 10мс и отсутствие ожидания Flow Control, что полностью ломает весь процесс передачи.

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

В шнурке используется преобразователь USB-UART FT232, который имеет некоторые проблемы при работе с USB 3.0. И проблемы эти — конские задержки, которые не настраиваются из драйвера, хотя на USB 2.0 все работает, но где вы сейчас найдете честный контроллер USB 2.0 в матери/ноутбуке. В общем, ручное форматирование тоже отпадает, задержки между CF не поддаются критике, работать это тоже не будет.

Остается крайняя мера — залезть внутрь и попробовать исправить кривой софт костылями, насколько это возможно. Не знаю как, но прямо по USB из контроллера можно вычитать и записать флеш память даже без разборки шнурка с помощью программы Flash Magic. После чтения загружаем прошивку в IDA, процессор ARM Little Endian архитектура ARMv4T. Немного помощи руками, создание недостающих регионов и прошивка готова к исследованию.

Функция с реализацией отправки данных по ISO-TP была найдена от обратного (CAN периферия — отправка — обертка — сама функция). Что же по исходникам — вот кусок кода с отправкой данных. То, о чем говорилось выше не предусмотрено вообще никак.

iso_tp_fc_received_ptr = &ctx->iso_tp_fc_received;
while (sended_len < send_len)
{
    if (ff_flag)
    {
        if (cf_counter >= 0xF)
            cf_counter = 0;
        else
            ++cf_counter;
        v21 = 8;
        tx_data.data[0] = cf_counter + 0x20; // Сборка Consecutive frames
        v23 = v21 - 1;
        if (send_len - sended_len < v21 - 1)
            v23 = send_len - sended_len;
        memcpy(&tx_data.data[1], &send_data_[sended_len], v23);
        can_tx_1(ctx, &tx_data);
        sended_len += v23;
    }
    else
    {
        tx_data.data[0] = 0x10;         // Сборка First frame
        tx_data.data[1] = send_len; // Больше 255 байт не предусмотрено, хотя по стандарту должно быть 4 с копейками кб, хотя о чем это я
        memcpy(&tx_data.data[2], send_data_, 6));
        cf_counter = 0;
        set0(iso_tp_fc_received_ptr);
        can_tx_1(ctx, &tx_data);
        if (!wait_fc(ctx, 700)) // Ждем flow control
            return 0;
        ff_flag = 1;
        sended_len += 6;
    }
}

Как видно, Flow Control шнурок ждет всего один раз, а дальше даже не пытается соответствовать ISO-TP. Как только он получит FC, сразу же без задержек начинает слать остатки данных в Consecutive Frame’ах. Ладно, но может он хотя бы обращает внимание на данные из Flow Control? Ха-ха. Нет. Вот функция обработки приема данных по ISO-TP, нас интересует только прием Flow Control.

header = rx_byte_0 & 0xF0;
if (can_rx_ctx->rx_can_data[0] & 0xF0)
{
    switch (header)
    {    
        //Тут были обработчики других заголовков, но они нам не нужны
    case 0x30: //Flow control
        set_1(&iso_tp_ctx->iso_tp_fc_received);
        result = 0;
        break;    
    }
}

Как видим, просто выставляется флажок, что был принят какой-то flow control, а что там в нем нам не важно (мысли китайца).

Что же делать?

Дешево и сердито — засунуть простую задержку между отправкой Consecutive Frame’ов, чтобы приемник успевал отправить свой Flow Control там, где нужно и получил следующий CF уже после. Все что нам нужно, это найти место, в цикле с отправкой, куда можно засунуть переход в функцию с задержкой, благо мест таких полно, а замененные инструкции можно выполнить в новой функции, так что мы ничего не потеряем. Берем IAR, в нем есть поддержка именно такого процессора, чистый проект на ассемблере и пишем элементарный цикл

_my_func
        STMFD   SP!, {R10-R12,LR}
        LDR R10, =39062          ; ~7800 на 1 мс
        B compare
sub:
        SUB     R10, R10, #1
compare:        
        CMP     R10, #0
        BGT sub
        
        MOV     R0, R4          ; та самая замененная инструкция на переход
        LDMFD   SP!, {R10-R12,PC}

Конечный результат выглядит так — слева то, что было, справа то, что стало. Инструкция MOV R0, R4 перенесена.

Прошиваем и наслаждаемся прекрасной работой без сбоев.

Конечно, можно было сделать все по фен шую, и правильную обработку Flow Control фрейма, и честные задержки по желанию приемника, и ожидание остальных Flow Control’ов. Но результат в любом случае достигнут и терять время больше чем один вечер на такое желания нет.

Еще интересный момент — контроллер судя по всему китайский перемарк, т.к. определился программой по внутреннему ID как LPC2114, в котором, на минуточку, вообще нет CAN контроллера, если верить даташиту. Видишь CAN? И я не вижу, а он есть. Вот так вот.

Кому интересны прошивка и база IDA, то вот. Пароль habr.com

Background

Vehicles become more and more complex and almost every function is controlled by an Electronic Control Unit (ECU). The ECUs are often connected onto a communication bus to be able to share data between each other. The most common protocol is CAN, but there are other protocols. There are many Vehicle manufactures and almost as many different communication protocols. Every vehicle manufacturer has a tool for analyzing and reprogramming their product, and this tool is often expensive. This makes it difficult for a car, bus or truck workshop to analyze and repair all kind of vehicles.

U.S. Environmental Protection Agency (EPA) and the California Air Resources Board (ARB) have been trying to get vehicle manufactures to support common emission-related services for the aftermarket. The Society of Automotive Engineers (SAE) created the J2534 standard, in 2002, to promote the EPA and ARB in their work.

Hardware Requirements

The J2534 hardware works like a gateway between the vehicle ECU and the PC. This pass-thru device translates messages sent from the PC into messages of the protocol being used in the vehicle ECU. J2534 supports the following protocols:

• ISO9141
• ISO14230 (KWP2000)
• J1850
• CAN (ISO11898)
• ISO15765
• SAE J2610
• J1939 (since 2005)

The connection between the PC and the J2534 hardware can freely chosen by the manufacturer of the device i.e. RS-232, USB or maybe a wireless interface. The vehicle manufacturers programming application is not dependant on the hardware connection. Therefore any device can be used for programming any vehicle regardless of the manufacturer.

The connection between the J2534 hardware and the vehicle should be the SAE J1962 connector (Fig 2), also called the OBDII connector. The maximum length of the cable between the J2534 device and the vehicle is 5 meters. If the vehicle manufacturer doesn’t use the J1962 connector, necessary information for connection has to be provided.

Figure 2. J1962-male connector (to the left) and J1962-female connector (to the right).

The J2534 hardware interface should be able to provide a supply voltage between 5 and 20 volts to the J1962 connector. The power supply should use one of the pins 6, 9, 11, 12, 13 or 14 of the connector and this choice should be selectable in the software. The maximum source current is 200mA and the settling time should be within 1ms.

The J2534 hardware interface should have enough memory to buffer 4Kb of transmit messages and 4Kb of received messages. And the processor must naturally be fast enough to process all messages so that no messages are lost.

Software Requirements

Programming of an emission related ECU using J2534 is done from a PC, preferably a laptop computer, with a Win32 operating system (Windows 95 or later).

Each vehicle manufacturer will have an own API software used for analyzing and programming of their vehicles. If their vehicles only use i.e. ISO 9141, no other protocols have to be supported by the application. It is important that this application conform to the functions in the J2534 API.

This application will have complete information of the ECUs that are supported by the application. This application also includes a user interface where choices can be made depending on the ECU and what action to perform.

A vehicle repair workshop that wants to analyze and re-program vehicles from different manufactures must have an API for each. This API can be downloaded from the internet or installed from a CD or DVD. How this API is provided depend on the manufacturer, but they do charge the customer (repair workshop) ordering it. The price differs a lot between manufacturers, a one year subscription costs between $75 and $2500.

Each manufacturer of a J2534 tool (hardware device) must have a DLL-file which includes functions and routines for communicating with the PC. The DLL-file is then loaded into the vehicle manufacturer’s application. The functions in the J2534 tool are linked to a corresponding function in the application. The DLL-file also includes routines for the connection (RS-232, USB etc.) between the J2534 tool and the PC.

The intention is that every J2534 tool should to be capable of communicating with all protocols supported by the J2534 standard. The application provided by the vehicle manufacturers use commands described in J2534 standard to connect to a hardware tool (of any brand). The connection and initialization gives the hardware tool information of which protocol that is used. Thereafter it is up to the hardware tool to manage the connection to the vehicle with de desired protocol. The PC application will send messages in the earlier determined protocol format to the hardware tool which buffers the messages and transmits the messages in the order they were received.

J2534 Application Programming Interface (API)

The J2534 API consists of a number of functions for communication which must be supported by both hardware tool and vehicle manufacturer application. For the PC application developer this means that all commands and messages must made with the functions defined in the API. See table 1 below.

Table 1. J2534 function description.

The first command that is sent is the PassThruConnect which establish the connection between the PC application and the J2534 hardware tool. This command includes information about which protocol to use, standard or extended CAN identifier or if ISO15765 is used. The command also includes a channel identification which will be used for all following communication. If the connection was successful, a STATUS_NOERROR value is returned, which indicates that the function has been successfully performed. Before any messages can be sent an initialization has to be made, PassThruIoctl, where parameters like node address, baud rate or protocol specific parameters are set.

All messages sent from the PC application follow the same structure which consists of: protocol type (i.e. J1850, CAN, J9141), receive message status, transmit message flags, received message timestamp (microseconds), data size in bytes, extra data index (start position of extra data in received message i.e. IFR, CRC, checksum), and last but not least an array of data bytes (the received message). It is possible to send CAN messages longer than 8 bytes using ISO15765 commands if this feature was selected upon connection.

Some ECUs sends a lot of messages with short period of time between each message. The filter function, PassThruStartMsgFilter, can be set to either block or pass messages. This will decrease the messages needed to be sent between the hardware tool and the PC. The message is first “ANDed” with a mask which gives the opportunity to compare only some important bits of the identifier. Thereafter the “ANDed” message is compared to a specific pattern.

J2534 API DLL

The J2534 API DLL provides a linkage between the API functions and the hardware tool. Since the PC application should not have to care about which communication protocol is being used between the PC and the hardware tool. Each manufacturer of a hardware tool has a DLL-file with a unique name. This way it is possible for the software application on the PC to distinguish which hardware tool to connect. It is important that the developer of the firmware in the hardware tool follows the API and name the functions exactly as in the J2534 description. Otherwise it will be impossible for the PC application to find the functions in the DLL when performing the linkage.