.NET obfuscation tools/strategy

We've tried a number of obfuscators. None of them work on a large client/server app that uses remoting. Problem is that client and server share some dlls, and we haven't found any obfuscator that can handle it.

We've tried DotFuscator Pro, SmartAssembly, XenoCode, Salamander, and several small time apps whose names escape me.

Frankly, I'm convinced obfuscation is a big hack.

Even the problems it addresses is not entirely a real problem. The only thing you really need to protect is connection strings, activation codes, security-sensitive things like that. This nonsense that another company is going to reverse-engineer your whole codebase and create a competing product from it is something from a paranoid manager's nightmare, not reality.

I am 'Knee Deep' in this now, trying to find a good solution. Here are my impressions so far.

Xenocode - I have an old licence for Xenocode2005 which I used to use for obfuscating my .net 2.0 assemblies. It worked fine on XP and was a decent solution. My current project is .net 3.5 and I am on Vista, support told me to give it a go but the 2005 version does not even work on Vista (crashes) so I and now I have to buy 'PostBuild2008' at a gobsmacking price point of $1900. This might be a good tool but I'm not going to find out. Too expensive.

Reactor.Net - This is a much more attractive price point and it worked fine on my Standalone Executeable. The Licencing module was also nice and would have saved me a bunch of effort. Unfortunately, It is missing a key feature and that is the ability to Exclude stuff from the obfuscation. This makes it impossible to achieve the result I needed (Merge multiple assemblies together, obfuscate some, not-Obfuscate others).

SmartAssembly - I downloaded the Eval for this and it worked flawlessly. I was able to achieve everything I wanted and the Interface was first class. Price point is still a bit hefty.

Dotfuscator Pro - Couldn't find price on website. Currently in discussions to get a quotation. Sounds ominous.

Confuser - an open source project which works quite well (to confuse ppl, just as the name implies).

Note: ConfuserEx is reportedly "broken" according to Issue #498 on their GitHub repo.

Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again with very little effort.

Now with .Net 3.5 I'm not at all sure. Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

Add the optimisations from 3.5 (far better than 1.1) and the way anonymous types, delegates and so on are handled by reflection (they are a nightmare to recompile). Add lambda expressions, compiler 'magic' like Linq-syntax and var, and C#2 functions like yield (which results in new classes with unreadable names). Your decompiled code ends up a long long way from compilable.

A professional team with lots of time could still reverse engineer it back again, but then the same is true of any obfuscated code. What code they got out of that would be unmaintainable and highly likely to be very buggy.

I would recommend key-signing your assemblies (meaning if hackers can recompile one they have to recompile all) but I don't think obfuscation's worth it.

If your looking for a free one you could try DotObfuscator Community Edition that comes with Visual Studio or Eazfuscator.NET.

Since June 29, 2012, Eazfuscator.NET is now commercial. The last free available version is 3.3.

I have been using smartassembly. Basically, you pick a dll and it returns it obfuscated. It seems to work fine and I've had no problems so far. Very, very easy to use.

I have tried almost every obfuscator on the market and SmartAssembly is the best in my opinion.

I've been also using SmartAssembly. I found that Ezrinz .Net Reactor much better for me on .net applications. It obfuscates, support Mono, merges assemblies and it also also has a very nice licensing module to create trial version or link the licence to a particular machine (very easy to implement). Price is also very competitive and when I needed support they where fast. Eziriz

Just to be clear I'm just a custumer who likes the product and not in any way related with the company.

The short answer is that you can't.

There are various tools around that will make it harder for someone to read your code - some of which have been pointed out by other answers.

However, all these do is make it harder to read - they increase the amount of effort required, that is all. Often this is enough to deter casual readers, but someone who is determined to dig into your code will always be able to do so.

We have a multi tier app with an asp.net and winform interface that also supports remoting. I've had no problems with using any obfuscator with the exception of the encrypting type which generates a loader which can be problematic in all sorts of unexpected ways and just not worth it in my opinion. Actually my advice would be more along the lines of "Avoid encrypting loader type obfuscators like the plague". :)

In my experience any obfuscator will work fine with any aspect of .net including asp.net and remoting, you just have to become intimate with the settings and learn how far you can push it in which areas of your code. And take the time to attempt reverse engineering on what you get and see how it works with the various settings.

We used several over the years in our commercial apps and settled on Spices obfuscator from 9rays.net because the price is right, it does the job and they have good support though we really haven't needed the support in years anymore but to be honest I don't think it really matters which obfuscator you use, the issues and learning curve are all the same if you want to have it work properly with remoting and asp.net.

