Mine didn't advance at DST but its currently only 2 minutes ahead now.

 

Just pull the fuse under the dash (#7 backup - on my 07 TL Type S) and place it back in at 1:00 and all good.

 

Ditto ! I've had my TL since May 1st 2004.
.

 

Possibly dumb question, but do you mean modifying the DVD's image to correct the time problem without a hardware solution (killer work, BTW)? The clock in my 07 TL-S is losing a minute per week after pulling the battery during the last DST, and it's driving me nuts. I don't think think the change in August is going to correct the time drift.

 

I just did the power reboot at 1:00 work-around on my 2006 Accord. So haven't had a chance to see if there is a time "drift" yet. I'm hoping the update in August will fix this mess,

 

Good luck, and hopefully yours doesn't drift. It's annoying, to say the least. I'm also holding out hope that things correct themselves in August, though I have a feeling that I'll be disappointed.

 

i don't know if i'm into something or not, but my clock is completely fixed. one day i accidentally grabbed the wrong set of keys with a wrong fob. i got in the car and everything was reset - climate control, seat, etc. i thought maybe somehow i lost power and didn't think much of it until later i realized i had the wrong fob.

couple of days later i noticed my clock is on the dot! it was off maybe 10 minutes before, but now it was true.

 

I swear I read that others with 04-06 TLs had this happen, but the issue persists for 07-08 TL/TL-S owners.

 

Yea what year TL do you have?

the issue is supposedly fixed with 04-06.

 

Massive thanks to @DogP for all his research.

I've done the hardware fix on my 8th Gen Civic, and ported the code over to Arduino: https://github.com/dsclee1/HondaSatNavClockFix

Had a play around with the software too, and had limited success.

 

Very cool... nice work!

BTW, I noticed you mentioned RE'ing the original software in Ghidra. I also went through that exercise, and I believe the code that needs to be changed is on the WinCE system side, not the navigation application side (I also made several changes to Furuno related code on the application side, with no noticeable change).

I don't know about the Civic, but on the TL, we have 09touch.bin and 09touch2.bin. 09touch2.bin is the navigation application, while 09touch.bin is the WinCE system. Working on that binary is poorly documented, and likely less forgiving, so I've been very cautious. But once you extract that binary, you can find a lot of WinCE files, registry, etc., and more Furuno related code as well. I'd be glad to chat in more detail if interested.

DogP

 

On the Civic the files are the SMGA.bin and SMGA2.bin, and yes you're right, I extracted the SMGA2.bin and experimented with changes there. I came to a similar conclusion that the SMGA.bin (WinCE) file is probably where the changes are needed, but couldn't find a way to successfully extract the files. I managed to dump each block, but this didn't help too much as I still couldn't read the blocks correctly in Ghidra (I assume the blocks further contain DLLs/EXEs so the start address Ghidra is trying to read from is off, which means it fails to correctly identify the assembly instructions).

I've been using a tool called dumpnavi (https://github.com/ryangardner/dumpnavi), which is based off another piece of work called Bysin. It correctly extracts and allows patching of the SMGA2.bin files, but won't extract the SMGA.bin. Looking in SMGA.bin manually it appears as if the ECEC address (which should point to the ROM header containing the file details) maps to a location outside the extent of the bin.

I'd be interested to know what your extraction method is if you're happy to share?!

 

Yep... glad to share. I'll dig up my notes and post a bunch of stuff when I get home tonight. It's definitely a challenge to find info, and particularly tools that aren't dead links, for old WinCE stuff.

DogP

 

It's been a couple months since I messed with this, and it's taking a bit to remember where I left off... but gonna try a brain dump here anyway.

First, the 09Touch.bin file (like 09Touch2.bin) is a "B000FF" file. You can see the details of the format here: https://docs.microsoft.com/en-us/pre...ectedfrom=MSDN . I also noticed that dumpnavi couldn't handle 09Touch.bin... I think maybe it contains compressed files, unlike the 09Touch2.bin file. IIRC, the difference between the two files is that at boot, 09Touch.bin decompresses into RAM to run, while 09Touch2.bin runs from flash (Execute In Place). XIP doesn't work for compressed files. Basically, the 09Touch.bin file is the equivalent of a standard WinCE nk.bin file, which you can find a lot of info on. BTW, not sure which CE version yours runs, but in the case of the 07-08 TL, it's WinCE 4.2. You can still find some useful documentation here: https://docs.microsoft.com/en-us/pre...0900(v=msdn.10) . If yours is a different version, some of what I'm saying might be different or not work (I came across lots of tools, etc. that sounded useful, but only worked for 3.x, 5.x, etc).

Luckily, M$ provides tools for working with nk.bin files, but the most convenient way I found was this batch file here: https://forum.xda-developers.com/t/b...-easy.2078325/ . Note the comment at the end about dumprom.exe defaulting the machine type to MIPS R4000. Since I haven't tried reloading my modifications to the Navi yet, I don't know whether it's critical or not... but it's probably safest to modify the .exe to set the machine type to SH4, which is 0x01A6. Running this batch file should extract the 09Touch.bin file, allowing you to look at the files in Ghidra. You'll probably notice that it's not quite as RE friendly as the Navi application.

It's definitely worth checking out the registry (particularly default.hv). There's an application called mRegEdit that can open these (others I tried seemed to fail). You'll see references to SystemManager.exe:VddGPSReadThread and SystemManager.exe:SSD_GPSReceiverThread, and probably some other stuff you find interesting.

Inside the code itself, I think SSD_Server.dll is one place to start. You'll find a couple places where there's an obvious BCD to decimal conversion, in code called under a check for 0x75. This obviously looks like Furuno GPS related code. I have a note about CommonLibrary.dll maybe having CUtil_Time (SetTime, etc.) stuff, though didn't dig into that.

The part that I haven't actually tried is reloading a modified 09Touch.bin. I've been a bit short on time lately, and while modifying 09Touch2.bin seems to be forgiving, if I'm not careful, I think there's decent odds of bricking the Navi with a bad 09Touch.bin... in which case I'll have made a bunch more work for myself attempting to unbrick it. So, I guess I've been kinda dragging my feet. ;-)

