KatWalk C2: ч.4: поиграемся с прошивкой

Для тех, кто только подключился — я рассказываю про платформу для VR игр, как с ней интегрироваться и как добраться до ее сенсоров напрямую.

Я уже заметил некоторые глюки и проблемы с сенсорами — значит, неплохо было бы их поправить. Но чтобы их поправить, надо понять что они за зверь, и можно ли их как-то поменять. Из-за огромного размера статьи, пришлось разделить и без того маленький рефератик на еще более маленькие кусочки — поэтому сегодня мы просто заглянем внутрь сенсора и научимся менять ему прошивку в простом и удобном виде.

Вскрытие покажет

Изучение чего либо обычно представляет собой хаотичный процесс с заходами с разных сторон, так называемый «метод научного тыка». Никогда заранее не скажешь, где идеальный путь, пока не посмотришь на итог процесса на ретроспективе. Поэтому не следует воспринимать данный опус как руководство к действию, скорее как небольшой обзор на что можно смотреть, да где искать крупицы полезностей. Как правило, всё множество путей помогают друг другу и в конце концов приводят к пониманию.

Но что точно хорошо почти всегда (когда есть возможность) — это заглядывание внутрь. Если мы заглянем внутрь сенсора для ног, мы сходу заметим большой модуль, подписанный HY-40R201C. Это BLE5.0 модуль, основанный на TI CC2640R2. То есть это процессор (точнее, два) плюс радиомодуль. Может быть использован как сам по себе, загружая свою прошивку в него, так и в тандеме с внешним процессором.

Других процессоров на плате не видно, на обратной стороне ничего, кроме модуля оптической мыши A9800 не обнаружено.

Вывод: модуль используется напрямую как логический процессор. На плате присутствуют два порта для батарей, но подключена только одна. Есть кнопки Reset и Boot. Теперь мы всегда можем открыть даташит, чтобы понять где какие порты и адреса железа лежат, да знаем что это ARM Cortex M3 с ПЗУ на 128кб, рам на 8кб. Не очень много, но явно хватает.

В отличие от Nordic модуля, которым я воспользовался, поддержка USB напрямую отсутствует. Зато на плате виден CH9326, который совпадает по названию с лежащей в папке гейтвея DLLке.

Таким образом, мы либо узнали, либо подтвердили, что сенсоры общаются через USB-HID конвертер-чип, работают на ARM, и основаны на Texas Instruments SIMPLELINK-CC2640R2-SDK. К SDK еще идёт «Academy», в котором в сжатой форме можно почтитать про BLE, как его готовить внутри СДК, да немного рассмотрено примеров. В любом случае, так как девкита нет, на самом сенсоре поиграться сходу не получится, в остальном придётся пользоваться полнотекстовым поиском внутри установленного SDK.

Что в ROMушке тебе моём

Внешний осмотр это хорошо, но понять, что внутри, просто осмотром не получится. На плате есть пятачки подписанные «V R C M G», где G явно Ground, всё остальное — вопрос. Можно прозвонить, конечно, но… JTAG у меня всё равно нет.

Тут, к счастью, можно вспомнить, что гейтвей умеет прошивать сенсоры. Я когда первый раз их подключал, он мне говорил, что прошивка старая, и надо залить новую. И залил. Вывод — прошивка гейтвею доступна. Обзор глазами файлов в папке гейтвея:

C:\>dir /b /d "C:\Program Files (x86)\KAT Gateway\*bin" loco_ankle_by_embeded.bin loco_receiver_by_embeded.bin loco_sensor_group_application_foot_release_by_embeded_engineer.bin loco_sensor_group_application_waist_release_by_embeded_engineer.bin loco_s_ankle_by_embeded.bin loco_s_foot_by_embeded.bin loco_s_receiver_by_embeded.bin loco_s_waist_by_embeded.bin loco_waist_by_embeded.bin walk_c_foot_by_embeded.bin walk_c_hall_by_embeded.bin walk_c_receiver_by_embeded.bin walk_c_v2_foot_by_embeded.bin walk_c_v2_hall_by_embeded.bin walk_c_v2_receiver_by_embeded.bin

Прикольно, а где C2?!