As others have mentioned all you're really doing is the equivalent of a padlock, keeping otherwise honest people out and or making it harder to simply recompile an app.

Licensing is usually the key area for most people and you should definitely be using some kind of digitally signed certificate system for licensing anyway. Your biggest loss will come from casual sharing of licenses if you don't have a smart system in place, the people that break the licensing system were never going to buy in the first place.

It's really easy to take this too far and have a negative impact on your customers and your business, do what is simple and reasonable and then don't worry about it.

For the past two days I've been experimenting with Dotfuscator Community Edition advanced (a free download after registering the basic CE that comes bundled with Visual Studio).

I think the reason more people don't use obfuscation as a default option is that it's a serious hassle compared to the risk. On smaller test projects I could get the obfuscated code running with a lot of effort. Deploying a simple project via ClickOnce was troublesome, but achievable after manually signing the manifests with mage. The only problem was that on error the stack trace came back obfuscated and the CE doesn't have a deobfuscator or clarifier packaged.

I tried to obfuscate a real project which is VSTO based in Excel, with Virtual Earth integration, lots of webservice calls and an IOC container and lot's of reflection. It was impossible.

If obfuscation is really a critical requirement, you should design your application with that in mind from the start, testing the obfuscated builds as you progress. Otherwise, if it's a fairly complex project, you're going to end up with a serious amount of pain.

I've recently tried piping the output of one free obfuscator into the another free obfuscator - namely Dotfuscator CE and the new Babel obfuscator on CodePlex. More details on my blog.

As for serialization, I've moved that code into a different DLL and included that in the project. I reasoned that there weren't any secrets in there that aren't in the XML anyway, so it didn't need obfuscation. If there is any serious code in those classes, using partial classes in the main assembly should cover it.

You should use whatever is cheapest and best known for your platform and call it a day. Obfuscation of high-level languages is a hard problem, because VM opcode streams don't suffer from the two biggest problems native opcode streams do: function/method identification and register aliasing.

What you should know about bytecode reversing is that it is already standard practice for security testers to review straight X86 code and find vulnerabilities in it. In raw X86, you cannot necessarily even find valid functions, let alone track a local variable throughout a function call. In almost no circumstances do native code reversers have access to function and variable names --- unless they're reviewing Microsoft code, for which MSFT helpfully provides that information to the public.

"Dotfuscation" works principally by scrambling function and variable names. It's probably better to do this than publish code with debug-level information, where the Reflector is literally giving up your source code. But anything you do beyond this is likely to get into diminishing returns.

I have had no problems with Smartassembly.

You could use "Dotfuscator Community Edition" - it comes by default in Visual Studio 2008 Professional. You can read about it at:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

The "Professional" version of the product costs money but is better.

Do you really need your code obfuscated? Usually there is very little wrong with your application being decompiled, unless it is used for security purposes. If you are worried about people "stealing" your code, don't be; the vast majority of people looking at your code will be for learning purposes. Anyway, there is no totally effective obfuscation strategy for .NET - someone with enough skill will always be able to decompile/change you application.

I've been obfuscating code in the same application since .Net 1, and it's been a major headache from a maintenance perspective. As you've mentioned, the serialization problem can be avoided, but it's really easy to make a mistake and obfuscate something you didn't want obfuscated. It's easy to break the build, or to change the obfuscation pattern and not be able to open old files. Plus it can be difficult to find out what went wrong and where.

Our choice was Xenocode, and were I to make the choice again today I would prefer to not obfuscate the code, or use Dotfuscator.

Here's a document from Microsoft themselves. Hope that helps..., it's from 2003, but it might still be relevant.

We're using SmartAssembly on our windows client. Works just fine.

Does add some extra problems too. Printing out your class names in log files/exceptions have to be de-obfuscated. And of course can't create a class from its name. So it's a good idea to take a look at your client and see which problems you can get by obfuscating.

It all depends on the programming language, which you use. Read the article: Obfuscated code

the free way would be to use dotfuscator from within visual studio, otherwise youd have to go out and buy an obfuscator like Postbuild (http://www.xenocode.com/Landing/Obfuscation.aspx)

You may also want to look at new code protection technologies such as Metaforic and V.i.Labs and new software copy protection technologies such as ByteShield. Disclosure: I work for ByteShield.

I also use smartassembly. However, I don't know how it works for a web application. However, I'd like to point out that if your app uses shareware type protection, make sure it don't check a license with a boolean return. it's too easy to byte crack. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx