RTKlib/постпроцессинг

HTC Athena тоже работает по умолчанию на NMEA/57600, и тоже после переключения
в internal boot mode после MID148 или же с помощью соответствующего GPIO
на sirfmemdump не реагирует. Тут что-то не так, видимо какой-то нетривиальный баг
в sirfmemdump. Я еще раз посмотрел на перепрошивку GPS из SPL, о котором писал ранее.
Проблема с SHA1+RSA (по-блочная цифровая подпись) пропала после перепрошивки на SPL-1.20Olipro, но
остается проблема с “security level”. По какой-то причине он равен 0x32 (48)


Level = 32

а должен быть =0.
Эта проблема гораздо проще RSA, и была решена на других телефонах HTC
с помощью т.н. goldcard, т.е. шифрованного блока из 128 байт в начале SD карты
создаваемого из SD CID с помощью DES. Сам ключ для DES находится в SPL,
и для многих моделей присутствуют в знаменитом файле typhoonnbfdecode.pl
Но Athena там нет, и я что-то пока не понял как их найти.

Упс… Мож я как-то не так выразился. Ничего относящегося к GPS/ГЛОНАСС и т.д. я не разрабатывал. :slight_smile:
А так программист и в некоторой степени железячник.

GPS модуль Telit JN3 с ПАТЧ-антенной 15х15мм параллельной плоскости экрана.

А софт эхолота судя по всему поддерживает и SIRF и U-blox модули, ибо на разъём к которому можно подцепить внешний ЖПС модуль эхолот порой посылает строки инициализации типа
$PUBX,41,1,0007,0003,38400,0*20
для U-blox-модуля

и
$PSRF100,1,38400,8,1,0*3D
для SIRF-модуля

Т.е. sirf4 с 5Hz. А какой там процессор ? OMAP ?

Я скачал наугад 3 прошивки (786, 798 и ONIX) с сайта Humminbird.
786 поддерживает только ublox, 798 и ublox и sirf, а на ONIX вообще песня:
полный дистрибутив Linux для TI814x, с xserver-kdrive и qt-4.7 :sunglasses:
http://arago-project.org/wiki/index.php/Main_Page

Edit

У 898/998/1098/1198 тоже Linux на OMAP3530 с 512MB RAM и 24MB VRAM и


root:41YEYwkWSNZXE:0:0:root:/home/root:/bin/sh

В конце концов удалось успешно перепрошить sirf3 на HTC Athena через SPL с помощью HTCFlasher.
Проблема была в том, что .nbh файл должен быть 512 bytes aligned (CurLen=0x200, так считает
встроенный алгоритм CRC32). Я добавил в конец к созданному с помощью yang .nbh
файлу нулей, чтобы первая цифра в команде wdata делилась на 512, и все заработало.
(FSEND: [wdata 4ae00 1ee74382])
Тут дается неправильная информация http://forum.xda-developers.com/wiki/Hermes_BootLoader
по команде wdata: ее формат на новых устройствах (в том числе и HTC Hermes)
не wdata [[Len [StartAddr]]], а wdata block_Len block_CRC32, при этом должно быть
выполнено условие block_Len mod 512 = 0, чего HTCFlasher не делает (баг!).
В HTCFlasher похоже есть еще один баг, что он не дожидается пакета -GPS_Firmware_Update (%d)
а после последнего посланного блока говорит Done! FSEND: [ResetDevice],
так что такой способ перепрошивки не для слабонервных :sunglasses:
Видимо целесообразно уменьшить константу RUUBLOCK с 1 MB на значительно меньшее
значение, ведь UART на 115200 не так быстр, как встроенный flash,
для которого был написан HTCFlasher, а SREC файл все-таки ~1.5MB.
Но такой метод работает, а sirfmemdump в современном виде нет.


$ ~/htc-flasher-read-only/src/HTCFlasher -v -F RUU_Sign3d.nbh
=== HTCflasher v3.1
=== Open source RUU for HTC devices
=== (c) 2007-2008 Pau Oliva Fora   

[] Verbose mode enabled
[] Flash NBH file 'RUU_Sign3d.nbh'
[] Setting RUU mode, please wait............done

FSEND: [password BsaD5SeoA]
GET:
[   
00000:  50 61 73 73 2e 0d 0a 0d 48 54 43 53 54 20 20 20  |Pass....HTCST   |
00010:  7f da c8 d2 48 54 43 45                          |....HTCE        |
]
[] SPL auth result (T=True, F=False): T

FSEND: [progress 0]
   0% [----------------------------------------------------------------------]
FSEND: [wdata 100000 caa37e1]

RSEND: [HTCS]

RSEND: [HTCE]
GET:
[   
00000:  48 54 43 20 4b 65 79 0d 0d 0a 49 6d 61 67 65 30  |HTC Key...Image0|
00010:  20 54 79 70 65 3d 30 78 38 31 30 2c 20 4f 66 66  | Type=0x810, Off|
00020:  73 65 74 3d 30 78 32 30 30 2c 20 4c 65 6e 67 74  |set=0x200, Lengt|
00030:  68 3d 30 78 31 34 41 30 30 30 0d 0a 53 65 74 20  |h=0x14A000..Set |
00040:  4e 42 48 20 74 61 67 0d 0d 0a 43 75 72 4c 65 6e  |NBH tag...CurLen|
00050:  3d 30 78 32 30 30 2c 20 30 78 31 34 41 32 30 30  |=0x200, 0x14A200|
00060:  0d 0d 0a 48 54 43 53 01 00 01 00 00 00 00 00 3b  |...HTCS........;|
00070:  d3 f6 07 48 54 43 45                             |...HTCE         |
]
 
