Yesterday evening, I've delivered a talk on protecting your code. Frequent readers would recognize that the first half of the talk was actually written in depth in the first SLPS post. It's not perfect, but I had fun. But definitely the best I did in English, so far.
So for you who didn't quite caught up with what I was talking (I know, I mumble here and there trying to buy some time :D), I'll explain in depth through this post.
First of all, I'm going to reemphasize my point of view; open source does not work, for business. It might be good for education, community, or charity, but not for business. You're trying to sell something you share, that's just doesn't make sense. This is why, there's an inherent requirement to protect your code.
When we're thinking about protection, we'll think: "It's compiled! They won't/don't/can't have the source code." Wrong.
If you're still on this mind set, then you should visit (or revisit) the first part of this post. There I demonstrate how easy it is to convert any compiled .NET assembly back to it's original source code. This actually made up the first of three parts of the talk. Compiling a small application and decompiling it using Microsoft and third party tools.
The next part is about basic protection. Microsoft have bundled Visual Studio with Dotfuscator Community Edition. It doesn't do much (even though the UI provided so many different features -- disabled), only some simple renaming. I've demonstrated how to use Dotfuscator.
This is the original code, which is 100% reproducible:
And after obfuscation using Dotfuscator Community Edition, it will become, even though it's 100% reproducible, but it's harder to understand:
Several important points on obfuscation:
- The external interface to an obfuscated code will never be modified. This is to ensure that any code that depends on the interface will not break. Of course, this is basic logic.
- Dotfuscator stripped all namespace and rename everything to single letter alphabets (sometimes numbers if it runs out of z's).
- The obfuscation process happens after your code is done. Which means, it doesn't affect development, at all.
- Obfuscation, given enough time and effort, eventually will be broken. It's still reverse engineering, but with added hurdles to slow down progress.
You've seen Dotfuscator in action, now you'll want more. Unfortunately, more means money! You can easily search for obfuscation products using Google Live Search, so finding one is not on the scope of this post. I don't have any product ready, so I just try to open one of the users of obfuscator.
The company is Intersoft, the product is a UI control library. I "volunteered" to crack open their authorization code. Since good product requires good adversaries, therefore I embark upon the journey of the dark.
Here's one piece of the code which I have successfully decompiled:
This is only one part of the code which is the constructor. As you can see the obfuscator actually renamed parts of the code with unidentified characters. It's not easy to distinguish one with another, and in come parts of the code, Reflector crashes when trying to decompile it.
Long story short, I've been able to crack half of it (only the runtime component) in 8 hours. After that I lost interest, since buying it will be cheaper than hacking it.
Several important points on (expensive) obfuscation:
- The external interface is not change. Again, this is basic logic.
- Obfuscation, given enough time and effort, eventually will be broken. But since the hurdles are higher, the economics become: which one is cheaper; to hack or to buy?
- You get what you pay for. Expensive obfuscation will make your code less interesting to hack (except for hardcore hackers out there).
The third part of the talk is actually about Microsoft's product, Software Licensing and Protection Services, or in short SLPS. They have a product web site at root level (which means it's quite important) at www.microsoft.com/slps and if you have MSDN Subscription, you can get a free basic subscription to play with.
The difference between Microsoft and partner offerings is in the way the code protection does. While partners sell obfuscators, Microsoft sells encryptors. So your code is 100% not modified, but encrypted. This encrypted code will then run in a Secure Virtual Machine, or in short SVM. SVM itself runs on top of CLR (so it's still managed code). Moreover, Microsoft also offer activation services for your protected code. So when you pay for protection from Microsoft, they give you the ability to sell your software. Money out, money in.
Details will be in part three.