Search This Blog


Saturday, August 7, 2010


One of the benefits ( or drawbacks) of .NET application is that the code can be easily decompiled by tools such as Reflector. This feature is tremendously useful if you have a third party application whose methods are  behaving bizarrely and you want to know what’s under the hood so that you can work around it. It is also comes in handy when you are trying to understand the algorithms offered by .Net framework ( such as LINQ’s Sort()) so that you can decide whether to use the existing one or writing your own.

However, for those who are in the line of selling software ( as opposed to, say open sourcing the software and then selling the service), the danger of having the whole application decompiled and resold by the competitors is just too great to ignore. Which is why .NET developers will have to obfuscate and encrypt their code before they package it for sale.

CliSecure .NET Obfuscator is a .NET code protection and licensing solution that I have been using for past one year. To date, we are very satisfied with the product and the service. Here are a list of the features that we really love
1.    .NET 4.0 support. We are in the process of migrating to .NET 4.0. The most important .NET 4.0 feature for us is PLINQ. For computationally intensive application, parallelism is the way to go as Moore’s Law is going to hit the wall. Instead of counting on the processor clock cycle to double up every 18 months, it is far more realistic to distribute computational loads to different cores to solve your speed issue. Which is why .NET 4.0 support is crucial for us in this matter. With CliSecure 5.2, we know that by the time we have transit to 4.0, we can release it straight to the customers without worrying about whether the protection tool is up to the task or not.
2.    Support various .Net Applications. The  .NET ecosystem is vast; Windows Form, ASP.NET, Silverlight, WPF, WCF, Windows Phone 7 etc. Different types of application development caters to different groups of needs, but they share the same CLR and framework. It is not unlikely that your application has to run on desktops, browsers and windows smartphones at the same time. The good thing about CliSecure is that it can handle all the nuances of the types, so that you don’t have to use different protection tools for different types of applications. One caveat though, some of the nonstandard .NET applications ( such as assemblies compiled by Matlab .NET builder and Silverfrost the fortran.Net compiler) may not be supported due to the nonstandard nature of those compiled assemblies. But in those cases, one can readily work around the limitation by editing the assemblies by hand. For me, this is not really a problem, as we seldom compile those nonstandard .NET code.
3.    Method Call Obfuscation. A lot of the protection tools keep the name of external calling method intact, because the names are needed in order to resolve the dependencies between different methods across different assemblies at runtime. This could create a security risk as hackers can determine what are the external calls your assemblies make and guess the content of your code. However, CliSecure solves this problem by replacing external calls with internal delegates so that the real, external calls are hidden from Reflector tools. With method call obfuscation, there is no problem in protecting the dynamic type objects, introduced in C# 4.0. So all your dynamic language fanatics! You can now have the privilege to write duck typing code that is previously restricted to dynamic type languages. But don’t blame anyone else if you introduce silly bugs that could have been caught by C# compilers. Greater flexibility comes with greater risks, I’m warning you. 
4.    64 bit support. Our application is a heavy number crunching engineering application. It uses up memory a lot. So 64 bit machine is the only hope for large projects. We were using other protection tools before stumbling upon CliSecure. Amazingly at that time ( about a year ago) there was not a single .NET obfuscator tool that protected a pure 64 bit application. When contacted on how to solve this problem, those tool providers advised us to compile our application as 32 bit app and run as 32 bit app on 64 bit OS. But this is completely impractical, as the very reason why we need 64 bit OS is because we need bigger memory.  I communicated this need to CliSecure and they got it done in one month. This was the deal breaker for us to use CliSecure.
5.    Stack Trace Translation. It’s often that when you are debugging a assembly which calls a protected assembly, you will get a gibberish stack trace when the crash happens. With the obfuscation, the real stack trace is also obfuscated and thus make debugging hard. However, with CliSecure 5.2, the stack trace is nicely preserved so that the developers won’t have to scratch his head and guess what’s going on wrong in the protected assembly. This would save us tremendous amount of time.
6.    Encryption, not just obfuscation. There is a difference between encryption and obfuscation. With obfuscation, Reflector can still see your method body and logic, with all the variables renamed, logic reshuffled ( not to the point of destroying the original code flow, of course). The weakness is that with enough determination, the hacker can still de-obfuscate the code and understand what is going on in your application. Encryption, on the other hand, completely hides the method body from hackers so there is no way of guessing what the code does beyond what is revealed from the method name.
7.    Compatible with reflection. One of the things I love about .NET is its rich meta data and the ability to use reflection to manipulate it. You can use reflection to dynamically infer an object’s type, create an instance of a type, access an object’s available methods, fields and properties. This is extremely useful when you are trying to  bind and display data in a declarative fashion. Unfortunately, obfuscation tools have the nasty habit of obfuscating private variables’ name, and make them inaccessible reflection, thus defeating the purpose of .NET rich metadata concept. CliSecure, on the other hand, doesn’t have problems with reflection. You can write the code in the way you want to without worrying about how the protection tool would work on it.
8.    Technical Support. The standard mantra of technical support in software world is “we’ll get back to you in 24 hours time”. But not everyone follows this. When we were researching for a .Net protection tool, there was one provider who got back to us only one week later, and his response was “sorry we can’t do this now, but we’ll keep you posted” and we never heard from him since. Providing good technical support is very important as we, the end users have our business to do; we can’t wait too long for our vendors to fix their problems or else our business would be affected. Provide timely and helpful technical support is sometimes more important than features. And for this reason I would normally eschew large software company with resellers and prefer the ones that are small and nimble enough to answer my question quickly. CliSecure .NET Obfuscator has never failed to resolve my queries in a timely manner. When I encountered bugs in their software, they would usually give me an update that fixed the problem within a reasonable time frame. The technical support should always factor into the consideration when purchasing a component.


.net Obfuscators said...

Great reading this is quite interesting and a must read for any coder who wants to protect his code against hackers.

Anonymous said...

Great post. Can’t wait to read the next ones :)

Eternity Bands said...

Every software needs to be user friendly and proper support to users must be available there. I think this is the best thing about .NET

used dell desktops said...

used dell desktops said...

CliSecure .NET code protection module secures the IL code stored in .NET assemblies. By implementing a unique code protection technology it blocks attackers from recovering the original source code. CliSecure binds to the .NET runtime engine and prevents access to the IL code even when it's stored in memory. The CliSecure execution engine assures that at most a single method will reside in memory in its decrypted form at any given time.

Opensource Development said...

Your post was interesting. You provided me valuable information to protect my code.Thanks

GR Brains said...

Thank you for sharing this post about the best techniques for Symfony Development, This is very useful for Symfony Development and Symfony Development Company. Thanks again :) Symfony Development

LogicNP said...

Have you looked at Crypto Obfuscator? It too has all of these features and also some protections not seen in other products like Code Pattern Masking, constant encryption, etc.