[] WDATA BLOCK RECEIVED OK

FSEND: [progress 77]
  77% [#####################################################-----------------]
FSEND: [wdata 4ae00 1ee74382]

RSEND: [HTCS]

RSEND: [HTCE]
GET:
[   
00000:  43 75 72 4c 65 6e 3d 30 78 32 30 30 2c 20 30 78  |CurLen=0x200, 0x|
00010:  31 34 41 32 30 30 0d 0d 0a 4c 61 73 74 20 70 61  |14A200...Last pa|
00020:  63 6b 61 67 65 0d 0d 0a 2b 47 50 53 5f 46 69 72  |ckage...+GPS_Fir|
00030:  6d 77 61 72 65 5f 55 70 64 61 74 65 28 30 29 0d  |mware_Update(0).|
00040:  0d 0a                                            |..              |
]
 
[] NBH PART ENDED

Done!

FSEND: [progress 100]
 100% [######################################################################]
FSEND: [ResetDevice]

Конец успешной перепрошивки sirf3 GPS на HTC Athena с помощью HTCFlasher
(без hexdump):


-GPS_Firmware_Update (0)
Restore SiRF GPS complete
CurLen=0x14A200, 0x14A200
Clear NBH tag
NBH Update Complete
HTCS
HTCE

Еще раз перепрошил телефон для чистоты эксперимента.

Теперь думаю в плане железа вернуться к старому (т.е. до октября 2013 года)
трекеру Globalsat TR-600GLONASS. После этой даты из них выкинули изделие NVS-CSM
и заменили на дешевый китайский MT3333. Хотя разводка на плате осталась,
и “старый” модуль можно впаять выкинув MT3333.

вышла прошивка c Galileo
u-blox M8 Firmware v 3.01
https://yadi.sk/d/iK6GjTqSnkMuf

В release notes добавлены новые сообщения с криптографией и unique id.

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                                                                                   

Прикольно, надо допиливать. Жаль цена теперь стала ощутимой.

RXM-RAWX (0215) в прошивке есть, надо только суметь его активировать
(без RAM патча, которого теперь нет).

Нет самой возможности или просто адреса ещё не найдены?

Нет возможности модифицировать RAM, адреса же лежат рядом с идентификаторами,
их искать не надо. Официальный путь, как я понимаю, это изменение LLC,
но там можно нарваться на серьезную криптографию, а не на дедский сад
как в CFG-LIC. Можно конечно прямо во флеше поменять адрес какого-нибудь
левого сообщения на адрес raw, и пользоваться потом этим левым сообщением
после перепрошивки. Fletcher64 остался как и был, но не исключена еще
какая-нибудь цифровая подпись текста (как в старой доброй гисруссо :sunglasses:)

Т.е. там какие-то хеши есть в самом чипе отдельно от прошивке?

Раз они считают 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).
Алгоритм естественно неизвестен, но так как само кодированное сообщение известно,
то это интересная тема для дипломной работы по криптоанализу :sunglasses:

Из 9 “видимых” спутников Galileo (E11, E12, E14, E19, E20, E22, E24, E26, E30)
я (но это может сделать любой с NEO-M8N и совместимыми как Navilock NL-8*)
уже отследил E12, E22, E24, E26, E30. Интересно будет поглядеть на E14 с его эллиптической
орбитой, где эксцентриситет не помещается в битовое поле альманаха.

Edit
LLC это TXT сообщение типа


$GPTXT,01,01,02,LLC 7FFFFFFF-FFFFFFED-FFFFFFFF-FFFFFF9E-FFFFFF69*2D

состоящее из 5 полей


Low-Level configuration
  Communication section    0xFFFFFFFF
  Clock section            0xFFFFFFFF
  Clock offset             0xFFFFFFFF
  Software feature section 0xFFFFFFAE (3)
  Generic section          0xFFFFFFFF

Оно действительно шифровано или там просто мусор? УЦентр как-то реагирует на него, ну там пароль для расшифровки спрашивает?

Правильно шифрованное сообщение от мусора статистически неотличимо.
УЦентр выдает такую последовательость пакетов
2700(68 байт) 0213 (48 байт) 2700(68 байт) 0213 (48 байт) … 2700(68 байт) 0213 (48 байт)
Для 0215 (в представлении 2700) байтов естественно больше, но длина всех пакетов кратна 16.
Внутреннюю структуру надо более внимательно изучать, но они вроде все начинаются с 2
(версия пакета?) и остальное выглядит скорее как заголовок + простой XOR, так как многие позиции
не меняются во времени.

Все парсеры UBX сообщений находятся в UBX.dll, и для
0x2700 там ничего нет.

Ну чтобы попытаться разгадать, надо как минимум сплиттер и два девайся с грязным хаком, или на худой конец с 7/6 версии. Хотя для начала можно проверить CRC считается для этого сообщения правильно, а то вдруг оно считается для правильного содержимого :slight_smile:

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).