Because .NET assemblies consist of a standardized, platform-independent set of instruction codes and metadata that describes the types contained in the assembly, they are relatively easy to decompile. This allows decompilers to generate source code that is very close to your original code with ease, which can be problematic if your code contains proprietary information or algorithms that you want to keep secret.
The only way to ensure people can't decompile your assemblies is to stop people from getting your assemblies in the first place. Where possible, implement server-based solutions such as Microsoft ASP.NET applications and XML Web services. With the security correctly configured on your server, nobody will be able to access your assemblies and therefore won't be able to decompile them.
Where building a server solution is not appropriate, you have the following two options:
-
Use an obfuscator to make it difficult to decompile your code. (Visual Studio .NET 2003 includes the Community Edition of an obfuscator named Dotfuscator.) Obfuscators use a variety of techniques to make your assembly difficult to decompile; principal among these techniques are
-
Renaming of private methods and fields in such a way that it's difficult to read and understand the purpose of your code.
-
Inserting control flow statements to make the logic of your application difficult to follow.
-
-
Build the parts of your application that you want to keep secret in native DLLs or COM objects, and then call them from your managed application using P/Invoke or COM interop.
Neither approach will stop a skilled and determined person from reverse engineering your code, but they will make the job significantly more difficult and deter most casual observers.
The risks of application decompilation aren't specific to C# or .NET. A determined person can reverse engineer any software if he has the time and the skill.
No comments:
Post a Comment