.NET obfuscation tools/strategy [closed]

Question

My product has several components: ASP.NET, Windows Forms App and Windows Service. 95% or so of the code is written in VB.NET.

For Intellectual Property reasons, I need to obfuscate the code, and until now I have been using a version of dotfuscator which is now over 5 years old. I'm thinking it is time to move to a new generation tool. What I'm looking for is a list of requirements which I should consider when searching for a new obfuscator.

What I know I should look for so far:

• Serialization/De-serialization. In my current solution, I simply tell the tool not to obfuscate any class data members because the pain of not being able to load data which was previously serialized is simply too big.
• Integration with Build Process
• Working with ASP.NET. In the past, I have found this problematic due to changing .dll names (you often have one per page) - which not all tools handle well.

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.