There is an official tool for modifying this binary (binmod: https://docs.microsoft.com/en-us/pre...ectedfrom=MSDN ), though it only works on the FILES section. There may also be a bug, discussed here: https://web.archive.org/web/20200809...inmod.exe.aspx . I was able to "replace" the registry with the identical file, and 09Touch.bin was identical to the original file, so it may be possible to make simple changes like that. It didn't work when I tried the same with SSD_Server.dll (said "Error: File not found in image", which could be that bug, or more likely it's in the MODULES section). Maybe the data can simply be patched directly in the binary, but I haven't dug deep enough into it to see if there's a checksum, etc. that would have issues with this. There's an overview on sections, etc. here: https://social.technet.microsoft.com...compact-7.aspx .

Something else I noticed was that nk.exe looks to have support for an SMC9000 (at least SMC91C94 in particular, presumably PCMCIA) Ethernet adapter. I was planning to track one of these down to see if I could make it do anything interesting... just never got around to it.

Anyway, hopefully this is enough to get started, and let me know if you need any other info, or make any progress.

DogP

 

Oh, the other thing I meant to mention is that I never looked into why dumpnavi didn't work with the 09Touch.bin file... it's possible that fixing dumpnavi would be quicker, easier, better, and/or safer (since it does support updating the MODULES section). Or, maybe at least analyzing that code could tell what needs to be done to successfully do it. Unfortunately, getting that image modified is where I ran out of time.

DogP

 

Ah... progress! I was able to tweak dumpnavi to extract and update the 09Touch.bin file, both changing the default.hv and SSD_Server.dll (updating with the identical file produced an identical output, so I have some faith in the update procedure). I'll have to try actually making a change and reloading it to my navi to see if it actually works...

DogP

 

Success! At least for the dash clock annoyance...

I updated SSD_Server.dll in 09Touch.bin to add 10 years in the conversion, so it always thinks the clock is valid. You can see the GPS debug output still shows 2002, but the Navi system thinks it's 2012, which is a valid year, allowing the clock to update, and to be manually set. I disconnected my battery and confirmed it comes up correctly (you need to turn the car off and then back on once after receiving GPS to sync the clock, since it now thinks the default 1:00 is OK).

Of course this can be changed to add 20 years, so it's closer to the correct date (Sept. 2022)... though I'm going to see how difficult it'll be to fit a true conversion into the code.

I'd be glad to help if anyone would like to try this... preferably someone with experience updating their Navi (custom splash screen, etc.), or at least familiar with burning CDs, etc. And of course not afraid of bricking their Navi. It should be fairly safe, but I'm only 1 for 1 on doing this. ;-) BTW, my disc is the White 2015 DVD (version 4.D0)

