FAQs for Remotesoft .NET Protector


  1. What is remotesoft .NET protector?

    Remotesoft .NET protector is a tool to protect your intellectual properties. It transforms your .NET assemblies (.EXE or .DLL) into a new format that completely stops decompilation and disassembling . With this tool, you are assured that no one will be able to steal your source code. With this tool, you no longer need to worry about the biggest headache of Microsoft .NET platform - decompilation.

    Our protector is extremely easy to use through a command-line utility that simply takes .exe or .dll files as input and transform them into the new format. Comprehensive testing has been conducted, and in all cases the protector generates code that behaves exactly same as the original but with a new format that is impossible to decompile (as difficult as decompiling C/C++ code).

  2. Why do I need to protect .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 disassembler or 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 protect your .NET code before distributing your products.

  3. How does remotesoft protector work?

    Microsoft .NET assemblies are easy to decompile because they use Common Intermediate Language (CIL), which contains enough information for reverse engineering. Our protector does not use CIL code, instead, it emits pseudo-native code, and thus can not be decompiled. At run time, pseudo-native code is transformed to native format. To make it even more secure, the pseudo-native code is also encrypted.

  4. Can remotesoft protection be reversed?

    No. After protection, high level CIL is replaced with low level register and memory-based instructions. The symbolic information associated with original CIL is lost, and can not be recovered. Or, more accurately, it is as difficult as converting native executables back to C/C++ code. Since transformed native code is also encrypted, one has to break into this layer of protection before native code can be retrieved.

  5. How is remotesoft protector different from an obfuscator?

    An obfuscator provides limited protection through modifying symbol names to confuse someone from understanding the decompiled code, but it has no mechanism to hide and protect CIL code, the obfuscated executables still use CIL code, and thus can be decompiled. It provides no protection over disassembling, i.e., you can always use ILDASM to view the CIL code.

    To make things worse, an obfuscator can not guarantee code equivalence, for example, if a program contains System.Reflection calls, it may not work after obfuscation. The following is an example that you can try, run it before and after obfuscation, and you will see the difference.

    
    using System;
    using System.Reflection;
    
    class ReflectionTest
    {	
      int which;
      string name;
    	
      ReflectionTest(int which)
      {
        this.which = which;
        name = "Christina Zhang";
      }
    
      public static void Main()
      {
        int data = 1234;
        ReflectionTest rt = new ReflectionTest(data);
    
        try {
          // use reflection to get the field value
          FieldInfo fi = typeof(ReflectionTest).GetField("which", BindingFlags.Public|BindingFlags.NonPublic|BindingFlags.Instance);
          Console.WriteLine("You should see {0}, here: {1}", data, fi.GetValue(rt));
        } catch (Exception e) {
          Console.WriteLine(e.Message);
        }
        // display field directly
        Console.WriteLine("name = {0}", rt.name);
      }
    }
    
      
    Overall, what an obfuscator really does is replacing symbol 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 its obfuscator can prevent your code from decompilation, take it with salts.

    Remotesoft .NET protector is not an obfuscator, it uses totally different approach, and it changes the underlying CIL code to native code. It completely stops decompilation, so no one can steal your source code. It completely stops CIL disassembling, so no one can even view your CIL code.

    In short, an obfuscator modifies symbol names to make decompilation harder, while our protector changes underlying code to make CIL decompilation and disassembling impossible.

  6. Why should I choose remotesoft protector rather than an obfuscator?

    Based on reasons in (4), our protector provides the real protection. An obfuscator might be used before our protector to modify symbol names, and thus add one more level of protection, but make sure no reflection APIs are used, since they may fail the obfuscation.

  7. Does remotesoft protector prevent ILDASM and similar utilities from disassembling my protected assemblies?

    Yes. Since remotesoft protector does not use CIL code at all, it completely prevent Microsoft's ILDASM and other similar tools from disassembling your code.

  8. Does remotesoft protector prevent decompilation?

    Yes, that is the point why we develop our protector in the first place.

  9. Does remotesoft protector prevent your own salamander decompiler from decompiling my assemblies?

    Yes. It stops any decompilation, including our own decompiler. Our obfuscator can also stop our own decompiler, but the mechanism is totally different, our obfuscator marks a special key into the obfuscated assemblies so that our own decompiler can recognize it and stops decompilation. Our protector does not rely on such special measures, it provides an inherent mechanism to prevent decompilation.

  10. Does remotesoft protector prevent other decompilers from decompiling my assemblies?

    Yes.

  11. How does remotesoft protector prevent assemblies from being decompiled by any .NET decompiler?

    Because the underlying CIL code is replaced with native code, which can not be decompiled back to source code level.

  12. Does remotesoft protector perform whole assembly protection, and then a native loader decrypts the protected at runtime?

    No, our protector does not use this kind of mechanism to protect code, as we are fully aware that whole assembly protection is very easy to reverse. For more information, you can check out for yourself and see how easily our sample DeProtector can undo such protection.

  13. How does remotesoft protector compare to other protection tools?

    As far as we know, all other available protection tools perform whole assembly encryption, with a native loader embedded to decrypt at runtime. Although fancy tricks, such as anti-debugging techniques, might be in place as well, it does not solve the fundamental problem, that an assembly must exist somewhere in memory in its raw form to be consumed by the CLR engine. This provides wide open opportunities for people to dump out the original assemblies. For more information, you can check out for yourself and see how easily our sample DeProtector can undo such protection.

  14. How much does remotesoft protector cost?

    $1899 for 1-5 users, $2999 for 5-10 users,

  15. Why is remotesoft protector a command line utility?

    Our protector is designed to be seamlessly integrated into your build process. This cannot be done in a reliable and repeatable fashion if the protector depends on a graphical user interface for operation.

  16. Does your protector introduce corruption to the protected assemblies?

    No, our protector outputs only valid and fully verifiable .NET format, as described by Microsoft .NET specification.

  17. Are there situations where protected code can behave differently than the original?

    No, there is no runtime discrepancy from all of the tests we conducted thus far.

  18. Does remotesoft protector work with reflection APIs?

    Yes.

  19. Does remotesoft protector support mixed images produced by Visual C++.NET?

    Yes, 100%.

  20. Does remotesoft protector support COM interop and PInvoke?

    Yes, 100%.

  21. What platforms does remotesoft protector support?

    Our product works on those platforms with .NET support, namely, the following platforms,

    Microsoft Windows® 98
    Microsoft Windows NT® 4.0 (SP 6a required)
    Microsoft Windows Millennium Edition (Windows Me)
    Microsoft Windows 2000 (SP2 Recommended)
    Microsoft Windows XP Professional
    Microsoft Windows XP Home Edition

    Since .NET does not run on WIN95, therefore, our protector does NOT support WIN95. Our protector currently does not support UNIX systems.

  22. How does remotesoft protector deal with strong named assemblies?

    Our protector 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 protector is invoked, and our protector 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 protected code.


Copyright © 2002-2011 Remotesoft Inc. All rights reserved.