Protect and Authenticate .NET applications
As most of you know, VistaDB does obfuscate the assemblies we ship. Why? Well, sometimes I ask myself that question. Most of the de-compilers worth their salt can still rip apart the obfuscated DLL. Sure, you lost the variable names, and it replaces them with DefaultClass1 and things like that, but you can still do it. We do it mostly because it actually does shrink the DLL by a bit, and it gives us that warm fuzzy feeling of being safe. Well, more like the illusion of being safe. We don’t license the runtime, we license to the developer. And in the 3.3 release we will be making this clearer by requiring some sort of license key activation on the developer workstation. I have written about this before and gotten some great feedback from you guys (thanks!). But I recently ran across a proposed solution built by Microsoft. It is new with Visual Studio 2008 (add on), but I thought I should give it a look before continuing with our roll-your-own approach. I mean who knows the dangers of licensing more than Microsoft? Microsoft Software Licensing and Protection (SLP) Services 2008 Microsoft is preparing to release a new SDK called the Code Protector SDK. This is a part of a new package called Microsoft Software Licensing and Protection (SLP) Services 2008. The Code Protector is the part that allows you to encrypt and protect .NET assemblies (like the current obfuscator tools), but with a new twist. The protector runs as a secure virtual machine within .NET. So this new obfuscator is much more than just renaming variables. It actually encrypts part of the code in a Virtual Machine. This seem a strange choice to me. Your app will have to startup and hit the JIT – well, first the virtual machine has to JIT and validate your IL code, THEN you get a chance to JIT. Hmm, seems like a bad idea. The startup hit on JIT is already incredibly painful on some machine (PocketPC / Compact Framework). Adding another layer on top of that seems to be asking for trouble. Why won’t they let you precompile to native code at least the Virtual Machine? It would make it a lot harder for a hacker, and it would run a lot faster. Now, what about the rest of the SLP suite? A common need for any application (protected or not) is to license it. And of course Microsoft has figured out a way to do it, and to charge developers a premium for the service. What about the real world costs? Go to the site for the nitty gritty details on pricing, but let’s say for someone like VistaDB. We have around 1,000 paid license activations per year, and another 5,000 or so trial licenses. In order to use the SLPS service we would have to pay either $7,500 per year to use the Microsoft hosted service, or $23,000 + $5,750 (software assurance) to host it internally (not to mention Server hardware and OS costs). WOW! That is about all I can say. What small business can afford those rates? This pricing scheme seems highly targeted at the companies that sell software in the higher end of the market with less activation seats. Maybe a software consulting firm that gives a company 100 licenses for their entire network, something like that. The small office / home office (SOHO) market we cater to cannot afford this for products. I am still unclear after having read all the documentation (I didn’t bother to download it) whether you get the activation style like Microsoft uses (tied to a machine, but with so many hardware keys changeable), or if it is some other activation scheme. What about VistaDB? I think we will have to pass on this Microsoft tool. It just does not make economic sense to me. And I am unclear on the flexibility we would have at the runtime level. I really want our licensing to be a thing that just works, without a lot of hassle or stress on anyone. I don’t personally want to be worried about it all the time, and I want users to know we are not “out to get them” as well. We are just trying to keep honest people honest, and make a living doing what we are passionate about. Hopefully enough people are willing to pay for that to keep us doing this for a long time. LINKS http://www.microsoft.com/SLPS/
Similar Posts
- TSQL Stored Procs and License Enforcement Changes
- devLINK 2007 – post show analysis
- Looking ahead to 2008, and back at 2007
