GD-77 firmware has been cracked by DG4KLU

posted in: DMR, Ham radio | 17

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.

For example.

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.



17 Responses

  1. Anonymous

    fix for the no talk permit tone on rptr channels condition?

  2. Roger Clark

    In theory, all the bugs could be fixed.

    However I don’t personally know enough about the DMR data protocol to know exactly what the problem is.

    Also, at the moment we don’t have even an assembler disassembly file for the whole of the firmware.

    I’ve tried using Radare2 to disassemble the bootloader, and but I find radare2 difficult to use, and at the moment don’t know how to get radare2 to produce a disassembly of the entire 512k firmware file.

    Perhaps someone with access to IDA Pro, or someone who knows how to use radare2, could disassemble the latest firmware and post it to me or Kai etc.

  3. ken

    wow, looking good for the future

  4. Roger Clark



    BTW. What did you use to disassemble and decompile?

    I tried radare2 for disassembly

  5. r00tstar

    I used ida pro 6.8 and the arm decompiler in it. I exported the dbs now into radare2 compatible scripts in case you want to use that util. The cutter GUI makes it somewhat more palatable and you can even see most of the disassembly. That said, its terrible at finding functions and very buggy. Maybe a little better at memory mapping because of the emulation when it doesn’t crash. In my opinion, if you don’t buy/torrent/borrow ida, radare will make you tear your hair out. Its probably geared towards malware analysis more than anything. Tytoolz guy was also using ida, don’t think there is a replacement.

  6. Roger Clark


    I tried disassembling in radare2, and had a reasonable result, but far from perfect.

    I used this setting in radare2

    radare2 -a arm -b16 -m 0x4000 FILENAME_OF_BINARY

    And ran both ‘aa’ and ‘aaa’ disassembly

    I was going to start to annotate these, but perhaps we should start to annotate your versions

  7. r00tstar

    Compare the 2 and see where you get. I preferred the gui for radare, like things a bit more visual. FYI, I ran everything at 0x0 and not 0x4000, if I need to re-run it let me know.

  8. r00tstar

    Ok, application starts at 0x4000, firmware image with boot-loader starts at 0x0 but radare isn’t smart enough to realize there are 2 things there so it decompiles nothing unless you pass it that loading address. So if I understand this correctly, BL=0x0, Full flash= 0x0, decrypted fw = 0x4000. At least when I’m loading to ida. So exported stuff for full flash and bootloader should be fine.

  9. Roger Clark

    There are separate files for the fw application 3.1.1 and the bootloader, or it can be split manually.

    I loaded just the application binary into radare2, and I did the same thing with the bootloader, execept for the bootloader there doesnt need to be an offset because the start of flash in the MK22 is 0x0000 (unlike the STM32 where the start of flash is 0x8000000)

  10. Fernando

    Great news! Thanks both for such a great work

  11. Anonymous

    how did you get it(“datafile”)

  12. Roger Clark

    What datafile.
    Kai produced tools, which are on github, which extract the raw binary of the firmware from the .sgl firmware update file, if that’s what you mean.

    No one will post the unencrypted firmware binaries, because of copyright issues with the codec

  13. Anonymous

    yes, Do you have any information about algorithms?

  14. Roger Clark

    No. DG4KLU said he won’t release how the firmware was cracked or any other information about the encryption

  15. Anonymous

    thank you

  16. Roger Clark

    No worries

    BTW. I presume you work for TYT or Baofeng or the development company who write the firmware for those companies, or you work for another DMR company.

    But I don’t suppose you’d tell that information 😉

    If you want to talk privately, please goto my Contact Me page

Leave a Reply