Hello trid users,
some days ago i run TrID on some Garmin map (*.img) and voice files
(*.vpm. ). Some IMG files like gmaptz.img are not recognized as "Garmin
basemap" by img-basemap.trid.xml. Many files are misidentified as
"Adobe PhotoShop Brush" by abr.trid.xml ( See output/trid-old.txt).
The newest file command { See
https://en.wikipedia.org/wiki/File_(command)}identifies all such examples as "Garmin map" ( See output/file-new.txt).
According to page about Garmin ".img" format on Wikipedia such
examples are used by Garmin navigation devices use to store the
maps. This is now expressed instead garmin home page by reference URL:
<RefURL>
https://en.wikipedia.org/wiki/Garmin_.img</RefURL>
From there i found on SourceForge a PDF document imgformat-1.0.pdf
with title "Garmin IMG File Format". According to that document the
img format itself is a container for other data sub files. Depending
on sub files things are different. Inspired by DOS FAT file system
meta information about sub files is stored in a File Allocation table
(FAT). So three lines in global string section like
<String>GARMIN LBL</String>
<String>GARMIN RGN</String>
<String>GARMIN TRE</String>
means map file contains 3 sub-file parts with DOS alike 8+3 filename
"GARMIN.LBL", "GARMIN.RGN" and "GARMIN.TRE". The name extension is the
most interesting part, because each sub-file type carries a specific
data. Some known file sub-types are:
? RGN. Map elements such as poly lines, polygons and points.
? LBL. Labels for map elements, city names, localities, etc.
? TRE. Map structure information that organizes the map elements into
a data tree.
So there also exist a few map files without these 3 sub file part
types like Open Street Map example mapsetx_mdr.img. So these 3 string
must be removed for a general definition file.
According to page about Garmin IMG File Format on Open Street Map wiki
instead usual signature string DSKIMG\0 also DSDIMG\0 is found for
demo maps. Unfortunately i myself found no example with a demo
signature. That means the following XMl construct must be replaced:
<Bytes>44534B494D47</Bytes>
<ASCII> D S K I M G</ASCII>
<Pos>16</Pos>
The new XML construct looks like:
<Bytes>4453</Bytes>
<ASCII> D S</ASCII>
<Pos>16</Pos>
<Bytes>494D470002</Bytes>
<ASCII> I M G</ASCII>
<Pos>19</Pos>
And in global string section now only 1 line is left:
<String>GARMIN</String>
Unfortunately the informations in PDF document dated about year 2005
are incomplete or sometimes wrong, because John Mechalas gets file
format information by reverse engineering. According to that document
at offset 0x40 string \2GARMIN\0\0 should appear. This was expressed
by XML construct:
<Bytes>024741524D494E0000</Bytes>
<ASCII> . G A R M I N</ASCII>
<Pos>64</Pos>
Instead \2 i also found value \8 in examples like Time Zone Map
gmaptz.img and Suedtirol442.img. This is now expressed by changed XML
construct:
<Bytes>4741524D494E0000</Bytes>
<ASCII> G A R M I N</ASCII>
<Pos>65</Pos>
It is not clear if part with string "GARMIN" is required or only used
for description purpose. So only a few and not 100% reliable pattern
are left. So instead of updating img-basemap.trid.xml i started a new
definition file img-garmin.trid.xml suited in general for all Garmin
maps. After running tridscan i refine this file by looking for
described characteristics.
All inspected map files are also misidentified as "Master Boot Record
dump" by mbr-dump.trid.xml. That is not surprising because it also use
the MBR signature 55AA. According to PDF document 48 null before that
signature start at offset 1CEh. This is now expressed by XML
construct:
<Bytes>0000..55AA</Bytes>
<ASCII> . ... U</ASCII>
<Pos>462</Pos>
For a real MBR the partition table starts at offset 446. But for the
Garmin maps fixed or zero values are found at some partition table
places. According to documentation this is now expressed by 2 XML
constructs:
<Bytes>0000010000</Bytes>
<Pos>446</Pos>
<Bytes>00000000</Bytes>
<Pos>454</Pos>
According to PDF document after the information inside header the
remaining 314 bytes at offset 84h should be nils. This is true for
real maps, but wrong for gmaptz.img and all *.vpm examples according
to my own experiments. There only the remaining 309 bytes are
nul. This is expressed by XML construct:
<Bytes>0000....0000</Bytes>
<Pos>137</Pos>
To store big maps a trick is used, which is known for DOS experts. The
unit used for counting block is not the physical block size, but the
logical block size. So with a large logical block size like 16384 in
sample CARPATHIAN_en_gmapsupp.img it is possible to address many map
elements with details. The logical block size is stored in the header in
exponent fields E1 and E2. The logical block size is is calculated by
formula:
block size=2**(E1+E2)
According to PDF document Exponent E1 appears to be always be 0x09
which gives a minimum block size of 512 bytes. This is what i see for
my inspected examples. This is now expressed by XML construct:
<Bytes>09</Bytes>
<Pos>97</Pos>
For most Garmin map file name extension ".img" is used. But some maps
with extension ".vpm" contains Garmin voice processing module (which
itself are container for WAV sounds. That means RIFF magic is found
inside somewhere). So extension is now expressed by:
<Ext>IMG/VPM</Ext>
Unfortunately there seems to exist at least 3 variants for Garmin voice
processing module (*.vpm). Beside IMG based format there exist a
variant starting with magic AUDIMG. This is described by definition
file vpm.trid.xml. The third variant of VPM files are encrypted and
are described by vpm-enc.trid.xml. So mention these facts in remark line.
Of course not all pattern especially padding with nulls are needed to
identify Garmin maps. But the definition img-garmin.trid.xml can now
also be used to test the integrity of the used IMG file format
description, which itself is incomplete or not 100% correct.
With new trid definition all inspected Garmin map are now recognized (
see appended output/trid-new.txt). TrID definition and output are stored in
archive garmin_img.zip. I hope that the XML file can be used in future
version of triddefs
With best wishes
J?rg Jenderek
