I believe you are reading "In contrast to an obfuscator that makes
decompilation more difficult by symbol renaming, our protector completely
stops MSIL disassembly and decompilation ."
Okay, let's examine this:
1. Who makes the only commercial decompiler? RemoteSoft
2. Who released Protector? RemoteSoft
Fox in the chicken house.
What level of protection do you need? Salamander will decompile most
obfuscated code. This is true, but you figure out how to make this code
work:
private int i;
private double i;
private string i;
public long RandomMethod()
{
i = 100;
i = 1000;
i = "something";
i = i(i,i,i);
}
private string i(string i, long i)
{
}
Yes, you can decompile, but imagine tons of lines of code written like so.
It would take you a long time to "steal" the product; long enough a new
version would likely be out.
A couple of things you can do:
First, refactor classes to place all repetitive code in private methods. If
you find the same code in two functions, put it in a private method. This
will make your code harder to decompile, as an obfuscator will name a lot of
things by the same symbol. It is also a good practice, regardless, as you
have code in one place, not many, when you need to update.
Second, reduce exposure on as many functions as possible. Public and
protected functions are not obfuscated. If you do not need outside access,
reduce the exposure. This is also common programming practice.
NOTE: This post is not a knock of protector. From what I have gathered,
protector is a great product. In some instance, protector may be needed,
esp. if you shrink wrap software.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
**********************************************************************
Think Outside the Box!
**********************************************************************
