Spices.Obfuscator v5.0

Why to Obfuscate .Net Assemblies?

One of the key features of Microsoft .NET is that all its languages generate assemblies containing CPU-independent instructions, or so called Microsoft Intermediate Language instructions. .NET assemblies also include metadata that describe types, members, and code references from other assemblies. At program runtime, these instructions are converted to CPU-specific language by the just-in-time compiler.

This architecture provides developers for several benefits: it makes possible easy interoperability for code written in differing languages, and simplifies assemblies interlinks. However, there is one major drawback as well: the data contained in assemblies provide enough information to recover the original code. This makes it difficult to protect the intellectual property in an application, which source code source code can be read by anyone. Developers who have spent months or years working on complex algorithms or workarounds for bugs, often prefer to have their methods remain secret from others.

This is where obfuscation can help. Its purpose is to transform a .NET assembly without affecting its functionality, so that it becomes difficult or impossible to be decomplied. Code obfuscation of .NET assemblies helps achieve two main goals:

Complicate reverse engineering

Obfuscation significantly complicates decompilation and decreases its efficiency.

Optimize code size

Obfuscation breaks down structures that make programs modular, surprisingly reducing program code size in many cases. For example, reducing metadata size and optimizing the symbol tables.

How does .NET Obfuscation Work?

Entity Renaming

The most esential method of obfuscation. Entities are all the named objects in the .NET assembly: namespaces, classes, methods, properties, fields, and enums. As everybody knows, it's a good practice to give the entities meaningful names and so make the code easier to read and debug. When you build a .NET assembly, the entity names from your source code are preserved in the assembly's metadata, and so provide clues for those trying to understand the code. During the process of entity renaming, all the entities are renamed to short, nonsensical, or obscure names, so making code very hard to read, but still operational. Overloaded renaming, in addition, takes advantage of .NET specifics, giving same names to more than one entity as long as this is allowed by .NET overloading rules. Method return type can also be overloaded on MSIL level, making the assembly code absolutely impossible to decompile.

Declarative Obfuscation

This technique lets developer decide what exactly should be obfuscated and supports for repeatable obfuscation that is well-documented directly in the source code.

Control Flow Obfuscation and Method Calls Anonymization

This method modifies source code so that it becomes logically harder to understand, while remaining logically equivalent. 

Stub Untouched Methods

This method replaces bodies of untouched methods with anonymized stubs. 

Unused Members Removal

When this approach is used, the entire source code is evaluated to determine whether there are any methods that are actually unused, and if so, such members are removed from the assembly. This approach also lets optimize application size.

String Encryption

String constants and literal strings in your .NET source code appear unchanged in your compiled .NET assemblies. At the obfuscation stage, they are encrypted and decryption routine is added into the assembly to be then called at runtime to return the original string values.

ILDASM Breaks

ILDASM is the MSIL disassembler that comes with.NET Framework SDK. The breaking technique is based on injecting a piece of code into assembly that leads ILDASM to crash and inability to handle the assembly.

Product compare matrix: