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.
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.
No comments:
Post a Comment