Geeks With Blogs
.NET Corner Jeans, .NET and Physics (eka The Quantum Boy)

Honestly, I'm a frequent user of infamous .NET decompiler - Reflector ( Hacking vanilla .NET assemblies are insanely easy with this tool. Now that I'm writing my own .NET based product (which will be launched soon and I'm pretty much sure that it will be immensely popular in Indian music lovers. I will write a fresh post while launching the tool) my attention is turned into the protection of my own assemblies. After researching a bit I came to conclusion that .NET code protection strategies broadly can be divided into these categories.

A. Traditional obfuscators - symbol renaming, control flow obfuscation are generally falls into this category. Visual Studio comes with a community edition of .NET Obfuscator or DotFuscator. But it is not impressive. 9rays, RemoteSoft, Xenocode are some known names in the word of .NET obfuscators.

B. Secure IL Stream - Basic strategy is to impose a secure envelope around the .NET assembly to be protected. Another component (which needs to be deployed to the client spaces) attaches itself to the execution engine (EE) of CLR and decodes the secured IL just before handing over to the JIT compiler. This decoding is extremely specific and on-demand based. Effectively, at a time only a few functions' IL remains decoded into the memory. Details can be found at

C. This is perhaps the most rigorous endeavor to protect .NET assemblies till date. Basic idea is to get some user information (username or user ID or user's Hardware ID - HID or license file) and use this to encrypt/compress the assembly which needs to be secured (often prior to this, there is a Assembly Packing stage where all non-system referenced assemblies of the main executable are packed into a master assembly with suitable entrypoint). Then the binary image is added to a Win32 stub as a Win32 resource. This stub usually has a specific entrypoint which upon loading extracts the special resource (binary image added earlier on the fly) , asks for the user information (username or user ID or user's Hardware ID - HID or license file) , uses this to decrypt/decompress the extracted resource, hosts the CLR (there could be a policy about the loading of the CLR) , create a secure appdomain , loads the decrypted assembly image into the appdomain and starts executing its entrypoint (which is normally the Main method). Symmetric encryption technique is enforced here. The purpose of this entire process is to build up a native-code wall around the .NET assembly to be protected. Naturally Reflector fails badly. To get an example of this technique visit - Now I was pretty impressed by this tool called .NET Reactor. But like any other shareware it is not free and to be true - expensive. I decided it would be a good idea to jump into my new project  - .NETCodeProtector - modeled around this strategy. I'm on the way to finish it and I promise I will publish it into the SourceForge along with a relevant post here. Anyway I like to share the solution structure of the project -

1. ClrHostStub : It is the Win32 Stub with CLR hosting code embedded into it.
2. AssemblyPacker: Optionally packs multiple non-system referenced assemblies into a master assembly with suitable entrypoint.
3. PackToStub: This component is used to add the assembly (or packed assembly) into the Win32 stub as a Win32 resource.

Apart from discussing various .NET code protection strategies, this post also shows how I used to pick up my next project. Well, see you soon. Happy programming.

Debasish Bose

Posted on Friday, November 7, 2008 9:56 AM .NET Core | Back to top

Comments on this post: .NET Code Protectors, Obfuscators And more

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © dbose | Powered by: