New garmin gcd

**intuicion** · 16th November 2020, 06:19 PM

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

**VadimK** · 17th November 2020, 05:01 PM

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

Originally Posted by intuicion

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?

**intuicion** · 17th November 2020, 05:17 PM

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.

**VadimK** · 17th November 2020, 09:24 PM

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!

Originally Posted by intuicion

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.

Originally Posted by intuicion

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)?

**intuicion** · 18th November 2020, 01:16 AM

Originally Posted by VadimK

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

**VadimK** · 18th November 2020, 09:13 PM

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.

**Butters** · 18th November 2020, 11:54 PM

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

**intuicion** · 19th November 2020, 09:45 AM

Originally Posted by VadimK

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

Originally Posted by Butters

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

**Butters** · 20th November 2020, 02:36 AM

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.

**VadimK** · 21st November 2020, 08:21 PM

intuicion

Originally Posted by intuicion

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?

Originally Posted by intuicion

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?

Thread: New garmin gcd

Thread Tools

Display

New garmin gcd

Advertissements

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions