Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 3 of 14 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 133
  1. #21
    syzygy
    Guest

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

  2.    Advertissements


  3. #22
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    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.

  4. #23
    Kanopus
    Guest

    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?

  5. #24
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    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.

  6. #25
    Kanopus
    Guest

    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.

  7. #26
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    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 ?

  8. #27
    Master
    Join Date
    Feb 2011
    Location
    Sofia
    Age
    38
    Posts
    736
    Rep Power
    222

    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?

  9. #28
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    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 !!)
    Spoiler: pic
    JB9ZdXi


    Spoiler: old pics
    [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:
    Spoiler: list
    Code:
    Please Login or Register to see the links

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

  10. #29
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    testlelelala
    I really don't think that it's a good idea to change offsets of subfile data.
    If you search for "pointer" keyword inside imgformat-1.0.pdf, you would find that it's not uncommon for data from one subfile to point (i.e. to contain the offset) to data from some other subfile. For example, some TRE data could point to data inside RGN, NET could point to NOD and to NET itself.
    Therefore, if you move subfiles, you change all the offsets and all the links mentioned above are destroyed.

  11. #30
    Member
    Join Date
    Aug 2013
    Location
    A
    Posts
    24
    Rep Power
    68

    Default

    Yes i read that, and have some thoughts about it in that moment.
    But changing the offsets of the subfiles already is working perfect!!.
    Keep in mind that i already know what it must/should be as i have maps compiled by myself in where i have both, pseudo-NT and non-NT.
    I knew before hand that there where differences between pseudo-NT and non-NT map compilation of the same data. Then i realize that this differences where the offsets, this is confirmed as subtracting the same value, change the offsets from pseudo-nt to the ones in the non-NT version, in a way that the pseudo-nt header now became exactly the same as the non-nt header.
    None of the headers i revised had an offset that pointed out of the corresponding data of that header subfile.
    I think that the info in imgformat-1.0.pdf is not complete/ok , take a look at [Only registered and activated users can see links. ].

    Either way, in case some of the offsets do really point to a position in another subfile, this could be detected, just taking into account that if some offset in a header is greater than the end of the corresponding subfile, the subtract value will change including now the header size of the others subfiles that are between or something else.
    The regular non-nt img is structured as:
    some things
    TRE subfile
    some zeros
    RGN subfile
    some zeros
    LBL subfile
    some zeros
    NET subfile
    some zeros
    NOD subfile

    In case this occur, it would need to be revised. But i bet that this won't in case of pseudo-nt.
    But just to know that the pseudo-nt has exactly the same data that the non-NT counterpart and that the only thing to change is apparently the offsets, makes it easier to analyse in the future cases as the one you are referring.
    Last edited by testlelelala; 12th August 2013 at 03:03 AM.

 

 

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
  •