Well, the good news is:
Theoretically i should be able to "backup" a licensed key, unregister it and "restore the backup" without registering again.
As useless as that is...^^
We could make a tool to activate a license, store the valid code somewhere, ask to remove the license, put the valid code back and use a fake server to avoid reactivating it. Will need to modify the host of the user to avoid wrong activation and prevent the game from being launched without the "crack".
It's probably the simplest option but it needs a real license and be sure that people don't activate the original license by mistake. And if the server see multiple register/unregister, the key will probably be blacklisted. Also need a new key for each update.
Otherwise it's patching.
The server generates a license key from it and sends it back to the user. The license key is then verified by the key system (implemented in Ekag20nt.exe). If it's found valid, the key inside C:\ProgramData\Key-Base\63e70b6f.052\CODE.PKD is updated to a registered state.
If I get it, we need to patch the function that looks at the CODE.PKD to make him believe the code is valid.
But the check is probably done in the DLL where there is a checksum verification. Can we patch the checksum in the binary calling the dll functions?
edit:
I think I know what you might be hitting. I believe there's 2 programs making requests: The "Deactivation.exe" and the actual game "Shipping" something exe. Monitor the requests made by the shipping exe, that's the one doing the actual license check to launch the game. The Deactivation exe is only doing a check to see if the license exists or not, and I think that one you can actually bypass with the dnspy tool.
What we basically need to do is tell the shipping exe when it makes a request, "yes, your license key is valid".
Fallendoll.exe calls Ekag20nt.exe (CreateProcess with apparently two parameters "C:\XXX\WindowsNoEditor\EKAG20NT.EXE" 0200D4XXXXBE5A5A 0) and that's the binary which check CODE.PKD (ReadFile). Then Fallendoll.exe start the Deactivation.exe. I guess Ekag20nt.exe communicate with Fallendoll.exe to tell him when the key is alright and in that case it doesn't start deactivation.exe. deactivation.exe doesn't look for the keys nor seems to directly interact with Ekag20nt.exe.
I tried to find any reference to "CODE.PKD" in the strings of Ekag20nt.exe to help pinpoint the location of its opening but to no use. I have multiple XREFs from ReadFile so starting from there could be an option. Or maybe try to setup a ReadFile() hook in a debugger to see where he does that.
We could also start from the CreateProcess of fallendoll.exe to see how they communicate.
The callstack shows us it's coming from H4C+0x2601 in Ekc6420.dll.
edit2:
Really not sure about that but I found functions DdeClientTransaction() and many other like DdeConnect, DdeDisconnect() , DdeAccessData(),DdeUnaccessData() in ekc6420.dll just after the CreateProcessA().
and DdeNameService(), DdeGetData() in Ekag20nt.exe
It could be use to communicate between them. DDE use memory objects to pass data from one application to another.
I'm really not familiar with this library so maybe I'm totally in the wrong here.
But if DDE is used by Ekag20nt.exe to tell FallenDoll.exe thru Ekc6420.dll that the license is not valid, it could be interesting to try to tamper the data to make him believe the key is valid. It would need to be done from Ekag20nt.exe and not Ekc6420.dll if there is a checkum validation. But I doubt it will be as simple as a true/false from Ekag. Maybe it sends some data and Ekc6420.dll does to cryptographic validation or something. Or worse, Ekag20nt.exe sends the PKD file to the dll and he does a verification on it.