Salamander .NET obfuscator is a tool to protect your intellectual properties. It transforms your .NET assemblies (.EXE or .DLL) in such a way that decompilation of the new format would result in source codes that are extremely difficult to be understood by humans, and virtually impossible to be recompiled by a compiler. It provides symbol obfuscation, class member and metadata removal, and structure re-organization. Code optimization and flow obfuscation will be soon available. It is extremely easy to use through a command-line utility that simply takes .exe or .dll files as input and transform them into new format. For more than 100 assemblies that have been tested, our .NET obfuscator always produces equivalent and obfuscated codes.
Although .NET assembly files share the same extension (.exe or .dll) as traditional executables, they contain all of the information, apart from comments, that is in original source files (e.g., C#, managed C++, Visual Basic.NET). Using a decompiler, a hostile competitor can easily reverse engineer your products and get your source code.
To counter this threat and protect your intellectual properties, it is better to obfuscate your .NET code before distributing your products.
We see both to be mutually beneficial, rather than in conflicts. To develop a decompiler, we gain a deep insight in ways of protecting your .NET code.
Yes and no, remotesoft obfuscator can be used to emit code that will crash Microsoft ILDASM utility, so one can not disassemble your code. However, this feature only works well for .exe files, where no methods need to be exported and accessed from outside.
No. Obfuscator is just an obfuscator, its main functionality is to replace symbolic names with meaningless ones so any decompilation of the resulting file will be hard to understand. The flow and data structures could still be decompiled. If a vendor claims that his obfuscator can prevent your code from decompiled, take it with salts. Although an obfuscator can not fundamentally prevent someone from decompiling your code, we make sure that our own decompiler will NOT decompile assemblies protected by our obfuscator.
The obfuscation process strips all unnecessary information (line numbers, parameter names, local variable names, source file names used by debuggers, certain .NET metadata) from your assemblies. Also, namespace, class, interface, struct, enum., field, method, property and event identifiers are renamed to make them meaningless. Original class hierarchy is randomized so unrelated classes might end up in a same namespace.
No. Obfuscation is one way mapping that is impossible to recover, because it is an information-lossy process. For example, you have the following method in your class, void displayCopyrightInfo(), after obfuscation, it might become, void A(), which can by no means be reversed back into the original name.
Yes. Great care has been taken to make sure assemblies protected by our obfuscator will NOT be able to get decompiled by our own decompiler.
Special signatures and patterns are incorporated into the obfuscated images, when later our decompiler recognizes such marks, it will stop decompiling those assemblies.
$799 per license,
Our obfuscator is designed to be seamlessly integrated into your build process. This cannot be done in a reliable and repeatable fashion if the obfuscation tool depends on a graphical user interface for operation.
This XML config file provide you with a very flexible way to control the obfuscator. For instance, certain names have be reserved from obfuscation because they are public members intended to be accessed from outside. Especially when you develop public libraries, this list of reserved names can become quite extensive due to the large number of public APIs that you want to export. By default, all unnecessary info is stripped from each class during obfuscation. In the unlikely event that you want to retain any of these info, this can be done through the config file.
No, our obfuscator outputs only valid and fully verifiable .NET format, as described by Microsoft .NET specification . There is one exception, that is when you choose to emit code to protect ILDASM, some invalid format will be incorporated into your assemblies.
Due to inheritance constraints, some identifiers, mostly virtual methods, cannot be modified. For example, the public String ToString() method, an override of the System.Object class, cannot be renamed.
Yes. The reflection APIs, namely, certain methods of the System.Type and the System.Reflection namespace, refer to classes, methods, fields, properties and events using a string name. If your assemblies use these reflection methods to refer to identifiers , your code may behave incorrectly after obfuscation because the string name may have been changed.
Our obfuscator adds a warning to the log file if the above reflection methods are used in the obfuscated code. If the reflection methods act only on classes, methods, fields, properties and events outside of the assembly, there will be no problem. If, however, the reflection methods act on identifiers within the assembly, these identifiers must be specified in the XML config file so that obfuscation does not change them.
Yes, but you need to reserve the class-names of the server objects from obfuscation, and Remoting calls will work normally. If you use an interface to define the remote methods, the interface and its methods need to be excluded from obfuscation as well.
Our obfuscator deals with strong named assemblies automatically, no extra work is required.
Usually,
attaching a strong name signature to your code involves two steps:
(1) create the strong name key using the SN
utility: sn -k sample.snk
(2) compile your assembly with the key by adding a
declaration to the assembly to indicate the location of the key file, as shown
below,
C#:
[assembly: AssemblyKeyFile("sample.snk")]
class StrongNameTest
{
...
}
VB.NET:
<assembly: AssemblyKeyFile("sample.snk")>
Public Class StrongNameTest
...
End Class
Just make sure that your
key file is in the correct path when the obfuscator is invoked, and
our obfuscator will automatically re-sign the modified assembly with the
same key file. If you do not have access to the key file, you can choose to
delay sign the protected assembly, or choose to remove the signature, so you
can continue to work with the obfuscated
code.