With Babel Obfuscator Enterprise you can easily encrypt the code inside a method so that it will be hidden to decompilers like .NET Reflector or ILSpy. The encrypted methods will be decrypted and compiled at runtime on first call. 

To encrypt a method, you can just add the ObfuscatioAttribute to that method:

[Obfuscation(Feature = "msil encryption", Exclude = false)]
public void DoSomething()

Or create Ad Hoc XML rule like the following one:

<Rule name="encrypt1" feature="msil encryption" exclude="false">
   <Target>Methods</Target>
   <Pattern isRegEx="true">
      LicensedApp.Features::Feature1.*
   </Pattern>
   <Properties>
      <Cache>true</Cache>
   </Properties>
   <Description>Encrypt Feature1 method</Description>
</Rule>

Because to build our licensing system, we need some advanced properties of XML rules that are not available with custom attributes, we’ll use XML rules for this tutorial.

The above XML rule will makes Babel to encrypt the method Feature1 declared inside the LicensedApp.Features class. The regular expression match all (.*) at the end of the method name, is used to match the method parameters. Note that because we used .* after the name Feature1, all the overloaded methods of Feature1 will be also encrypted.

So far so good, but how can we use MSIL Encryption to make a license file. Well, actually we can use a couple of advanced features related to MSIL encryption.

Babel can store the encrypted method MSIL code into an external file instead of the obfuscated assembly. Doing so Babel will remove all the encrypted code from the obfuscated assembly making the code not available to anyone .NET Framework included. This means that our obfuscated assembly cannot work properly without the external file containing our encrypted method code, or at least it will crash when the encrypted method Feature1 will be called. To successfully run the Feature1 method the obfuscated assembly must know where the encrypted code is, and Babel can plug this extra bit inside our assembly.

This makes easy to use Babel MSIL Encryption to create a license file where each feature is represented by the encrypted code that Babel can extract from our obfuscated assembly. The assembly extracted code can be stored into a license file or for example into an USB stick. When the obfuscated assembly is executed, it can load the encrypted code from the license file or from our super-secured USB stick.

Let’s start modify the above XML rule so that Babel can save the encrypted code into a file. To do that just adds to the Properties rule element the Source element:

<Rule name="encrypt1" feature="msil encryption" exclude="false">
   <Target>Methods</Target>
   <Pattern isRegEx="true">
      LicensedApp.Features::Feature1.*
   </Pattern>
   <Properties>
      <Cache>true</Cache>
      <Source>feature1</Source>
   </Properties>
   <Description>Encrypt Feature1 method</Description>
</Rule>

The Source property makes Babel to create the file feature1.eil during the obfuscation process. This file contains all the encrypted code of the method Feature1.

Now we need to instruct our assembly, where to find the file feature1.eil when the method Feature1 will get called at runtime. To do that we must declare inside our assembly one method that given the name of the feature returns the encrypted file stream:

[Obfuscation(Feature="msil encryption get stream")]
internal static Stream GetSourceStream(string source)
{
   return File.OpenRead(source + ".eil");
}

Just to make this tutorial easy we made the GetSourceStream method very simple. The source parameter contains the name of the feature we used in the XML Source element. The method opens the “source”.eil file and returns its System.IO.Stream object. We added the Obfuscation attribute to let Babel know that this method has to be called at runtime in order to get the MSIL encrypted method data for a given source.

Finally remeber to enable MSIL encryption at Babel command line entering the following switch:

--msilencryption

That’s all, we have our license file made by the encrypted method code inside the feature1.eil file and our assembly is now able to find the encrypted file when the method Feature1 it get called. It is easy to extend these concepts in order to make a more complex license file, for instance an XML license file able to accommodate more than one feature. Because the license contains the encrypted code, the application cannot be cracked without the license file itself. In this scenario, the developer can deploy the application with a reduced set of capabilities that can run without a license file and other features that need the license file to be executed properly.

Back to List