Protect .NET code from reverse engineering?

Question

Obfuscation is one way, but it can't protect from breaking the piracy protection security of the application. How to make sure that the application is not tampered with, and how to make sure that the registration mechanism can't be reverse engineered. Also it is possible to make to convert C# app in native code, Xenocode is too costly.

C# provides lot of features, and is the ideal language for my code, so writing in C++ again the whole codebase is out of question.

Secure certificates can be easily removed from the signed assemblies in .NET

Answer 1

Is it really worth it? Every protection can be broken with sufficient determination. Consider your market, price of the product, amount of customers, etc.

If you want something more reliable then go down the path of hardware keys, but that's rather troublesome (for the user) and more expensive. Software solutions would be probably a waste of time and resources and the only thing they would give you is the false sense of 'securiry'.

Few more ideas (none is perfect, as there is no perfect one)

• AntiDuplicate
• Change the language, use the nice tricks that the authors of skype used
• License server

And don't waste too much time on it, because the crackers have a lot of experience with the typical techniques and are few steps ahead of you. Unless you want to use a lot of resources, probably change the programming language (do the skype way).

Answer 2

If its written in .NET and compiled to MSIL, it can be reflected. If security is a concern and obfuscation is to be avoided, then I recommend writing your app using a non-managed language, which is, by nature, harder to reverse engineer.

Answer 3

You can't.

There are steps you can take to make it a little more difficult but ultimately any executable on the local machine is crackable. Eventually that code has to be converted into native machine code and every application that is runnable is vulnerable.

What you want to do is just make it difficult enough to crack to make it not worth peoples trouble.

Some suggestions I have for you to help protect your app:

• Obfuscate your code. Dotfuscator has a free edition and comes with Visual Studio.
• Use public/private key or asymmetric encryption to generate your product licenses. This ensures that only you can generate your license codes. Even if your app is cracked you can be sure that they won't be releasing a key generator for your application because it is impossible to reverse the key generating algorithm.
• Use a 3rd party packer to pack your .NET executable into an encrypted w32 wrapper application. Themida is one of the better ones. This stops people from reflecting your application in .NET Reflector and makes it a pain to unpack for reversing.
• Write your own custom packer. If the 3rd party packers are too expensive, consider writing your own. Sometimes custom packers can be very effective because there aren't well published methods on how to unpack them. This tutorial gives a ton of good information on writing your own win32 packer.

Ultimately though, if people want your application cracked they will. Look at all the commercial software out there that has a vast amount of resources to protect their applications and yet they are cracked before the applications are even released to the public.

A skilled reverse engineer can fire up IDA-Pro and slice through your application like butter no matter what you do. A packed application can be unpacked and obfuscation only prevents it from making it a walk in the park. All your hard work with your complex license code can be undone with a single byte patch.

You just need to accept that there is a very real chance people are going to pirate your software. There are some people who are never going to pay for your application no matter what and these are the people you don't need to worry about.

There are however, many businesses out there who would never risk a lawsuit and happily buy software licenses and many computer users who either don't want to risk it, find it wrong or are not tech savvy enough to pirate. These are your true customers and you should focus your efforts on providing them with a good user experience and ignore the people cracking your software.

I've had my application pirated before and I took it as a personal affront. Here I was, a small-time developer, pouring my heart and soul into an application and these people had the gall to pirate from me?! They were taking money directly from my pocket!

I immediately added in a bunch of draconian DRM code and attempted to sabotage any person using an illegitimate or cracked copy. I should of been working on making my application better instead of trying to stop the inevitable. Not only that, but I was hurting my true customers will all these extra protections I was putting in.

After a long battle I realized I was fighting the tides and all this time wasted was for naught. I took out all the phone-home code except for the barebones license functions and never looked back.

Answer 4

Unfortunately you are not going to run away from this. Your best bet is to write your code in C and P/Invoke it.

There is a small catch-22, someone could just decompile your app to IL and kill any verification/activation code (e.g. the call to your C library). Remember that applications that are written in C are also reverse-engineered by the more persistent hackers (just look at how fast games are cracked these days). Nothing will protect your application. In the end it works a lot like your home, protect it well enough so that it is too much effort (spaghetti code would help here) and so that the assailant just moves onto your next door neighbor (competition :) ). Look at Vista, there must be 10 different ways to crack it.

There are packages out there that will encrypt your EXE and decrypt it when the user is allowed to use it, but once again, that is using a generic solution that has no doubt been cracked.

