There is some great news for GD-77 owners…
Kai, DG4KLU has managed to crack the Radioddity GD-77 firmware encryption system, and has published his work on github.
This includes unencrypted copies of all the firmware versions, which Radioddity has released for the GD-77, as well as tools to decrypt and encrypt, and some documentation.
In the short term, this will not make any difference to most GD-77 owners, as this is just another step in the very long road.
However in the longer term, this may allow the community to fix some of the long list of bugs, which Radioddity has been unable or unwilling to fix.
It may also allow some enhancements to the GD-77, similar to those available on the MD-380 , when using MD380-Toolz.
However, the GD-77 hardware is quite different to the MD-380, and has much smaller memory capacity, so its unlikely that its going to be able to hold the entire DMR ID database, like the MD-380 can.
I have know about Kai’s work for about a week prior to him publishing the files etc, but at Kai’s request, I’ve not disclosed anything.
Please also note, that Kai’s work is very experimental, and people use his files and tools at their own risk.
I took one of my GD-77 radio’s apart and have connected a hardware debugger to the PC and have erased the main CPU, however at the moment, neither Kai or I has been able to re-install the firmware onto a blank radio, because of hardware lock features in the firmware.
Using Kai’s tools to create new SGL firmware files is a bit less risky, but still carries a risk, so at the moment I’d only recommend that people experiment with this, if they are willing to sacrifice their radio
If anyone has software development experience, especially on Microcontrollers, who thinks they can help with this, please leave a comment or contact me directly.
I’ve managed to unbrick my GD-77, using Kai’s CPU ID key encoder tool.
The problem was the CPU ID I read from the MK22 MCU, using JLink Commander, was in Big-Endian format, but Kai’s data file requires the 32 bit chunks to be in Little-Endian format.
Strangely his unique CPU ID and my CPU-ID have 4 bytes with the same value. 2 of these are zero’s so are probably not relevant, but 2 of the bytes in the middle of the 16 byte ID number were also identical, which makes me think that the CPU ID is not as unique as it should be.
I double checked the Reference Manual document for the MK22FN512 processor and as far as I can see, there is no reason those 2 bytes should be the same.
So there is probably a bug in Freescale’s random ID generator 😉
Anyway. This means I am free to experiment with the firmware and can upload using JLink or other programmers, and don’t need to worry about breaking the radio… Except perhaps if I do something nasty to the EEPROM data, since I don’t have a copy of that.
(And I’ll backup the Flash using FlashManager (again), just to be safe.