Достоинства открытого протокола для мелкой электроники и в частности трекеров шагов, можно не заморачиваться с приложениями пользователи с конспиративными наклонностями(из фонда fsf.org) сами напишут приложении и построят, если нужно графики и тому подобное. Пользователи более или менее довольны, что могут сами проверить: что отправляется и принимается и если что: сами осуществить поддержку устаревших в каком-то плане устройств. Можно если что добавить поддержку этих устройств на новых платформах. Но возникает проблема в цене, если протокол доступен пользователь может уйти от идеи материальной поддержки производителя или его сервисов, он же сам может все сделать. Также конкуренты могут сделать дешевле или добавить в свое устройство поддержку вашего сервиса и не вкладывать деньги в поддержку сервиса, и вы будете осуществлять его своим и чужим. А он будет только клепать устройства. Поэтому возникает достаточно сложная задача в каком объёме будет окупаться ваш продукт, в цену будет вкладываться разработка устройства, производство и сервисные услуги, такие как сообщества пользователей устройства и страница рейтингов пользователей, если это игра или подразумевается какой-то вид вовлечения в сообщество под средством игры(кто быстрее ходит, сбрасывает вес, бывает в новых местах). Причем последний пункт может быть сразу вложен в цену продукта так и быть оплачен отдельно через платную поддержку.
И так история разбора протокола одного трекера....
При этом не использовались методы обратного инжинеринга, подобного декомпиляции программного или аппаратного продуктов. Все данные получены через наблюдение данных отображаемых устройством и передаваемых через usb шину. Замечалось что на экране показывается и какие пакеты идут с устройства к программе и уточнялись примерно по показаниям программы особенности данных, такие как примерное распределение значений данных и предположения как можно было реализовать с нуля и как можно хранить эти данные. Как результат единственно используемое средство это слежение за трафиком и просмотр общедоступных данных отображенных на устройстве и статистика на сервере.
Общая структура системы была такова: устройство в виде ремешка с экраном на котором отображались количество шагов, расстояние пройденное за день и потраченные килокалории. В полночь карета превращалась в тыкву и все значения на экране обнулялись. Связь с внешним миром у устройства была только через usb, есть другие версии устройств с Bluetooth, но у меня было только подобное.
Существовали различные приложения для этого устройства:
- Приложение под мобильную платформы, через otg на android не заработало, так как не видело устройства. Содержало не очень приятную особенность, получало почти все возможные разрешения, зачем оно ему нужно, не знаю.
- Под iphone не проверял так как такого в наличии у меня не было, сказать ничего не могу.
- Поэтому осталось только приложение под windows. К сожалению именно так под линукс не было, но на результат это впрочем не влияло. Поэтому пришлось скачать альфа версию десятки и поставить на виртуалку. Приложение выполняло роль посредника вычитывало данные с трекера и синхронизировало их с сайтом. И содержало ссылку на сайт, где можно было просмотреть эти данные.
Для того чтобы дамп стал возможен нужно добавить своего пользователя в группу (vboxusers для debian), которая дает virtualbox захватывать на себя usb устройства по фильтру. Поэтому нужно уточнить тип устройства с которого будем снимать трафик и внести его в список устройств которые нужно пробросить в виртуальную машину и добавить себя в группу. После этого устанавливаем windows и программу обслуживания трекера. После этого нужно начать вычитывать данные с файла в который сохраняется весь трафик с шины.
Для сохранение трафика устройства ищем свое устройство в /sys/kernel/debug/usb/devices или lsusb, в моем случае это был преобразователь последовательного порта в usb именно так оно отображалось в системе, обращаем внимание только на номер шины, так как мы будем сохранять все пакеты на шине (должно быть что-то подобное Bus=04) и запускаем сохранение этих данных вычитывая /sys/kernel/debug/usb/usbmon/4u, перед этим вызывать modprobe usbmon. Или через tcpdump -i usbmon4 -w usblog.pcap как уж будет удобнее. Я выбрал первое.
После этого я начал анализировать пакеты, которые идут устройству и выявил, что общение всегда начинается похожего на статусный пакет, в ответ на который всегда возвращается номер трекера и еще пара байт, которая до сих пор непонятно для чего предназначена.
Следующим шагом нужно было понять, с какими параметрами происходит соединение, по сохраненному трафику это было не понятно, так как средство, которое я использовал для визуализации, не содержало фильтров для подобного трафика. Поэтому проверил набор стандартных скоростей и характеристик потоков и одна из скоростей подошла. Если бы не подошла, то пришлось бы все же посмотреть на код драйверов для этого преобразователя чтобы расшифровать технический трафик.
Попробовав отправить наш статусный пакет трекеру, и получив тот же самый ответ, что и в нашем трафике - я понял, что на верном пути, параметры связи совпали и можно пробовать следующие пакеты.
Следующим шагом было несколько раз сбросить устройство с интерфейса и установить часы, это были единственные пункты подразумевающее действия, на которые может повлиять пользователь. Запомнив время в которое выполнялись эти команды, стало возможным отфильтровать эти 2 команды. И можно было начинать разбираться с форматом пакета. По дампам на устройство всегда уходили 17 байтные пакеты, первый байт был постоянен в одно значение для всех пакетов. Второй байт зависел от команды, трое из которых мы отфильтровали (были еще, но на данном этапе они были не важны). Затем 14 байт предположительно данных завершающихся нулем и один байт, похожий на хеш сумму так как изменялся в зависимости от данных, и для одного значения устанавливаемых часов всегда совпадал, как и для других команд, на содержимое которых мы не могли влиять.
Поэтому я предположил что это crc8, по сути, единственный хеш который приходил в голову сразу, и начал искать его реализацию или сайт, которые могут посчитать хеш по уже известным данным. Проверив данные, что у меня есть на соответствие по результату crc, оказалось, что не угадал. На одном сайте был пример простейшего хеша заключающегося в сумме всех байт по модулю 256 и он подошел к уже известным пакетам. И проверив это предположение попытавшись отослать немного измененный пакет для установки времени и время установилось в том виде что указывал в пакете. И теперь можно разбираться с форматом этого времени, по внешнему виду значения всех чисел в дате было в классическом человеко-читаемом виде(не секунды с начала эпохи) в bcd формате когда в полубайте храниться десятичное число и в hex виде совпадает посимвольно обычному десятичному числу.
После этого осталось три не опознанных пакета, первый всегда предшествовал остальным двум и содержал 4 не нулевых байта, и после выполнения остальных команд это число уменьшалось, поэтому я предположил, что это количество дней содержащихся в памяти. Остальные две команды возвращали одна большой дамп каких-то пакетов и одна только один пакет. Посмотрев статистику за предыдущие дни - я увидел, что интервал для данных меньше часа и предположил что первая это как раз дамп по времени, а вторая какой-то итого. Так первая выдала больше одного пакета я начал высчитывать эти данные несколько раз, и заметил, что всегда возвращается 96 пакетов и в каждом пакете был увеличивающийся байт. И тут можно предположить, что оно возвращает значения по 15 минутный интервалам за день. Так данные показываются на индикаторе только за сегодня я провел эксперимент, делая шаги и замечая когда и сколько их я сделал. В результате я узнал что среднее значение в этом пакете это шаги.
Далее я обратил внимание, что в этих запросах на дамп байт после кода команды увеличивают. И сделав запрос с циклом от минимального 0 до максимально значения, которое было в дампах полученных вначале, можно было сделать вывод, что это день начиная от сегодня. Но оставалось понять, что делает вторая команда, если она всегда возвращает нули. И на следующий день я обнаружил, что мой трекер забыл предыдущее дни, и тут меня осенило - это удаление дня из памяти. И оставалось понять, как 4 байта описывают заполненность памяти и почему на 3 возвращается только 2 дня, на 7 только 3, а на следующий по счету день вместо 96 пакетов приходит один и байт после кода команды другой. Методом не сложных умозаключений, смотря на hex код, я понял, что это не количество, а маска заполненности памяти.
Теперь осталось понять самую малость, что за остальные два числа в режиме бодрствования и что за данные в режиме сна. (Трекер имеет два таких режима, и в режиме сна шаги не считает, но проверяет качество сна, если верить графикам). Первый случай решился достаточно просто, я решил просуммировать оставшиеся числа в столбик, и оказалось, что это расстояние и затраченные энергия. Перед этим я думал, что это какие-то слагаемые шагов, так как иногда сумма этих чисел была равна шагам, но эта идея отпала когда я выяснил, что это не корректно - сумма крайних столбцов не равна среднему. Для определения, где старший байт, а где младший - я сделал более 300 шагов за интервал и там, где появилась эта единица то и старший разряд.
А теперь сон, при включенном сне один байт после кода операции меняется это выявить оказалось достаточно просто, но что делают остальные байты, которые не всегда нули и наверное что-то значат? Попытка включить режим сна и походить привела к тому, что этот интервал засчитывался как бодрствование. Данные по графикам на сайте были не точны, но каждый вид активности глубокий сон или легкий отображался другим цветом и сравнив данные на графике и распределение чисел в дампе по интервалу построив график в libreoffice calc получилось, что это значения по какому-то интервалу. Но остался вопрос размерности этих чисел, может быть один байт если это не шаги и большого уровня данных быть не должно осталось только это каким-то образом проверить.
Как понять тип сна я смоделировать не мог, так не мог сравнивать, вид сна на экране не отображается, только то что мы в режиме сна.Чтобы понять безопасность сервиса, я решил посмотреть, что и как отправляется на сервер, оказалось, что ничего шифровалось. И данные в режиме сна идут побайтно, получается это значение в интервале около 2 минут. Остались личные данные вида роста, пола и веса, но изменение их на сайте не создавало новых пакетов, поэтому я решил, что они обратно не передаются.
Вот и вся история, если нашли ошибки в рассуждениях пишите... Буду благодарен за уточнения и пожелания.
