In this series of articles, I want to show how you can protect your intellectual property. In the previous article I demonstrated that compiling your binary doesn’t protect your code from being read by outsiders. With the help of decompilers, we reverse engineered the binary into human readable code. In the next (part 4) and final article in this series article I’ll show you how your can protect your code from prying eyes.
The purpose of decompilation is to transform the binary code into a more human readable form. In the early days binary code was disassembled into assembly. When programming languages evolved into higher level languages, the decompilers evolved as well. With the modern languages we know today, the decompiled code is better readable than ever. This means that more people than ever are capable of understanding the code.
Warning: This article (part 3 in the series) is a theoretical article.
A powerful weapon programmers can use to protect their code from being decompiled, is a technique called obfuscation. Obfuscation is the process of renaming the meta-data in an Assembly so that it is no longer useful to a hacker but remains usable to the machine for executing the intended operations. It does not modify the actual instructions or mask them from observation by an outsider.
Within obfuscation there are a number of techniques that can be applied (from simple to very sophisticated):
- Name Obfuscation
Name obfuscation changes the name of your classes and methods to unreadable characters, making your code harder to understand. Name obfuscation makes the decompiled source harder to understand but the overall flow of the code is not obscured.
- String Encryption
Managed software stores all the strings in one place and in a clear structure. This makes it easy to find the strings in a decompiled assembly. By following the references to these strings, it may be possible to understand the purpose of your code, even after obfuscation. String encryption works by moving all user strings to an encrypted block of storage. When needed, the runtime executive decrypts the string in memory.
- Control Flow Obfuscation
Control flow obfuscation is about modifying the program so that it yields the same result when run, but is impossible to decompile into a well-structured source code and is more difficult to understand. Most code obfuscators would replace MSIL instructions produced by a .NET compiler with gotos and other instructions that may not be decompiled into valid source code.
- Code Encryption
Code encryption protects the MSIL instructions by encrypting them and stripping the original instructions from the assembly, encrypted instructions are kept in a secure storage. When the assembly is loaded a native runtime executive assumes control of portions of the .NET runtime and manages decrypting the MSIL as needed.
- Code Virtualization
Code virtualization converts your MSIL code into Virtual Opcodes that will only be understood by a secure Virtual machine. As opposed to protecting MSIL code through encryption where the encrypted code must be decrypted back into MSIL before it can be executed by the CLR, Code Virtualization use a virtual machine which directly processes the protected code in the form of a virtual machine language. Code virtualization feature is by far the strongest protection method available in code protection arena today as it implements a one-way code transformation.
Not all obfuscators use the same techniques (courtesy to Wikipedia for the list of techniques). The most sophisticated techniques are in general available in commercial obfuscation software solutions.
Some of the available obfuscation solutions for the Microsoft.Net framework are:
- ConfuserEx (open-source)
- Obfuscar (open-source)
- Eazfuscator.NET (commercial)
- Red-Gate SmartAssembly (commercial)
In the next and final article in this series, I’ll demonstrate how you can use obfuscation in your projects using ConfuserEx. In the past I used to use Eazfuscator.Net, which is in my eyes one of the best and easy to use obfuscators out there (to be recommended).
More to come, later this week…