I'm sure many readers on SO have used Lutz Roeder's .NET reflector to decompile their .NET code. I was amazed just how accurately our source code could be recontructed from our compiled assemblies.
I'd be interested in hearing how many of you use obfuscation, and for what sort of products?
I'm sure that this is a much more important issue for, say, a .NET application that you offer for download over the internet as opposed to something that is built bespoke for a particular client.
I think to some extent we should ALL be worrying about our IP :)
Good question though as its something I am keen to know more about (I currently do not obfuscate).
Having had some discussions with my manager at work, he said he doesn't obfuscate, but does NGEN on install, apparantly that should be enough to stop Reflector working on your assemblies, but I have no idea if this is true and to what extent, so please don't take it as gospel :)
Good question :) +1
I wouldn't worry about it too much. I'd rather focus on putting out an awesome product, getting a good user base, and treating your customers right than worry about the minimal percentage of users concerned with stealing your code or looking at the source.
See my answer here to a similar question.
I don't think it's really needed anymore in .Net 3.5
We currently obfuscate all our output, even though we are a small outfit who sells specialist software to a small number of clients.
We made this decision for one simple reason - we discovered a disgruntled ex-employee was actively approaching our clients requesting binaries - there was some some concern he was intending to reverse engineer newer features in order to offer competing functionality.
Of course he is still able to do this if he uses the software, but there is no reason to make it easy for him.
See my answer here to a similar question. I don't think it's really needed anymore in .Net 3.5
Thanks Kieth, good answer to that question (+1). I'll try decompiling some of our 3.5 assemblies, since my experience before was based with .Net 2.0
No new obfuscation, but lots of compiler tricks since 1.1
For instance every time you use an anonymous type you get IL that compiles back with a pretty obscure name. Every time you use yield you get a whole new class that implements both IEnumerable and IEnumerator (clever optimisation, unreadable code). Every time you use an anonymous delegate you get a new method with a name that's invalid in every .Net language that I know of, but that's fine in the IL.
@Rob Cooper
Having had some discussions with my manager at work, he said he doesn't obfuscate, but does NGEN on install, apparantly that should be enough to stop Reflector working on your assemblies, but I have no idea if this is true and to what extent, so please don't take it as gospel :)
This doesn't offer any kind of protection against disassembly. First I imagine its quite possible to extract raw files from any installation package like an MSI or a CAB file.
But more importantly, Ngen runs on the client machine after the assembly has been installed. Ngen just forces the assembly to compile now instead of later using the JIT. The original assembly remains and is unmodified and it must remain because Ngen might not be able to compile the entire assembly.
Ngen is for performance, not security, and does nothing to prevent disassembly or make it even slightly more difficult.
1) Create a kickass app in .NET 2) People steal your code 3) Sue those people 4) ??? 5) PROFIT!2
Remember, obfuscation is not encryption. IMHO, if somebody perceives value in reverse-engineering your code, they will do it. That's true for managed code or native code, obfuscated or not. Sure, obfuscation deters the casual observer, but is your business actually threatened by such people? Every .NET obfuscation method I've seen makes your life as a developer harder.
There are services that offer true encryption, such as SLPS from Microsoft. See http://www.microsoft.com/slps/default.aspx
Obsfucation is limited in it's effectiveness, it might keep the casual guy away. The most effective obsfucation is making only the smallest amount of code available to the user. If you can, make your app run depend heavily on a fat server.
We don't use obfuscation for "non public" applications but we use it for public available applications. The obfuscated app contains plenty of highly sophisticated code which took us an exorbitant amount of time to write and that's the reason that let me think that obfuscation is a must - at least in that case.
Agree, most people who know how to code even a little bit do not need to steal your code!