Is .NET code obfuscation really worth it?

Question

From what I've read, code obfuscation isn't really that hard to "crack", and it will only delay the inevitable. In that case, what is it's purpose?

If someone really wants to steal your source they can.

If someone needs to view your source code for harmless/helpful purposes they can't.

You probably shouldn't be storing anything sensitive in the code, so that shouldn't be an issue.

If you don't obfuscate, you're still not providing the full source code, so you could sell a "source code license".

The funny thing is, the only code that I have ever seen obfuscated is terrible code that has bugs in it. The only reason I need to look at the code is to figure out what the problem is and what I can do to fix it.

For example, I need to replace some of the images in ASPDotNetStoreFront. When looking for the location of the tags, I found that they were contained within compiled code. CRAP. So I figured I would decompile the code, to find out which img tags to replace via Regex. I tried to view the source code to see what images could possibly come from the given compiled method, and reflector can't handle it, I presume because of obfuscation. I don't really have time to go looking around for de-comilers/de-obfuscators.

Answer 1

I don't know whether it's 'worth it' to obfuscate, but I can say that there are alternatives to obfuscation that are more secure.

XHEO for example provides a tool (CodeVeil) to actually encrypt .NET assemblies, rather than just obfuscate them.

Answer 2

Only if your project is a long-running and would take someone a great deal of time to implement is it worth it. This is of course an opinion here, but I haven't found an obfuscated .Net DLL yet that I couldn't figure out what's going on using only Reflector.

It's a deterrent, nothing more. If the cost of someone reverse engineering your code is greater than the cost of implementing it themselves, that's the only legitimate case I see for it, but if someone wants to see how your code ticks, it's not very good at preventing that.

One common case I see a lot is how you produce and/or decrypt a license key. Anyone that's motivated to figure this out and dig in reflector for you salt/decryption methods isn't going to be stopped by obfuscation, I'd dare to say it won't really slow them down much either.

Answer 3

In my opinion, no. I've seen guys hacking programs written in different languages. With professional tools like IDA (works for unmanaged code), nothing is 100% secure. Obfuscated assemblies are even easier to hack because of metadata that is still present.

Answer 4

For .Net apps, NOT obfuscating amounts to making your product open source, since its so easy to see and analyze the source code using Reflector. You may have a license agreement, but only a few companies have the time and money to defend the license agreement in court. For such companies, obfuscation is the best option. Sure, you need to test the obfuscated assemblies, but then, you are already testing your product, so why not test the final obfuscated assemblies.

It also depends on how helpful the obfuscator is. Consider our Crypto Obfuscator - it supports easy integration with Visual Studio so you are always running obfuscated assemblies. It also has many automatic exclusions so it will not obfuscate classes/members which will cause obfuscated assembly to run incorrectly. It will also display warnings (including line number) for code which may cause the obfuscated assembly to run incorrectly. This is a huge time saver.

Answer 5

I think its worth it. The cost to you is virtually nothing, and you make the hacker's life much harder. Even if they crack it, you have the satisfaction of knowing you wasted anywhere from several hours to several weeks of their lives. Just because a lock isn't perfect doesn't mean you don't lock your doors.

Answer 6

Of course nothing is 100% protected. But not obfuscating for that reason is like not closing your house door because "any determined thieve can open it anyway". You lock the door anyway!!

I think that the main threat is some dude decompiling your app using ildasm, spotting SQL sentences, tampering with them, and then compiling it again. This way, he/she can eliminate restrictions and get full customer list, as an example, or just make plain harm.

You, as the application provider, will be held responsible in the first place...

BitHelmet's dudes explain it rather well in http://www.bithelmet.com/Overview.html.

I worked in a medium sized credit card company some years ago. There were three thefts (big time money) involving employees that we kwnew of, and all of them were performed not by a russian or chinese world-class hacker, but by kwnow-just-enough-of-programming employees that made just some little twists to the cashiers software.

I was a junior then :), my boss had to deal with it. I always wonder how many of these thefts were never discovered ;-). I could have done it, but never did!

Fact is, you must think in some level of protection, and you must consider in inhouse attacker. And will make life harder to the determined reverse enginner too.