Thread: partnumber in DSKIMG header on original img files

I can’t find any information on how to read or edit the partnumber part in a DSKIMG file. It is present in original files like:

• gmaptz.img
• gmapprom/gmapsupp.img
• gmapbmap.img
• gmap3d.img

Where to find information:

• You can read it in your nuvi inventory [hold battery ,next until Version Information, start test, More]
• It appears in GarminDevice.xml and other logfiles that are send to Garmin with webupdater/mapupdater program [firmware/lifetime updates].
• GMaptool does not handle it [re-assembled files get hex 00 values]
• MapSource does not handle it [mapsource images all get the same partnumber]

GarminMapUpdater.exe does handle it properly and gets it from the file:
%temp%\ IMG\006-Dxxxx-xx\manifest.xml

Code:

Please Login or Register to see the links

GarminMapUpdater.exe holds GpsImgWrapper.dll, I guess that this is where the secret things happen ???

All different coverage/regions from the map have a different partnumber making it a usefull tool to identify original maps. Additional files [DB, SID, ASR, G2S, JCV, etc.] for the mapupdate have all normal readable partnumbers in the header or even have the partnumber in the filename.

I used a gmaptz.img and rename it to gmapsupp.img on a SD-card for testing in the nuvi inventory page.
-only the first 64 printable ASCII chars are displayed [#20 -> #5F = space -> underscore = capitals, numbers, etc.]
[Only registered and activated users can see links. ]
-invalid partnumber are displayed as ?????-??
-The last 2 numbers of the partnumber are the part revision, incremented with every mapupdate. But on some files like gmaptz the version number is updated and not the part revision number.
-The partnumber string is located just before the date/time
[Only registered and activated users can see links. ]
- it is a string of 8 char coded in 9 bytes
- D032318AG013 is displayed as D0323-18, the "-" is part of the string and is the "AG013" also coded somewhere in the string or left out?
- the full partnumber is 006-D0323-18, but the "006-" prefix is left out.
- a "little endian conversion" makes some sense, when you compare two img files like 2012.40 and 2012.30
- if you hex-edit a byte +1, the displayed char leaps 4 places in the ASCII Code Chart
- the start of the string is not always on the same place