.NET decompilation, how easy is it?

Question

I was looking into the best encryption for a license key for an application, and someone said that someone can easily decompile the application and then just skip the test for the license key.

how would someone go about doing that practically speaking? So they have my .dll, they have to decompile it somehow, then comment out the function call to check the license, then recompile it? The decompiler has to be really good such that the code still compiles!

Answer 1

Try opening your application with Reflector. You will probably be surprised :-)

And once a cracker has located the right location in your code, they can use a combination of ildasm/ilasm to remove the check from your application - even if the code Reflector generates won't compile.

Answer 2

If the source code was normally compiled it is very easy to decompile .NET assemblies.

You could use .NET Reflector, originally developed by Lutz Roeder, now supported by Redgate Software. There is a screenshot at the bottom of this answer which gives you an impression what Reflector does.

You can browse through your namespaces and classes and see the source code and methods in your favorite .NET language. Denis Bauer's FileDisassembler will allow you (or the evil hackers in your case) to convert it into a VS solution and make modifications to the program.

There are some countermeasures like using a code obfuscator to make your code practically unreadable.

There are some other interesting questions on StackOverflow about this topic:

• Should you obfuscate a commercial .Net application?
• How do I decompile a .NET EXE into readable C# source code?
• Best .NET obfuscation tools/strategy
• .NET cryptography for licence keys?

Screenshot from Reflector:

Answer 3

Josh Smith also released Crack.NET recently which can be used to attach to a running .NET process, and then open that up in Reflector - so even if the assemblies on disk are encrypted somehow (to avoid people using Reflector to get at them), they'll still be able to use the in-memory versions

Answer 4

.NET is super easy to decompile. Obfuscation will make it a little harder to understand what's going on, but someone decompiling your code can still figure it out if they are persistent.

Here is some advice on protecting your .NET code that I found online:

http://blogs.msdn.com/ericgu/archive/2004/02/24/79236.aspx

Just note that none of the techniques discussed are 100% effective, its just a question of how many hoops you'll make the cracker jump through.

Answer 5

.NET compilation in general is pretty easy: to get a feel for this yourself, just grab a copy of .NET Reflector and give it a try.

In most cases, there will be no need to recompile the code in order to remove a simple license check: simply patching the MSIL will do the trick.

Protecting yourself against this scenario yields rapidly diminishing returns: there will always be someone clever enough to bypass whatever additional checks you add to your code. For example, you could add a digital signature to your code, and refuse to run of the signature doesn't match (indicating the code has been tampered with, for example to remove the license check).

The game then becomes to remove the signature check (in addition to the license key check). So you add another check, which can then be bypassed, et cetera, ad infinitum.

There's a whole industry of code obfuscatation and copy protection tools to help you defend your software against issues like this. It's up to you to decide if the additional effort on your side, and the annoyance you'll cause your legitimate customers, is worth buying into these solutions...

Answer 6

If this is something you're looking to defend against, you may want to read up on how to attack it.

Exploiting Software by Greg Holland & Gary McGraw is an excellent introduction.

Answer 7

It is best not to go overboard on licence key technology. Whatever you do can be hacked by a determined user and you run the bigger risk of adding issues that stop legitimate users using your application. I have even seen code that was protected with Hasp Dongles get cracked. Encrypting your licence key and obfuscating your code should be enough to hinder opportunist attacks, there is little point going beyond that.

Eric Sink wrote a good article covering this point see section "4. Don't Annoy Honest People" of "Tenets of Transparency"

Answer 8

Even without Reflector, people have been doing this for ages. Basically you watch the app with a debugger - something like WinDBG will do - and then find out when the license check happens. You watch the return value, and then you simply patch the application to jump directly to the "all good" check.

I'd recommend everything that people have posted above. You just have to realize that it is a cat and mouse game, and if your return on investment is going to be worth it. If you have users that aren't trying to game the system, then something simple may do. If you have something where cracking is rampant, then you will have to look at different strategies and go from there.

You don't have to recompile the application to patch it - plenty of binary patch tools exist out there. And it won't stop your most determined crackers if there is enough money to be made.

Answer 9

"Too"

Any kind of "standard"/usual license check mechanism is a target for automated removal tool. And in the few commercial .NET apps I've reflected over, these "Too trivial" checks appear common.

Best bet is to protect by making part of the program dependent on web service. This should not be too chatty interface to avoid slowing the execution, but it should neither be very chunky, as those chunks could be just then downloaded and cached locally in the "cracked version" unless the app depends on them frequently changing.

If you want to avoid network connectivity (some uses or users might find that problematic/questionable depending on the app unless it's something that you describe and provides value) then splitting some of the program into a native dll or two and having the license checks in all parts of the app and less obviously so in the native dll's, would likely be enough to deter most.