Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 3 of 15 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 141
  1. #21
    ☼ADMIN☼
    catymag's Avatar
    Join Date
    Nov 2007
    Location
    light side
    Posts
    23,655
    Rep Power
    5330

    Default

    It could be nice to hear
    [Only registered and activated users can see links. ]
    opinion about this matter
    [Only registered and activated users can see links. ]
    [Only registered and activated users can see links. ]

    [Only registered and activated users can see links. ]
    You have to navigate to get to the good.
    Nuvi1250/Nuvi 34xx/Nuvi 2200/Nuvi 66/Oregon 600/Galaxy S5 MM 6.0.1/TomTom GO/iGO Nextgen Avic,Basar,Isr.Gift/Navigon
    Please don't flood my pm box with questions you can post on forum!! You won't hear back from me.

  2.    Advertissements


  3. #22
    Navigation software expert
    Join Date
    Mar 2011
    Location
    City
    Posts
    287
    Rep Power
    438

    Default

    Quote Originally Posted by testlelelala View Post
    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. ]

  4. #23
    Navigation software expert
    Join Date
    Mar 2011
    Location
    City
    Posts
    287
    Rep Power
    438

    Default

    Quote Originally Posted by Giomen View Post
    Do the bible by John Mechalas have another analogue?
    Additional NOD format can be found at
    [Only registered and activated users can see links. ]

    Additional NT format (but far from complete) can be found at
    [Only registered and activated users can see links. ]
    [Only registered and activated users can see links. ]

  5. #24
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    Default

    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.

  6. #25
    Navigation software expert Kanopus's Avatar
    Join Date
    Jan 2010
    Location
    Internet
    Posts
    481
    Rep Power
    249

    Default

    Quote Originally Posted by kunix View Post
    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?
    Thanks, Kanopus

  7. #26
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,041
    Rep Power
    601

    Default

    Quote Originally Posted by Kanopus View Post
    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.

  8. #27
    Navigation software expert Kanopus's Avatar
    Join Date
    Jan 2010
    Location
    Internet
    Posts
    481
    Rep Power
    249

    Default

    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.
    Thanks, Kanopus

  9. #28
    Navigation software Moderator

    kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    1,041
    Rep Power
    601

    Default

    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 ?

  10. #29
    Master
    Join Date
    Feb 2011
    Location
    Sofia
    Age
    31
    Posts
    919
    Rep Power
    213

    Default

    Now is interesting what would happen if someone would release decompiling tools for Garmni NT maps? Would Navteq stop selling data to Garmin?
    Doubt, as Garmin is the official sponsor of the Nokia mapping. How would all Lumias have a free world wide licence for the Navteq maps if Garmin don't pay for those maps?

  11. #30
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    25
    Rep Power
    61

    Default

    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 !!)
    JB9ZdXi

    [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.

    The GMP is structured as
    GMP header
    TRE header
    RGN header
    LBL header
    NET header
    NOD header
    TRE body
    RGN body
    LBL body
    NET body
    NOD body

    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

    *****
    RGN
    header size: 125
    in GMP Begin at: x3a4 (dec 932) ## this info can be retrieved from x15 (4bytes) relative to begin of RGN header

    932-125= 807 (x327) ##amount needed to be subtracted in every changed offset

    *****
    LBL
    header size: 236
    in GMP Begin at: x52f (dec 1327) ## this info can be retrieved from xb0 (4bytes) relative to begin of LBL header

    1327-236= 1091 (x443) ##amount needed to be subtracted in every changed offset

    *****
    NET
    header size: 100
    in GMP Begin at: x632 (dec 1586) ## this info can be retrieved from x15 (4bytes) relative to begin of NET header

    1586-100= 1486 (x5ce) ##amount needed to be subtracted in every changed offset

    *****
    NOD
    header size: 63
    in GMP Begin at: x7cb (dec 1995) ## this info can be retrieved from x15 (4bytes) relative to begin of NOD header

    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...

    EDIT: I attach the files i used if you want to use them
    Attached Files Attached Files
    Last edited by testlelelala; 11th August 2013 at 08:22.

 

 
Page 3 of 15 FirstFirst 1234513 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
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.