сбакаплено отсюда https://www.drive2.ru/l/719488249575260613/
Clarion QY-7204+. Патч GPS для исправления календаря.
В августе 2025 в процессе настройки подключения к opencarwings было обнаружено, что календарь в магнитоле синхронизируется в 2006 год (как выяснилось позже, на 1024 недели назад) и не хочет от туда возвращаться даже после ручной установки актуальной даты. Как следствие, пропала возможность настроить таймеры заряда и климата: при заходе на экран настроек таймеров, система просит произвести синхронизацию времени и сама тут же говорит, что синхронизация невозможна.

Причина проблемы описана там же по линку выше. Здесь расскажу о решении. Самый простой способ лечения — отключить антенну GPS или спрятаться от спутников под крышу или в паркинге и настроить время вручную в сервисном меню. Но при выезде из паркинга дата опять синхронизируется назад в прошлое, а если отключите антенну, то потеряете возможность иметь в машине всегда точные часы, что хоть и не смертельно, но весьма уныло.

Помочь согласился товарищ YDean. И на мой взгляд задачу он решил весьма изящно, хотя сам назвал это решение грязным хаком, модифицирующим оригинальный буфер.
То есть, в подмененную SetSystemTime передать не структуру со временем, а оригинальный пришедший буфер, а уже внутри надругаться над ним.

Взять сам патч можно здесь https://drive.google.com/drive/u/0/fold … RHuBtzabA_

Внутри готовый образ памяти nb0 для японской QY-7204 протестированный мною лично в течении нескольких месяцев и готовый для помещения в нанду магнитолы такой же модели. nb0 нужно положить в бакап образа нанды магнитолы и пересчитать SUM4, как я рассказывал тут
https://www.drive2.ru/l/676021531272284166/
а потом зашить бакап обратно в магнитолу. Зашить правленый бакап в нанду можно с помощью обновлятора ханави
https://telegra.ph/Xanavi-restore-firmware-10-01
или с помощью сдтулзы финского товарища.
https://github.com/developerfromjokela/leafsdtools

Других магнитол у меня нет, так что если вам это нужно на магнитолах 72хх других рынков и моделей, то можете пропатчить вашу магнитолу по тому же принципу по инструкции ниже. На прошивках ханави этот nb0 тоже не заработает, ибо хоть магнитола и японка, но их прошивка построена из европейки, так что пинайте их чтобы патчили и присылали вам обновления, ну или сами по образу и подобию…

Дальше расскажу очень скучную и далеко не всем неинтересную историю, как он был получен. Конечно с большим количеством непонятных слов и технических подробностей…

Те, кто ознакомился с сутью проблемы уже поняли, что проблема аппаратная и скрыта в прошивке чипа GPS. Вскрывать магнитолу и писать новую фирмварь для древнего чипа без документации конечно никому не улыбалось, потому YDean предложил подменять значение недели именно в потоке приходящем в проц по уарту в момент получения данных с GPS.
Если рассуждать логически, время должно поступать в систему через драйвер GPS, заглянем в реестр и найдём кто это:
[HKEY_LOCAL_MACHINE\Drivers\Launch\Navigation]
"Index"=dword:1
"Order"=dword:9
"Dll"="navdrv.dll"
"Prefix"="NAV"

Если заглянуть внутрь этого navdrv.dll, в нём видно SetGpsData. А в COREDLL.DLL::SetSystemTime. SetSystemTime — функция стандартная, но нам интересно кто ею пользуется.

Для начала настроим гидру видеть правильно:
CFF explorer : Section headers смотрим .data RelocAddress
В гидре Window- > Memory map
.data move to another address
Вписываем этот. Потом делаем анализ заново. Выглядит теперь красивее.

Для вникания, как устроено время "глазами" GPS посмотрим этот кальк:
www.labsat.co.uk/index.php/en/gps-time-calculator

Пишут, что номер недели может быть зашит в ПО timetoolsltd.com/gps/what-is-gps-time/
То есть, какие-то миллисекунды приходят. Они из них высчитывают номер недели, меняют на свой, и запихивают обратно в миллисекунды, а потом из них делают системную дату.
Напоминает анекдот про костыли и велосипеды в ай-ти. И так будет еще не раз)

week mod — это просто week по модулю 1024
1356=54С, week mod 1024 = 14C (убрали 400h)

