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

+4  A: 

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).

Don't forget that it is quite possible to attack the software part of the hardware lock.
Magnus Hoff
Yes, that's true, the only real option would be to have the application partially implemented in hardware (some weird mix of software-VHDL application for example). This would also be crackable though...
What about dongles that implement a public/private key strategy. Only the private key of the dongle can decrypt the application and run it.
That's what the hardware key usually does. But you can either attack the dongle - clone it, or the software responsible for talking with the dongle (circumvent, disable, etc).
In my case it really WAS worth it. After I implemented Partial Key Verification and changed registration key scheme for an existing product, sales went up in significant manner. All software can be cracked, the question is just how high you raise the bar for the casual software pirate.
Adrian Grigore

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.

Kyle Trauberman
+140  A: 

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.

So +1 that it’s almost +2. I wish more people would finally get that you simply can not protect your software against a determined attacker.
free obfuscator for .NET platform:
You have reached software protection nirvana: it's not about adding more protection, it's about focusing on the product and making it so good that people WANT to pay for it. And for those that pirate it, they would have never paid anyways so it's as if they never existed.
Arthur Chaparyan
@Arthur Chaparyan, I agree. It took a long time to get here but I finally have seen the light. I went down the road of more restrictive protections and battling the crackers. I learned all I could about reverse engineering in an attempt to prevent my own. I finally figured out the right ideology
I think the key is to throw a poisoned bone to the software crackers (my see partial key verification answer) and to release new versions often to make sure that there are lots of non-working registration keys / keygens / cracks. This will put off most would-be pirates. Worked in my case.
Adrian Grigore
If every piece of software a multi-billion dollar company like Microsoft has put out has been cracked, then you have no chance. It's really not worth the hours upon hours you spend on research, coding, and testing when, by definition, your software CAN be cracked regardless.
Arthur Chaparyan
Hell I'd have been honored to find out someone thought my software was worth pirating...
Erik Forbes
When you start relying on the sales of your software for a major part of your income it changes things. It feels like someone is stealing from you. I get what you are saying though. I was shocked when I first found cracks for my software on torrent sites.
I wish I could +2 this.
Its just sad how few people understant that everything is void if the bad boy can change the brne or breq into nop or br. :( so, +1 for one of the sane people out there.
+1 - Deserve your gold badge 99-100 :P
Kyle Rozendo
+5  A: 

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.

Jonathan C Dickinson
If you really bother outsourcing your registration code into a dll, you should make sure that the DLL has to be different with every new version of your software. Otherwise your making it even easier for people to crack your software. All they'd need to do is crack your DLL once and use that for all later versions. Even end users could do this once they find an old cracked DLL, and this is even worse than putting the registration mechanism in your managed code.
Adrian Grigore
+1  A: 

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 :-(

Jonas Kölker
doesn't a crash point is easy to debug, and override the code in .NET to bypass that check. Also how will you change the opcodes in .NET, can u elaborate on this?
Priyank Bolia
Oh. I had C tricks in mind; say, take the address of the validation function, add up the 10 first bytes in that char array (cast the function pointer); pick any function f, and store [the address of f minus the previous sum] in fptr. Always call f as *(fptr + that sum). Precompute "that sum"
Jonas Kölker
+7  A: 

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).

Using strong cryptography to protect/verify your licences is completely useless if somebody rips out the code that aborts the application if the licence doesn’t check out. :)
Agreed, but as I was saying, the protection isn't for those groups of users who will resort to using cracks (an assumption that I made will exist).
public-key cryptography = asymmetric cryptography. I think you meant symmetric.
Bummer, thanks for pointing it out, I'll edit that :)
+5  A: 
  • 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.

+9  A: 

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.

Adrian Grigore
like the idea, you can also use different passwords for assymetric encryption in different releases.
Priyank Bolia
Interesting idea, but what exactly is the problem with a long registration code, anyway? Nowdays nobody would enter it by hand anyway - everyone would copy and paste it, so whether it's 10 characters or 100 characters shouldn't make any difference.
@Evgeny: That's only true if your users are power users. We have been creating shareware / casual games for many years and I can tell you that most of our users can't copy and paste. The registration window even comes with a manual on how to copy and paste, and some even don't it after reading it.
Adrian Grigore
Wow! OK, well, you obviously have more experience than me in this, so I can't argue, I can only say I'm surprised. But I would say that if they don't know how to copy and paste then you *should* make the code 200 characters long, so that they learn a highly useful general computer skill. :)
@Evgeny: Even with the short registration codes, we still got a lot of e-mails from people who have mistyped their codes and therefore thought that the code can't be valid because they would *never* make a mistake like this several times in a row. I prefer to leave the IT teaching to other companies... :-)
Adrian Grigore
+2  A: 

You can..

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

Binoj Antony
pricing my friend, buying a licensing software from Microsoft is too costly for normal ISV
Priyank Bolia

.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.

