How
to prevent a particular .NET DLL from being decompiled?
Using satellite
assemblies and other similar options, you convert your source code into
DLL and deploy it. You convert your program into DLL files because they
don’t include any source code thereby ensuring security of your code.
However you have provisions to decompile your DLL back to your source
code. For performing such DLL decompilation, many third party products
like Reflector are available. Even Microsoft provides a tool to perform
such DLL decompilation. That tool is termed as ILDASM. But performing
such decompilation and getting hold of the code is very dangerous in terms
of security when the decompilation is performed by some one who is not
part of your team. Hence it is always recommended to prevent your DLL
from being decompiled. This is achieved using Obfuscation.
Microsoft
provides a solution called Dotfuscator Community editor to perform obfuscation.
This solution is available as part of Visual Studio .NET. Several other
third party solutions are also available to accomplish obfuscation. Few
of them are: Demeanor and Xenocode.
Advantages
of Obfuscation:
• Protecting sensitive information of the code like licensing implementations,
trade secrets if any
• If you have done hard coding of your database login credentials
then you can perform encryption with the help of obfuscation, thereby
ensuring that your login credentials are not shown to other users even
when the DLL is decompiled
• When some one opens the obfuscated code that some one should not
understand or get any clued about your code. For that, obfuscation even
renames your identifiers. When doing so, identifiers with long names will
be converted into identifiers of length one character. This will obviously
reduce the program size
Drawbacks
of Obfuscation:
• Obfuscation alone cannot prevent malicious user from fetching the
code back. You cannot judge what level of security that obfuscation provides.
Moreover such malicious users can use powerful debuggers and decompilers
to perform reverse engineering of obfuscated code and get the original
source code out of it. Hence it is always recommended to use additional
encryption mechanisms or security measures along with obfuscation to ensure
security of your code
• When you deploy obfuscated code, it is hard to debug it. This is
because obfuscated code will contain different variable names and unreadable
code which on debugging will not make sense to the programmer. Hence you
might be forced to maintain two different builds, one containing the actual
source code and the other containing the obfuscated code. You should maintain
both the codes in sink.
• You might perform obfuscation on code or obfuscation on intermediate
languages. If you perform code obfuscation, it is platform specific and
compiler specific. Using that particular obfuscated code on a different
platform or compiling it with different compiler will lead to error. This
forces a restriction that you should not change the platform and compiler
of your application. This restriction is not posted on obfuscation performed
on intermediate languages.
• Few obfuscation solutions do not support reflection API’s
and create conflicts if they are used in the source code.
