Привет,

Нужна помощь в определении параметров либо самого алгоритма подсчета CRC, мозг уже кипит, новые идеи закончились

История: Мучаю протокол общения между приложением на Android и 3-х осевым стабилизатором. Из коробки была заложена функция съемки 3х3 панорам, но как обычно результат оказался слишком далек от ожиданий, по этому взялся за самостоятельную доводку и превращению стабилизатора в паноголовку.

Со стороны приложения я уже уперся в стену, так как оно обфусцировано, плюс это только загрузчик, а дальше дебри на которые моих знаний уже не хватает. Но оно мне и не очень нужно, так как при помощи btlejuice снял протокол и уже частично его разобрал как на отдельные команды, так и примерно по составу данных в команде. Пример нескольких посылок одной и той же команды перемещения
24 3c 08 00 18 12 1b 01 35 c0 54 f2 fc bc
24 3c 08 00 18 12 27 01 35 c0 00 00 b5 95
24 3c 08 00 18 12 34 01 35 c0 ac 0d 6f c8
24 3c 08 00 18 12 40 01 35 c0 ac 0d 52 8b
24 3c 08 00 18 12 57 01 35 c0 54 f2 0f dd
24 3c 08 00 18 12 62 01 35 c0 54 f2 82 b1
24 3c 08 00 18 12 6e 01 35 c0 00 00 47 b7
24 3c 08 00 18 12 7a 01 35 c0 ac 0d dc 22

Первые 6 байт — условно MAC, на самом деле вероятно нет, но в данном случае это константа для ВСЕХ команд с этим устройством
7 байт — порядковый номер отправленной команды по порядку
8 байт — почти во всех командах это 1, поймал только одну с 0.
9 байт — ID команды
10 байт — некоторое магическое значение c0 для почти все видов команд
11-12 байты — значение угла поворота в попугаях (INT16 / Little Endian)
13-14 байты — ожидаю тут контрольную сумму, так как значение меняется даже если в команде поменялся только 7 байт.

На https://crccalc.com/ перебрал уже всевозможные варианты длины строки для расчета и поигрался с порядком байт, но все бестолку. Также не смог получить одинакового CRC при расчете его по срокам разных команд уже с имеющимся в нем CRC. Направьте на новую идею для исследования пожалуйста.