I tried to contact those guys with some question, I had about their product, but they never replied. Did your tried their product.I have gone with smart assembly and both their product and support is very good. But as I already said in the question obfuscation is one way, but not full proof.
Priyank Bolia
I had some issues with their product earlier and then I asked some question regarding high resolution icons in and I got a reply and a fix, but now it seems like they are hard to get hold of. To bad - it's a great product and I'm still using it
+2  A: 

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.

didn't get can you explain in detail.
Priyank Bolia

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.

+1  A: 

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.

Matt Olenik

it's impossible to fully secure an application, sorry

+1  A: 

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.

+1  A: 

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.

what if the server is down or users don't have internet access always, your method will simply frustrate the customers by having so many frequent round trip to the internet servers just to use an app.
Priyank Bolia
I agree completely. That's why I said "this is probably more invasive than you want..." in my last line. I was just offering the OP the best solution that I thought was technically feasible, not the best approach to keeping customers happy :)
In the first quarter of 2010 (several months after this answer was written), the game development company Ubisoft tried this, and apparently the load on the server-side components was so big that the games were unplayable. Overall impression of the SW: "hassle to install, cannot be used offline, invasive *and unreliable*". So, should you decide that server-side processing is the way to go, make sure you can actually scale to demand.
+21  A: 

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

Kent Boogaart
I wish I could vote you up more than once.

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.

George Stocker
+55  A: 
Joel Coehoorn
Thanks for the info everyone, i kind of figured that it would be imposable to lock it down completely, releasing a free and a pro version might be the way to go
Beautifully written.
Chris Lively
CW? +1 regardless.Nice answer, all points covered.
@Learning: it kinda grew over time and passed the automatic convert to CW threshold.
Joel Coehoorn
+1 Great answer!
Patrick McDonald
+1 Better than the answer I gave to the previous version of this question. @Joel Didn't know there was a limit.
I don't agree completely with everything in here, and it's an easy +1 anyway for the extremely well thought out presentation and argument.
Spot on answer!
Good argument, but misses a point about protecting intellectual property. If your app has some code that does something that is somewhat complex, obfuscation can provide the difference between flat out copying and pasting code, and trying to interpret and re-engineer code so it works. This is particularly important with updates: if someone has copied your obfuscated code, when you release an update, they have to do that over again - and at the very least, it causes them more pain/expense/time. If you don't have it protected in some way, they just copy/paste again and it works.
@gregmac : I didn't forget intellectual property (at least in that sense). If someone took the time to unobfuscate code for one version, they'll do it again for an update. And if someone has the time, skill, desire, and resources to decompile your code looking for hacks, obfuscation is only likely to slow them down a little. It's not gonna stop things. And by that I mean you stop a few people at that point, but someone somewhere will sit down and figure it out, and then they'll post it online for everyone.
Joel Coehoorn
Where it might matter is when you license code from someone else... then you may have an obligation to protect that IP.
Joel Coehoorn
Great post - it really goes into all the right details about the reasons why it's not worth bothering to write complex copy protection. Even though the question is a duplicate it's worth reopening it just for this answer. Maybe a mod can merge it?

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

Paul Sasik
NGen still requires the original assembly to be present on the machine, so that pretty much puts you back where you started if your goal is code obfuscation.
Perhaps NGen is not what he meant - there are some obfuscators that actually convert .NET assemblies to mixed .NET/native assemblies. These are indeed much more difficult to reverse engineer, but I strongly advise against using them - while a true .NET DLLs work in both 32bit and 64bit applications, a pre-compiled ones are either 32bit or 64bit only, which is a real hassle these days.
Lukas Pokorny
@Lukas, no in a previous revision ngen was specifically mentioned.
Josh Einstein
@Josh, you are right, thank for pointing this out.
Lukas Pokorny
+9  A: 

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.

Josh Einstein
+11  A: 

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.

Eric Lippert
Btw i m doing a project in which i want to activate a product "offline" also.(I made a WCF service to make activate online). In this case how u will manipulate code ? can u give me some hits ?

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

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.

Joel Coehoorn

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.

Mehdi Golchin

use obfuscator. see this link.

masoud ramezani

obfuscate the code!

there is an example:

+5  A: 

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.

Jörg W Mittag
+4  A: 

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):



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

Justin Niessner
It's not just "if they really want to see how your software works, they will". If they care, they can probably guess without looking. 99.9%+ of software doesn't have any magic pixie dust algorithms. The hard part of programming isn't some special secret technique. It's just getting all the parts to line up and work.
@Ken - Shhhh! You can't let the rest of the world know that most of the time we're not using magic pixie dust algorithms.
Justin Niessner
Justin: Does Love count as a magic algorithm? Love is what makes *my* programs special. I don't think you can disassemble Love.
+2  A: 

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.


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.

Redgate appears to have an obfuscator as well. I haven't used it, but I have liked some of their other tools. It's certainly not free though. See
Is Dotfuscator community edition at par with other obfuscator?I checked this comparision, however, most of the functionalities un-checked for the community edition, I didnt really understand whether they wuld be necessary!
+1  A: 

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.

+1  A: 

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.

Hans Kesting
Reflection can become quite fragile with obfuscated assemblies ...
James Westgate