Activation and registration mechanisms are aimed at the 'average Joe:' people who don't have enough tech savvy to bypass it (or for that matter know that they can bypass it). Don't bother with crackers, they have far too much time on their hands.

Answer 5

How to make sure that the application is not tampered with, and how to make sure that the registration mechanism can't be reverse engineered.

Both have the same very simple answer: don't hand out object code to untrusted parties, such as (apparently) your customers. Whether it's feasible to host the application on your machines only depends on what it does.

If it isn't a web app, maybe you can allow for ssh login with X forwarding to an application server (or remote desktop, I guess, for windows).

If you give object code to nerdy type persons and they think your program might be fun to crack, it will get cracked. No way around it.

If you don't believe me, point out a high-profile application that hasn't been cracked and pirated.

If you go with the hardware keys, it'll make production more expensive and your users are going to hate you for it. It's a real bitch to crawl around on the floor plugging and unplugging your 27 different USB thingies because software makers don't trust you (I imagine).

There are packages out there that will encrypt your EXE and decrypt it when the user is allowed to use it

Of course the way around it is to crack the "can-I-use-it" test so that it always returns true.

A nasty trick might be to use the byte values of the opcodes that perform the test somewhere else in the program in a dirty way that'll make the program crash with high probability unless the value is just right. It makes you linked to a particular architecture, though :-(

Answer 6

Broadly speaking, there are three groups of people out there. Those who will not buy your software and resort to cracks, or if they don't find any, not use your software at all. Don't expect to make any money from this group. They rely either on their own skills or on crackers (who tend to prioritize their time depending on your useful and how big your audience is. The more useful, the sooner a crack will be available).

The other is the group of legitimate users who will buy (pay for) your software, irrespective of what protection mechanism you use. Don't make life hard for your legitimate users by using an elaborate protection mechanism since they are going to pay for it in any case. A complex protection mechanism can easily spoil the user experience and you don't want this happening to this group. Personally, I'd vote against any hardware solution, which adds to the cost of your software.

Thirdly, a minority who will not resort to "unethical" cracking and will pay for your software because its features are protected by a licensing mechanism. You probably don't want to make it exceedingly easy for this group to circumvent your protection. However, all that effort you spend on protecting your software will pay back, depending on how big this group of people is. This entirely depends on the type of software you're building.

Given what you've said, if you think there is a large enough minority who can be pushed into buying your software, go ahead and implement some form of protection. Think about how much money you can make from this minority versus the time you spend working on the protection, or the amount you spend on a third party protection API/tool.

