The names of all the variables and methods, as well as the values of all constants, are visible to anyone with a disassembler. Anyone who has the .NET Framework has access to a disassembler (ILDASM.EXE). There is something that you can do to defend your code from prying eyes: obfuscation.
Obfuscation
refers to performing a series of operations that disguises the true meaning,
purpose, and logic of your application's code. This is done by changing your
variable and method names to a series of unintelligible alphanumeric
characters. After obfuscation, reverse-engineering MSIL code that might
ordinarily be easily reversible quickly becomes a colossal task that would take
so long that most people would be discouraged from attempting it.
Don't
let this fool you: Anyone who wants to reverse-engineer your code badly enough
will either do it or find the resources to get it done. As a result, you need
to write your code defensively. If you really do have a trade secret embedded
in your code, don't put it in the same place, scatter it around, and make sure
that the obfuscated MSIL doesn't make it obvious what your code is doing.
Everyone with the determination and resources will be able to reverse-engineer any code that they have on their hard drive. There are products that can generate C# from MSIL code even if it has been obfuscated. In such a format, it would take only minutes for an intruder to search for what he needs to find out all the information he wants.
Obfuscators
work by transforming a .NET assembly into an equivalent .NET assembly that is
more difficult to understand when disassembled or decompiled. Some obfuscators
use ILDASM to disassmble the assembly and operate on the disassembled MSIL, and
then use ILASM to reassemble the result. Others operate directly on the
assembly without any ILDASM/ILASM round trip. Obfuscators apply a variety of
different techniques to make the disassembled source code more difficult to
understand.
Compilers
work by removing the bulk of the MSIL code from a .NET assembly, replacing it
with compiled native code targeted at a particular platform and a MSIL stub to
call the native code. This prevents decompilation by removing the MSIL and the
metadata on which a decompiler operates. Using a compiler ties your assembly to
a particular CPU architecture, removing the potential cross-platform nature of
.NET. This may become an important consideration as Microsoft releases. Using a
compiler also means that you lose some of the benefits of managed code, such as
the Common Language Runtime's safe code execution environment.
Ordinarily,
a .NET assembly depends on code from a variety of assemblies that are shipped
by Microsoft. These assemblies, known collectively as the .NET Framework, make
up the basic functionality of .NET. These assemblies include things like
Windows Forms, file processing functions, networking code, and so on. A linker
can pull just the parts of the .NET Framework that your application uses into
your application's own assembly, and in so doing, lets you obfuscate those
parts of the Framework as well as your own code. This can make it more
difficult for others to determine what your code is doing. However, it is
possible that the use of a linker in this way violates the Microsoft license
terms for the .NET Framework.
Encrypting
launchers employ a two-step strategy for protecting source code. First, they
encrypt your assembly and its resources. Second, they wrap the encrypted
assembly in an executable application. At runtime, this application decrypts
your assembly directly to memory, where it is then executed normally by the
.NET Common Language Runtime. With this strategy, the code on your hard drive
is no longer native .NET code and thus cannot be deciphered with the usual
tools for exploring .NET assemblies.
dotNet
Protector 5 protège Applications et composants grâce à une technologie inovante
de maquillage de bodies. Les assemblies ne sont plus transformés en application
native, mais restent des assemblies .Net. dotNet Protector 5 protège votre code
code grâce à un obfuscateur associé à un maquilleur de méthodes.
Les
assemblies sont obfusqués, et le corps des méthodes est remplacé par du code
corrompu; Les outils de décompilation ou désassemblage comme ILDASM ne pourront
pas désassembler ou décompiler les méthodes. dotNet Protector 5 prend en charge
la protection des composants et ASP.Net.
La runtime dotNet Protector 5 (5 dlls) doit être déployée avec les assemblies protégés. Il suffit de copier ces dlls dans le répertoire d'exécution. L'inscription de PvLogiciels.dotNetProtector.Runtime.dll dans le GAC est aussi possible.
dotNet Protector 5
This section intriduces protection methods dotNet Protector implements and helps choosing a project type regarding assembly to protect.