Advertissements

I think i got it!!!
It seems to be that what is changed are the offsets of each internal section of each sub-file.
Which are changed simply because the header is displaced from the rest of the sub-file.
working...

PS: Now i need to learn how to interpret and change the offsets, which is probably very basic, but i don't have a clue

As you have found out, the difference between two, say TRE, headers are the contained offset values pointing to data sections in the TRE data area. In a NT or pseudo-NT GMP subfile the offset is always relative to the start of GMP header. But in a non-NT TRE/RGN/LBL subfile, the offset is relative to the start of TRE/RGN/LBL header respectively. So, for example, after you join a TRE header with its TRE data area (both from a pseudo-NT file), you need to update those offsets in TRE header to be relative to the start of the TRE header.

The location of an offset within a non-NT subfile header can be found in the document below.[Only registered and activated users can see links. ]

Thanks syzygy.
Yes i already read those documents the other day.
And you are correct on what you are saying.
The imgformat-1.0.pdf document was the most useful. The document is a little incomplete, but we don't need to know/understand where exactly the offset point to. We only need to know where are the offsets to be changed and the amount that need to be sustracted from them to properly point to the data when relocated.
It was relative simple, i need to see some details and i'll upload what i found, later.(i've been busy)
But to resume i will say: THE MATTER IS CLOSED!!!. It is definitely possible to convert pseudo-NT to non-NT without any problem.
I will upload the details and explanation later. But correctly changing the offsets is easy.
The ideal thing would be to do it automatically, but the most important part, that is understanding the issue, is CLOSED.

I don't really believe that people who reverse engineered non-NT IMG files can't do the same with NT IMG files There should be some other reasons... Like all of them being involved in some economic relations which make decompiling NT maps by others not desirable

Decompiling maps is a quite different matter than unlocking maps.

There are many companies, which own digital data suitable for GPS maps. I think in each country there could be a few such companies. They could have better local data than Navteq. Or they sell data to Navteq. Actually they could sell data to any publisher who releases maps. But there is condition - no leaks including no possibility to decompile their data. Since cgpsmapper gives no protection, there are nearly no alternative commercial maps. We get one City Navigator Europe, one Topo Germany, one Topo France etc. And Garmin control market, they don't sell their tools to competition.

Now is interesting what would happen if someone would release decompiling tools for Garmni NT maps? Would Navteq stop selling data to Garmin?

Now is interesting what would happen if someone would release decompiling tools for Garmni NT maps? Would Navteq stop selling data to Garmin?

That would probably be a navigation market disaster for Garmin, right? And a big win for others who didn't have good map data before.
Well, I know that both maps formats can be unlocked. I know that unlocking is "relatively" easy and that free OpenSource tools are available.

What I was talking about is that non-NT maps can be decompiled with easily available 3rd party tools and NT maps cannot. I can be wrong here, as I'm an absolute noob when it comes to maps.

There are Garmin NT maps, non-NT maps and 3-rd version are quasi-NT maps created by cgpsmapper. Quasi-NT maps could be decompiled, but until recently there was no available tools to do it. That kind of tools can make problems for remaining competitors of Garmin.

Yeah, I've forgotten about quasi-NT maps... Thank you.
As I understand, decompilation of CarteBlanche won't make their sales significantly lower, as they're not encrypting their map anyway. Who would buy the map if it can be downloaded for free? Most probably most map installations are performed by unofficial dealers, who can surely find it and download it...
But it will make Garmin devices less competitive and some other navigation devices more competitive, due to wider map material available. Thus, everyone who sells Garmins would be hit somehow. Am I right ?

I'll try to be as clear as possible.
What we want to do is to convert a garmin *.img map from pseudo-nt to non-nt.
So, i have this "example2_NT.img" map and using GmapTool i "split it" and get its subfile "48580011.GMP"
Inside the gmp as stated in first post, there are all of the 5 regular subfiles TRE, RGN, LBL, NET and NOD, and the info on them is EXACTLY the same as if the file where non-nt.
If we get them we can "re-join" them using GmapTool and get the non-nt version.

