The Radioddity GD-77 is a great DMR radio, however the CPS (PC software used to setup the transceiver), is not the most user friendly piece of software I’ve ever come across 
Ideally the CPS would be available as open source, possibly using a cross platform like Python, or even Java, but this is not the case.
Fortunately however, the CPS is written using Microsoft’s Dot Net (.Net) using C#, which can be reasonably well reverse engineered using open source de-compilers like ILSpy
https://github.com/icsharpcode/ILSpy
This has enabled me to produce a re-engineered version of the CPS which I have made available in both source code and installer exe, which I’ve decided to call the “Community Edition”
The installer can be downloaded from this link https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps2.0.5/raw/master/installer/RadioddityCPS2.0.5CommunityEditionInstaller.exe
The Github repo is here https://github.com/rogerclarkmelbourne/radioddity_gd-77_cps2.0.5
My aim with this project is to create a version of the CPS which resolves the bugs in the existing CPS, as well as trying to address some issues in the firmware, by using work-arounds, and also makes general improvements to its operation.
For example, the official CPS has a bugs where Scan list of more than 256 items have an error, and…
If Dual Direct mode checked in a digital VFO and is the changed to an Analog VFO, there is a bug in the firmware version 3.0.6 which causes the GD-77 to transmit even if the PTT is not pushed.
The CPS also didn’t prompt when you press the Read or Write, button(s), which could mean you accidentally overwrite the codeplug in the GD-77 or in the CPS.
I also didn’t like the additional popup which appears to tell you an upload or download (Write or Read) was complete, as this seemed very clunky.
Ideally the data storage used by the CPS needs to be completely rewritten, to unlink the position of Contacts and Rx Groups in their respective lists from the values that are selected in the Channel screen, but that’s a much bigger undertaking, which I don’t have time to investigate at the moment.
The CPS is also missing the feature to export and import Rx Group lists and Zone lists etc, but this may be possible to do whilst using the existing data storage.
Since publishing the files onto Github a few days ago, Colin G4EML has sent me several PR’s to fix bugs that were present in the official CPS and some bugs which seem to be new to this version, and I’m hoping the other people will send me enhancements and bug fixes using GitHubs’ Pull Request (PR) system, as it would be good, for example to be able to include languages other than english and possibly to have example codeplugs for various countries, as part of the installed software.
For those interested in the technicalities of how this was possible…
Although the CPS is written in C# .net, I initially had difficulty in decompiling it. I tried using a demo version of .Net Reflector (by RedGate Software), however it was unable to read the exe, because it had been “protected” using an “obfuscator”
After trying several de-obfuscator tools, I was able to establish that the exe is obfuscated using “.Net Reactor”, and I could not find any tools, either open source / free of commercial which would de-obfuscate the file.
However a few weeks ago, I downloaded the latest version of de4dot ( https://github.com/0xd4d/de4dot ), and some recent updated to this excellent tool, allowed it to “Clean” the CPS DMR.exe
De4dot is not a decompiler, its just a deobfuscator, so I took the “cleaned” exe and tried using .Net Reflector again, and this time it was able to open the file and show the internals.
However, possibly because the version of ,Net Reflector I was using was a demo copy, it didn’t seem to have a easy way to export the source code to separate .CS files.
Searching for an alternative to .Net Relector I came across ILSpy https://github.com/icsharpcode/ILSpy which is an excellent open source decompiler, and with this I was able to export all the source code to individual class and resource files, and it also creates a Visual Studio project file.
Having the decompiled sources and a VS project file is still only half the battle in this case, because when I opened the VS project, and tied to build the application, I got hundreds of errors.
Looking at the errors they seemed to mainly be caused by half a dozen different problems.
Firstly many of the Class constructors had a call to a non existent function in the base class.
base._002Ector();
My guess is that these are the default calls to the base class constructor, which normally the C# compiler hides from developers and which they take for granted,
But the calls can be written as
base..ctor();
The best solution was simply to comment out these calls, because the compiler will automatically make the appropriate calls to the base class for the default constructor (constructors with no arguments)
Also, all of the class constructors made a call to:
Class21.mKf3Qywz2M1Yy();
But class21 looks like this:
internal class Class21
{
internal static void mKf3Qywz2M1Yy()
{
}
}
These calls don’t seem to serve any purpose, and are probably just an artifact produced by the decompiler.
I’ve looked at some tutorials about ILSpy and I have not come across these sorts of things, so they could also be caused because of the obfuscation process.
Either way, I found I could completely remove Class21 and comment out all calls to it, and the code still ran just fine.
The next type of error was caused because the decompiler didn’t seemed to have problem with classes with no default constructor. These classes only had constructors with arguments.
The solution for this was to add the appropriate calls to the base constructor e.g.
public InputReport(HIDDevice oDev) {
base._002Ector();
}
Needed to be:
public InputReport(HIDDevice oDev) : base(oDev)
{
}
Making those changes allowed the code to compile, however it would not run because the application could not find any of its resources
I found the solution to this was to rename the resource files which had been preface with the namespace e.g
DMR.ZoneBasicForm.resx
change to:
ZoneBasicForm.resx
And I moved these into the same folder as their respective class.
The app then built and ran reasonably well, but I did need to resolve a few problems, in the same way you’d normally bug fix any code that didn’t seem to be working correctly. namely put a break point where the code was crashing and examine the variables etc and see why things were not doing what they were supposed to.
The first change I made to the code was to upgrade to a newer version of WeifenLuo.WinFormsUI.Docking.dll by downloading the latest sources from Github, and rebuilding using .Net 4 to match the .Net version being used by the main application.
The newer version of Winforms UI, had a small change to the API, and I needed to change a few places in the code where the setFont was being called as a method, but in the new version of WInforms UI this is a property.
This seemed to work fine, except possibly it may have caused one strange bug, which I found later where I was able to open multiple copies of the same form, but in the official App this wasn’t possible
Colin G4EML sent me a bug fix / work around, for this, and neither of use was able to see how the original code , which checked if an existing form, of specific type was open, before instantiating a few copy.. Could have been working in the first place.
However I tested with the original DLL and it seemed to have the same problem, so perhaps this bug was also caused by the decompilation process.
Overall, I’ve been pleasantly surprised at how relatively easy, after just a few hours work, it has been to re-engineer this exe, and I hope that people will contribute to make it better.
PS.
Only time will tell if Radioddity releases a firmware which requires a new CPS, in which case I’ll hopefully be able to just though the same process again.