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