Thread: Nuvi 58LMT "can't unlock maps".

That was sort of what I was attempting to say probably with completely wrong terminology. I was relying on the "power off" option not a nonvol clear.

So with a nonvol clear I'm back to the errors until I insert the SD card fix. Then it works fine without the SD card until next clear. It doesn't know/care that the gmapprom.unl (and gmapprom.gma?) on the internal flash aren't valid and doesn't attempt to recheck it unless it changes in some way. Reinstalling the map with GE doesn't count as "changes".

Is there some documentation above the noob level indicating what all the filetypes do, what's known about them and pointers to tools to mess with them? I know some of the answers to that for .unl but not the other types. I'm hoping to educate myself enough to be able to fix this myself (and maybe help someone else) if/when this happens again.

I'm very happy that it's no longer a brick but there's that little bit of me saying it would be even better if it could work without needing the SD card fix on every hard reset and if I knew how to create the files to do that, if it's possible.

Update... reread the thread and tried what GN said might work earlier. Replacing the bad .unl and .gma files in internal flash with those on the SD fix and after a nonvol clear it's all working fine.

I'll go away and leave you all in peace now

What i was saying in my previous posts is this, in highly expanded paraphrase:

• Following a reset/clear NV, GMA and UNL codes in visible memory are initially read, checked against the map IMGs present to ensure they are valid for them, copied and then stored by the devices somewhere on its (not user accessible) internal memory, i'm absolutely 100% certain that they're exclusively written to its clearable NV (note: codes can also be inserted into the map IMG file too rather than as standalone *.unl files - from the IMG data they're read and copied the same as codes in UNL files are treated from the visible internal or external memories);
• Since those codes, now stored in non-volatile memory, were successfully checked via some 'majic' by the device during initial re-boot in that they're found to match with the maps, the device no longer looks for them in visible internal or external memory. So, it only checks on subsequent re-boots that the valid codes remain in NV, it doesn't matter about what's in normal memory because it won't even look there again unless the code data in NV's either missing or it isn't valid for the current maps. The device also overwrites the GarminDevice.xml on reach successful reboot from the wealth of general and unique info stored in NV - that's why manually rewriting any data to the XML doesn't work on the device, it just re-writes it completely on each reboot from the unique NV memory data, both temporary and permanent. Just some of the latter's data seems to be also stored elsewhere because only part of the programmed permanent data is restored to the NV region following erasure of its data. Clearing NV on the other hand is just a very comprehensive hard-reset.
• Therefore, removing codes from visible memory or even replacing them in there with invalid codes doesn't matter - that is of course provided the correct data's still in temporary NV. Until the next hard-reset or clear NV the device will happily function regardless of countess reboots.

So i think you'll now clearly understand why the faulty (invalid) UNL code (with FID "1") is ignored if present. On the other hand, GN's supplied UNL for full EU does work for your UK/ROI because it is valid for any and all parts of EU (FID 12956). Once that code's been parsed and passed to NV, the SD card's presence doesn't matter because the code data's been correctly written to NV memory as explained above. However, Garmin's OS and many of its processes and even the function of many of its "regions" remain a mystery to me and many others outside of Garmin. If anyone has managed to really 'get under the bonnet' like we can with Linux or even Windows they've kept it real quiet.

Try making your own valid UNL code with JetMouse, i bet it'll work the same as the SD card UNL file from GN does after a reset provided the GMA file is present with it.

You've got formal programming experience, that's very clear to me. I don't, i'm only an enthusiastic and somewhat incompetent amateur. GN i suspect is also quite more like me than you in coding experience.

So it you wanna know more, go ahead - [Only registered and activated users can see links. ] - i dares ya.

Originally Posted by stevex

OK well I did offer to go away...

Yeah i know. But i hadn't finished torturing you had I? ...

Yes that makes sense. Storing the results of a computationally expensive result in NV will speed up boot times. I'd have expected it to check to see if the files had changed (if they exist, dates, sizes even hashes) but apparently not.

I happily admit i don't understand the detail behind the actual machinations and fancy footwork happening, i just know it does happen. Once the data is in NV there is no need for UNL/GMA files in visible memory to be inspected again by the deviceunless the existing map data changes or another map is added. Then, if the new map has a different FID, because the device can't find the appropriate associated codes in NV, it'll start searching the visible internal and external memory for them and even look inside the map IMG files for a relevant UNL code.

OK well here's a few things I'm curious about. If any of this is documented anywhere just point me in the right direction and I'll go off and study it.

Because of the fact that Garmin's OS is a closed shop i really don't know if you'll find anything more that what's talked about right here.

The .unl files seem like something relatively simple.

Yes they are really just a bog-standard TXT file renamed UNL. The file can contain just one single code with matching map file name, or many individual codes unseparated and continuous. I think a file with multiple codes can only be named as "gmapsupp.unl" - i haven't had to think about this stuff for a while now.

Is their precise format documented anywhere?

Not much to tell. They're simply a string of 25 alpha numeric characters generated by a 'keygen' having the knowledge of a device's UID and a particular FID etc. for the relevant map data.

I was thinking of throwing together a quick parse/generation tool that wont trigger the stupid anti-virus warnings.

Are you getting warnings using JM? Many AV programs treat all such keygen tools as a threat. JM doesn't trigger anything in my Win 11 PC running Windows Security (aka Defender) but i may have excluded it years ago.

The .gma files? What's known about those?

Very little AFAIK. The initials stand for "Garmin Map Authentication" and they were introduced as an additional barrier to map piracy because the UNL codes were so easy to generate once JM circulated. They are certainly far more sophisticated than UNL files. Now we additionally have MSV and GSV (aka GVS) protection in modern devices' firmware which confirm the Map Signature Verification and GUPDATE Signature Verification, that means an unlocked map IMG file or modified GCD fw file is rejected. That's overcome by the patcher janch referred to earlier.

They've got some ASCII stuff in what looks like a header and then nothing obvious. Might be binary data or some kind of cryptographic information to check authenticity.

I dunno what it is after "GARMIN GMA" in clear. All i know is what it does, which is check the authenticity of the map for use on the device. Far smarter ppl than me decided long again it was easier to strip the GMA protection from the map than try to generate GMA codes like was done for UNL codes.

What do the .sid files do?

Look here: [Only registered and activated users can see links. ], and [Only registered and activated users can see links. ]. Scroll down the alphabetic list to SID.

The one that I'm still puzzling over is how GN got the Full EU map. Creating data on an SD card (virtual or real) with just GarminDevice.xml is enough to keep GE happy and download maps details (presumably this is so it can recover if someone wipes the visible flash) along with .unl and .gma for the device but I've never been offered Full EU as an option when I change region.

It's not to do with selecting a different region on the device following a reset.

You can replicate what he did by putting your latest GarminDevice.xml file in a Garmin root folder on a USB or Virtual device. This is simply exploiting what GarminExpress does, it only reads the XML to check entitlements for the specific Unit ID number on Garmin's servers. If it's got allowable updates it'll offer them. If, like your UK-market travel edition, it has LM entitlement to maps other than UK/ROI you can get them too just like GN did:

Spoiler: Click for Image

[Only registered and activated users can see links. ]

The above page is reached from GE's Home Page>Map Details>Map Options>Change Map>Accept>Continue then the dropdown next to the current map detail will list all other maps available to the device.

Also actually, no i don't think the option in GE to restore existing maps or download new ones is to do with recovering an empty flash specifically.

PS: I see GN replied as i was still drafting this so i've probably repeated some of what he's just explained.