"Что б они ни делали -- не идут дела. Видимо в прошивке багов дофига". Как я напомнил в прошлой статье (где я подготовил утилиты для перепрошивки сенсоров) -- я рассказываю про платформу для VR игр, как с ней интегрироваться и как добраться до ее сенсоров напрямую.
Её исходный ресивер обновляет сенсоры с частотой в 86Гц, тогда как технически возможно разогнать до 133 Гц, получив ощутимо ниже задержки, но связь была нестабильной.
Давайте начнём погружение в сенсоры -- посмотрим, что за игра ghidra_11.0_PUBLIC установлена у меня в C:\Games, заглянем одним глазком в саму прошивку и поковыряемся там грязными патчиками, да исправим race condition плюс выкинем немного отладочных глюков. В общем, готовимся к погружению. В этот раз -- всё серьёзно.
Гидра: как накормить дракона бинарником под ARM
Так как развлечения не позволяют покупать полноценную IDA с поддержкой ARM, а IDA Freeware только работает с x86, придётся пользоваться чем-нибудь другим. Этим чем-нибудь, разумеется, оказалась Ghidra -- нашумевший несколько лет назад выложенный в опенсорс мощный дизассемблер, с системой скриптования, поддержкой множества архитектур и так далее.
Всё никак было не до него, а тут прекрасный повод подвернулся.
Скачиваем гидру куда-нибудь (C:\Games), распаковываем и запускаем через C:\Games\ghidra_11.0_PUBLIC\ghidraRun.bat. Создаём проект, через "File=>Import File" импортируем наш Bin файл. Гидра умеет разные форматы, но вот HEX не умеет, хорошо, что мы уже превратили в bin. Еще не определяет сама содержимое, хорошо, что мы уже знаем что это ARM, Cortex M3, little endian:
Гидра справшивает, не проанализировать ли файл, соглашаемся, и получаем ничего практически интересного, практически, чистый лист!
Регионы памяти
Не будем опускать руки, для начала, заполним карту памяти, которую я нашел где-то в документации у TI:
Идём в "Windows => Memory Map" и правим. Уже загруженный регион переименовываем во "flash" и убираем галочку "W" (это не записываемый регион). Через зеленый плюс в наборе инструментов в правом верхнем углу добавляем "rom" с адресом начинающимся с 10000000, длинною в 0x20000 (точнее в 0x1CC00 но это не важно), галочки ставим в R и X (убираем W). Еще добавляем регион "ram" с адреса 20000000, размером в 0x5000, R/W но не X.
С новой информацией мы понимаем, что в самом начале у нас адрес на стек, в RAM, 0x20004000, как и положено согласно карты памяти. Затем есть вектор, с которого начнётся исполнение, затем обработчики прерываний -- все указывающие внутрь ROM, которого у нас нет, и в конце два каких-то кривых указателя. Не похожи на правду.
Но с картой памяти мы еще не закончили, еще есть "Peripherals" регион, через чтение-запись адресов в котором идёт доступ и настройка железа. Самое удобное, скачать CMSIS-SVD пакет, в котором собраны в машиночитаемом виде описание железа для большинства ARM чипов и модулей. А чтобы воспользоваться им, скачиваем SVD-Loader-Ghidra, после чего идём в "Window=>Script Manager", жмём на третью справа иконку (три таких полосочки, левее крестика и красного плюсика, называется "Manage Script Directories"), где через зелёный плюсик добавляем путь до скачанного плагина ($USER_HOME/Documents/GitHub/SVD-Loader-Ghidra в моём случае). Закрываем менеджер директорий, и в фильтр в менеджере скриптов вводим SVD, чтоб быстро найти его:
Двойным кликом запускаем его, он попросит выбрать требуемый SVD файл. Выбираем ...GitHub\cmsis-svd-data\data\TexasInstruments\CC26x0.svd.
Скрипт отработает и создаст требуемые регионы памяти в 0x40000000.
Разметка недоступного ROM
Когда код представляет собой сырую портянку, каждый бит полезной информации на вес золота. А потому, скачиваем SDK, распаковываем, и начинаем копаться. Мы знаем, что отладка возможна. То есть какие-то отладочные символы должны лежать. Осталось их найти :)
Проще всего начать с адреса прерываний: 1001c901, на который указывают все вектора. Возвращаемся в линукс, и:
$ cd /mnt/c/ti/simplelink_cc2640r2_sdk_5_30_00_03
$ find . -name '*map' | xargs grep -i '1001c90'
./kernel/tirtos/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/rtos_rom.map: 1001c900 00000020 arm_m3_Hwi_asm_rom.obj (.text:ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I)
./kernel/tirtos/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/rtos_rom.map:1001c901 ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I
./kernel/tirtos/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/rtos_rom.map:1001c901 ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I Отлично, выглядит интересно! Надо только прогрузить. В плагинах с гидрой уже есть ImportSymbolsScript.py, но игры с ним оказались неудобными. Под свой случай я подправил его до ArmImportSymbolsScript.py. Основная модификация: если символ это ссылка на функцию, то адрес округляется до четного и на этом месте создаётся dword, чтобы адрес+1 указывал прямо на этот символ. Это позволило импортировать символы более удобно для автоанализа и чтения когда потом.
Впрочем, нам всё равно надо символы превратить в подходящий формат: <имя> <адрес> <тип f или нет>.
А еще, карта хоть и совпадает для символов, то, что ниже 1xxxxxxx -- не всё правда. Например, по адресу 00001a25 main -- совсем не main.
Самое простое -- не разбираться с этой картой, а разобрать напрямую приложенный объектник:
$ cd /mnt/c/ti/simplelink_cc2640r2_sdk_5_30_00_03
$ mkdir symbols
$ objdump -t ./kernel/tirtos/packages/ti/sysbios/rom/cortexm/cc26xx/r2/golden/CC26xx/CC2640R2F_rtos_rom_syms.out | perl -ne '@a=split;print "$a[-1] $a[0] $a[2]\n" if $a[1] eq "g"' > symbols/rom.txtИ теперь мы можем его подгрузить двойным кликом по ArmImportSymbolsScript.py в Scripts Manager, выберем файл из C:\ti\simplelink...\scripts\rom.txt:
$ for k in source/ti/ble5stack/rom/ble_rom_releases/cc26xx_r2/Final_Release/*symbols; do
objdump -t $k | perl -ne '@a=split;print "$a[-1] $a[0] $a[2]\n" if $a[1] eq "g"' > symbols/${k##*/}.txt
doneИмпортируем ble_r2.symbols.txt и common_r2.symbols.txt.
Разметка API SDK
Как мы видели в карте памяти, с адреса 0x1000 начинается "TI RTOS ROM Jump Table". Если сходим туда, увидим кучу указателей. Но не джампов... Впрочем, в TI системе есть еще одна огромная табличка переходов -- "ROM_Flash_JT" -- она расположена совсем не по 0x1000, но найти её легко: достаточно взять функцию из тех, что мы уже нашли в символах -- я использую HCI_bm_alloc -- и найти ссылку на неё:
Это и есть она. Переименовываем в "ROM_Flash_JT". Теперь мы можем сравнить табличку с содержимым в rom_init.c (полный путьC:\ti\simplelink_cc2640r2_sdk_5_30_00_03\source\ti\blestack\rom\r2\rom_init.c), чтобы расставить еще кучу имён. Чтобы не делать это вручную, Я накидал скриптик ROM_Flash_JT -- запускаем, выбираем rom_init.c, наслаждаемся:
Распаковка ROM2RAM
Еще один важный момент: при работе часто используется статическая инициализация разных структур в оперативной памяти. То есть когда в коде написано что-то типа
const char * str = "MyString";
char * str2 = "OtherString";то str можно ставить как указатель на строку в ROM, то str2 должна быть скопирована в RAM, так как мы можем её менять. То же самое с константами в статических структурах и так далее. Чтобы это работало, компилятор перед запуском пользовательского кода производит распаковку констант, сохранённых в ROM. Насколько понимаю, разные компиляторы делают это по разному, но в случае с GCC использованным в TI SDK (как часть XDC Tools), таблица перекидывания прописана в самом начале кода. Скачиваем скрипт arm-romtotram, затем идём по адресу указанному в Reset:
Из неё нам требуется проставить три метки:
"ROMtoRAMtable" -- начальное значение цикла,
"ROMtoRAMtableEnd" -- финальное значение цикла (гидра может не позволить сразу поставить там метку, придётся дважды кликнуть на неё, создать там указатель кнопкой "p" и потом уже через "L" поставить метку "ROMtoRAMtableEnd"),
Указатель на массив обработчиков использованный внутри цикла -- "ROMtoRAM_Processors".
Функция принимает вид:
void unpackRomToRam(void)
{
byte **ppbVar1;
for (ppbVar1 = (byte **)&ROMtoRAMtable; ppbVar1 < &ROMtoRAMtableEnd; ppbVar1 = ppbVar1 + 2) {
(*(code *)(&ROMtoRAM_Processors)[**ppbVar1])(*ppbVar1 + 1,ppbVar1[1]);
}
xdc_runtime_Startup_exec__E();
return;
}Таблица процессоров содержит три функции: функция распаковки чего-то напоминающего LZ (переносим байт как есть, или копируем N байт начиная с M байт в прошлое), memcpy и обнуления региона. Сама таблица rom2ram содержит просто пары адресов -- адрес в ROM аргумент для распаковщика и адрес в RAM для получателя.
Теперь, когда мы подписали все три метки, можно запустить "arm-romtoram" скрипт, и бульк -- всё готово.
Анализ кода
Когда мы собрали всё, что может нам понять код, можем приступать. Для начала поправим непонятные ссылки, которые висят в SysTick и IRQ. Это не указатели, а уже начальный код прошивки, поэтому сбросим из через "c", переименуем SysTick в "Begin" и сделаем его кодом через F12, затем функцией через "f".
Код выглядит как инициализация чего-то:
FUN_0000c9d0(&DAT_20001130,&DAT_20001150);
ti_sysbios_knl_Queue_construct(&DAT_2000118c,0);
DAT_20001154 = &DAT_2000118c;
FUN_0000cdfc(&DAT_2000120c,&LAB_000100e2+1,0,8);
FUN_0000cdfc(&DAT_20001230,&LAB_000100e2+1,3,4);
FUN_0000cdfc(&DAT_20001254,&LAB_000100e2+1,0,0xb);
FUN_0000cdfc(&DAT_200011e8,&LAB_000100e2+1,0,3);
DAT_20002038 = FUN_00009730(&DAT_20002040,&DAT_20002064);
if (DAT_20002038 == 0) {
do {
/* WARNING: Do nothing block with infinite loop */
} while( true );
}
FUN_00005bf4(0x10,0xe165,0x1f,6);
uVar20 = 0;
local_5c = 9;
local_5e = 8;
local_53 = 0;
local_56 = 0;
local_5a = 100;
local_58 = 1000;
FUN_0000363c(0x306,2,&local_56);
FUN_0000363c(0x308,0x10,&DAT_200011a4);
FUN_0000363c(0x307,7,&DAT_20001174);
FUN_0000363c(0x310,1,&local_53);
FUN_0000363c(0x311,2,&local_5e);
FUN_0000363c(0x312,2,&local_5c);
FUN_0000363c(0x313,2,&local_5a);
FUN_0000363c(0x314,2,&local_58);
FUN_00005bf4(0x10,0xe165,6,0xa0);
FUN_00005bf4(0x10,0xe165,7,0xa0);
FUN_00005bf4(0x10,0xe165,8,0xa0);
FUN_00005bf4(0x10,0xe165,9,0xa0);
local_64 = 0;
local_50 = 0;
local_52 = 1;
local_51 = 1;
local_4f = 1;
FUN_00005bf4(0x10,&DAT_00003fb5,0x408,4,&local_64);
FUN_00005bf4(0x10,&DAT_00003fb5,0x400,1,&local_52);
FUN_00005bf4(0x10,&DAT_00003fb5,0x402,1,&local_51);
FUN_00005bf4(0x10,&DAT_00003fb5,0x403,1,&local_50);
FUN_00005bf4(0x10,&DAT_00003fb5,0x406,1,&local_4f);
FUN_00005bf4(0x10,&LAB_0000f3f8+1,&DAT_2000117c);
Осталось понять чего. Для начала, сделаем поиск по константам (через Notepad++ или grep'ом):
datacompboy@NUUBOX:/mnt/c/ti/simplelink_cc2640r2_sdk_5_30_00_03$ find . -name '*.h' | xargs grep 0x306
./kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include/elf.h:#define NT_S390_LAST_BREAK 0x306
./source/ti/blestack/profiles/roles/cc26xx/broadcaster.h:#define GAPROLE_ADV_EVENT_TYPE 0x306 //!< Advertisement Type. Read/Write. Size is uint8_t. Default is GAP_ADTYPE_ADV_IND (defined in GAP.h).
./source/ti/blestack/profiles/roles/cc26xx/multi.h:#define GAPROLE_ADVERT_OFF_TIME 0x306
./source/ti/blestack/profiles/roles/cc26xx/peripheral.h:#define GAPROLE_ADVERT_OFF_TIME 0x306
./source/ti/blestack/profiles/roles/peripheral_broadcaster.h:#define GAPROLE_ADVERT_OFF_TIME 0x306 //!< Advertising Off Time for Limited advertisements (in milliseconds). Read/Write. Size is uint16. Default is 30 seconds.О, прекрасно, у нас же сенсор, значит из peripheral. Давайте подгрузим константы в гидру:
File=>Parse C source=>зеленый плюс=>"c:\ti\simplelink_cc2640r2_sdk_5_30_00_03\source\ti\blestack\profiles\roles\cc26xx\peripheral.h"=>Parse to program.
Ругнётся на что-то, но константы добавится. Тыкаем в "0x306", жмём "E" видим GAPROLE_ADVERT_OFF_TIME -- двойным кликом применяем. Ниже видим 408/400/402... Можем повторить с ним, но лучше понять что за функции, и почему они не подписаны.
Поищем на тему примеров с GAPROLE_SCAN_RSP_DATA:
$ find . -name '*.c' | xargs grep GAPROLE_SCAN_RSP_DATA
./examples/rtos/CC2640R2_LAUNCHXL/blestack/multi_role/src/app/multi_role.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/project_zero/src/app/project_zero.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData), scanRspData);
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_broadcaster/src/app/simple_broadcaster.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof (scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_np/src/app/simple_np_gap.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_np/src/app/simple_np_gap.c: status = GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, len, pDataPtr);
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral/src/app/simple_peripheral.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral/src/app/simple_peripheral_dbg.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral_oad_offchip/src/app/simple_peripheral_oad_offchip.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral_oad_onchip/src/app/simple_peripheral_oad_onchip.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral_oad_onchip/src/persistent_app/oad_persistent_app.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
./examples/rtos/CC2640R2_LAUNCHXL/blestack/simple_peripheral_secure_fw/src/app/simple_peripheral_dbg.c: GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
Что у нас там в simple_peripheral.c:
// Setup the Peripheral GAPRole Profile. For more information see the User's
// Guide:
// http://software-dl.ti.com/lprf/sdg-latest/html/
{
// By setting this to zero, the device will go into the waiting state after
// being discoverable for 30.72 second, and will not being advertising again
// until re-enabled by the application
uint16_t advertOffTime = 0;
uint8_t enableUpdateRequest = DEFAULT_ENABLE_UPDATE_REQUEST;
uint16_t desiredMinInterval = DEFAULT_DESIRED_MIN_CONN_INTERVAL;
uint16_t desiredMaxInterval = DEFAULT_DESIRED_MAX_CONN_INTERVAL;
uint16_t desiredSlaveLatency = DEFAULT_DESIRED_SLAVE_LATENCY;
uint16_t desiredConnTimeout = DEFAULT_DESIRED_CONN_TIMEOUT;
GAPRole_SetParameter(GAPROLE_ADVERT_OFF_TIME, sizeof(uint16_t),
&advertOffTime);
GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, sizeof(scanRspData),
scanRspData);
GAPRole_SetParameter(GAPROLE_ADVERT_DATA, sizeof(advertData), advertData);
GAPRole_SetParameter(GAPROLE_PARAM_UPDATE_ENABLE, sizeof(uint8_t),
&enableUpdateRequest);
GAPRole_SetParameter(GAPROLE_MIN_CONN_INTERVAL, sizeof(uint16_t),
&desiredMinInterval);
GAPRole_SetParameter(GAPROLE_MAX_CONN_INTERVAL, sizeof(uint16_t),
&desiredMaxInterval);
GAPRole_SetParameter(GAPROLE_SLAVE_LATENCY, sizeof(uint16_t),
&desiredSlaveLatency);
GAPRole_SetParameter(GAPROLE_TIMEOUT_MULTIPLIER, sizeof(uint16_t),
&desiredConnTimeout);
}Ха! 1-в-1: GAPROLE_ADVERT_OFF_TIME, GAPROLE_SCAN_RSP_DATA, GAPROLE_ADVERT_DATA, GAPROLE_PARAM_UPDATE_ENABLE...
Переименовываем FUN_0000363c => GAPRole_SetParameter, смотрим ниже:
// Set the Device Name characteristic in the GAP GATT Service
// For more information, see the section in the User's Guide:
// http://software-dl.ti.com/lprf/sdg-latest/html
GGS_SetParameter(GGS_DEVICE_NAME_ATT, GAP_DEVICE_NAME_LEN, attDeviceName);
// Set GAP Parameters to set the advertising interval
// For more information, see the GAP section of the User's Guide:
// http://software-dl.ti.com/lprf/sdg-latest/html
{
// Use the same interval for general and limited advertising.
// Note that only general advertising will occur based on the above configuration
uint16_t advInt = DEFAULT_ADVERTISING_INTERVAL;
GAP_SetParamValue(TGAP_LIM_DISC_ADV_INT_MIN, advInt);
GAP_SetParamValue(TGAP_LIM_DISC_ADV_INT_MAX, advInt);
GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MIN, advInt);
GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MAX, advInt);
}Хмм... У нас следом за пачкой GAPRole_SetParameter идет просто четыре вызова, ничего напоминающего вызов GGS_SetParameter нет. Кажется, начинаю понимать, почему нет таблицы параметров -- её вырезали из примера. Но еще один непонятный момент -- GAP_SetParamValue должен иметь два аргумента, а у нас 4:
FUN_00005bf4(0x10,0xe165,6,0xa0);
FUN_00005bf4(0x10,0xe165,7,0xa0);
FUN_00005bf4(0x10,0xe165,8,0xa0);
FUN_00005bf4(0x10,0xe165,9,0xa0);Давайте убедимся, что это они:
$ find . -name '*.h' | xargs grep TGAP_LIM_DISC_ADV_INT_MAX
./source/ti/blestack/inc/gap.h:#define TGAP_LIM_DISC_ADV_INT_MAX 7Да, они.... А что такое GAP_SetParamValue, может, это макрос?
$ find . -name '*.h' | xargs grep GAP_SetParamValue
./source/ti/ble5stack/icall/inc/ble_dispatch_lite_idx.h:#define IDX_GAP_SetParamValue JT_INDEX(152)
./source/ti/ble5stack/icall/inc/icall_api_idx.h:#define IDX_GAP_SetParamValue GAP_SetParamValue
./source/ti/ble5stack/icall/inc/icall_ble_api.h:#define GAP_SetParamValue(...) (icall_directAPI(ICALL_SERVICE_CLASS_BLE, (uint32_t) IDX_GAP_SetParamValue , ##__VA_ARGS__))
./source/ti/ble5stack/icall/inc/icall_ble_apimsg.h: * @see GAP_SetParamValue()
./source/ti/ble5stack/inc/gap.h: * Parameters set via @ref GAP_SetParamValue
./source/ti/ble5stack/inc/gap.h:extern bStatus_t GAP_SetParamValue(uint16_t paramID, uint16_t paramValue);
./source/ti/ble5stack/rom/map_direct.h:#define MAP_GAP_SetParamValue GAP_SetParamValueВот оно что! В зависимости от флагов компиляции, вызов либо прямой, либо косвенный через таблицу джампов (с индексом 152), либо косвенный по прямому адресу. Убедимся, что ICALL_SERVICE_CLASS_BLE == 0x10:
$ find . -name '*.h' | xargs grep ICALL_SERVICE_CLASS_BLE
...
./source/ti/blestack/icall/src/inc/icall.h:#define ICALL_SERVICE_CLASS_BLE 0x0010
./source/ti/blestack/icall/src/inc/icall.h:#define ICALL_SERVICE_CLASS_BLE_MSG 0x0050
./source/ti/blestack/icall/src/inc/icall.h:#define ICALL_SERVICE_CLASS_BLE_BOARD 0x0088
...переименуем FUN_00005bf4 в icall_directAPI, адрес 0xe165 в GAP_SetParamValue. Смотрим дальше пример:
GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairMode);
GAPBondMgr_SetParameter(GAPBOND_MITM_PROTECTION, sizeof(uint8_t), &mitm);
GAPBondMgr_SetParameter(GAPBOND_IO_CAPABILITIES, sizeof(uint8_t), &ioCap);
GAPBondMgr_SetParameter(GAPBOND_BONDING_ENABLED, sizeof(uint8_t), &bonding);
GAPBondMgr_SetParameter(GAPBOND_LRU_BOND_REPLACEMENT, sizeof(uint8_t), &replaceBonds);как раз 408, 400, ... переименовываем 0x3fb5 => GAPBondMgr_SetParameter.
Процесс дальше, впрочем не похож на инициализацию таблицы. Таки либо пример неверный, либо таки отдельные сервисы типа GSS вырезаны.
Заметки на полях: поиск полезных данных никогда не бывает лишним. Выше я показывал вывод strings, в котором были интересные вещи -- "inputGyroRv" и "inputNormal". Поиск по ним на github дал сходу интересную вещь, что позволило еще разметить часть функций и структур, которыми пользуется сенсор направления. Для ног однако подобной фкусности не обнаружилось.
Тут можно бесконечно пытаться понять дальше, однако ж, давайте научимся менять код прошивки. Иначе зачем нам это всё?
Играемся с прошивкой
Для эксперимента, мы уже пропатчили прошивку, заменив "KATVR", которая используется для анонса данных, на "KAT-F" (типа "Ноги"). Но это не интересно. Каждый сенсор прошивается его типом -- левый или правый -- хорошо бы, чтобы он анонсировал себя "KAT-R" или "KAT-L"! Для этого надо найти где же хранится его тип (левый-правый).
Мы знаем, что спаривание висит на USB, и пакеты 0x55/0xAA. Простым пролистыванием вниз натыкаемся на кусок:
case 0xc:
cVar6 = *(char *)(puVar23 + 1);
pcVar26 = *(char **)(puVar23 + 2);
FUN_0000af16(&DAT_200011c8,0,0x1f);
if ((*pcVar26 == 'U') && (pcVar26[1] == -0x56)) {
DAT_200011cb = 0;
DAT_200011c8 = 0x55;
DAT_200011c9 = 0xaa;
cVar4 = (char)local_48;
cVar7 = DAT_200011c0;
if (cVar6 == '\x01') {
....который явственно обрабатывает событие "пакет по USB" и реагирует на него. WriteDeviceId это команда 0x04:
if (cVar6 == '\x03') {
DAT_200011cc = '\x03';
cVar4 = DAT_200011cc;
cVar7 = DAT_200011c1;
goto LAB_000009b8;
}
if (cVar6 == '\x04') {
DAT_200011c1 = pcVar26[5];
PostMsg(7,0,0);
DAT_200011cd = 0;
DAT_200011cc = '\x04';
FUN_0000fa20();
FUN_0000f8ec();
break;
}Вывод -- DAT_200011c1 это искомый ID сенсора, он же использован как аргумент в ReadDeviceId (команда 0x03). Кросс-реферес по ссылкам на него находит интересную простую функцию:
void FUN_0000f8ec(void)
{
if (ParamDeviceId == '\x03') {
DAT_20001132 = 5;
}
else {
DAT_20001132 = 4;
}
return;
}Которая вызывается дважды из Begin() -- при инициализации (очевидно, после подгрузки параметров) и после WriteDeviceId. Идеальная точка врезки!
Изучим ассемблер:
*************************************************************
* FUNCTION
*************************************************************
undefined FUN_0000f8ec ()
undefined r0:1 <RETURN>
FUN_0000f8ec XREF[2]: 0000038c (c) , 000009a4 (c)
0000f8ec 04 49 ldr r1,[DAT_0000f900 ] = 20001130h
0000f8ee 91 f8 91 00 ldrb.w r0,[r1,#0x91 ]=>ParamDeviceId
0000f8f2 03 28 cmp r0,#0x3
0000f8f4 14 bf ite ne
0000f8f6 04 20 mov.ne r0,#0x4
0000f8f8 05 20 mov.eq r0,#0x5
0000f8fa 88 70 strb r0,[r1,#0x2 ]=>DAT_20001132
0000f8fc 70 47 bx lr
0000f8fe c0 ?? C0h
0000f8ff 46 ?? 46h F
DAT_0000f900 XREF[1]: FUN_0000f8ec:0000f8ec (R)
0000f900 30 11 00 20 undefine 20001130h ? -> 20001130
Итак, функция грузит в r1 адрес объекта из неподалёку лежащей константы; затем грузит в r0 байт из объекта+смещение. Сравнивает этот байт с 0x3 (левая нога), и затем использует инструкцию "ite ne".
Очень красивая система условного выполнения без переходов. В полноценном ARM режиме у каждой команды просто приписано выполняется ли она при флагах, в thumb режиме всё задаётся командой -- (I)f,(T)hen,(E)lse, которая может быть просто "IT" (if-then, выполнить инструкцию если совпадает условие), ITT (if-then-then, выполнить две). Управляется от 1 до 4 инструкций, и первая следующая всегда then.
Затем два mov в R0, первая выполнится если R0 != 3, вторая если R0 == 3.
Затем новое значение сохраняется в другой байт в структуре и идёт переход на адрес lr. Так как функция трогает только регистры r0 и r1 (они же -- параметры функций), их сохранять похоже не обязательно.
Так как после возврата у нас есть еще два байта (выравнивание), мы можем заменить (bx lr + nop) на один длинный jmp куда-нибудь.
Сразу по окончании ROMtoRAM таблицы у нас как раз пустое место, всё нули. Для удобства отмотаем до круглого числа (0x12e10) и придумаем что мы хотим вписать. Превратим "KATVR" в "KAT-L" или "KAT-R" в зависимости от настройки. Соответственно, надо просто превратить R0 в L или R, и записать куда-надо. А куда? Строка "KATVR" нас дважды: один раз в ПЗУ части, один раз в ОЗУ в пакете для анонса:
DAT_200011a4 XREF[1]: 000000ee (*)
200011a4 06 ?? 06h
200011a5 09 ?? 09h
200011a6 4b ?? 4Bh K
200011a7 41 ?? 41h A
200011a8 54 ?? 54h T
200011a9 56 ?? 56h V
200011aa 52 ?? 52h R
200011ab 05 ?? 05hИтого, нам надо вписать эквивалент:
if(left) {
scanRsp[6] = 'L';
} else {
scanRsp[6] = 'R';
}
scanRsp[5] = '-'; // можно сделать патч в ROM, можно вписать тутК моменту выхода из функции в R0 у нас 4 или 5 в зависимости от ноги, а в R1 у нас указатель на 20001130. Расстояние от 20001130 до 200011A9 -- 0x79. В принципе, у нас еще и флаги уже стоят с прошлого сравнения. То есть можно сделать нечто вроде:
ite ne
mov.ne r0,#'L'
mov.eq r0,#'R'
strb r0,[R1,#0x7A]
mov r0,#'-'
strb r0,[R1,#0x79]
bx lrЧтобы править код в гидре нужно очистить область от режима (если там уже есть инструкции), затем через ctrl+shift+g включить ассемблер для текущей строки, она ругнётся что процессор не тестирован. Вписываем инструкцию и аргументы, воюем с ней так как не всегда понимает, что мы хотим, но вроде получается. Правда на "mov.ne r0,#'L'" она откаывается реагировать! Когда такое начиналось, я пользовался online assembler где вводил инстуркции и потом переносил байтики. "mov r0, #'L'" => "4f f0 4c 00"... Не не, надо 2хбайтную, "movs r0, #'L'" => "4c 20" -- идеально. "movs r0, #'R'" => "52 20". И так далее...
Эм.... Что-то гидре поплохело:
MoveFeetNumNew
00012e10 14 bf ite ne
00012e12 4c 20 mov.ne r0,#0x4c
00012e14 52 20 mov.eq r0,#0x52
00012e16 81 f8 7a 00 strb.eq.w r0,[r1,#0x7a ]
00012e1a 81 f8 79 00 strb.eq.w r0,[r1,#0x79 ]
00012e1e 70 47 bx.eq lrНепонятно почему, но в дизассемблере залип отслеживатель флагов. Жаль, но, проигнорируем. Зальем патч... Вот только не сработало. :(
Надо не только сменить структуру, но еще и вызвать GAPRole_SetParameter(GAPROLE_SCAN_RSP_DATA, 0x10, &scanRsp).
Хорошо, тогда нам нужен указатель на scanRsp в R2. Поправим код:
ite ne
mov.ne r0,#'L'
mov.eq r0,#'R'
adds.w r2,r1,#0x74
strb r0,[R2,#6]
movw r0,#0x308
movs r1,#0x10
b.w GAPRole_SetParameterВсё хорошо, но тут гидре сорвало крышу, декомпиляция совсем сошла с ума. Ткнём в "b.w" инструкцию правой кнопкой мыши и через "modify instruction flow" сменим её на "CALL_RETURN". Уже лучше. Чтобы вылечить залипшие ".eq", можно ткнуть на первую кривую инструкцию (adds.eq.w) правой, и выбрать "Clear Flow and Repair", после чего опять F12 -- код исправится (более-менее):
MoveFeetNumNew XREF[1]: MoveFeetNumSmt:0000f8fc (j)
00012e10 14 bf ite ne
00012e12 4c 20 mov.ne r0,#0x4c
00012e14 52 20 mov.eq r0,#0x52
00012e16 11 f1 74 02 adds.w r2,r1,#0x74
00012e1a 90 71 strb r0,[r2,#0x6 ]
00012e1c 40 f2 08 30 movw r0,#0x308
00012e20 10 21 movs r1,#0x10
00012e22 f0 f7 0b bc b.w GAPRole_SetParameter undefined GAPRole_SetParameter()
-- Flow Override: CALL_RETURN (CALL_TERMINATOR)Декомпиляция тоже станет лучше:
void MoveFeetNumSmt(void)
{
if (DeviceId == '\x03') {
DAT_20001132 = 5;
UNK_200011aa = 0x52;
}
else {
DAT_20001132 = 4;
UNK_200011aa = 0x4c;
}
GAPRole_SetParameter(0x308,0x10);
return;
}Единственное, она потеряла аргумент к функции. Если нажать на ней правой кнопкой и сделать Edit Function, добавить три аргумента и выставить им простые типы:
Код окончательно примет нормальный вид:
void MoveFeetNumSmt(void)
{
if (DeviceId == '\x03') {
DAT_20001132 = 5;
UNK_200011aa = 0x52;
}
else {
DAT_20001132 = 4;
UNK_200011aa = 0x4c;
}
GAPRole_SetParameter(0x308,0x10,&scanRspData);
return;
}Прекрасно, опять экспортируем патч (File=>Export Program), "fc.exe /b .\katvr_foot_orig.bin .\katvr_foot.bin" и так далее. Загружаем в сенсор. Урра, работает! :) Видим "KAT-R" и "KAT-L" устройства плавающие вокруг. Красота.
Поиграли - пора и делом заняться.
Разгоняем ноги на KatWalk C2 до 133 Гц
Чтобы понять в чем проблема с сенсорами, надо думать как сенсоры. Итак, мы знаем, что сенсоры отдают данные через Notification. Пойдём искать, где же они используются. Слева в "Symbol tree" в поле поиска вводим Notifi и легко переходим на GATT_Noficiation. Ссылок не видно. Значит, используется косвенный вызов, делаем поиск по 0x10010045 (адрес+1, ибо код в Thumb режиме) и находим одну единственную функцию, где идёт подготовка, потом вызов:
_DAT_20001186 = 0x14;
_DAT_20001188 = (undefined *)thunk_EXT_FUN_10018404(DAT_20001142,0x1b,0x14,0,in_r3);
cVar1 = DAT_20000521;
if (_DAT_20001188 != (undefined *)0x0) {
_DAT_20001184 = 0x2e;
if (_DAT_20001146 == 0) {
...
cVar1 = icall_directAPI(0x10,(int)&GATT_Notification + 1,DAT_20001142,&DAT_20001184,0);0x2E -- это же наш handle, так что да, мы нашли то самое место.
Если упростить, код получается такой:
void KatSendNotification() {
out = malloc(...);
if (out) {
if (packetNo == 0) {
out->_type = 0; // status packet
fill_charge_levels(out);
} else {
out->_type = 1; // data packet
if (!DATA_READY || !DATA_OK) {
out->_x = 0;
out->_y = 0;
} else {
DATA_READY = false;
out->_x = DATA_X;
out->_y = DATA_Y;
}
out->status = STATUS;
}
if (something) {
out[0] = 0; out[1] = 1; out[2] = 0; out[3] = 1; out[4] = 0; out[5] = 1;
}
attHandleValueNoti_t notification = { 0x2e, 0x14, out };
if (!GATT_Notification(0x2E, ¬ification, 0)) { free(out); }
if (++packetNo == 500) {
packetNo = 0;
}
}То есть, каждые 500 пакетов отправляется уровень заряда (плюс версия прошивки и ID сенсора), все остальные пакеты содержат данные. Причем если данные не готовы (или была ошибка связи с сенсором), то отсылаются нули. Еще, если стоит какой-то флаг, то начало пакета перетирается последовательностью 0-1-0-1-0-1.
Теперь нужно понять, как часто этот GATT_Nofication вызывается. Ссылок на "KatSendNotification" (как я назвал эту функцию) две, и обе из основного потока, обе внутри цикла обработки событий:
while(!QueueEmpty(...)) {
Entry* event = QueueGet(...);
switch (event->id)
{
...
case 4:
KatSendNotification();
ClockStop(...);
break;
case 6:
if (Flag1 == 1 || Flag2 == 1) {
KatSendNotification();
}
break
...
}
}Событие №4 должно бы посылаться таймером, но таймер не запущен -- и даже если будет запущен, сразу будет остановлен. Никаких других ссылок на этот таймер я не нашел.
Событие №6 генерируется по коллбэку на обработку события BLE, так что похоже на то, что события посылаются после того как два флага взведены (один из них -- соединение установлено, второй не совсем понял сходу), причем следующее событие формируется после отправки предыдущего. Окей, это совпадает с наблюдением, что поток начинается после изменения параметра соединения.
Пока непонятно, но, вроде, сколько раз спросили -- столько раз мы должны ответить. Что ж, посмотрим, на когда данные появляются? Кросс-референс на DATA_OK приводит нас к функции:
void ReadSensorData(...)
{
do {
Semaphore_Pend(SensorSemaphore, -1);
Task_sleep(700);
GPIO_SET(..., 0);
SPI_Send(0x50);
Task_sleep(10);
char* out = &SensorData;
for (int i = 0x0C; i; --i) {
*(out++) = SPI_Recv();
}
GPIO_SET(..., 1);
Task_sleep(0.1);
DATA_OK = 0;
if ((SensorData[0] & 0x80 != 0) && (SensorData[0] & 0x20 != 0)) {
DATA_OK = 1;
}
DATA_READY = 1;
SensorReads++;
If (SensorReads > 99) {
// refresh something
SensorReads = 0;
}
if (SomeFlag == 0) {
Semaphore_Post(SensorSemaphore);
}
} while(true);
}Функция занимается обновлением данных с сенсора до тех пор, пока SomeFlag не будет взведён. Как показало дальнейшее расследование -- этот флаг означает переход в режим сна. Семафор инициализируется на старте и сразу взводится, то есть датчик читается непрерывно пока мы не спим, с перерывами в 700+10+13байтSPI + обновление еще чего-то раз в 100 чтений. SPI настроен на 4 мегабод. Единицы сна в десятках микросекунд. То есть сенсор обновляется раз в ~7.11 миллисекунды, или около 140-141 Гц. Выглядит так, что не должно бы быть проблем с обновлением сенсора на 133Гц. Однако же они есть.
Наблюдаемое поведение -- иногда мы видим нулевые пакеты (ведешь себе ровненько сенсор, а точка в гейтвее внезапно срывается в центр).
Как ни странно, это поведение вполне объяснимо: при обновлении данных каждые ~140Гц и чтении 133Гц, мы двигаемся рядом, и вероятность того, что пакет был обновлён вот-только-что, а мы обновляем данные -- крайне высока. Мы наблюдаем состояние гонки, так как никакой синхронизации между отправкой, формированием и обновлением данных нет.
Решение, как ни странно, очевидно. Нам нужны новые данные для отправки, поэтому читать сенсор нужно только когда есть связь. Пакеты запрашиваются регулярно. А что если... Перенести вызов Semaphore_Post из ReadSensorData в KatSendNotification? Тогда получится идеальная связка: ReadSensorData() подготовит данные, KatSendNotification их заберёт -- и запросит опять. Идеально. Единственное, что KatSendNotification вызывается после отправки прошлого пакета, то есть задержку изнутри ReadSensorData убирать нельзя. Я бы, пожалуй, чуток ее даже понизил, чтобы пакет точно был готов. Так как мы обновляем пакеты каждые 86..133Гц, момент замера скорости не так критичен, до тех пор, пока задержка одна и та же -- 5 миллисекунд погоды не сделают.
Достанем блокнотик и спланируем наш патч. Во-1х снизим задержку:
000079d0 41 f6 58 31 movw r1,#7000 # The delay
=>
000079d0 41 f2 88 31 movw r1,#5000Во-2х, замкнём цикл до вызова SensorSemaphore. Способов замкнуть цикл множество: можно заменить в IF условный jmp (bne) на безусловный, можно просто заNOPитьвызов функции, а можно тупо вписать переход вместо всего IFа:
LAB_00007ab0 XREF[1]: 00007a54 (j)
00007ab0 28 78 ldrb r0,[r5,#0x0 ]=>SleepState = 52h
00007ab2 00 28 cmp r0,#0x0
00007ab4 98 d1 bne LAB_000079e8
00007ab6 68 68 ldr r0,[r5,#0x4 ]=>SensorReadSem
00007ab8 f9 f7 7e fa bl Semaphore_post undefined Semaphore_post()
00007abc 94 e7 b LAB_000079e8
=>
LAB_00007ab0 XREF[1]: 00007a54 (j)
00007ab0 9a e7 b LAB_000079e8И в-3их, поправить KatSendNotification. Действуем аналогично прошлому подходу с реакцией на лампочки -- уходим на свободный кусочек в конце (после прошлого патча, я взял 00012e40). Соответственно, в конце функции меняем return на jmp:
LAB_00006b14 XREF[1]: 00006a08 (j)
00006b14 f8 bd pop {r3,r4,r5,r6,r7,pc}
00006b16 c0 ?? C0h
00006b17 46 ?? 46h F
=>
LAB_00006b14 XREF[1]: 00006a08 (j)
00006b14 0c f0 94 b9 b.w KatSendNotificationTailИ на новом месте формируем кусочек подобный вырезанному из ReadSensorData. Главная сложность, по сравнению с ReadSensorData, это спланировать сколько надо места перед хранением константы для загрузки указателя на семафор. Так же может понадобиться поправить переход, сбросить/вызвать Repair Flow после правок -- но после заполнения всего кода и сброса, всё получается:
=>
KatSendNotificationTail XREF[1]: KatSendNotification:00006b14 (j)
00012e40 03 4d ldr r5,[->SleepState ] = 20001584
00012e42 28 78 ldrb r0,[r5,#0x0 ]
00012e44 00 28 cmp r0,#0x0
00012e46 02 d1 bne LAB_00012e4e
00012e48 68 68 ldr r0,[r5,#0x4 ]
00012e4a ee f7 b5 f8 bl Semaphore_post undefined Semaphore_post()
LAB_00012e4e XREF[1]: 00012e46 (j)
00012e4e f8 bd pop {r3,r4,r5,r6,r7,pc}
PTR_SleepState_00012e50 XREF[1]: 00012e40 (R)
00012e50 84 15 00 20 addr SleepState = 52h
Заливка патча, на удивление, сработала с первого раза, ресивер на 133Гц получает пакеты стабильно. Если медленно вести, в гейтвее нет никаких проблем и не сбрасывается на ноль. Ура!
Исправляем баги (выкидываем забытый скальпель)
Я уже начал радоваться, но вот Utopia Machina (да-да, еще раз спасибо за кучу тестирования) жаловался на то, что сенсор направления периодически залипает и требует перезагрузки. "Залипает" это когда направление меняется только на пару градусов, еще и перестаёт показывать уровень заряда. Еще жаловался на то, что иногда пропадают данные с одной из ног. При этом на оригинальном ресивере практически не воспроизводится.
У меня не воспроизводилось... Но как-то выяснилось, что у меня не воспроизводится когда висит на зарядке, а у него без зарядки. Выкрутил сенсор, оставил на пару часов периодически пошевеливая чтоб убедиться что работает. И... Да! Воспроизвел!
Когда произошло, я через Wireshark посмотрел на пакеты, и выяснилось, что в пакетах вместо направления и номера сенсора -- идёт "0 1 0 1 0 1". Хвост данных был как всегда, таким образом кусоче квартерниона направления таки менялся, потому и получалось что-то видеть.
Это сработала вот эта мина отложенного действия, которая есть и в прошивке сенсоров ног и в прошивке направления:
if (something) {
out[0] = 0; out[1] = 1; out[2] = 0; out[3] = 1; out[4] = 0; out[5] = 1;
}Это же объясняет, почему пропадала одна из ног -- когда этот код срабатывал, координаты-то не затирались (в ногах они в самом конце пакета), а вот данные о батарее и номер сенсора -- затирались.
Прекрасно, мы знаем, что случилось -- но почему? К счастью, флаг "somthing" трогался только один раз, внутри обработчика таймера тикающего раз в секунду; и только если некий счетчик доходил до 1800, и не сбрасывался по дороге. Сбрасывался он при определённых условиях связанными с разрядом батареи. Проще говоря, это оказался отладочный код для настройки скорости разряда батареи и тюнинга перехода в режим сна. Я нашел в обоих сенсорах хвосты для настройки этого параметра по USB.
В любом случае, это отладочный кусок который в релизной прошивке не нужен -- а значит, просто можно безопасно вырезать.
Вырезать опять же можно несколькими споосбами -- через замыкание if'а, через затирание nop'ами... Я просто заNOPил строку, где ставилось "something = 1".
А что не так
Примечательно, что исправленные сенсоры остаются совместимы с оригинальными ресивером... Почти. Главная разница -- значения, которые читаются сенсорами, теперь читаются с частотой обновления (86Гц..133Гц) а не с фиксированными ~140Гц.
Оптический сенсор на каждом чтении возвращает некое расстояние (в попугаях), которые он насчитал с прошлого чтения.
Оригинальный сенсор читает последнее доступное значение 86 раз в секунду, получается, использует данные о расстоянии как скорость -- часть пройденного расстояния при этом теряется, но, с некоторой точностью, восстанавливается перемножая на время.
Патченный сенсор начинает читать данные со скоростью опроса -- то есть данные о пройденном расстоянии почти не теряются (теряется каждый 500й пакет + часть пакетов просто теряется по радио), но при этом каждое значение получается больше, чем в оригинале: при обновлении 86 раз в секунду значения будут амплитудой до 163% по отношению к исходным, а на 133Гц всего 105%.
Представляет ли это проблему? Зависит от того, как этими данными пользоваться. Если использовать данные для вычисления скорости напрямую (как, к сожалению, делает гейтвей) -- то и да и нет. Нет -- так как при использовании 133Гц ресивера и исправленные сенсоры практически не чувствуется разницы, зато задержки ощутимо ниже (реально ощущается, особенно при игре на 120fps). Да -- так как при использовании исправленного сенсора и исходного ресивера все скорости сильно выше и нужно исправлять настройки для каждой игры -- понижать скорость разбега.
Можно ли это тоже исправить? Да, есть несколько способов исправления: патч гейтвея, патча исходного ресивера, более сложный патч сенсоров... Есть где разгуляться. Но это тема отдельного разговора.
Что дальше
А дальше на самом деле -- избавление от гейтвея, как минимум для нативных игр -- сейчас, используя KAT SDK невозможно сделать Standalone игры, так как SDK жестко прибит гвоздями к винде и ресиверу подключенному к нему. А я раньше уже показал как связаться с ресивером напрямую, сделал маленький ресивер который прикидывается оригинальным... То есть есть всё, что нужно, для создания действительно standalone игры -- идеально вписывается в концепцию игры, которую разрабатывает Utopia Machina. Так что в следующей серии я покажу итог совместной наработки -- UE SDK с прямым доступом до платформы хоть под виндой хоть нативно на Quest 2/3 :) Не переключайтесь!
Ссылки
Часть 1: "Играем с платформой" на [Habr], [Medium] и [LinkedIn].
Часть 2: "Начинаем погружение" на [Habr], [Medium] и [LinkedIn].
Часть 3: "Отрезаем провод" на [Habr], [Medium] и [LinkedIn].
Часть 4: "Играемся с прошивкой" на [Habr], [Medium] и [LinkedIn].
Часть 5: "Оверклокинг и багфиксинг" на [Habr], [Medium] и [LinkedIn].
