Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: New garmin gcd

  1. #1
    Junior Member intuicion's Avatar
    Join Date
    Jun 2017
    Location
    España
    Posts
    8
    Rep Power
    0

    Default New garmin gcd

    Hello to everyone, Garmin uses on its new device (montana 700i,Zumo xt, Alpha 200i.....)
    Does anyone have an idea or interest in the GCD format, uses garmin os like older devices
    sd card commands work exactly but dumped rgn14 is not rewritable, only compressed fw_all can be written
    When I view it with binwalk two compressed files appear
    ----------------------------------------------------
    0x15B44 rzip compressed data - version -83.-65
    0x271A49 StuffIt Deluxe Segment (data): f
    ----------------------------------------------------
    StuffIt and rzip latest versions cannot extract them, Is there anyone have an idea


    Important note
    0009D98C ; ---------------------------------------------------------------------------
    0009D98E ALIGN 0x10
    0009D990 dword_9D990 DCD 0x2F ; DATA XREF: sub_9D540+74o
    0009D990 ; sub_9D540+C2o
    0009D994 aErgn unicode 0, <ergn>,0 ; DATA XREF: sub_9D892+Co
    0009D99E ALIGN 0x10
    0009D9A0 aRrgn unicode 0, <rrgn>,0 ; DATA XREF: sub_9D892+18o
    0009D9AA ALIGN 4
    0009D9AC aXrgn unicode 0, <xrgn>,0 ; DATA XREF: sub_9D892+24o
    0009D9B6 ALIGN 4
    0009D9B8 aCopy unicode 0, <copy>,0 ; DATA XREF: sub_9D892+30o
    0009D9C2 ALIGN 4
    0009D9C4 aCopydir unicode 0, <copydir>,0 ; DATA XREF: sub_9D892+3Co
    0009D9D4 aReboot unicode 0, <reboot>,0 ; DATA XREF: sub_9D892+48o
    0009D9E2 ALIGN 4
    0009D9E4 aDel unicode 0, <del>,0 ; DATA XREF: sub_9D892+54o
    0009D9EC aFftl unicode 0, <fftl>,0 ; DATA XREF: sub_9D892+60o
    0009D9F6 ALIGN 4
    0009D9F8 aChksum unicode 0, <chksum>,0 ; DATA XREF: sub_9D892+6Co
    0009DA06 ALIGN 4
    0009DA08 aFfs unicode 0, <ffs>,0 ; DATA XREF: sub_9D892+78o
    0009DA10 aFsclean unicode 0, <fsclean>,0 ; DATA XREF: sub_9D892+84o
    0009DA20 aErrorInvalidCo unicode 0, <Error: invalid command '%s'>
    0009DA20 ; DATA XREF: sub_9D892+94o
    0009DA20 DCW 0xD, 0xA, 0
    0009DA5C ; ---------------------------------------------------------------------------
    Added ffs to ldr commands, completely formats the main directory, be careful when using

  2.    Advertissements


  3. #2
    Member
    Join Date
    Jan 2019
    Location
    Russia
    Posts
    11
    Rep Power
    0

    Default

    Could you please share a rrgn dump of the region14 and corresponding .GCD file of the same version ?

    Quote Originally Posted by intuicion View Post
    sd card commands work exactly but dumped rgn14 is not rewritable, only compressed fw_all can be written
    What do you mean ?

    You dumped the region with the rrgn command.
    But you can not flash this dump back using the xrgn command?

    You can flash region 14 only with xrgn and fw_all.bin extracted from .GCD file.
    Did I understand you correctly?

  4. #3
    Junior Member intuicion's Avatar
    Join Date
    Jun 2017
    Location
    España
    Posts
    8
    Rep Power
    0

    Default

    You can flash region 14 only with xrgn and fw_all.bin extracted from .GCD file.
    Did I understand you correctly?

    Yes you got it right, Also on some devices fw_all.bin is written on rgn 144
    but cannot be written to room rgn 14 because it is filled with zeros.

  5. #4
    Member
    Join Date
    Jan 2019
    Location
    Russia
    Posts
    11
    Rep Power
    0

    Default

    I downloaded the GCD-file for Montana-700,
    Code:
    Please Login or Register to see the links
    unpacked it using RGN-tool.
    You're right.
    It looks like the binaries it contains are encrypted or compressed.

    I found and downloaded an archive with the same firmware version (6.40) for the same navigator.
    Code:
    Please Login or Register to see the links
    The archive contains both RGN and GCD files.
    Extracted binaries from RGN and GCD - and binaries matched!

    Quote Originally Posted by intuicion View Post
    Also on some devices fw_all.bin is written on rgn 144
    What devices?
    I can't find anything about this "Region 144".
    Perhaps this region is used as a "temporary folder (region)" for storing the binary file before unpacking or decrypting it.

    Quote Originally Posted by intuicion View Post
    but cannot be written to room rgn 14 because it is filled with zeros.
    Then I'll expand my query:

    Could you share the rrgn dumps of region 14 (and/or 114 as well)?
    Last edited by Boki_Srb; 17th November 2020 at 09:25 PM. Reason: approved

  6. #5
    Junior Member intuicion's Avatar
    Join Date
    Jun 2017
    Location
    España
    Posts
    8
    Rep Power
    0

    Default

    Quote Originally Posted by VadimK View Post
    I can't find anything about this "Region 144".
    Perhaps this region is used as a "temporary folder (region)" for storing the binary file before unpacking or decrypting it.
    I am not in the same decision as you, Rgn 144 appears blank on different devices of the same type

    I guess it makes more sense to examine the boot and xloader with ida, check your pm for files
    I have reviewed it many times, I could not understand, maybe you will find a meaning
    Last edited by Boki_Srb; 18th November 2020 at 07:11 AM. Reason: corrected quote

  7. #6
    Member
    Join Date
    Jan 2019
    Location
    Russia
    Posts
    11
    Rep Power
    0

    Default

    intuicion

    Thanks for the files provided.

    FW_ALL.BIN is a file saved in the RGN-tool from the GCD.
    RGN14.BIN is a file obtained using rrgn command.

    Unfortunately, I didn't have to work with IDA.
    But the HEX editor helped me make a few observations:

    1. The size of the FW_ALL.BIN is always 556 bytes larger than the size of the RGN14.BIN !
    Therefore, it can be argued that FW_ALL.BIN is not compressed RGN14.BIN, but encrypted!

    Code:
    Please Login or Register to see the links
    2. The first double word (four bytes) of the FW_ALL.BIN file is always equal to the size of this file minus 4 and corresponds to the size of the remaining encrypted part of this file.

    [Only registered and activated users can see links. ]

    It remains to find out what the "extra" 552 (= 556-4) bytes are for.
    Perhaps these are some kind of key or encryption table.
    Or some other service information that is not written directly to the region.

    Both of these observations also apply to the pair of BOOT.BIN (encrypted) and RGN12.BIN (unencrypted) files.

    PS:
    As for the title of this topic.
    The problem is not with the new GCD format. The format is old.
    The problem is that the executable binaries are encrypted now.
    Last edited by VadimK; 19th November 2020 at 06:44 AM. Reason: Added table and picture.

  8. #7
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    972
    Rep Power
    142

    Default

    The 'extra' size of the contents in a saved region is accounted for by the fact that the entire region is saved as a BIN file, not just the usable data in it. The extra space is indicated by empty FFs at the end of the BIN viewed in a hex reader. If the FFs are removed the hash files of the original bin file and the shortened dumped bin file should match.

    Certainly devices listed in the first post (and also Drive 52 for further example) have encrypted firmware.

    PS: It's worth noting that rgn12 is usually a virtual region which in turn flashes rgn5 (the bootloader) and rgn43 (the X-loader).

  9. #8
    Junior Member intuicion's Avatar
    Join Date
    Jun 2017
    Location
    España
    Posts
    8
    Rep Power
    0

    Default

    Quote Originally Posted by VadimK View Post
    ...As for the title of this topic.
    The problem is not with the new GCD format. The format is old.
    The problem is that the executable binaries are encrypted now.
    I think it's compressed in a different way, not encrypted
    for example fenix6 uses a very different hardware chip for example, but gcd is the same
    I think if you will work with hex, find meaning with different gcd versions of different devices helps us more
    common point for all new gcds hex (01 B4 44) Rzip
    thanks on behalf of everyone for your help

    Quote Originally Posted by Butters View Post
    The 'extra' size of the contents in a saved region is accounted for by the fact that the entire region is saved as a BIN file, not just the usable data in it. The extra space is indicated by empty FFs at the end of the BIN viewed in a hex reader. If the FFs are removed the hash files of the original bin file and the shortened dumped bin file should match.
    ....
    dear butters, nice to see you interested, I hope you help us with your experience

    but rgn14 is filled with 00 not with ff, Writes to the entire 30,720 kb memory
    idem rgn144 (compressed fw_all.bin) but not visible on some devices
    Last edited by Boki_Srb; 19th November 2020 at 11:11 AM. Reason: Merged two posts, approved

  10. #9
    Master Butters's Avatar
    Join Date
    Jul 2017
    Location
    CA
    Posts
    972
    Rep Power
    142

    Default

    Yes, my apologies. You're right of course it's "00" not "FF". I posted from my phone without checking and mixed up how the extra unpopulated region space shows in a hex reader comparing, for example, fw_all.bin with dumped 14.bin. How i should have said it is this: It should be indicated by 00s following the series of FFs at the end of the 14.bin file. My 'experience' is limited to the basics and to older devices too, i.e those with non-encryted firmware. Although i do understand quite well how most Garmin devices work, because i'm not a programmer i may not be of any great help in your current mission. However i'll follow this thread with interest regardless. Good luck with your efforts.

  11. #10
    Member
    Join Date
    Jan 2019
    Location
    Russia
    Posts
    11
    Rep Power
    0

    Default

    intuicion
    Quote Originally Posted by intuicion View Post
    I think it's compressed in a different way, not encrypted
    Why then is the size of the "compressed" file larger (+ 556 bytes) than the uncompressed file?

    Quote Originally Posted by intuicion View Post
    for example fenix6 uses a very different hardware chip for example, but gcd is the same
    What do you mean ?

    ----
    If I understand correctly, you made rrgn dumps on the device with firmware version 3.00.

    But region 144 contains an encrypted binary file FW_ALL.BIN from GCD version 2.70!
    I wonder how it got there? Is this a backup of a previous firmware version?

    What version of the firmware was the device originally equipped with?
    Did you upload firmware version 2.70?

    Could you roll back the firmware to version 2.70 and dump all regions again?
    To figure out the encoding method, we need as many "encrypted-unencrypted" file pairs as possible!

    By the way, where did you download the firmware for Alpha 200? I could not find it either on Garmin's site or Perry's site. WebUpdater?

 

 

Tags for this Thread

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
  •