Code protection is often the last thing to be considered, only after the software has been written and tested just before it is ready for distribution. CodeVeil is very good at determining most requirements of a project and is usually safe to run with the defaults, but when problems do come up they can be difficult to diagnose. By carefully planning your project ahead of time you can avoid these issues. This guide will help you plan how to setup your project - even if you have already completed your development.
Obfuscation is the process of renaming meta-data in an Assembly so that it is no longer useful to a hacker but remains usable to the machine for executing the intended operations. See the What is Obfuscation topic for a more detailed discussion.
There are a few cases where you need to be careful about the use of obfuscation.
When an assembly makes calls to classes in another assembly the .NET runtime uses the names of the classes stored in both assemblies to find and locate the intended target. When public members of the target assembly are obfuscated the target type and member no longer use the same name and thus cannot be found.
As long as you add both assemblies to the same project, any references between the assemblies will be updated to use the new obfuscated names.
When passing the full name of a type in code, do not use a literal string. Instead use the type discovery intrinsic's in your language to discover the actual name of the type at runtime.
Dim typeName As String = GetType(ObfuscatedType).FullName
string typeName = typeof( ObfuscatedType ).FullName;
Many 3rd party controls, such as grid controls, will use Reflection to discover the types and properties of an object to determine how to render it. When you pass obfuscated types to these controls it can cause unexpected results. You will need to exclude these types from obfuscation.
The .NET framework provides a robust system for communicating data and instructions between processes. This serialization framework reflects over objects in a request and writes the data to the underlying storage or network.
If you save serialized data to a database then attempt to read the data back at a later time, you must ensure that the names of the type and members are exactly the same as when they were serialized. There are three options to resolve this issue.
By default, when CodeVeil discovers a type marked as serializable it will not obfuscate the public properties even if the class itself is private unless the type also implements ISerializable.
When calling XML Web Services, the .NET Framework will use the names of the method and its parameters when serializing the request. Because of this you cannot obfuscate any class that inherits from WebService or any proxy class that handles calls to the remote service. These proxy classes are generated automatically when you add a Web Reference. CodeVeil will usually recognize these classes and automatically exclude them from obfuscation.
Using Code Encryption is one of the easiest things you can do to significantly increase the security of your assemblies. It does not change the runtime behavior expected by the .NET runtime and is really a set-and-forget type feature. However, encryption does add additional system requirements
In most cases this is not an issue, but there are two specific limitations of the encryption system that must be addressed. First, the assembly must be granted full trust on the target machine. Secondly, 64-bit native applications are not supported.
During the encryption process CodeVeil will add a native 32-bit Runtime Executive to manage the decryption and runtime protection of your assembly. Because this is native code, the .NET Runtime cannot guarantee its safety to the end user and thus requires that the assembly be trusted. For standard Windows Applications and Services this is not an issue - they are granted Full Trust by default. The only time this becomes an issue is when you deploy veiled applications to untrusted targets such as shared ASP.NET hosting environments set to Medium Trust, a network share or ClickOnce deployment. To work in these environments you must explicitly grant Full Trust to your assembly.
The term Trust in .NET does not have any relationship to permissions granted to a specific user. For example, running the program as an Administrator does not have any effect on the Trust of an assembly. Trust is a system wide setting.
Because the Runtime Executive is 32-bit code it cannot execute in a 64-bit process. 64-bit operating systems are fully supported but the application must target the 32-bit subsystem. If you are veiling the host application (EXE) then no further attention is required; CodeVeil will automatically re-target the 32-bit subsystem. If you don't veil the application, you will need to change the main EXE to target the 32-bit subsystem.
64-bit operating systems are fully supported. The applications cannot use encryption.
Veiling should be a regular part of your build and testing process. CodeVeil comes with tools to easily integrate into automated build tools to make the deployment process much easier.
CodeVeil has a command line tool and MSBuild tasks to allow you to integrate the veiling process directly in your distribution build process.
Finding bugs introduced by the veiling process can be tricky. The easiest way to find them is to veil the assemblies that you actually test with. This will reveal any issues quickly and usually help isolate the problem area since you can review only the most recent changes. Be sure to review the Preparing for Obfuscation section in this topic and the Troubleshooting Obfuscation Problems topic.