[Из песочницы] Реверс-инжениринг протокола китайского USB ИК трансивера

Попался мне китайский MicroUSB ИК трансивер, и возникло желание подключить его к компу с Windows. Трансивер представляет собой весьма компактный девайс с разъемом Micro USB. Единственный «официальный» вариант работы с ним — через Android приложение под названием ZaZaRemote.

При подключении к компу через переходник девайс определился как HID-совместимое устройство USB\VID_10C4&PID_8468. Гугление по этому ID не дало никаких результатов, и пришлось заняться реверсингом протокола.

Неправильный HID

Класс девайса определялся как USB\Class_03&SubClass_FF&Prot_FF. Class_03 — HID устройство, SubClass_FF — vendor specific. Системой был автоматически установлен драйвер hidusb.sys. С этим драйвером можно работать посредством HID API.

Набросав простенькую программку, я смог получить различную инфу по девайсу:

HidD_GetManufacturerString: "Tiqiaa"HidD_GetProductString: "Tview" HidP_GetCaps: Usage 1 UsagePage ff00 InputReportByteLength 61 OutputReportByteLength 61 FeatureReportByteLength 0 NumberLinkCollectionNodes 1 NumberInputButtonCaps 0 NumberInputValueCaps 2 NumberInputDataIndices 2 NumberOutputButtonCaps 0 NumberOutputValueCaps 2 NumberOutputDataIndices 2 NumberFeatureButtonCaps 0 NumberFeatureValueCaps 0 NumberFeatureDataIndices 0

Получается что обмен ведется блоками по 61 байту максимум, имеется 2 InputValue и 2 OutputValue интерфейса. Более подробную информацию по ним возвращает функция HidP_GetValueCaps:

HidP_GetValueCaps(HidP_Input): UsagePage ff00 ReportID fe LinkUsage 1 LinkUsagePage ff00 BitSize 8 ReportCount 8 UsagePage ff00 ReportID 1 LinkUsage 1 LinkUsagePage ff00 BitSize 8 ReportCount 60 HidP_GetValueCaps(HidP_Output): UsagePage ff00 ReportID fd LinkUsage 1 LinkUsagePage ff00 BitSize 8 ReportCount 8 UsagePage ff00 ReportID 2 LinkUsage 1 LinkUsagePage ff00 BitSize 8 ReportCount 60

Из этих данных наиболее интересными являются ReportID — ID report-а (фактически, пакета данных) и ReportCount — его размер. Данные можно отправлять и принимать с помощью функций HidD_SetOutputReport и HidD_GetInputReport соответственно. Поэкспериментировав с этими функциями, с разными ReportID и размером данных, я так и не смог добиться успешного обмена. Поснифав трафик по USB с помощью USBPcap, я обнаружил что данные даже не пытались передаваться. Появилось подозрение что это какой-то неправильный HID.

SET_REPORT Request остался без ответа

Реверсинг приложения ZaZaRemote

В APK файле этого приложения я обнаружил библиотеку libtiqiaa_dev_usb.so. Она экспортирует следующие функции:

Java_com_icontrol_dev_TiqiaaUsbController_usbOpenJava_com_icontrol_dev_TiqiaaUsbController_usbCloseJava_com_icontrol_dev_TiqiaaUsbController_usbSendCmdJava_com_icontrol_dev_TiqiaaUsbController_usbSendIRJava_com_icontrol_dev_TiqiaaUsbController_d

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

LDR R3, [R0]LDR R3, [R3,#0x18]BLX R3

Регистр R0 — первый аргумент этой функции. Эти функции вызываются только из Java кода classes.dex. Декомпилировав этот файл, получаем их тип:

private native boolean usbOpen(Context context);private native void usbClose();private native boolean usbSendCmd(UsbDeviceConnection usbdeviceconnection, UsbEndpoint usbendpoint, int j, int k);private native boolean usbSendIR(Context context, UsbDeviceConnection usbdeviceconnection, UsbEndpoint usbendpoint, int j, byte abyte0[], int k);private native IControlIRData d(byte abyte0[]);

Java код оказался обфусцирован, однако некоторые имена все же сохранились. Применительно к этой библиотеке, обфускатор испортил только имя последней функции, однако имена в основном Java коде были испорчены почти все.

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

com.tiqiaa.icontrol.e.i.a("DeviceHolder", (new StringBuilder("send......cmdType=")).append(i1).append(",cmdId=").append(j1).toString());boolean flag1 = a.b(i1, j1); com.tiqiaa.icontrol.e.i.d("DeviceHolder", (new StringBuilder("send....................freq=")).append(i1).append(",cmdId=").append(j1).append(",buffer.length=").append(abyte0.length).append(" , device = ").append(a).toString());boolean flag1 = a.a(i1, abyte0, j1);

Дебаг логи — хороший друг реверс-инженера.

Для вызова нативных методов из Java кода используется механизм Java Native Interface. Экспортируемая функция должна иметь вид:

extern "C" JNIEXPORT void JNICALL Java_ClassName_MethodName(JNIEnv *env, jobject obj, <java arguments>)

Теперь можно задать тип функций в IDA:

bool __cdecl Java_com_icontrol_dev_TiqiaaUsbController_usbOpen(JNIEnv *env, jobject obj, struct Context *context);void __cdecl Java_com_icontrol_dev_TiqiaaUsbController_usbClose(JNIEnv *env, jobject obj);bool __cdecl Java_com_icontrol_dev_TiqiaaUsbController_usbSendCmd(JNIEnv *env, jobject obj, struct UsbDeviceConnection *usbdeviceconnection, struct UsbEndpoint *usbendpoint, int cmdType, int cmdId);bool __cdecl Java_com_icontrol_dev_TiqiaaUsbController_usbSendIR(JNIEnv *env, jobject obj, struct Context *context, struct UsbDeviceConnection *usbdeviceconnection, struct UsbEndpoint *usbendpoint, int freq, jbyte buffer, int cmdId);struct IControlIRData *__cdecl Java_com_icontrol_dev_TiqiaaUsbController_d(JNIEnv *env, jobject obj, jbyteArray buffer);

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

v5 = ((int (*)(void))(*env)->FindClass)();

bool __cdecl Java_com_icontrol_dev_TiqiaaUsbController_usbSendCmd(JNIEnv *env, jobject obj, struct UsbDeviceConnection *usbdeviceconnection, struct UsbEndpoint *usbendpoint, int cmdType, int cmdId){ char v6; // r5@5 bool result; // r0@12 char data[24]; // [sp+8h] [bp-18h]@12 dword_B57C = 0; if ( UsbEndpoint_bulkTransfer ) { if ( usbdeviceconnection ) { if ( usbendpoint ) { switch ( cmdType ) { case 0: v6 = 'L'; goto LABEL_12; case 2: v6 = 'R'; goto LABEL_12; case 3: v6 = 'H'; goto LABEL_12; case 4: v6 = 'O'; goto LABEL_12; case 6: v6 = 'C'; goto LABEL_12; case 7: v6 = 'V'; goto LABEL_12; case 1: v6 = 'S';LABEL_12: data[0] = 'S'; data[1] = 'T'; data[3] = v6; data[2] = cmdId; data[4] = 'E'; data[5] = 'N'; result = sub_3528(env, usbdeviceconnection, usbendpoint, data, 6); break; default: result = 0; break; } } else { result = 0; } } else { result = 0; } } else { result = UsbEndpoint_bulkTransfer; } return result;}

Код элементарный, формат сообщений очевиден: начинается с сигнатуры «ST», далее идет байт типа команды — один из символов {'L', 'R', 'H', 'O', 'C', 'V', 'S'}, далее байт cmdId (просто инкрементальный идентификатор чтобы сопоставить команду и ответ на нее) и заканчивается все сигнатурой «EN». Сформированное сообщение отправляется функцией sub_3528.

int __cdecl sub_3528(JNIEnv *env, struct UsbDeviceConnection *usbdeviceconnection, struct UsbEndpoint *usbendpoint, void *data, int size){ JNIEnv v5; // r1@1 JNIEnv *v6; // r4@1 int result; // r0@2 int v8; // r2@3 int tsize; // r7@5 size_t fragmSize; // r5@9 int v11; // r0@11 JNIEnv v12; // r3@11 int v13; // r6@11 int rdOffs; // [sp+10h] [bp-80h]@7 int v15; // [sp+14h] [bp-7Ch]@15 int jbyteArray; // [sp+18h] [bp-78h]@1 int fragmCnt; // [sp+1Ch] [bp-74h]@7 char *_data; // [sp+28h] [bp-68h]@1 char buf[64]; // [sp+34h] [bp-5Ch]@7 int _stack_chk_guard; // [sp+74h] [bp-1Ch]@1 _data = (char *)data; v5 = *env; v6 = env; _stack_chk_guard = ::_stack_chk_guard; jbyteArray = ((int (*)(void))v5->NewByteArray)(); if ( jbyteArray ) { v8 = UsbPackCounter + 1; if ( UsbPackCounter + 1 > 15 ) v8 = 1; tsize = size; UsbPackCounter = v8; if ( size > 1024 ) tsize = 1024; j_j_memset(buf, 0, 0x40u); buf[0] = 2; buf[3] = (tsize / 56 & 0x7F) + ((((tsize + -56 * (tsize / 56 & 0x7F)) >> 31) - (tsize + -56 * (tsize / 56 & 0x7Fu))) >> 31); rdOffs = 0; fragmCnt = 0; buf[2] = UsbPackCounter; while ( 1 ) { if ( rdOffs >= tsize ) goto LABEL_25; fragmCnt = (fragmCnt + 1) & 0xFF; fragmSize = tsize - rdOffs; if ( tsize - rdOffs > 56 ) fragmSize = 56; buf[1] = fragmSize + 3; buf[4] = fragmCnt; j_j_memcpy(&buf[5], &_data[rdOffs], fragmSize); ((void (__fastcall *)(JNIEnv *, int, _DWORD, signed int))(*v6)->SetByteArrayRegion)(v6, jbyteArray, 0, 61); v11 = ((int (__fastcall *)(JNIEnv *))(*v6)->ExceptionCheck)(v6); v12 = *v6; v13 = v11; if ( v11 ) { ((void (__fastcall *)(JNIEnv *))v12->ExceptionClear)(v6); v13 = 0; goto return_r6_del; } if ( !dword_B2A4 ) {LABEL_25: v13 = 1; goto return_r6_del; } v15 = ((int (__fastcall *)(JNIEnv *))v12->CallIntMethod)(v6); if ( ((int (__fastcall *)(JNIEnv *))(*v6)->ExceptionCheck)(v6) ) { ((void (__fastcall *)(JNIEnv *))(*v6)->ExceptionClear)(v6); goto return_r6_del; } if ( v15 < 0 ) break; rdOffs += fragmSize; } v13 = 0;return_r6_del: ((void (__fastcall *)(JNIEnv *, int))(*v6)->DeleteLocalRef)(v6, jbyteArray); result = v13; } else { ((void (__fastcall *)(JNIEnv *))(*v6)->ExceptionClear)(v6); result = 0; } if ( _stack_chk_guard != ::_stack_chk_guard ) j_j___stack_chk_fail(result); return result;}

Эта функция немного посложнее. Видно, что максимальная длинна отправляемого сообщения ограничивается 1024 байтами. Сообщение делится на фрагменты. Фрагмент состоит из 5 байт заголовка и максимум 56 байт данных — в сумме 61 байт. Структура заголовка:
Сформированные фрагменты отправляются через вызов CallIntMethod. Он имеет следующий тип:

jint (JNICALL *CallIntMethod)(JNIEnv *env, jobject obj, jmethodID methodID, ...);

Видно, что HexRays на этот раз не справился — в аргументах только v6 = JNIEnv *env. Однако в ассемблерном коде все на месте:

LDR R2, [R2,#(dword_B2A4 - 0xB284)] ; jmethodID methodID

methodID хранится в переменной dword_B2A4. Посмотрим откуда он взялся:

Запись производится в функции usbOpen и usbClose. Очевидно, нас интересует usbOpen.

Нужный фрагмент:

v27 = ((int (__fastcall *)(JNIEnv *, int, const char *, const char *))(*v4)->GetMethodID)( v4, v26, "bulkTransfer", "(Landroid/hardware/usb/UsbEndpoint;[BII)I");dword_B2A4 = v27;

Итак, это метод UsbEndpoint::bulkTransfer. И ничего — связанного с HID!

Теперь рассмотрим как передаются ИК коды — функция usbSendIR.

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

 buf[0] = 'S'; buf[1] = 'T'; buf[2] = cmdId; buf[3] = 'D'; if ( freq > 255 ) { LOBYTE(v36) = 0; v37 = -1; v38 = 0; while ( 1 ) { v39 = (freq - IrFreqTable[v38] + ((freq - IrFreqTable[v38]) >> 31)) ^ ((freq - IrFreqTable[v38]) >> 31); if ( v37 != -1 && v39 >= v37 ) { v39 = v37; } else { LOBYTE(v36) = v38; if ( !v39 ) break; } if ( ++v38 == 30 ) break; v37 = v39; } } else { v36 = (unsigned int)(freq - 1) <= 0x1C ? freq : 0; } buf[4] = v36; v40 = &buf[v22]; v40[5] = 'E'; v40[6] = 'N';

Как и в случае с остальными командами, начинается все с «ST», затем следуют cmdId и код команды 'D', далее байт, определяющий частоту — если аргумент freq > 255 — он ищется в таблице частот IrFreqTable, иначе — копируется напрямую. Затем идут данные и завершается все на «EN».

Функция с обфусцированным именем «d» оказалась парсером принятых данных.

Смена драйвера и работа через bulkTransfer

Изучив HID API я выяснил, что оно в принципе не предоставляет возможности использовать bulkTransfer — значит придется менять драйвер. Для работы с этим устройством подходит драйвер WinUsb.
Написав inf файл, я сменил драйвер на WinUsb и попробовал отправлять команды. Все заработало и был получена реакция от девайса — в ответ на отправку команд (через WinUsb_WritePipe) приходил ответ аналогичного формата.

Дамп обмена с ZaZaRemote

Несмотря на предыдущие успехи, я пока что так и не смог добиться главного — заставить девайс передавать ИК команды. Приложение было слишком большим и запутанным и захотелось просто сдампить USB трафик. Однако как это сделать в случае Android-приложения? Вход был найден в виде Android-x86 на VirtualBox-e. Несмотря на то, что x86 ни разу не ARM, он тем не менее позволяет запускать нативные ARM бинарники через механизм NativeBridge. Установив и настроив необходимое ПО я смог заставить работать это приложение в VirtualBox.

Запрошенные разрешения определенно вызывают доверие к этой софтине

Запустив приложение и настроив проброс USB я смог заснифать USB трафик. Так я получил последовательность команд для инициализации приема и передачи ИК команд, а также образцы данных ИК посылок.

Выяснилось что девайс способен не только передавать, но и принимать ИК команды, однако прием работал весьма так себе — с расстояния 10 см, и то через раз.

Выяснилось, что у девайса проблемы с размером данных для отправки — помимо ответа сыплется всякий мусор — как правило то, что осталось от предыдущей посылки.

Изучение дампа и последующие эксперименты позволили узнать функции всех команд:

• 'V' — Version — запрос версии — мой девайс выдает нулевой GUID;
• 'L' — IdleMode — режим ожидания — в этом режиме девайс находится после подачи питания, либо переходит по этой команде;
• 'S' — SendMode — режим передачи — используется для посылки ИК сигналов;
• 'R' — RecvMode — режим приема — используется для приема ИК сигналов;
• 'D' — Data — в режиме передачи — данные для передачи, в режиме приема — данные захваченной ИК посылки;
• 'O' — Output — в режиме передачи — подтверждение передачи, в режиме приема — запрос на захват/выдачу данных;
• 'C' — Cancel — в режиме приема — отмена приема, ранее запрошенного по 'O';
• 'H' — Unknown — ответ на неизвестную команду.

Исследование формата ИК посылок

Получив дамп управляющих команд и ИК посылок я смог реализовать полноценное управление девайсом — прием и передачу ИК сигнала. Однако для того, чтобы синтезировать произвольный ИК сигнал необходимо было определить формат, в котором он кодируется. Для этого я подключил ИК фотоприемник к осциллографу и стал исследовать посылаемые сигналы. Путем экспериментов я выяснил формат кодирования: старший бит каждого байта определяет включен или нет передатчик, а младшие 7 бит — время. Единица времени оказалась равна 16 мксек. Например: 8A — передатчик включен на 160 мксек; 8A 05 FF 83 — 160 мксек включен, пауза 80 мксек, 20.8 мсек включен.

Когда передатчик включен, светодиод пульсирует с частотой ~36.64 кГц. Теоретически, эта частота должна определяться аргументом freq команды usbSendIR, однако эксперименты показали что девайс абсолютно никак не реагирует на этот аргумент. Тем не менее, имеющаяся у меня бытовая техника нормально принимала сигналы этого трансивера.
Формат данных, записываемых девайсом в режиме приема, оказался аналогичным.

Класс TiqiaaUsbIr и программа IR Control

Я реализовал управление трансивером в виде C++ класса TiqiaaUsbIr и написал простенькую программу CaptureIR на QT. Помимо функций приема и передачи ИК сигналов я реализовал синтезирование и декодирование сигналов по протоколу NEC. Этот протокол используется например в пультах телевизоров LG. Также я реализовал сохранение и загрузку ИК сигналов в исходном формате и формате LIRC. Была идея сделать модуль для WinLirc, однако там оказалось кривоватое и не до конца реализованное API, так что эту идею я пока отложил.

Исходники и скомпилированную программу можно скачать тут.

Пример использования класса TiqiaaUsbIr:

std::vector<std::string> IrDev;TiqiaaUsbIr::EnumDevices(IrDev); //Получаем список устройствTiqiaaUsbIr Ir;Ir.Open(IrDev[0].c_str()); //Открываем первое устройствоIr.SendNecSignal(0x0408); //Посылаем ИК код (LG POWER)Ir.Close();

Захваченный сигнал включения питания:

Он же, синтезированный:

В процессе захвата что-то пошло не так:

Итоги

В процессе исследований был полностью восстановлен USB протокол ИК трансивера Tiqiaa Tview, написан inf файл драйвера и ПО для работы с ним.

Рассмотренный ИК трансивер — весьма дешевый, доступный и компактный (5$ на Али, габариты 15 x 10 x 5 мм) девайс для управления бытовой техникой и исследования ее ИК протоколов. К сожалению, управление частотой передатчика оказалось неработоспособным, что в моем случае не вызвало проблем, однако возможно что существует техника с более привередливыми приемниками.

Режим приема, в следствии мизерного радиуса и низкой надежности захвата, непригоден для использования в качестве полноценного ИК приемника — рекорд дальности успешного захвата ~30 см, при этом пульт нацелен точно на приемник, и даже в упор нормально захватываются далеко не все посланные сигналы. Тем не менее, он полезен для захвата сигналов и исследования протоколов ИК пультов.

Бонус

Интересные IR коды телевизоров LG:

POWER 0408
POWERON 04C4
POWEROFF 04C5
IN_STOP 04FA
IN_START 04FB
POWERONLY 04FE
EZ_ADJUST 04FF

P.S. Ищу информацию про LG AccessUSB, подробнее тут.