DogP

 

I’m game to try it out on my 07 TL-S. I’m already running a burned copy of a 4.x white DVD (can get the actual version if I turn my computer on). I’ve never modified the nag screen, but work in IT for a living, so I can follow along easily.

 

I for one don't know why we bother to listen to this DogP dude, he clearly has NO idea wtf he's talking about (is there a limit in here on how many sarcasm emojis you can use, asking for a friend)?

But really sir, absolutely impressive knowledge. I have done this whole thing -

and I'm fine with doing that until August, but the time does drop off. I just did it roughly 2 weeks ago and I've lost 3-4 minutes. Wonder if that'll change in August. I have a feeling it won't.

 

It'll definitely "fix" itself mid-August, when the years rolls over to 2003. I tested that with a GPS simulator earlier in this thread: https://acurazine.com/forums/3g-tl-a.../#post16786756 . The date will still be wrong, but the clock will be back to normal.

DogP

 

I have no doubt that come mid August this will rectify itself (somewhat, I frankly NEVER used the calendar option so whatever) I guess my question is when this does happen do you think the time drop off will still occur? Like I said I did the whole 1pm/am reset roughly 2 weeks ago by doing the process I posted NOT by doing a battery disconnect, and well for 2-4 days the time was dead on. But I have lost about 6-7 minutes since. I'm just skeptical "that" will ever be right again, as in these mystery minutes disappearing will continue to drop, and therefore needing yet another reset.

 

Yes, in August the dash clock will begin to track the actual time from GPS again, and won't keep losing minutes.

Basically, the time coming from the GPS is still correct, but the computer doesn't "believe" it, because it's programmed to ignore the GPS if it says it's 2002 (likely because 2002 is the default year after the battery is disconnected, and the cars were made after 2002, so they expected 2002 means GPS hasn't sync'd yet). So, once GPS says it's 2003, the computer will believe that the clock is correct, and synchronize everything to GPS again.

DogP

 

BTW, if anyone wants to play with the code, images, etc. themselves, I created a fork of dumpnavi with my updates here: https://github.com/pdaderko/dumpnavi .

DogP

 

Fantastic, thanks @DogP . I should have checked back here a couple of days ago! I'll take a look a through.

There's a SuperH4 compiler that I've been experimenting with in Debian to create the Assembly bytes for the required date adjustment function. (apt-get install gcc-sh4-linux-gnu g++-sh4-linux-gnu)

