andru8, после внимательного прочтения Release Notes у меня есть пара вопросов:
работает ли теперь RXM-SFRBX всегда по умолчанию,
и есть ли на ваших приемниках RXM-RAWX ?
TRK-MEAS/TRK-SFRBX похоже из прошивки убрали, и также UPD-UPLOAD, UPD-DOWNLOAD и UPD-EXEC
(последние три под полунадуманным предлогом),
а после каждого UBX сообщения идет сообщение 27,0 с хешем.
За 5 минут моего тестирования новой прошивки затрекались 2 спутнега Galileo: E26 (operational)
и E24 (In commissioning) https://en.wikipedia.org/wiki/List_of_Galileo_satellites
Декодера I/NAV subframes в rtklib не имплементировано:
2 ubx rawsfrbx galileo nav not supported sat=80
2 ubx rawsfrbx galileo nav not supported sat=82
Нет возможности модифицировать RAM, адреса же лежат рядом с идентификаторами,
их искать не надо. Официальный путь, как я понимаю, это изменение LLC,
но там можно нарваться на серьезную криптографию, а не на дедский сад
как в CFG-LIC. Можно конечно прямо во флеше поменять адрес какого-нибудь
левого сообщения на адрес raw, и пользоваться потом этим левым сообщением
после перепрошивки. Fletcher64 остался как и был, но не исключена еще
какая-нибудь цифровая подпись текста (как в старой доброй гисруссо )
Раз они считают SHA в железе, то я бы не удивился.
Не зря там есть такая фраза
INCOMPATIBLE HARDWARE -> NO GNSS OPERATION
Меня интересует опыт других людей, т.к. у меня raw и так работает out of the box.
Кстати в новом мануале по ublox-m8 тоже
почему-то правильный LLC (страница 3 внизу), хотя официально
так быть не должно. Акционеры должны настучать автору по голове.
На самом деле все обстоит несколько не так. Сообщение RXM-SFRBX доступно всем и везде.
Сообщения RXM-RAWX, TRK-MEAS, TRK-SFRBX тоже в прошивке, но в зависимости от
битов LLC выдаются в нормальном виде, или в виде недокументированного
шифрованного контейнера (0x2700).
Алгоритм естественно неизвестен, но так как само кодированное сообщение известно,
то это интересная тема для дипломной работы по криптоанализу
Из 9 “видимых” спутников Galileo (E11, E12, E14, E19, E20, E22, E24, E26, E30)
я (но это может сделать любой с NEO-M8N и совместимыми как Navilock NL-8*)
уже отследил E12, E22, E24, E26, E30. Интересно будет поглядеть на E14 с его эллиптической
орбитой, где эксцентриситет не помещается в битовое поле альманаха.
Правильно шифрованное сообщение от мусора статистически неотличимо.
УЦентр выдает такую последовательость пакетов
2700(68 байт) 0213 (48 байт) 2700(68 байт) 0213 (48 байт) … 2700(68 байт) 0213 (48 байт)
Для 0215 (в представлении 2700) байтов естественно больше, но длина всех пакетов кратна 16.
Внутреннюю структуру надо более внимательно изучать, но они вроде все начинаются с 2
(версия пакета?) и остальное выглядит скорее как заголовок + простой XOR, так как многие позиции
не меняются во времени.
Все парсеры UBX сообщений находятся в UBX.dll, и для
0x2700 там ничего нет.
Ну чтобы попытаться разгадать, надо как минимум сплиттер и два девайся с грязным хаком, или на худой конец с 7/6 версии. Хотя для начала можно проверить CRC считается для этого сообщения правильно, а то вдруг оно считается для правильного содержимого
To avoid any misunderstandings by google translate, i will write it in english.
I have got full raw Galileo datastream with the 3.01 firmware on NEO-M8N, but it is a special hardware setup
which i don’t want to disclose. This data is not yet validated.
The proper generic solution should consider dissecting the SEC-0 packet contents (0x2700).
Хм… может и давно, но нас заметили, на странице поддержки ссылка на нас, правда не на эту тему, а русский раздел.
А вообще залез почитать о проблемах на гитхабе про глонасс.
/* тут были разные грязные мысли про PPP-Static */
{2 0 len_lo len_hi} (len-1)/16*16 [16] ← 128бит + xor + permutation + [sha256?]
лучше не трогать, сделано явно для галочки. кому надо тот сам разберется.
Thank you very much.
It seems the RAM (around 300kB) is very large compared to other cortex-M3 designs.
I’ll try to find the code related to Peripherals like uart1