Should I be worried about obfuscating my .NET code? [closed]

Answer 1

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.

Answer 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

Answer 3

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.

Answer 4

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