GD-77 firmware analysis

posted in: DMR, Ham radio | 4

Since my last post, I have been trying to get to grips with the decrypted GD-77 firmware

 

One of the first things I did, was take the back off my GD-77 and solder wires onto the hardware debugger pads

The connections are Vcc,Gnd, SWCLK, SWDIO and reset. The wires are held in place using hot glue to act as strain relief, otherwise its likely that force from the wire could pull the pads off the PCB

 

Here is the full photo

 

 

 

I connected this to a STM32 based hardware debugger, and took the bull by the horns, and did a full chip erase on the CPU (MK22 Microcontroller).

A full chip erase was necessary because the MK22 MCU is read protected to prevent the firmware being read out via the debug port, and the only way to do anything with the MK22 once its read protected is to completely erase the chip.

 

The next step was to reload the whole MCU with the program data dump taken from Kai’s GD-77, but I found after programming the MK22 that my GD-77 was not working, and it seemed to be constantly rebooting.

Fortunately by the time I’d tried Kai’s firmware, Kai had worked out that the firmware dump from his radio would not run on any other GD-77’s because the firmware contains a hardware lock feature.

Both the bootloader and the main application check the unique ID number in the MK22 MCU (which is assigned during manufacturing of the IC), and if this does not match a “key” in the firmware, which is specific to each GD-77 (MK22), the GD-77 just reboots about once per second.

 

Fortunately Kai was able to track down where the “key” was stored in his firmware dump file, and was able to write a tool that allowed a new key to be generated for my GD-77.

 

To do this I had to read the CPU ID (16 bytes) using the hardware debugger, and use a utility written my Kai to generate 2 sets of keys (32 bytes), which are specific to my CPU ID

These “key” bytes then needed to be copied into Kai’s firmware dump, so that it would work in my GD-77.

 

Having a hardware lock in the firmware is actually completely pointless, and I’m not sure why Radioddity bothered to include it, because anyone with access to an unencrypted copy of the firmware, and enough programming knowledge, could find where the hardware lock code was located, and remove it from both the bootloader and the main application.

 

But the most expedient fix to get my GD-77 working again, was to install the “key”.

Having the correct key installed, also allows me to still upload any previous version of the firmware using the Radioddity firmware updater program, since the “key” value is not overwritten by the Radioddity firmware updater when it uploads an update.

 

Up to this point, I didn’t have the front panel on the GD-77, so I was unable to press any keypad buttons or see what was on the display. So I decided to cut a hole in the side of the front panel and start to install a socket, so I could connect to the hardware debugging pins.

 

 

I had hoped to be able to fit the socket completely inside the GD-77, but there wasn’t enough space between the back of the main PCB, and the PCB of the front panel keypad and display.

So my current plan is to glue the socket on the outside and just have the pins protruding inside the case.

 

However, I have not got that far yet, because I found small problems with the GD-77 after i refitted the front.

Firstly, I’d got some plastic dust on the inside of the display, which in the long term I will need to remove,

and secondly the RF connector seems to be slightly miss aligned and I was unable to fully refit the retaining nut.

 

I’m not sure why the RF connector is miss aligned, but I did remove and refit it, when I initially removed the main PCB from the back of the radio, only to find that it was not necessary to do this, since the hardware debugging connections were on the side of the PCB which is immediately accessible.

I had to unsolder the connector to remove it, and I think somehow, I have not refitted it correctly, despite it being secured by 2 small bolts.

 

 

Currently I have just threaded the hardware debuging wires, out though the hole, and connected them to the external hardware debugger.

 

 

 

 

One problem with this, is that because the Vcc and Reset wires are not connected to anything, they act as mini antennas, and the RF generated when transmitting, can cause the MK22 to reset.

In an effort to prevent this problem, I’ve temporarily turned down the PA power settings, by updating the calibration table in the GD-77’s external Flash memory. But in the longer term, I think I will need to decouple the ends of the wires. Or possibly just pull the Reset pin high, via a 10k resistor, and the other SWD pins with appropriate resistors to whatever supply is required.

 

One thing I have also noticed, is that the GD-77 should not have power applied to the Vcc pin on the debugging connections.

This is because the MK22 MCU seems to have its voltage supply controlled by some other IC, so that when the volume control is turned to the off position, the MK22 reads the ON/OFF switch and runs some shutdown code, before triggering its own power to be cut off.

Supplying power to the Vcc would feed voltage to the output of the power control circuit, which could potentially damage it.

 

Over the weekend I started to explore the internal data inside the MK22 when it was running, but I’ll write a separate post about this.

4 Responses

  1. ken
    |

    its getting exciting

  2. Justin
    |

    How can I get involved? I see the version I have has a Secure Connection issue and I know how to resolve it

  3. Roger Clark
    |

    Hi Ken

    My proof-of-concept changes to enhance the DMR ID seem to be working ok and I have sent the firmware to 2 people for initial testing.

    I have already updated the CPS to use the enhanced DMR ID operation, and you can download that already.

    It is still compatible with the existing firmware unless you change the number of characters that are stored per DMR ID.

    I will write a separate post to explain the new feature in the CPS.

  4. Roger Clark
    |

    Most of the activity is on GitHub https://github.com/rogerclarkmelbourne/Radioddity_GD-77/issues

    Post a new issue for this bug

    If you want to actively investigate this bug, you are going to need to..

    1. Install Ghidra
    2. Install my MK22 processor Spec file into Ghidra
    3. Use Kai’s tools to decrypt firmware 3.1.8
    4. Create a new Ghidra project and import the decrypted firmware, using the MK22 PSPEC file, at start address 0x4000
    5. Install my symbol loader script into the Python plugins
    6. Run the script to import the latest list of symbols created by @forkoz

    This will allow you to view the code, in assembler and also rudimentary C decompilation

    To do any serious debugging, you need to partially disassemble the GD-77 and connect a hardware debugger to the SWD pads on the back of the main PCB.

    AFIK, only Kai and I have a debugger connected to our radios , but it is essential in order to be able to debug the radio while it’s actually running.

Leave a Reply