The function I mocked up was this:
This is a modification of the code from the workaround note (https://content.u-blox.com/sites/def...-19016936).pdf) where I'd made use of a function I found in DiagAPI.dll that calculates the number of days since 1980-01-06, and an array I found containing the number of days in each month. Obviously we can't do this way now, as DiagAPI.dll won't be available from the context of the WinCE side, but I can take a look through SSD_Server.dll and see if I can find a duplicate function. This way we can save valuable bytes when trying to slot a new function in!

 

@DogP I've successfully used your version of dumprom to get the files out of the WinCE bin.

I've gone through SSD_Server.dll and unfortunately had no luck finding any useful "days since 1980" looking functions, so it looks like doing a patch to get the date correct is probably going to be a longer function, and hence more bytes that would need adding. Looks like a difficult job (more on this later)...

I did find a few interesting bits of code though, that will hopefully give you a bit more info. If you search through SSD_Server.dll for scalars of "2003" you'll find where Honda handily decided to make 2003-01-01 01:00:00 the beginning of time... Changing these to 2002 will more than likely make the clock work as well (rather than changing the year to 2012).

Here's one of the instances where it looks to me like Honda have earlier read in the date from the GPS byte stream, and are then checking if that date is greater than 2003-01-01 (this is ripped from the SMGA.bin so expect Ghidra name assignments to be different):
You'll see I've marked up the function with the 2003 as "CUtil_Time", this is my "best guest" of what's actually being called. I was hoping that the code would do some kind of transformation where the date and time would be converted to the number of seconds or days since a certain date, which would make the job of adding 1024 weeks nice and easy, but no such luck. CUtil_Time (in CommonLibrary.dll) seems to store the year/month/day/hour/min/second all as there separate components. So it looks like any patch will need to happen on the SSD_Server.dll to add in the appropriate function to convert the date to a "number of days since X" before adding the 1024 weeks and replacing the date components with their updated figures. - whether this is worth doing is a different question!

 

Cool, glad dumpnavi worked for you!

BTW, this is the function I modified... it's obviously a BCD to decimal conversion. E.g. year 2002 comes in as 0x02 - this function adds 200 to the upper nibble 0x0 then multiplies it by 10... then adds the lower nibble 0x2. I modified it to add 20 years (e.g. add 202 instead of 200 to the upper nibble), which puts us in Sept. 2022 instead of Sept. 2002. This is just changing a single byte in SSD_Server.dll from 0xC8 to 0xCA.
I agree 100% that it's probably not worth the effort to correctly fix the date to 1024 weeks, other than for the interesting exercise to do so. It'd make daylight savings work correctly, though with the discussion of eliminating daylight savings time, that may matter less soon. Of course it'll also fix the calendar (who cares), and maybe a few other minor things that Honda/Acura noted (navigation history, traffic/detours, Acuralink, etc). Overall, I don't think it'll be particularly difficult to write some efficient code for the conversion, though I haven't dug through the .dll to see if there's any code that can be stripped out. From a quick glance, I did notice ~400 or so bytes of 0x00s at the beginning of the file which I suspect are unnecessary and could likely be overwritten, and also a string of 94 bytes ("C:\PVCS\11Annual\SourceFiles\US\Touch(11MY_Annua l)\PF\Frameworks\dev\release_CE\SSD_Server.pdb") which I assume also doesn't need to be there.

I did send an updated file to @NTP66 this weekend for his 2012 Navi disc (4.A0), and he reported success... so I'm happy to say we're up to 2 for 2. ;-) I also checked the 4.62 disc that originally came with my car, and it has the same function (the binary is called 08Touch.bin instead of 09Touch.bin on that one).

I'll make a quick post in a bit in case anyone would like to modify their own file.

DogP

 

Here's a quick howto for modifying your own Navi disc to add 20 years, in effect allowing the dash clock to update correctly. Note that this adds exactly 20 years, not 1024 weeks, so the date is close, but not 100% correct.

• Download the updated dumpnavi from github: https://github.com/pdaderko/dumpnavi to a folder on your PC. You only need the "Release" directory with Bysin.exe and CECompressv4.dll .
• If you don't already have a hex editor, download and install one, such as HxD: https://mh-nexus.de/en/hxd/
• Remove the navigation DVD disc (turn the car on, press the eject button on the navigation unit in the trunk) and put the disc in your PC. Copy 09Touch2.bin, 09Touch.bin, A0000_00.MNG, PRG_INFO.MNG, DCA0.REG, and UPDATE_APL.exe to a folder on your PC. Note that 09Touch2.bin and 09Touch.bin may be named something different, depending on your disc (older white discs are named 08Touch2.bin and 08Touch.bin, other similar cars such as the Civic have other names).
• Copy 09Touch.bin to the folder with Bysin.exe . Open a command prompt in that folder and run:
  Code:

  bysin 09Touch.bin extract SSD_Server.dll

  (change 09Touch.bin to whatever your file is actually called, if a different version)
