.NET Obfuscator protects your .NET software from hackers, competitors, and prying eyes by preventing unauthorized use, code tampering and reverse engineering.

Spices.Net Obfuscator offers reliable code protection and optimization

Using Spices.Net Obfuscator, you can protect your .Net applications from being decompiled or tampered. This helps to protect your intellectual property and keep your .Net code secure from theft and hackers.

Don't give competitors and hackers a chance: protect your code and data!

Spices.Obfuscator is a .Net code protection and optimization tool that offers the wide range of technologies to completely protect your .Net code and secure your data. Spices.Obfuscator rebuilds your .Net assemblies to the new format that is impossible to disassemble, decompile, impossible to understand.

Spices.Obfuscator completely integrated into Spices.Net and distributed as Visual Studio Integrated package (Spices.VSIP.Obfuscator), stand alone GUI and console version.

Why to protect code and data?

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 four main goals:

  • Complicate reverse engineering

    Obfuscation significantly complicates decompilation and decreases its efficiency.
    Spices.Obfuscator stops ILDASM/ILASM roundtrip.

  • Secure your data

    Spices.Obfuscator removes all string data from your code to hidden and safe place and makes impossible to extract any string info from protected assembly.

  • Optimize code size and performance

    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.

  • Produce tamper-proof assemblies

    The risk with tampering is that strong name of your assembly can be cracked and resigned by another key.
    Assemblies generated by Spices.Obfuscator is tamper resistant. Our patent pending technology allows generating assemblies protected from a recently emerged spoofing technique: modifying or removing strong-names.
    The assembly won't work correctly with a modified strong-name even if the new strong-name is recognized by .net loader as a valid one.
    Hackers have learned to crack strong-names. Having modified the assembly, a hacker (either leaves it unsigned, or) re-signs it with his or her own strong-name key. With the our tamper-proof technology, the assembly won't work correctly neither if not signed at all, nor if signed by a strong-name key which differs from the assembly originator's one. If your assembly does not contain any string information, you can check the assembly validity by performing an easy testing procedure for any of the use strings. Tamper-proof technology encrypts string and binary resources (user strings, binary arrays used in the code) to protect and secure resources from prying eyes and provide tamper-proof mechanisms that prevent assembly from unauthorized copying, tampering, spoofing, and malicious code injection.

  • Resource Protection

    Resource Protection protects managed resources by encrypted resource names so that they can't be determined if the assembly is altered.

  • Software watermarking

    Software watermarking can be used to an additional hidden identification or marking a given application with specific information, such as its buyer and copyright. This information can help reveal a forgery of an application and identify its owner, the distribution region, the OEM distributor and the serial number. A watermark is incorporated into an assembly in such a way that it disappears with the application after decompilation and disassembly.

How does .NET Obfuscation Work?

During obfuscation a .NET assembly is transformed into an equivalent .NET assembly that is more difficult to understand when decompiled. Some obfuscators use ILDASM to disassmble the assembly and then transform the original MSIL, and then use ILASM to reassemble the result. Wide variety of different techniques is applied to the assemlies to make the disassembled source code more difficult to understand. Below given the brief outline of the most effective of them.

  • Entity Renaming

    The most essential 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 CodeAnonymization

    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.

    To find out more about protecting your software with a .Net obfuscator, visit the Spices.Net Obfuscator Home page.