email article printer friendly more resources

Protect Your Code Investment
You can guard your .NET assemblies against reverse engineering by using tools within .NET.
by Jason Bock

October 2002 Issue

For this solution: .NET Framework

Consider the following scenario: Your team has been designing a component in .NET for the last three months with the intention of making the assembly available for purchase. After all the phases of the project are complete, you make the assembly available to the public on the company's Web site. Unfortunately, no software project is completely free of bugs, and users encounter problems. But the way customers report these bugs makes you wonder if they have access to the source code. In fact, some reports include source code that looks just like the code that's locked up on a secure, internal server.

How is this possible? Here's how it works. Whenever code written in a .NET language is compiled, the compiler has to include information in the resulting assembly so other .NET compilers can determine what it contains. Some of this information, called metadata, contains the definitions of several .NET elements, such as class, method, and field names. It also includes the source code, albeit in a different format: Common Intermediate Language (CIL). You can think of CIL as an object-oriented assembly language that all .NET code, regardless of the language it's written in, is translated into during compilation. Reverse-engineering tools can take all the information in the assembly and turn it into legible code in the high-level .NET language of choice (see Figure 1).

Figure 1 View How Reverse-Engineering Works

Because .NET code is susceptible to reverse-engineering techniques, you don't want your developers to spend a lot of time and money investigating and testing new algorithms only to have them stolen by a clever hacker. Fortunately, commercial developers can employ a few techniques to protect your investment. .NET offers several tools in the .NET Framework installation that can provide some resistance to reverse-engineering programs. In this article, I'll explore these tools and techniques, and I'll highlight their advantages and disadvantages to help you find the right solution for protecting your .NET code investment.

The native image generation tool (ngen.exe) that comes with .NET is one potential solution. It looks at the CIL code within a given assembly, and generates a new assembly that contains native instructions targeted for the current processor. This way, the code is optimized for the target platform. Theoretically, this should thwart hackers, because native code isn't easy to decompile into high-level .NET code. However, keep in mind that the original assembly must always exist on the user's machine. Although the .NET runtime is smart enough to use the native code, it needs the original assembly's metadata to determine the classes and methods that exist within the assembly. Because the CIL code isn't stripped out of the original assembly after a native assembly is created, would-be miscreants can still read the source code. So the ngen tools won't really provide the security your code needs.

Strong names and certificates offer another alternative. Developers can assign assemblies a strong name and a digital signature with a certificate. Technically, the strong naming and digital signature processes are the same, but they have subtle differences. When you strong name an assembly, you do so with a private key. This means that only a privileged few within the company, who have access to the key, can sign the assembly. This private key (along with its related public key) is usually stored in a file created by a tool called sn.exe. Once the tool creates the key pair (the private and public keys), it adds an attribute to the code to tell the compiler a strong name should be added to the assembly.