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 device unless 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 string 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 universal firmware patcher janch referenced 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 drive. 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 space permitting. 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

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.

I could've sworn I'd tried that before and didn't see the option. I do now.

Any way to fool GE into thinking a virtual drive/folder is an SD card or does it always require a physical card? I tried VHD but no luck there.

A virtual drive made with ImDisk will fool Garmin's BaseCamp and HomePort so it should also appear as a drive to GE if properly mounted i would think.

Code:

Please Login or Register to see the links

EDIT: Don't bother, it seems GE is smarter than Garmin's older softwares and refuses to recognise a virtual drive. It's not a problem these days with flash memory being so cheap anyway.

I got warnings downloading, extracting and opening JM until I disabled them.

It's part of my curiosity when I see a file like .unl to wonder how the information is encoded rather than just use a tool to parse/generate it and if I can do anything interesting by setting fields to strange values. If it was used as (admittedly bad) copy protection it wont be trivial but not too complex. There are obviously random elements in there as putting the same info in can produce multiple completely different outputs and changing one field changes the whole string. InfoUC looks like it's written in some flavour or BASIC and there's a CRC table in there.

BTW you're sort of right about my formal stuff. I was involved with some rather significant code development before I retired. I somehow persuaded people to pay me to write C code for nearly 20 years with occasional bits of other languages notably perl. Now I do that for fun.

Update: looks like .unl format is a very simple obfuscation which barely counts as cryptography. For my own amusement I'm working on a simple perl script that can unpick it. If I get bored I'll see if I can write something to generate it too.

Update#2: I've wrote a simple perl script that prints out the fields. InfoUC was very helpful in working out the format. Not sure I should say too much about what I found out in a public forum so

Originally Posted by stevex

.....................
Update#2: I've wrote a simple perl script that prints out the fields. InfoUC was very helpful in working out the format. Not sure I should say too much about what I found out in a public forum so

Well it's no problem talking here about defeating UNL codes in a very general and theoretical sense, because it's been done in actual practice for almost two decades anyway. I don't want to seem to be minimising what you've achieved because that's far from my intent - i'll explain below why i think it's only of particular academic interest to a few of us but of no real effect these days given Garmin's protection history ....

As you know, their UNL code protection is unbelievably trivial today and even was in comparison to some protections introduced by others around the same era. Before that Garmin's detail maps had no protection whatsoever and were "already unlocked" in the sense that they (potentially) could be moved from one device to another compatible device freely - however to do so in practice you needed to understand how it all worked - and few ppl did. Early Garmins didn't have any visible file system accessible by computer. They connected in "Garmin Mode" which is still mimicked by more modern devices as "preboot mode" today. Along with PC installation methods involving data on CDs, many detail maps and charts for automotive, offroad, marine and aviation devices were supplied as already-compiled IMG files on proprietary Garmin Data Cards. They were unable to be read like an SD/microSD card can now when inserted in a modern device connected via USB (or earlier, via Serial Port) to a computer. Those older devices will show in Device Manager on a PC, but not in Disk Management nor can it therefore be seen by File Explorer. In fact, the Data Card is treated as just another "region" of its own internal memory by the device, rgn10. It was possible to buy a USB Data Card reader/programmer from Garmin but they were expensive when available new and still are on the 2nd hand market. No after-market versions have ever been made AFAIK. Apart from using programs like [Only registered and activated users can see links. ] to facilitate a very involved dumping of the specific map region/s as a HEX file, converting that to a Garmin IMG file and then re-flashing it to another device, the only 'easy' way to copy mapping data from one Data Card to another was by using the Garmin Data Card reader. Regardless, because neither method was easily available to the average garmin user at the time, unlocked maps weren't much of a problem anyway. But Garmin did introduce the 25 character unlock codes anyway. However, once Garmin relented on its Data Card and started using SD cards as media cards in later devices, the game changed. Such devices (some early StreetPilots for example) were still "region-only" and the card when inserted in the device still didn't show in Disk Managment ....but!!! ... it was easy to get compatible media card readers and copy the gmappsupp.img from one SD card to another for illegitimate use if the maps weren't locked to a specific UID/CID. That action's clearly against Garmin's EULA for both its hardware and software/data of course, but that didn't much stop anyone. In mid-naughties Garmin moved to devices like SP c5x0 and nuvi 3x0/6x0 with locked internal maps and by then the first JetMouse keygen was widely distributed, so map piracy potential exploded further because those devices' internal files could be easily read in Mass Storage Mode just like an SD card.

Around the same time or shortly after, Garmin introduced the "NT Format" (i.e. New Technology) mapping for its detail maps. Then at the end of the naughties we got GMA (Garmin Map Authentication) in maps and device firmware, not such an easy protection to overcome as was the relatively trivial UNL code. But it was still easy. Then Garmin got serious with the previously mentioned MSV and GSV in firmware about 10 years ago, again it was eventually overcome by the Universal Firmware Patcher. So now we have heavily encrypted proprietary fw and also fw based on using an altered Android/Linux OS - and it seems everyone's given up trying to play catchup since Garmin took punitive action against this forum and some of its leading lights back in 2017.

Given the later developments in its protection, it's even surprising that Garmin still bothers to include UNL codes as part of map data protection. Seems more like habit, or an ingrained corporate culture of "it's there because we can't be bothered removing it". Whatever the reason it's simply no real protection at all now, an anachronism.

Good on you for figuring it out though, i still applaud that. Now if you could do the same with Garmin's proprietary encrypted firmware and their bastardized Android or Linux based firmware many ppl might just want to have your baby .... .... but then in the immortal words of Elmer Fudd you better be vewy vewy quiet ...

Spoiler: Image

[Only registered and activated users can see links. ]