C:\>dir /b /d "C:\Program Files (x86)\KAT Gateway\*hex" katvr_direction.hex katvr_foot.hex katvr_receiver.hex

Хм. Грузим dotPeek опять, Ctrl+Alt+T, «.hex»… Ха!

    byte index = 0;      int num1 = (int) KatvrFirmwareHelper.ch9326_find();     assert(num1 != 0)      int num2 = (int) KatvrFirmwareHelper.ch9326_open(Update_Firmware_Upgrading_Form.vid, Update_Firmware_Upgrading_Form.pid);     assert(num2 != 0)      int num21 = KatvrFirmwareHelper.ch9326_set_gpio(index, (byte) 15, (byte) 15)     assert(num21 != 0)      int num3 = (int) KatvrFirmwareHelper.ch9326_connected(index);     assert(num3 != 0)      int num4 = (int) KatvrFirmwareHelper.flash(_hex_path, device_type, device_state);     assert(num4 == 1)      KatvrFirmwareHelper.ch9326_ClearThreadData();     KatvrFirmwareHelper.close_ch9326();      /* Write MACs of sensors into receiver if we updated receiver */     if (Update_Firmware_Upgrading_Form.deviceType == C2FirmwareUpdaeManager.C2DeviceType.Receiver) {         KATSDKInterfaceHelper.WriteSensorPair(...)     }

Прекрасно, то есть для прошивки нам потребуется пара вызовов из KatvrFirmwareHelper и гекс прошивки. Но в дизасм как правило надо грузить BIN, а не HEX. Впрочем, это решается множеством способов. Я просто запустил WSL:

$ cd /mnt/c/Program\ Files\ \(x86\)/KAT\ Gateway/ $ for k in foot direction receiver; do objcopy --input-target=ihex --output-target=binary katvr_$k.hex katvr_$k.bin; done $ ls -la kat*bin -rwxrwxrwx 1 datacompboy datacompboy 131072 Mar 29 21:46 katvr_direction.bin -rwxrwxrwx 1 datacompboy datacompboy 131072 Mar 29 21:46 katvr_foot.bin -rwxrwxrwx 1 datacompboy datacompboy 131072 Mar 29 21:46 katvr_receiver.bin

Обращаем внимание, что все файлы ровно 128кБ, при этом hex разных размеров, значит, прошивка из нескольких секций, и, вероятно, части в ней отсутствуют или использованы для настроек, или еще что. Просто учтём на будущее.

Кстати, если мы еще не вскрывали сенсор, и не знаем что за процессор, можно попробовать потыкать в бинарничек через binwalk:

$ binwalk --disasm ./katvr_direction.bin   DECIMAL       HEXADECIMAL     DESCRIPTION -------------------------------------------------------------------------------- 0             0x0             ARM executable code, 16-bit (Thumb), little endian, at least 1624 valid instructions

или cpu_rec:

$ python cpu_rec.py ./katvr_direction.bin  ./katvr_direction.bin       full(0x20000)  None        chunk(0x10000;32)   ARMhf

Где мы убеждаемся, что да, это ARM и в основном в Thumb режиме.

Потыкав дополнительно через strings:

