Protecting Your Intellectual Property

So far this chapter has been about how you can sell and license your application, make sure that the developers building with your controls have purchased them, and that the licenses are valid when the control runs.

Another aspect related to licensing and verifying the authenticity of the users of your application is the concept of protecting your intellectual property. Every .NET programmer knows that any managed code can be disassembled and examined. All managed code is expressed as MSIL. Therefore, any plain text information stored in your application is as visible as if it had been left in plain sight, as are most of your business logic, data access logic, and any other tasks that your code performs. The following sections provide a few ideas and concepts for coding your applications in such a way that you can protect your intellectual property.

Protecting Intellectual Property by Hiding Your Licensing Algorithm

As already mentioned, your code is basically an open book. If you are using an algorithm to determine whether the user is licensed to use your application and that algorithm is in a library sitting on the user's hard drive, all he needs to do is disassemble your code and spend some time reading MSIL to figure out how to get free access to your application.

One way around this is to store the license validation algorithm somewhere else and access it via the network through web services, remoting, or some other approach. Another possibility is to scatter the pieces of your licensing algorithm in such a way that once obfuscated (which is discussed next), it would be extremely difficult to figure out what your code does to determine the authenticity of licenses and license keys.

Protecting Intellectual Property Through Obfuscation

As mentioned earlier, your code is basically an open book. The names of all the variables and methods, as well as the values of all constants, are visible to anyone with a disassembler. Anyone who has the .NET Framework has access to a disassembler (ILDASM.EXE). There is something that you can do to defend your code from prying eyes: obfuscation.

Obfuscation refers to performing a series of operations that disguises the true meaning, purpose, and logic of your application's code. This is done by changing your variable and method names to a series of unintelligible alphanumeric characters. After obfuscation, reverse-engineering MSIL code that might ordinarily be easily reversible quickly becomes a colossal task that would take so long that most people would be discouraged from attempting it.

Don't let this fool you: Anyone who wants to reverse-engineer your code badly enough will either do it or find the resources to get it done. As a result, you need to write your code defensively. If you really do have a trade secret embedded in your code, don't put it in the same place, scatter it around, and make sure that the obfuscated MSIL doesn't make it obvious what your code is doing. Visual Studio .NET 2003 comes with a program called Dotfuscator, which obfuscates .NET code. Several other commercial and free products are available as well.

TIP

Keep in mind that obfuscators work only on code you write. They cannot mangle the symbol names of code already in the .NET Framework or of assemblies that your application references. As a result, it will still be obvious when your code attempts to use a class from the System.Security.Cryptography namespace.

Protecting Intellectual Property with Alternative Back-Ends

As I mentioned, everyone with the determination and resources will be able to reverse-engineer any code that they have on their hard drive. There are products that can generate C# from MSIL code even if it has been obfuscated. In such a format, it would take only minutes for an intruder to search for what he needs to find out all the information he wants.

The only way to protect your trade secrets and intellectual property from every single prying eye is to simply not give them out. Don't distribute your trade secrets. With the proliferation of broadband access, assuming that your user base has some form of network or dial-up access to the Internet is no longer a sure bet. If some operation must be performed and you can't risk someone discovering and distributing the algorithm behind that operation, don't distribute the algorithm.

You can expose some or all of your business back-end as a web service. If your code must perform an operation that might reveal too much about the application, such as decrypting sensitive data or comparing encrypted hashes, you can delegate the work to a web service and know that your trade secrets are safely inside your corporate firewall. Even if the client application is reverse-engineered, the real work is done behind the veil of the web service, so the reverse-engineered application will not reveal any sensitive or private information.