5

Right, I am talking about license validation code in a desktop application, e.g. a method bool ValidateLicense(string licenseCode). Of course, any protection scheme can be reverse engineered by a skilled and determined cracker. However, I'd like to prevent that anyone with some basic programming knowledge can use Reflector to build a keygen in a couple of minutes.

Possible approaches

  1. Obfuscate. My understanding is that obfuscating causes a performance overhead and may hinder (legitimate) debugging. So are there tools that allow obfuscating only selected methods?

  2. Move method to ngen'ed assembly or unmanaged DLL. But isn't this an invitation to simply replace the DLL? Any ideas how to prevent this (read: make it a bit harder for an attacker)?

  3. Other?

PS: Question is obviously related to Protect .NET code from reverse engineering? trying to put thoughts from there to practice

UPDATE

To 1. A first obfuscation step would surely be to rename the validation method. (Thanks, Jonathan)

To 2. Assuming the application uses Win32 API methods one could re-route the calls through an unmanaged DLL thereby making it an integral part of the application. Fiddling with the method signatures (e.g. change name, swap parameters) would make this less obvious. Do you think the innate drawbacks are justified?

To 3. Don't distribute validation method belongs here. Keep it on your server and call remotely, i.e. use online validation (Thanks, David Hedlund)

Community
  • 1
  • 1
Paul B.
  • 2,394
  • 27
  • 47
  • We decided against obfuscation and using a simple license key mechanism, together with an online activation. Of course can this be "cracked" (and in fact it was). Our calculation is as following: those who use pirated version never would have bought the tool, plus we get some more distribution of our software. Not perfect, but good enough comparing the effort to protect the software with the (much better) "protection" of writing good tools. – Uwe Keim Jul 19 '12 at 07:00
  • Use a combination of an obscure VM, online validation and using a randomised VM code supplied by an online validation service for some essential (but not performance-critical) parts of your code. Or even move parts of the essential functionality (not just validation) into an online service. – SK-logic Jul 19 '12 at 08:13

4 Answers4

2

Eazfuscator let you obfuscate your code only in Release, We're using it a don't feel any performance problem. It let you obfuscate selected methods too. Note that public methods can't be obfuscated.

Any function like your ValidateLicense can be easily modified with a good reflector inserting a return true as the first line :( I recomend you this articule about code injection in assemblies: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection

You should sign your assemblies to avoid modifications, but... The signature can also be removed with the propper tools: http://www.nirsoft.net/dot_net_tools/strong_name_remove.html

Sorry, but there isn't any trick to avoid reverse engineering in .Net, you can only makes things harder. (by ex. don't name yout function ValidateLicense and make your validation logic a bit cryptic)

Jonathan
  • 11,809
  • 5
  • 57
  • 91
  • There isn't any trick to avoid reverse engineering of any software that does not reside on your own servers. – Anton Tykhyy Jul 19 '12 at 07:10
  • 1
    The article about Reflexil is impressively demonstration the potential of .NET reflection! (Or scarily from a developer's perspective ;) – Paul B. Jul 19 '12 at 07:17
2

One approach that a lot of software vendors have adopted is to require online activation. That way, the key validation code can be executed only at your server, which would make it less accessible to would-be hackers.

Of course, then you introduce the new vulnerability of simply re-routing the validation call to a custom server that sends a success response, if the hacker knows or can extract information on how such a response is expected to look. But then, as you point out, there will always be someone who will be able to hack your product, so I would still say this is a viable option.

David Hedlund
  • 128,221
  • 31
  • 203
  • 222
  • Right, that's an excellent point for option 3. Getting it to work in an enterprise scenario could be tricky so maybe I start with an offline approach and monitor if my app really attracts crackers. – Paul B. Jul 19 '12 at 07:27
2

Three possible attacks against the validation are

  1. Bypassing validation by removing calls to it
  2. Reverse engineer validation logic to reveal legitimate codes
  3. reverse engineer validation logic to allow validation condition to met by modifying environment

One approach is to validate the licence at several points in your application - this helps mitigate 1. Code obfuscation helps mitigate 2 and 3 - but ultimately it's an intractable problem.

My opinion is a combination of these approaches would prevent basic programmers stealing your program, but then again, if somethings worth it - then somebody will do it.

Jimmy
  • 6,001
  • 1
  • 22
  • 21
1

I know it is not the answer, but I would suggest using .NET Reactor http://www.eziriz.com/ as it already has mechanisms for both licensing (with various licensing scenarios) and strong code protection.

Tomas Grosup
  • 6,396
  • 3
  • 30
  • 44