Another method of protecting your code

I ran across Debasish Bose's post on code protection tools.
He covered some of the protection methods I discussed in my previous post on the subject, and was very excited by .NET Reactor. However, as I wrote in my post, this tool is easily circumvented by patching into the framework and dumping the assembly once it's decrypted in memory.

The most interesting part for me deals with Secureteam's tool, used to encrypt the .Net code, and only decrypt specific sections in memory at any specific point in time, blocking the ability to dump the entire assembly:
"CliSecure protects the IL code stored in your assemblies. During execution the code is handed to the jitter in its decrypted form just before compilation occurs. The CliSecure execution engine assures that your assembly is never fully decrypted in-memory. This makes it impossible to reconstruct your original assembly by using memory dump tools."

Protecting your managed code

Since .Net is a managed environment, there is always the downside of having your code open to anyone using reflector.
Currently there are several methods to deal with the problem:

1) Obfuscation - "Obfuscated code is source code that is (perhaps intentionally) very hard to read and understand".
Obfuscators renames members to something like A.a.B.c(). This makes the code harder to read, but the protection is still very limited.
Some of the obfuscators include a feature called "string encryption", meaning all strings (which are constants in .Net) are encrypted on disk, with a decrypt function being called before a string is used. This makes a hacker's life easier, since all he/she need to do is search the line just before using the string to find the decryption method. It may also affect performance.
In addition, some of the obfuscators include code meant to crash disassembles, but again, this is easily avoided. (Try using this link to check this: http://dotnetprotector.pvlog.com/ildasm.aspx)

2) Encryption - Merging the .Net executable with Win32 code to make it unreadable for reflector-like tools.
The problem with this approach is the code need to be converted to it's origin just before having the framework run it, and at this point it's possible to intercept the original, unencrypted code. (http://www.remotesoft.com/deprotector/index.html)
Aladdin has recently release a version of their .Net protector with the ability to detect this and stop this method, but it's only a matter of time before another work-around is found (their product also require the purchase of a dongle).

3) Another method, used by Remotesoft's Salamander, converts the decompilable Microsoft Intermediate Language code (MSIL or CIL) of your assemblies into native format while keeping all .NET metadata intact, claiming to provide "the same level of protection as native C/C++ code".

4) Using a one-way conversion to a custom language - this way some of the code is converted into another form and executed inside a 'virtual machine', isolated from the .Net framework, and the code may even run inside a dongle (http://www.securelm.net/).
The major downside of this approach is the need to modify manually your code to use the benefits of the protection system, instead of taking a compiled PE and transfer it through a 3rd party application.

* No matter which method you choose, you should merge your assemblies into one before protecting them, using the free ILMerge utility from Microsoft.