Реверс-инжениринг протокола китайского 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_usbOpen
Java_com_icontrol_dev_TiqiaaUsbController_usbClose
Java_com_icontrol_dev_TiqiaaUsbController_usbSendCmd
Java_com_icontrol_dev_TiqiaaUsbController_usbSendIR
Java_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)();

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


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

• buf[0] = 2 — константа. Помните ReportID 2? Похоже что это оно и есть. А ReportCount 60 — это размер оставшихся данных — тоже совпадает.
• buf[1] = fragmSize + 3 — размер данных фрагмента + 3, т.е. размер считается от байта, следующего за этой переменной.
• buf[2] = UsbPackCounter — просто счетчик, 1..15.
• Значение buf[3], вычисляемое навороченным выражением, это просто число фрагментов, можно переписать как:
  
  

  buf[3] = tsize / 56;
  if (tsize % 56) buf[3]++;

• buf[4] = fragmCnt — номер фрагмента, 1..buf[3].

Сформированные фрагменты отправляются через вызов 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.

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


Как и в случае с остальными командами, начинается все с «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, подробнее тут.