Судя по чтению буфера, проблема совсем не в navdrv, а в железе или в драйвере, прикрепленном к этому железу — serial_scif.dll
Но драйвер также прикреплён к другим устройствам, значит он должен менять своё поведение в зависимости от устройства.
Внутри него есть имена типа "SCIF7", но надо смотреть, зависит ли поведение от них.
Если же проблема в железе, то придется ставить заплатку на SetSystemTime в navdrv.
Прокладку писать вместо COREDLL.
Вызов SetSystemTime заменить на свою функцию, которая будет делать SystemTimeToFileTime, потом прибавлять к FILETIME разницу между реальной и отображаемой датой/временем и обратно FileTimeToSystemTime, а потом уже SetSystemTime с новым значением.
И для этого надо в авто посмотреть разницу с реалом. Что оно показывает, а сколько времени на самом деле.

получаем результаты эксперимента:
09.09.2025 20:43 === 24.01.2006 15:43
1DC21CA548E6200 === 1C620FCDAB85A00
разница в часах из-за часового пояса (UTC+5).
09.09.2025 15:43 если взять то же время, то получается
1DC21A06BB85A00 (хвост тот же)

разница = 1600A391000000
Это число в 100-nanosecond intervals

/10 -> мкс
/1000 -> мс
/1000 -> с
/60 -> 10321920 min
/60 -> 172032 hour
/24 -> 7168 day
/7 -> 1024 week
таки сходится!

В navdrv.dll патчим COREDLL на COREXLL
Возвращаем в прошивку, и туда же добавляем файлом COREXLL.dll
navdrv.dll можно не вытаскивать, а патчить прямо в прошивке, потому что строка coredll лежит в секции кода несжатой.
Надо ориентироваться по соседним строкам.
Для 214 это NB04.nb0 по смещению 1F2FF4 1FC974.
Искал по строке рядом CApi_GetCurrentIlluminationMode

Во время патчинга случился смешной казус, по невнимательности я вместо драйвера GPS пропатчил lcddrv.dll, а это драйвер дисплея. Патч зашился, но тормозил невообразимо, синий экран (это когда магнитола включена без сдкарты) загружается минуты 2 (до патча магнитола до синего экрана загружается практически моментально после включения).
загрузки до скина за полчаса так и не дождался, пришлось разбирать бороду, чтобы тестпин заземлять и отшиваться…

Как определить, где какой файл или модуль лежит?
они поделены на секции, которые разбросаны по всей прошивке.
Секция .text тут обычно не сжатая. Значит, ее надо поискать в физич карте по имени модуля.
Кстати, ее там же можно исправить в 16ричном виде.

Справа в окошке написана dataptr — это то, где содержимое лежит. Вычти начало проши — получишь смещение. А то, что в карте написано о32 это сама структура, которую ты видишь в окошке справа.

В итоге чего сделано:
navdrv.dll пропатчен чтоб в SetSystemTime передавался сырой буфер с датой/временем.
SetSystemTime перехвачена в COREXLL.
Она преобразует сырые данные в SYSTEMTIME, конвертит ее в FILETIME, добавляет 1024 недели, конвертит обратно и заменяет сырые данные буфера на правильные.
Потом добавляет секунду и устанавливает это время в систему (у них в оригинале так).
=====================================================
BOOL
WINAPI
my_SetSystemTime (
BYTE *p
)
{
// нам приходит буфер, прочитанный из порта с неправильной датой

SYSTEMTIME st;
st.wYear = 2000 + p[0x10];
st.wMonth = p[0x11];
st.wDayOfWeek = 0;
st.wDay = p[0x12];
st.wHour = p[0x13];
st.wMinute = p[0x14];
st.wSecond = p[0x15];
st.wMilliseconds = 0;

union
{
ULARGE_INTEGER li;
FILETIME ft;
} ft;

// преобразуем дату в правильную:
SystemTimeToFileTime(&st, &ft.ft);
ft.li.QuadPart += 0x1600A391000000ui64;
FileTimeToSystemTime(&ft.ft, &st);

// запихиваем обратно в буфер
p[0x10] = st.wYear%100;
p[0x11] = st.wMonth;
p[0x12] = st.wDay;
p[0x13] = st.wHour;
p[0x14] = st.wMinute;
p[0x15] = st.wSecond;

// но системное время у них на секунду больше
ft.li.QuadPart += 10000000ui64; // +1сек
FileTimeToSystemTime(&ft.ft, &st);
return SetSystemTime(&st);
}
}
=====================================================
Эта версия сделана из предположения, что сырые данные с датой сохраняются еще где-то, и потом разбираются в другом месте. А здесь в navdrv они используются только для установки системного времени. Поэтому мы их портим до сохранения "где-то еще". Через 20 лет надо будет в corexll увеличить добавку вдвое… Будем надеяться, что еще 20 лет эти магнитолы тупо не проживут)

ну вот так как-то.