$ strings -n 10 katvr_direction.bin inputNormal FinputGyroRv executable N]_]>CNUW]>@FUm `(i0a(}0uh}pu [USQOMKIFCA?<:8 p>"`hBp!`h k +# p(F#p !i"hQ\)pch!i pGpGpGpGpG {unknown-instance-name} {empty-instance-name} F{static-instance-name}

Заливка прошивки на ходу

Разглядывание документации на Serial Boot Loader показывает, что бутлоадер просто готов принимать прошивку если в него перезагрузиться, 0x55 синхронизует скорость, в общем, всё как всегда. Мы, впрочем, не можем пользоваться родным прошивальщиком, так как у нас нет последовательного интерфейса — у нас есть HID2Serial, так что прошивка должна идти через него. Но, как мы уже выше выяснили, функции прошивки экспортированы наружу, так что можно просто попробовать вызвать их.

Создадим простой C# проект, куда импортируем KatvrFirmwareHelper и katvr_firmware.dll на которую он ссылается:

    static void Main(string[] args)     {         uint vid = 0xC4F4u;         byte device_state = 0;         byte index = 0;         uint pid = 28471u;         byte device_type = 3;         string hex_path = "C:\\Program Files (x86)\\KAT Gateway\\katvr_foot.hex";          if (KatvrFirmwareHelper.ch9326_find() == 0)         {             Console.WriteLine("ch9326_find failed");             return;         }          if (KatvrFirmwareHelper.ch9326_open(vid, pid) == 0)         {             Console.WriteLine("ch9326_open failed");             return;         }          if (KatvrFirmwareHelper.ch9326_set_gpio(index, (byte)15, (byte)15) == 0)         {             Console.WriteLine("ch9326_set_gpio failed");             return;         }          if (KatvrFirmwareHelper.ch9326_connected(index) == 0)         {             Console.WriteLine("ch9326_connected failed");             return;         }          if (KatvrFirmwareHelper.flash(hex_path, device_type, device_state) != 1)         {             Console.WriteLine("KatvrFirmwareHelper.flash failed");             Console.ReadKey();             return;         }          KatvrFirmwareHelper.ch9326_ClearThreadData();         KatvrFirmwareHelper.close_ch9326();     }

Запустим — в консоли какие-то отладочные распечатки, ошибка. Эм… А, ну да, зажимаем Flash кнопку, тыкаем Reset, запускаем опять — побежали точки по экрану. Через минуты полторы — готово. Сенсор всё еще жив. Правда, мигает левой лампочкой вместо правой, как мигал до этого. Упс. Настройки стерлись.

Патчим прошивку

Но хотелось бы комфортного патчинга. У гидры есть возможность экспортировать текущий файл как Hex или Raw, но экспортируется всё, включая рам и области, которых не было в исходном hex’е. Вывод — надо патчить прямо HEX файл, а как?

Для начала — на чем-то надо тренироваться. Проще всего сделать простой бинарный патч — поменяем «KATVR» строку на «KAT-F», то есть устройство будет себя анонсировать как «KAT-F» (типа Foot/нога). Открываем любым hex редактором, например, WinHex, и правим. Затем берём дифф:

> fc.exe /b .\katvr_foot_orig.bin .\katvr_foot.bin Comparing files .\katvr_foot_orig.bin and .\KATVR_FOOT.BIN 000129E9: 56 2D 000129EA: 52 46

Отлично, у нас есть патч, который легко прочитать как есть или сконвертировать с C#:

    static readonly PatchEntry[] PatchFoot = {         ( 0x000129e9, 0x56, 0x2D ), // V => -         ( 0x000129ea, 0x52, 0x46 ), // R => F     };

Из вкусных трюков, которые удалось найти для C# (я очень редко его трогаю) — приведение тупла к структуре, позволяющая сократить многабукав в статических массивах. Просто структуру автоматически он не разбирает, но мы можем добавить конструктор и implicit operator который вызовет приведение:

    struct PatchEntry {         readonly public int addr;         readonly public byte orig;         readonly public byte patch;         public PatchEntry(int addr, byte orig, byte patch) {             this.addr = addr;             this.orig = orig;             this.patch = patch;          }         public static implicit operator PatchEntry((int addr, uint orig, uint patch) tuple) {             return new PatchEntry(tuple.addr, (byte)tuple.orig, (byte)tuple.patch);          }     };

Теперь, когда у нас есть патч в удобном машино-читаемом виде, его надо наложить на HEX.

Возьмём HexIO библиотеку и накидаем фиксилку. Знать надо не много: следим за текущим адресом, если прочитанная строка включает в себя адрес патча — исправляем. К сожалению, HexIO не следит за изменениями в структуре, и не обновляет контрольную сумму — пришлось выкрутиться через пересоздание записи. Не очень красиво, но быстро и работает:

    static string PatchHex(string input, PatchEntry[] patch)     {         string output = System.IO.Path.GetTempFileName() + ".hex";          IIntelHexStreamReader hexInput = new IntelHexStreamReader(input);         using (StreamWriter hexOutput = new StreamWriter(output))         {             uint offset = 0;             var patch_i = 0;             do             {                 IntelHexRecord rec = hexInput.ReadHexRecord();                 if (rec.RecordType == IntelHexRecordType.Data)                 {                     while (patch_i < patch.Length) {                         var pe = patch[patch_i];                         if (pe.addr >= offset + rec.Offset)                         {                             long idx = pe.addr - offset - rec.Offset;                             if (idx >= rec.RecordLength)                             {                                 break;                             }                             if (rec.Data[(int)idx] != pe.orig)                             {                                 Console.WriteLine("File data doesn't match expected.");                                 throw new InvalidDataException();                             }                             rec.Data[(int)idx] = pe.patch;                             rec = new IntelHexRecord(rec.Offset, rec.RecordType, rec.Data);                             patch_i++;                         }                         else                         {                             Console.WriteLine("Can't apply patch to a gap.");                             throw new InvalidDataException();                         }                     };                 }                 else if (rec.RecordType == IntelHexRecordType.ExtendedLinearAddress && rec.RecordLength == 2)                 {                     offset = (uint)((rec.Data[0] << 8 | rec.Data[1]) << 16);                 }                 else if (rec.RecordType == IntelHexRecordType.EndOfFile)                 {                     if (patch_i < patch.Length)                     {                         Console.WriteLine("Not all patch was applied!");                         throw new InvalidDataException();                     }                 }                 else                 {                     Console.WriteLine(rec.ToString());                     throw new InvalidDataException();                 }                 hexOutput.WriteLine(rec.ToHexRecordString());             } while (!hexInput.State.Eof);         };          return output;     }

Теперь применим патч и используем патченный hex вместо оригинала:

    static void Main(string[] args)     {         string orig_hex = "C:\\Program Files (x86)\\KAT Gateway\\katvr_foot.hex";         string hex_path = PatchHex(orig_hex, PatchFoot);         ...     }

Прошиваем, смотрим, что видно в Bluetooth окружении: ха! есть «KAT-F» устройство.

    } else {         int start = pe.addr;         List<byte> data = new List<byte>();         do         {             data.Add(patch[patch_i++].patch);         } while (patch_i < patch.Length &&                     patch[patch_i].addr - 1 == patch[patch_i-1].addr &&                     patch[patch_i].addr - start < 0x20);         if (start - offset >= 0x10000)         {             Console.WriteLine("Can't inject a record: cross boundary");             throw new InvalidDataException();         }         var newrec = new IntelHexRecord((ushort)(start - offset), rec.RecordType, data);         hexOutput.WriteLine(newrec.ToHexRecordString());     }

User-friendly патчинг

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

В принципе, как уже было сказано, C# переносится в PowerShell тривиально:

param (     [string]$firmware = "",     [int]$dvid = 0xC4F4,     [int]$dpid = 28471,     [int]$type = 3,     [int]$index = 0 )  Add-Type -Path "C:\Program Files (x86)\KAT Gateway\KAT_WalkC2_Dx.dll"  if ($firmware -eq "") {   $firmware = $katPath + "C:\Program Files (x86)\KAT Gateway\katvr_foot.hex" } Write-Host "Want to flash $firmware"  if ([KAT_WalkC2_Dx.KatvrFirmwareHelper]::ch9326_find() -eq 0) {     throw "ch9326_find failed" } if ([KAT_WalkC2_Dx.KatvrFirmwareHelper]::ch9326_open($dvid, $dpid) -eq 0) {     throw "ch9326_open failed" } if ([KAT_WalkC2_Dx.KatvrFirmwareHelper]::ch9326_set_gpio($index, 15, 15) -eq 0) {     throw "ch9326_set_gpio failed" } if ([KAT_WalkC2_Dx.KatvrFirmwareHelper]::ch9326_connected($index) -eq 0) {     throw "ch9326_connected failed" } if ([KAT_WalkC2_Dx.KatvrFirmwareHelper]::flash($firmware, $type, 0) -ne 1) {     throw "KatvrFirmwareHelper.flash failed" } [KAT_WalkC2_Dx.KatvrFirmwareHelper]::ch9326_ClearThreadData() [KAT_WalkC2_Dx.KatvrFirmwareHelper]::close_ch9326()

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

Позаимствовав код определения спаривания из прошлых скриптов, по сути надо только добавить поиск сенсора и отправку команды

Причем и ReadDeviceId и WriteDeviceId уже есть готовые:

... $id = -1 [IBizLibrary.KATSDKInterfaceHelper]::ReadDeviceId($dev.serialNumber, [ref]$id) $sensor = New-Object IBizLibrary.KATSDKInterfaceHelper+sensorInformation [IBizLibrary.KATSDKInterfaceHelper]::GetSensorInformation([ref]$sensor, $dev.serialNumber) $leftmac = [IBizLibrary.KATSDKInterfaceHelper]::receiverPairingInfoSave.ReceiverPairingByte[7..12] $rightmac = [IBizLibrary.KATSDKInterfaceHelper]::receiverPairingInfoSave.ReceiverPairingByte[13..19] if(-not(Compare-Object $leftmac $sensor.mac)) {     [IBizLibrary.KATSDKInterfaceHelper]::WriteDeviceId($dev.serialNumber, 2)     Write-Host "Made the sensor to be Left Foot" } elseif(-not(Compare-Object $rightmac $sensor.mac)) {     [IBizLibrary.KATSDKInterfaceHelper]::WriteDeviceId($dev.serialNumber, 3)     Write-Host "Made the sensor to be Right Foot" } else {     throw "The sensor's mac is not paired to the treadmill" }

Если добавить еще cmd батнички:

:: restore-foot.cmd powershell.exe -ExecutionPolicy Bypass -File flush-feet-sensor.ps1  :: update-foot.cmd powershell.exe -ExecutionPolicy Bypass -File flush-feet-sensor.ps1 --firmware .\my-foot.hex

То пользователю надо будет только запустить скрипт.

Патчим патчи, чтобы патчить патчи

Строго говоря мы не владеем исходной прошивкой, а потому распространять её как-то не оч. С другой стороны, у всех пользователей уже стоит гейтвей, то есть мы можем просто использовать исходную прошивку — надо только наложить таки патч поверх неё. Хотелось бы избежать бинарников или слишком сложного скрипта (можно было бы перенести всю логику HEX патча с C# на PowerShell). Вывод — надо сделать простой патчинг.

Иначе говоря, чтобы пропатчить патч, надо наложить патч. Ну вы поняли, да?

У нас теперь есть два HEXа: оригинальный, и полученный после наложения на него бинарного патча. Можно взять текстовый diff между ними:

> fc.exe /l /n 'C:\Program Files (x86)\KAT Gateway\katvr_foot.hex' patch.hex Comparing files C:\PROGRAM FILES (X86)\KAT GATEWAY\katvr_foot.hex and PATCH.HEX ***** C:\PROGRAM FILES (X86)\KAT GATEWAY\katvr_foot.hex  2463:  :2029C80000010203AEC2E6ED0001C3AA9D00F802CF01060302040F02013F050609FF4B41D2  2464:  :2029E8005456520512089F000900020A039F1902AF9607B039043D4FF703636505771064CC  2465:  :202A0800115ED1F9E86567676215F40000E979FA175FBD027BA63075FFFF79BF19070080C2 ***** PATCH.HEX  2463:  :2029C80000010203AEC2E6ED0001C3AA9D00F802CF01060302040F02013F050609FF4B41D2  2464:  :2029E800542D460512089F000900020A039F1902AF9607B039043D4FF70363650577106401  2465:  :202A0800115ED1F9E86567676215F40000E979FA175FBD027BA63075FFFF79BF19070080C2 *****

Вот только как его наложить? Ну то есть diff есть (fc.exe) а вот patch нету! Что ж, так как формат патча прост и для нашего случая не требуется интеллектуального наложения (нужно чтобы он применился 1-в-1, это еще подтвердит что исходная прошивка правильная), то можно сделать просто: читаем файл, для каждой строки в исходном проверяем равенство, для каждой строки выходной просто печатаем её.

А можно вообще, превратить этот дифф в скрипт, который будет прямо патчить. Не знаю что проще, если честно, но я пошел вторым путём (если честно — чтобы не возиться с чтением двух файлов, а просто работать как обработчик пайпа). Конвертер делается простой стейт машиной:

• «Comparing files» строка => выводим заголовок, переходим в ожидание патча

• «*****» в ожидании патча => переходим в ожидание строк исходного

• «*****» в ожидании строк исходного => переходим в ожидание патченных строк

• другая строка в ожидании строк исходного => печатаем if на номер строки и её содержимое

• «*****» в ожидании патченных строк => переходим в ожидание патча

• срока в ожидании патченных строк => печатаем её

Вроде просто.

Из важных вещей с которыми пришлось познакомиться: по умолчанию редирект работает не в той кодировке, что было на входе и не в utf8, а в utf-16. Так что приходится редирект отсылать в Out-File -Encoding Ascii. Но это не сильно мешает.

Итак, теперь можно скормить ему патч, и посмотреть, что получилось:

> fc.exe /l /n 'C:\Program Files (x86)\KAT Gateway\katvr_foot.hex' patch.hex | .\fc-text-to-patcher.ps1 | Out-File -Filepath foot-patch.ps1 -Encoding Ascii > cat .\foot-patch.ps1 $in_line = 0 $Input | ForEach-Object {   $in_line++   $skip = 0   if ($in_line -eq  2463) {     if ($_ -ne ':2029C80000010203AEC2E6ED0001C3AA9D00F802CF01060302040F02013F050609FF4B41D2') { throw 'File content mismatch'; }     $skip = 1   }   if ($in_line -eq  2464) {     if ($_ -ne ':2029E8005456520512089F000900020A039F1902AF9607B039043D4FF703636505771064CC') { throw 'File content mismatch'; }     $skip = 1   }   if ($in_line -eq  2465) {     if ($_ -ne ':202A0800115ED1F9E86567676215F40000E979FA175FBD027BA63075FFFF79BF19070080C2') { throw 'File content mismatch'; }     $skip = 1   }   if ($in_line -eq  2465) {     Write-Output ':2029C80000010203AEC2E6ED0001C3AA9D00F802CF01060302040F02013F050609FF4B41D2'   }   if ($in_line -eq  2465) {     Write-Output ':2029E800542D460512089F000900020A039F1902AF9607B039043D4FF70363650577106401'   }   if ($in_line -eq  2465) {     Write-Output ':202A0800115ED1F9E86567676215F40000E979FA175FBD027BA63075FFFF79BF19070080C2'   }   if ($skip -eq 0) {     Write-Output $_   } }

Отлично! Проверим:

> cat 'C:\Program Files (x86)\KAT Gateway\katvr_foot.hex' | .\foot-patch.ps1 | Out-File -Filepath out.hex -Encoding ascii > fc.exe .\out.hex .\patch.hex Comparing files .\out.hex and .\PATCH.HEX FC: no differences encountered

Последние штрихи

Поправим скрипт, добавим вызов восстановления и код для наложения патча. Поймём, что в папке scripts образовалась каша, так что… Время рефакторинга! оставляем нормальные имена файлов для .cmd — для пользователей, чтоб в начале были.

Оба рабочих скрипта (прошивки и восстановления настроек) перенесём в конец, обозвав их y-$script.ps1. А патчи положим в z_patch_$sensor.ps1.

$newfw = $ENV:TEMP + "\katvr_" + $orig + "_patch.hex" $patchscript = ".\z_patch_" + $patch + ".ps1" Get-Content $firmware | & $patchscript | Out-File -FilePath $newfw -Encoding ascii

Полученную кашицу уже можно считать финалом.

В следующей серии

Теперь, когда мы подготовили материальную базу, можно заняться самой интересной частью — разбором паршивок и правкой их по-настоящему, а не просто прямой правкой констант. Не переключайтесь!

Ссылки

• Часть 1: «Играем с платформой» на [Habr], [Medium] и [LinkedIn].

• Часть 2: «Начинаем погружение» на [Habr], [Medium] и [LinkedIn].

• Часть 3: «Отрезаем провод» на [Habr], [Medium] и [LinkedIn].

• Часть 4: «Играемся с прошивкой» на [Habr], [Medium] и [LinkedIn].

• Часть 5: «Оверклокинг и багфиксинг» на [Habr], [Medium] и [LinkedIn].