What i'll explain here is how to find, extract and modify the header of each subfile inside the gmp.
As i already have the raw data of this example i can compare version pseuso-NT and non-NT made by myself, with this and some imagination i realize what is needed to be done.
Here it is the comparison of each subfile header in the pseudo-nt and non*nt version (obviously you won't have the non-nt version in real life !!)

[Only registered and activated users can see links. ]

[Only registered and activated users can see links. ]

[Only registered and activated users can see links. ]

[Only registered and activated users can see links. ]

I only put the headers as they are the only thing that is changed, the bytes you see in red are the ones that differ. This bytes represents the offset (location) of the data within the GMP file.
As in pseudo-NT the subfiles are re-arranged the offsets need to be changed to continue pointing to the right location where the data is.

The headers are easy recognizable and are easy to extract from the GMP file as they are one after another, where one ends the other begins.
The same is with the "body" of the data of each subfile.

Once you have each header, with the info inside them you'll know where to look up to retrieve the "body" in the GMP file.
For example in the TRE header (look at the right image) at x31 (4bytes) it is written where it is the beginning of the TRE "body" data (offset).
x31 4bytes means that the info is from x31 to x34. It needs to be read backwards. You see 24 03 00 00 so it is x00000324, without the meaningless zeros x324.
So the body of the TRE subfile begins at x324.
The other differences are from other offsets that point to other locations inside the TRE subfile inside the GMP
The differences are because the data is re-arranged, to put them back as they need to be you need to subtract the offsets some value as it is written here:
*****
TRE
header size: 217 bytes ##(the size is in this case only, because it could change depending on custom copyright info)
in GMP Begin at: x324 (dec 804) ##this info can be retrieved from x31 (4bytes) relative to begin of TRE header

804-217= 587 (x24b) ##amount needed to be subtracted in every changed offset

1995-63= 1932 (x78c) ##amount needed to be subtracted in every changed offset

*****

With this info we can correct the changed offsets values, each difference need to be subtracted to the correspondent value.
(At x13 (2bytes) this is not an offset, is creation time info of the map, you don't need to change it, it's okay even if it change)

For example in the TRE at x21 (4bytes) you read the offset x35a, if you subtract x24b you get the correct value:
x35a-x24b=x10f

at x58:
x366-x24b=x11b

for hex to decimal conversion and calculations (addition, subtraction) go to [Only registered and activated users can see links. ]

As how the gmp is arranged, each subfile "body" end one "position" before the subsequent subfile body begins.
So for example The body of TRE subfile begins at x324 (as x31 tells you) and ends one before RGN begins, that is x3a4-x1=x3a3

*****
TRE
begin: x324
end: x3a3

*****
RGN
begin: x3a4
end: x52e

*****
LBL
begin: x52f
end: x631

*****
NET
begin: x632
end: x7ca

*****
NOD
begin: x7cb
end: end of gmp file

*****
Whith this info we are now capable to locate and extract the body of each sufile.

Now you put in the "offset corrected" header and the body and create each subfile.

Now you can "join" all the subfiles using GmapTools (you need to SELECT "SHORT HEADER" option), and you get the non-NT version of the img.
You can open it with GPSmapedit, maptk 3.3.0, cgpsmapper 0085 etc...

There is another possibility as explained in an earlier post, instead of changing the offsets in the header you can leave them as they are, and add zeros between the header and the body to maintain the same absolute position of the body.
The number of bytes zeros needed in between are the same that you subtract in the other option.
For example in the TRE subfile, you can leave the header as it is in the gmp then add 587 bytes of zeros and then append the body data.

Obviously this need to be automated for "lot of map" conversion. But for a few map it can be done.
If anyone is already in the know of C, C+ or any other, it would be easy for him/her, i hope so, because i don't have so much time and i would need to study the relevants commands to manage binary data etc...

We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.