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).
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.
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.
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.
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.
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.
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.
Yes, that is the point why we develop our protector in the first place.
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.
Yes.
Because the underlying CIL code is replaced with native code, which can not be decompiled back to source code level.
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.
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.
$1899 for 1-5 users, $2999 for 5-10 users,
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.
No, our protector outputs only valid and fully verifiable .NET format, as described by Microsoft .NET specification.
No, there is no runtime discrepancy from all of the tests we conducted thus far.
Yes.
Yes, 100%.
Yes, 100%.
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.
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.