0

The environment is Windows. We are using 3rd party tools in our app, and for tools to work they require method call and pass a license key that is a string.
License.Import(string name, string email, string organization, string code)
Since it is an installable Windows app that might not have access to the internet, I don't see any solution, but to store license keys 'inside' the application.
The 'standard' way of protecting from memory dumping the key in C# is using SecureString. However, when initializing SecureString I still need to feed the actual key into it. Which means that someone could decompile the code and get the strings from there. To prevent that I could use XOR with another value to obfuscate the key, but then I would have to store the XOR value somewhere which then could be decompiled and so on...

How to go around this hide the string inside the app circularity? Or is it 'good enough' to just SecureString + XOR the key, and accept that if someone will be determined enough he will crack it no matter what?

1 Answer 1

2

Nothing you can do about it. DRM is impossible.

You can try to hide or encrypt your keys, but this only delays the inevitable. The data is on the computer of the customer/attacker, and as such can be found by them. Let me illustrate with some examples:

  1. Just leaving the string there

    Even a casual script kiddie could run strings over your application and detect the license key.

  2. Using SecureString

    This doesn't stop attackers at all, as SecureString isn't designed to protect against what you want to protect. The idea of a SecureString is to have the user enter some secret data manually (usually a password), and then wipe it from memory when no longer needed. This means if an attacker dumps the process memory after the password was entered, it will not be in the process memory anymore. Since you need to store your license key permanently in the application, it's identical to scenario 1.

  3. Encrypting the string and storing the key in the application

    This is like locking your house and hiding the key under the doormat. A determined attacker will be able to find both the encrypted blob and the decryption key, and then manually decrypt the license key. Or, an attacker can simply debug your application and wait for the application itself to decrypt the key and then steal it from there.

  4. Encrypting the string and storing the key on your server

    This is the same as 3., except way more difficult for you to implement. An attacker can again simply wait for the application to decrypt the license key and then steal it.

Why is this so hard?

Many many software companies try to implement DRM, and all of them get cracked. The reason for this is because any software that checks whether or not a check succeeded can be manipulated by the attacker to always make the check succeed. It is essentially impossible to make software that the attacker cannot manipulate, unless you use a system that is completely locked down from the hardware up (iPhone, Nintendo Switch, etc.), and even then attackers usually find weak spots that circumvent DRM.

2
  • "Many many software companies try to implement DRM, and all of them get cracked." This is true in an abstract sense, but in practice it's a cat-and-mouse game - the higher the stakes, the more money and resources will be needed to crack the DRM. There are examples of DRM systems that stay uncompromised for many years, either because the barrier was very high, or the stakes low enough not to warrant spending the effort. Jun 8, 2020 at 11:57
  • @GuidoDomenici Yes, but there is also the other side. If the stakes are very low, then the defender would be foolish to spend obscene amounts of money to do an extremely difficult to implement DRM. The most likely scenario for a low-stakes application is that nobody will bother to crack it and release an easy-to-use cracking software. I personally think that someone who is set out to pirate some software will either get the pirated version, or nothing at all. They usually don't pay for software.
    – user163495
    Jun 8, 2020 at 12:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.