If you like to implement a solution of your own, using public-key cryptography is a good way (as opposed to symmetric algorithms) to prevent easy hacks. You could for instance digitally sign your license (serial no, or license file). The only way to get around this would then be to decompile, alter and recompile the code (which you could make harder using techniques such as those suggested in Simucal's answer).

Answer 7

• Use online update to block those unlicensed copies.

• Verify serial number from different modules of your application and do not use a single function call to do the verification (so that crackers cannot bypass the verification easily).

• Not only check serial number at startup, do the verification while saving data, do it every Friday evening, do it when user is idle ...

• Verify application file check sum, store your security check sum in different places.

• Don't go too far on these kind of tricks, make sure your application never crash/get into malfunction while verifying registration code.

• Build a useful app for users is much more important than make a
  unbreakable binary for crackers.

Answer 8

You can't prevent people from cracking your software.

However, you can make them create cracks that will hurt your sales less. Keygenerators that can issue a valid registration code for your software are much worse than simple patches that remove registration incentives from your software. That's because a crack will work for one software version only, and will cease to work with the next software update you release. The keygenerator will continue to work until you change your registration key algorithm and that's something you don't want to do often because it will put off your honest clients.

So, if you are looking for a method to fight illegal keygenerators for your software and you do not want to use assymetric encryption because of the long registration codes this generates, you might have a look at Partial Key Verification.

Partial Key Verification makes sure that each illegal keygenerator works only for one particular release of your software. Basically what you do is to make sure that each release of your software only links with the code for checking SOME digits of the registration code. Which digits exactly is random, so crackers would have to reverse engineer many different versions of your software and combine all this into one keygenerator in order to release a keygenerator that works for all versions of your software.

If you release new software versions on a regular basis, this leads to numerous keygenerators spread on all kinds of software piracy archives which are not working anymore. Potential software pirates usually look for a crack or keygen for the latest version, so they will likely try a few of those and give up eventually.

I've used the Partial Key Verification in my (C++) newer shareware games and it has been very effective. Before we had plenty of problems with keygenerators which we could not fight. Afterewards there were lots of cracks and some few keygenerators that worked only for that particular version of the game, but no key generator that would work with all versions. We regularly released very minor updates of the game and to render all previously existing cracks useless.

There seems to be an open source .NET framework for Partial Key Verification, although I have not tried it.

Answer 9

You can..

Microsoft SLP Services offers the ability to help protect code without affecting the functionality of your applications, checkout this link

Answer 10

.NET Reactor

.NET Reactor provides complete protection for your sensitive intellectual property by converting your .NET assemblies into unmanaged processes which cannot be understood as CIL, and which no existing tool can decompile. Hackers have no access to any intelligible form of your source.

Powerful and flexible, the .NET Reactor licensing features allow you to enforce your license conditions and protect your revenue stream by using hardware and software locks. The license manager can build trial or permanent licenses, in a matter of seconds. A fully documented software development kit (SDK), complete with examples, allows you to call the licensing system directly from your code, allowing you to create custom extensions to the licensing system.

I highly recommend it and it is also very cheap compared to other products.

Answer 11

Apart from purchasing protection, you(or your developers) can learn to copy-protect.

These are ideas:

At first, try to write a program that writes itself to console. That's a famous problem. Primary purpose of this task is to practice writing self-referencing code.

Second, you need to develop a technology that will rewrite some code in a way dependable on other methods' IL.

You may write a virtual machine (yet in .Net). And put some code in there. Ultimately, the virtual machine runs another virtual machine which runs the code. That's for a part of rarely-called functions for not to slow the performance too much.

Rewrite some logic into C++/CLI, and mix managed code with unmanaged. This will harden the disassembling. In this case, do not forget to provide x64 binaries too.

Answer 12

Just make a good app and code a simple protection system. Doesn't matter the protection you choose, it will be reversed... so don't waste too much time/money.

Answer 13

There's Salamander, which is a native .NET compiler and linker from Remotesoft that can deploy applications without the .NET framework. I don't know how well it lives up to its claims.

Answer 14

it's impossible to fully secure an application, sorry

Answer 15

If MS could come up with a solution we will not have pirated windows version ;-) so nothing is very secure.Here are some similar questions from SO and you can implement your own way of protecting them. If you releasing different versions then you can adopt different techniques for different version so by the time first one is cracked the second one can take over.

http://stackoverflow.com/questions/638012/managing-features-on-a-license-basis-for-a-c-app

http://stackoverflow.com/questions/106347/secure-dll-with-license-file

http://stackoverflow.com/questions/111291/licensing-protection-software

Answer 16

Here's one idea: you could have a server hosted by your company that all instances of your software need to connect to. Simply having them connect and verify a registration key is not sufficient -- they'll just remove the check. In addition to the key check, you need to also have the server perform some vital task that the client can't perform itself, so it's impossible to remove. This of course would probably mean a lot of heavy processing on the part of your server, but it would make your software difficult to steal, and assuming you have a good key scheme (check ownership, etc), the keys will also be difficult to steal. This is probably more invasive than you want, since it will require your users to be connected to the internet to use your software.

Answer 17

In my experience, making your application or library more difficult to crack hurts your honest customers whilst only slightly delaying the dishonest ones. Concentrate on making a great, low friction product instead of putting a lot of effort into delaying the inevitable.

HTH, Kent

Answer 18

When it comes to .NET, if you're releasing a Windows Forms application (or any application where the client has the Portable Executable file), it's able to be cracked.

If you want to stick with .NET and want to minimize the chance of having your source code taken, then you may want to consider deploying it as an ASP.NET application across a webserver, instead of making it a Winforms application.

Answer 19

See my answer, here, too:
http://stackoverflow.com/questions/651291/securing-a-net-application/651375#651375

Answer 20

Instead of obfuscation you could precompile your .NET assemblies for the target platform making the code much more difficult to reverse engineer.

Answer 21

Reflector can only open "managed code" which basically means ".NET code". So you can't use it to disassemble COM DLL's, native C++, classic VB6 code, etc. The structure of compiled .NET code makes it very convenient, portable, discoverable, verifiable, etc. Reflector takes advantage of this to let you peer into compiled assemblies but decompilers and disassemblers are by no means specific to .NET and have been around as long as compilers have been around.

You can use obfuscators to make the code more difficult to read but you can't exactly prevent it from being decompiled without also making it unreadable to .NET. There are a handful of products out there (usually expensive) that claim to "link" your managed code application into a native code application but even if these actually work, a determined person will always find a way.

When it comes to obfuscation however, you get what you pay for. So if your code is so proprietary that you must go to such great lengths to protect it, you should be willing to invest money in a good obfuscator.

