FAQs for Remotesoft .NET Obfuscator

  1. What is remotesoft .NET obfuscator?

    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.

  2. Why do I need to obfuscate .NET code?

    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.

  3. Why does remotesoft develop a decompiler and an obfuscator in the same time? Are they in conflicts?

    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.

  4. Does remotesoft obfuscator prevent ILDASM from disassembling my obfuscated assemblies?

    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.

  5. Does remotesoft obfuscator prevent decompilation?

    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.

  6. How does remotesoft obfuscation change .NET assemblies?

    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.

  7. Can remotesoft obfuscation be reversed?

    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.

  8. Does remotesoft obfuscator prevent salamander decompiler from decompiling my assemblies?

    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.

  9. How does remotesoft obfuscator prevent assemblies from decompiled by your 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.

  10. How much does remotesoft obfuscator cost?

    $799 per license,

  11. Why is remotesoft obfuscator a command line utility?

    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.

  12. What is the XML config file?

    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.

  13. Does your obfuscator introduce corruption to the obfuscated assemblies?

    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.

  14. After obfuscation, why does the log file report that some names are left unchanged?

    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.

  15. Are there situations where obfuscated code can behave differently than the original?

    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.

  16. How can the above reflection problems be solved?

    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. 

  17. My application uses Microsoft Remoting technologies, will this work after obfuscation?

    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.

  18. How does remotesoft obfuscator deal with strong named assemblies?

    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,

    [assembly: AssemblyKeyFile("sample.snk")]
    class StrongNameTest

    <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.

Copyright 2011 Remotesoft Inc. All rights reserved.