Symbol and Metadata Obfuscation

The .NET obfuscation process renames all possible symbols (class, interface, field and method identifiers) to render them meaningless, and strips all unnecessary information (local variable, method parameter names, debug information and some metadata) from your .NET assemblies. A benefit to obfuscation is a substantial reduction in the size of your code, due to the removal of unnecessary information and the replacement of large, human-readable identifiers with small machine generated names. This size reduction is beneficial as it leads to a faster startup for your programs.

Whole Obfuscation     Tutorial

A simple way to view obfuscation is as a phase in your build process where multiple .NET assemblies are specified as inputs, and some public interfaces are to be exported to the outside while the rest are internal and thus to be obfuscated as much as possible. The input assemblies may depend on each other, and our obfuscator automatically analyzes the inter-dependency, then performs the obfuscation as a whole.

Shown here are 5 files: MyApp.exe (C#): an executable you'd like to sell MyPublicLib.dll (C#): a strong named library you'd like to sell MyModule.dll (VB.NET): an internal module MyPrivateLib.dll (MC++): an internal assembly sample.snk: a strong name key file for MyPublicLib.dll These 4 files are written in different .NET languages and depends on each other in a complex fashion, but you do not care, what you do care is to deliver MyApp.exe and MyPublicLib.dll to your customers, and you want the deepest obfuscation with as many public symbols renamed as possible. Simply invoke the following, or use an XML config file    obfuscator -private MyModule.dll -private MyPrivateLib.dll MyApp.exe MyPublicLib.dll will perform the whole obfuscation, with only the public symbols of MyPublicLib.dll and external references to system libraries left unchanged, all else including public symbols wil be renamed to "A", "a", "B", "b", ... Download the files here, and try it with other vendor's obfuscators

Incremental Obfuscation     Tutorial

Incremental obfuscation allows you to obfuscate new assemblies based on the previous obfuscation results, and therefore you can perform hot fixs by distributing a small patch to your customers. Most obfuscators require you to save a complete log file with all name mappings, which adds extra maintenance. Our obfuscator does not rely on any logs, instead it simply utilizes the original and obfuscated pair of images, and thus it is extremely easy to perform incremental obfusaction.

V-Spot Elimination (Unique feature)

There is one problem none of the current obfuscators address, that is, no matter how good the obfusaction is, there are system library calls and other external references scattered over in your code (see red in below). Since these calls are external references, obfusactors will have to leave them unchanged. However, these references help a lot to understand the decompiled code, because they are well-documented and public APIs. We call them Vunerable Spots (V-Spots). Our upcomming technology will try to rename, remove or reduce such V-Spots, and thus make your code much more difficult to decompile.

  IL_0000:  ldarg.0
  IL_0001:  call       instance void [System.Windows.Forms]System.Windows.Forms.Form::.ctor()
  IL_0006:  ldarg.0
  IL_0007:  newobj     instance void  [System.Windows.Forms]System.Windows.Forms.TextBox::.ctor()
  IL_000c:  stfld      class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
  IL_0011:  ldarg.0
  IL_0012:  ldfld      class [System.Windows.Forms]System.Windows.Forms.TextBox A.A::A
  IL_0017:  call       valuetype  [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Cyan()
  IL_001c:  callvirt   instance void  [System.Windows.Forms]System.Windows.Forms.TextBoxBase::set_BackColor(valuetype [System.Drawing]System.Drawing.Color)
  IL_0021:  ldarg.0              
             

String Protection

String protection refers to literal strings encryption during obfusaction and decryption at runtime. Since obfuscators must embed the decrypt method into the same assembly, it is very easy to recover the original strings. Our decompiler seamlessly removes any string protections injected by obfuscators. A detailed document can be found here. Due to its unsecure nature in obfuscators, we decided to implement a much better string protection in our protector. Our protector also offers resource protection.

Control Flow Obfuscation

Comprehensive testing has shown that our obfuscator is very robust. No matter how complex your application is, no matter which .NET programming language you use, our obfuscator will always work. As matter of fact, we have replaced many of the Microsoft .NET System libraries with the obfuscated version, and they work just great.

   Introducing Salamander .NET Protector, click here
- nothing to worry about decompilation

Uniqueness (differentiators from other obfuscators)    

• protection against our own decompiler. It prevents your assemblies from being decompiled by salamander decompiler.
• protection against ILDASM and utilities using reflection APIs. It will crash ILDASM utility and Reflector from disassembling your .exe files. more
• support for mixed images that contain both managed and unmanaged code. Almost every image produced by Visual C++.NET belongs to this category. See Microsoft metainfo sample for more details. If you are not sure whether an obfuscator supports mixed images, click here.
• no round ildasm-ilasm trip. Most obfuscators use these two utilities to disassemble your file to IL format, obfuscate the IL, and then recompile to a new .exe or .dll file. During this process, some information could get lost, and it only supports pure .NET image, and thus it does not support assemblies that contains native code.