Protecting .Net software, and Microsoft SLP Code Protector

I’ve been working on the protection of a .Net application recently. Protection against the application being distributed or used by a third party without paying for it that is. There are a few aspects to this but in this post I’d like to talk about preventing tampering, and the solution I arrived at, Microsoft SLP Code Protector.

Once you have a licensing system in place you need to make it difficult for someone to bypass that licensing system by modifying the IL. If you haven’t heard of Reflexil take a look at it and you’ll see that modifying the IL is fairly trivial. What about strong naming? Strong naming does not prevent tampering as it is easily removed. If you didn’t know that try the tool here to remove strong naming from your application in a couple of minutes (there are many others also). Note that strong naming can also be removed by round tripping the IL using ildasm.exe and ilasm.exe, or cecil. So strong naming does not prevent tampering.

One approach is to use an obfuscator to make it difficult to find the IL that needs to be changed to bypass the license system. However I came to the conclusion that this is not a great approach as it doesn’t seem like it would make it that hard. Licensing systems tend to have to display messages to the user when they fail and that would be a good place to start hunting for the modification. Obfuscators seem better suited to protect the secrets of algorithms or prevent large bodies of code being adopted by other parties via decompilation. However I would like to recommend Eazfuscator, the best free obfuscator I came across while working on this.

Another technique used for example by Salamander Protector (costing $1900) is compiling the IL to native code and then distributing that instead. However you are losing a lot of benefits when you move from a managed application back to native. And it intuitively seems well, a bit hairy, the sort of thing you can imagine causing problems. In addition remember that native apps are cracked. Another technique likely used by some code protection products is runtime code injection. There are a couple of articles about this here and here, including techniques that can be used to defeat it. These articles are pretty interesting, a tour de force of .Net innards!

In the process of finding a decent solution poking around the reversing (not necessarily cracking!) communities at http://www.reteam.org and http://www.woodmann.com/forum/ was invaluable in getting an idea of what I was up against. There are recommendations on which protection products are best although most have claims that they have been broken. I found no such claims about the Microsoft Code Protector (although this could be because the Microsoft lawyers are a more ‘tenacious’ than the rest!).

So Microsoft Code Protector, formerly the product SecureLM from Secured Dimensions, part of their SLP product. The approach used is to remove selected method implementations from MSIL into a ‘Secure Virtual Machine Language’ that is executed on a ‘Secure Virtual Machine’ outside of the CLR.
If you look in reflector you’ll see that the body of any protected methods has been removed and replaced with something like that shown here:

private OleDbConnection GetDBConnection()
    object[] args = new object[0];
    object obj2 =
        SLMRuntime.ExecMethod(
            null, "DS9FvZGluZyAvV2luQW5zaUVuY29kaW5A0vQmXZ“, args);
    return (OLEDBConnection) obj2;
}

Every SLP customer is given a unique of the SVM and SVML reducing the chance of a global crack. There is a white paper (pdf). There isn’t too much information to be found about the details of the security, however in theory it sounds stronger than the other approaches I came across, browsing the reversing communities loosely supports this, and also it is from Microsoft themselves which in this case seems a good thing.

Code Protector is one part of Microsoft SLP which includes everything you need to license an application including hosted management and distribution of licenses (msdn, forum, blog, home page). However I was interested in only the Code Protector component, providing protection against tampering as it does. I wasn’t ready to surrender the licensing aspect of the product to Microsoft SLP as I wanted control over licensing and aspects such as hardware locking, needed something that would work on a machine without internet access, and was sceptical it would be as trouble free and easy to use as my custom solution which required only a subset of the SLP behaviour.

Code Protector is freely downloadable to try out. To get a unique permutation that is valid for redistribution and that can be used to protect an unlimited number of methods you must subscribe to the standard service at $10 per month through a Microsoft reseller (GreyMatter sell it in the UK). There are no further costs for using the Code Protector. According to forum posts if you can cancel this subscription you will still be able to use the Code Protector. Up until a few months ago it cost around $5000 dollars to get access to it, so it is possible we will see it become more widely known about and used in the future.

I’ll talk more about the nitty gritty of using Code Protector and integrating it with the application next time.