However, in my 15 or so years of experience writing code I've realized that being over-protective of your source code is a waste of time and has little benefit. Just trying to read original source code without supporting documentation, comments, etc can be very difficult to understand. Add to that the senseless variable names that decompilers come up with and the spaghetti code that modern obfuscators create - you probably don't have to worry too much about people stealing your intellectual property.

Answer 22

A secret that you share with lots of people is not a secret. If you have secret stuff in your code, obfuscating it is no protection; it only has to be deobfuscated once. If you have a secret that you don't want to share with your customers, then don't share it with your customers. Write your code as a web service and keep your super secret code on your own server, where only you can see it.

Answer 23

I've written about this at length in the past:

http://stackoverflow.com/questions/651291/securing-a-net-application/651375#651375

The short version is that any time you put code out to a user's desktop, they will eventually be able to own that code. Even C/C++ programs can be decompiled and strong encryption will be broken. If systems like iPods and Playstations get cracked, where they even control the hardware, what do you expect to really do? Your software will get cracked.

Given that axiom, the best path is not to spend too much time trying to secure your app, but rather look for a way to turn to your advantage all those users who would never have paid for your product but now will have access to it.

Answer 24

Frankly, sometimes we need to obfuscate the code (e.g. Register license classes and so on). In this case, your project is not free. IMO, you should pay for a good obfucator. Dotfuscator hides your code and Reflector shows an error when you attempt to decompile it.

Answer 25

use obfuscator. see this link.

Answer 26

obfuscate the code!

there is an example: http://www.semdesigns.com/Products/Obfuscators/CSharpObfuscationExample.html

Answer 27

If you want people to able to run your code (and if you don't, then why did you write it in the first place?), then their CPU needs to be able to execute your code. In order to be able to execute the code, the CPU needs to be able to understand it.

Since CPUs are dumb, and humans aren't, this means that humans can understand the code as well.

There's only one way to make sure that your users don't get your code: don't give them your code.

This can be achieved two ways: Software-as-a-Service (SaaS), i.e. you run your software on your server and only let your users access it remotely. This is the model that StackOverflow uses, for example. I'm pretty sure that StackOverflow doesn't obfuscate their code, yet you can't decompile it.

The other way is the appliance model: instead of giving your users your code, you give them a computer containing the code. This is the model that gaming consoles, most mobile phones and TiVo use. Note that this only works if you "own" the entire execution path: you need to build your own CPU, your own computer, write your own operating system and your own CLI implementation. Then, and only then can you protect your code. (But note that even the tiniest mistake will render all of your protections useless. Microsoft, Apple, Sony, the Music Industry and the Movie Industry can attest to that.)

Or, you could just do nothing, which means that your code will be automatically protected by copyright law.

Answer 28

Yes. It is true. .NET code is extremely easy to reverse engineer if the code is not Obfuscated.

Obfuscation will add a layer of annoyance to people trying to reverse engineer your software. Depending on which version you get, you'll get different levels of protection.

Visual Studio includes a version of Dotfuscator. Since it's a bundled version, you're definitely not getting the strongest Obfuscation possible. If you look at their feature lists, you'll see exactly what you're missing (and exactly what the application will do to make your code more secure).

There are a couple of other Free or Open Source .NET Obfuscators out there (but I can't comment on the quality or the various methods they use):

Obfuscar

Babel.NET

In the end, nothing is perfect. If somebody really wants to see how your software works...they will.

Answer 29

Anything running on the client can be decompiled and cracked. Obfusification just makes it harder. I don't know your application, but 99% of the time I just don't think it's worth the effort.

Answer 30

Yes, .net binaries (exe and dll) can be easily decompiled to nearly source code. check tool: Reflector. Just try it against any .net binary file. The best option is to obfuscate files, they still can be decompiled by reflector but they create unreadable mess. I don't think that good obfuscators would be free or cheap. The one is Dotfuscator Community Edition that comes with Visual Studio.

Answer 31

Bear in mind that 99%+ of your users aren't going to be interested in examining your executable to see how it works.

Given that so few people are even going to bother trying and that most obfuscators can be worked around, is it worth your time and effort?

You'd be better off investing the time into improving your product so that more people want to use it.

Answer 32

Just to add a warning: if you are going to use obfuscation, check that everything still works! Obfuscation might change things like class- and method-names. So if you use reflection to call certain methods and/or classes (like in a plugin-architecture) your application could fail after obfuscating. Also stacktraces might be useless to track down errors.