Developer's Toolkit
Protecting Your Property
Obfuscating your source code.
- By Peter Varhol
- 05/01/2008
Writing managed code using C#, VB.NET or one of the lesser alternatives has some significant advantages, including built-in memory management, easier debugging and less code. But it also has one big drawback: Because .NET code is compiled into Intermediate Language (IL), then just-in-time (JIT) compiled into machine language just prior to execution, your intellectual property (IP) is at risk.
Protecting Code
The problem with the .NET compilation model is that applications are deployed as IL, not as machine code. IL is source code, in a slightly different form, and is readable by many programmers.
If you've never looked at the contents of one of your assemblies, take a few minutes and do so now. You'll probably see some pretty recognizable code. Programmers who have taken the time to learn it can read IL just as well as they can source code.
As .NET use continues to broaden for commercial applications and custom code, more IP is embedded in code that cannot only be reverse engineered, but also read in its entirety. That's a problem. In some cases, the code has proprietary algorithms or assumptions in it, and must be protected. In other cases, you may want to keep your methods a trade secret. Understanding how your code works can also assist hackers in breaking in and stealing data.
Conventional solutions for protecting IP embedded in software may not solve the problem. One approach is to copyright your source code. The problem with this method is that it in effect publishes the code, though parts can be redacted. You can also patent specific software algorithms as an invention, or patent the software business process. This also makes the invention public, which may not be what you want.
Intentional Spaghetti
So, in general, you want to continue to distribute your .NET code, at least within your enterprise, but at the same time protect it. You might think about a couple of ways to handle the problem of distributing IL.
Microsoft, to its credit, recognized the problem years ago before releasing the first .NET platform, and realized that something had to be done to alleviate it. For reasons of its own, the company decided not to implement a solution itself, but to encourage its partners to do so. I worked for one such partner at the time.
Microsoft's preferred solution early in the .NET days was obfuscation. Obfuscation, as the name implies, involves changing the look and context of the code without changing the meaning. It might rearrange the order of the methods, or change the variable names into something more difficult to read. It's rather like me or you intentionally writing spaghetti code.
A Microsoft partner, PreEmptive Solutions, developed a product called the Dotfuscator that does just that. Microsoft shipped the Dotfuscator Community Edition in successive versions of Visual Studio, and Preemptive Solutions also sells a Professional Edition with additional features.
Beyond Obfuscation
As you might guess, obfuscation only gets you so far. The end result is still IL code, albeit IL that's intentionally mangled. Your average programmer probably wouldn't bother trying to understand it, but to a top-notch IP thief -- or a hacker -- it wouldn't be that much of a challenge. If protecting your IP is a high priority, you have to do more.
Another method of protecting IP embedded in code is to encrypt it. This method is a bit more complicated, because you also have to decrypt it for JIT compilation and execution. However, it's highly unlikely that any encryption would be broken.
That's the approach taken by V.i. Labs with its CodeArmor product. CodeArmor encrypts .NET assemblies so that they're completely unreadable by both text editors and common debugging tools, including my beloved SoftICE and BoundsChecker. I'm going to be using this product in the near future, and will report back on how it works and if it causes any performance degradation in applications.
You may have no need to protect your code from theft. Your algorithms may be obvious, and your value really in the user interface. Or you may be confident that the app won't leave the bounds of the enterprise. You've probably at least experimented with the Dotfuscator Community Edition, and may be using it as a part of your development practices. But if what you're putting into your code is valuable or important to you, you should be looking for stronger solutions.
About the Author
Peter Varhol is the executive editor,
reviews of Redmond magazine and has more than 20 years of experience as a software
developer, software product manager and technology writer. He has graduate degrees
in computer science and mathematics, and has taught both subjects at the university
level.