Tech Ed Day 3 Part 2 - .Net Code Protection

Esendex don't currently ship any .Net applications to customers, so protecting the code which is inherently present in .Net assemblies has never been an issue for us. Obfuscating the code that runs on our servers would just be a needless overhead, and a maintenance headache.

But that might (dare I say "will") change in the future, so I thought I'd get a heads up of what is required by attending the .Net Code Protection session today.

A good rule of thumb, we were told, for deciding whether or not you need to obfuscate your assemblies is to ask yourself if you would mind if your source code was published. For open source applications this is a no brainer--there's no need to obfuscate if you're already giving them the source.

But if that same application contains things that could be damaging to you if discovered by an external entity, then you should definitely obfuscate. This includes proprietary intellectual property you don't want competitors accessing, or if access to the source code would highlight something about your IT infrastructure--such as the database schema, or file system.

So how do we obfuscate? Well Visual Studio 2003, 2005 and now (the newly named) 2008 (previously codenamed "Orcas") all ship with a copy of Dotfuscator Community Edition. Apparently if you're a registered user of this edition you can now get an enhanced version that includes a number of new features.

Dotfuscator doesn't need the source code, you just pass it the built assembly and let it do its stuff. But what does it actually do?

It can

• Rename Identities (like variables, method names, type names, etc)
• Remove Metadata
• Mess up the perceived control flow
• Encrypt string literals

The effect that this has is to make it difficult to decompile the code using tools such as Reflector. It won't stop the most determined hacker getting your code, but they will need to dedicate a lot more time to it in order to get it.

Messing up the perceived control flow is probably the most interesting point there. What this does is take how the intermediate code is due to execute, and splits it to look like spaghetti code. It still executes the same, but trying to figure out where everything is going will take much longer.

And that's what obfuscation comes down to. In its basic form all it is doing is making a mess of the assembly in an attempt to make it so difficult to decompile that people won't bother. It can never make your code hacker-proof. It's like installing a visible alarm on your house. You've not made it any harder to break into, but burglars will probably choose a house without an alarm first.

Dotfuscator now comes with ways of embedding information into your code that will detect and react to attempts to tamper with the code. In your code you specify attributes around the places you want to protect. One of these contains a delegate that is called when a tamper check is fired.

In this delegate you can do whatever you want--close the application, notify a web service, disable certain commands. It was even joked that you could format their hard drive.....at least I think it was a joke ;)

Of course, if someone did manage to decompile you code, they could just strip out these tamper sections, but that means they would have had to fully decompile it, which the obfuscation will make difficult.

So a decent session to go to, with plenty of information to chew on for when (or "if" ;)) Esendex decides to ship .Net applications.