• Bysin should have created a new folder called "09Touch" with SSD_Server.dll in it. Move SSD_Server.dll up a directory to the same one as Bysin.exe and 09Touch.bin .
• Open SSD_Server.dll in your hex editor and search for hex values 53699463C8E0. There should be only one instance of it. Change the C8 byte to CA (don't make any other changes - you should then have 53699463CAE0 instead of 53699463C8E0). Save the file and close the hex editor.
• Run:
  Code:

  bysin 09Touch.bin updatemodule SSD_Server.dll

  to push your modified .dll file back into the 09Touch.bin binary.
• Copy this modified 09Touch.bin file into the same folder as the other files (09Touch2.bin, 09Touch.bin, A0000_00.MNG, PRG_INFO.MNG, DCA0.REG, and UPDATE_APL.exe), overwriting the original 09Touch.bin file. Burn these 6 files to a CD-R.
• Turn the car on, and insert your CD-R into the navigation unit. The unit should complain about a disc read error. Press and hold Map/Guide, Menu, and Cancel buttons until the diagnostic menu pops up (roughly 5 seconds). Click the "Version" button, and then the "DownLoad" button. This will load the updated navigation software... it takes several minutes, so don't turn your car off until it's done.
• Eventually, it'll finish updating and reboot, and then complain about a disc error, since the CD-R is still in the drive. At that point, press the eject button and remove the CD-R and put your original navigation DVD back in.
• The system should reboot and load properly, and you should notice that your dash clock is now set to the correct time. Or, if you (unsuccessfully) tried manually setting it before, it might be offset by some amount of time, in which case you can go into the clock setup menu and press reset (or manually adjust it).

Note: if you disconnect your battery, after it first synchronizes to GPS, you might need to turn your car off/on once before the dash clock is properly updated.

Let me know if anyone attempts this, or have any questions on the process... and I'm happy to help and/or double-check your file if you're not comfortable modifying the file.

DogP

 

Like I said before, I appreciate the knowledge and effort here. This community has always been terrific to Acura owners.

 

It works! I followed the instructions from DogP on my 08 type-s and now my time is correct! It was very easy I just had the older disk with the 08touch.bin instead of the 09touch.bin so I followed the commands with that filename instead. It took less than 5 minutes to update, I am thrilled to have this fixed!

With the fork of dumpnavi does that mean some of the older hacks are now possible for the 07-08? I know the splash screen replacement was already working but I'd love the nag screen removed. Either way Thanks!

 

Dang!

too bad I don’t have any CD-Rs anymore

 

@bitterbuffalo What version DVD are you on? I'm only curious, and think it may be helpful to list it if only to keep track. My 07 TL-S is on 4.A0 (2012, White DVD).

 

white disk 4.63

 

Excellent, glad it worked!

Removing the nag screen has been on my list for a while... the ability to look at and change 09Touch.bin might help, though I haven't dug into it enough to say for sure. It looks like the GUI is based on displaying various forms. Looking at the registry you can see where it runs the process calling the start form. But it's not clear to me whether you can simply change it to start at a different form to skip the nag screen.

DogP

 

Fantastic to see others getting the fix working! I'll replicate your solution for the Civic @DogP and share it over on the civinfo forum in the near future.

Regarding the nag screen, what I found in testing was unless the Sat Nav was receiving the data stream of bytes from the GPS module it wouldn't show the "OK" button to clear it. Which might help with tracing it back? Could also lead to a possible solution if the "show OK" function is replaced with "jump to Sat Nav start". The Nag Screen would still show, but would auto-clear when the Sat Nav was "ready".

 

That would be a completely acceptable option, IMO.

 

So it sounds like Acura could easily fix everyone by simply releasing a modified Nav disk. No actual hardware changes to the nav system required?

 

It sure seems like it based off DogP’s work. But I bet they don’t want to pay for it

 

Yeah, I doubt they'd be willing to put in the work and send everyone free DVD updates. I still get e-mails from them asking me to buy the latest DVD.

 

@DogP

I've written a function to do the date conversion. Compiling it in Debian using the SH4 cross-compiler and then REing back in Ghidra the function comes out to roughly around 700 to 750 bytes in SH4 Assembly. Don't know if you'd like to try slotting it in?!

 

why pay for something when we can just take the "just wait until August, it will fix itselffor free" approach