This documentation is archived and is not being maintained.

Code Protection Best Practices

Microsoft Software Licensing and Protection (SLP) Code Protector provides ability to specify exactly what code to transform. This permits the developer to accomplish two things: balance the security of protected code against the performance of the application, and to reduce overhead in ways that no other code protection mechanism allows. 


Protecting Critical Intellectual Property 

When selecting code to protect, choose those classes and methods that have a high intellectual property component, or that are particularly vulnerable to hacking or reverse-engineering. These include the following:

  • Staging or initialization methods that permit access to functionality you want to control.
  • Methods that enforce licensing.
  • Code that implements algorithms which are unique to the product.
  • Code that contains information about the infrastructure of the enterprise: database connections, passwords, etc.

However, how you apply protection is as important as the content that needs the protection. As with any advanced technology, SLP Code Protector has advantages in performance depending on the level at which code protection is applied. In some cases, the level at which protection is applied can significantly lower the performance of an application. 


Managing Performance 

There are certain code protection scenarios where the performance of a protected application is slower than the unprotected versions. This is usually the result of applying protection to methods containing iterations of complex calculations. For example, executing a math operation on every pixel of a bitmap graphic as part of an image processing application would negatively affect performance. 

To work around this limitation, we recommend applying protection to methods that are not computationally intensive. In cases where you want to control access to a computationally intensive method, you can protect “gateway” methods — that is you protect the non-computationally intensive methods that call the computationally intensive methods. Consider a scenario where you are applying protection to an image processing application. You have implemented an algorithm that sharpens the image to enhance the clarity of captured images. To access this feature, users click Sharpen from a menu. The method that performs the work contains the iterated complex math. However, if you apply protection to the menu item, Sharpen, you can control the use of the feature without having to protect the computationally intense sharpen method. 


Debugging Protected Assemblies 

The Secure Virtual Machine (SVM) protection process does not provide reversing tools, however, you can use the following guidelines to simplify the analysis of unexpected errors that occur within protected methods.

  • Do not use method cloaking. Method cloaking can obscure the call stack at the error point. This is good to impede hacking, but makes life very difficult when analyzing the source of an error. This feature is turned off by default.
  • When throwing exceptions or logging errors (during development of the unprotected code) insert a unique error identifier for each location in the code (e.g. a GUID). This will leave the code obscure, but will allow the developer to pinpoint the line that generated the error based solely on this identifier.


Unsupported Method Constructs 

SLP Code Protector does not support the transformation methods with the following constructs.

  • Methods within generic classes.
  • Methods containing explicit instantiation of generic types.
  • Methods with generic parameters.
  • Non-static methods of a structure.
  • Methods with out or ref parameters.
  • Methods that invoke other methods with out or ref parameters.
  • Methods that modify any method parameter, even if the parameter is defined as a by value parameter.
  • Methods with a variable number of parameters (for example, the params keyword in C#).
  • Methods with too many local variables or parameters (> 254).
  • Methods that contain calls to Reflection.Assembly.GetExecutingAssembly method, Reflection.MethodInfo.GetCurrentMethod method, or Reflection.Assembly.GetCallingAssembly method.
  • For the Microsoft Common Language Runtime (CLR) 1.1 only: methods that create objects by using constructors with a variable number of parameters. This restriction does not exist when a non-constructor method is invoked.
  • Implicit and explicit cast operators cannot be transformed to the Secure Virtual Machine (SVM).
  • Unsafe code – For example, in C#, methods that contain the keyword unsafe cannot usually be transformed.

If you attempt to perform an SVM transformation on a method that violates one of the unsupported constructs in this section, SLP Code Protector will issue a warning.

What do you think about this topic? Send feedback!