On Fri, 31 Mar 2006 15:44:32 +0200, z f wrote:

> which is the best reasonable price tool for code encryption / dotfuscation?
> I found that the dotfuscator community edition only rename method names but
> does not encrypt actual implementation.
> If someone can share from their experience it will very help.

It depends what is a reasonable price to you but all the tools i came
across that could encrypt the code were horribly expensive to me (in the
order of several thousand pounds per application). Plus i think that they
don't encrypt the code itself but only the string litterals (and they also
of course rename the functions/classes/variables, modify the flow of your
code...).

But why do you want to encrypt the code of your application in the first
place? Obfuscation is all about protecting the code so that somebody else
can not simply decompile your app and ripp off your code. Dotfuscator
community edition does that pretty well and should be sufficient in most
cases.

I also suppose that you are aware of the implications of code obfuscation
and of how it could impede your ability to provide proper support for your
application or **** off developers using your library (if that's a library
that you're selling)

which is the best reasonable price tool for code encryption / dotfuscation?
I found that the dotfuscator community edition only rename method names but
does not encrypt actual implementation.
If someone can share from their experience it will very help.

thanks.

Dan Appleman created a decent start for an obfuscator, which goes beyond the
Dotfuscator community version. It is not as good as some, but the price is
free (or a few bucks if you buy the eBook that explains the open source
project).

I have tried trials of some of the obfuscators and seen output from others.
Here is a list of code protectors I know of, including obfscators and full
encrypted DLL models (may blog on feature sets later, as I would love to take
them out for a test drive).

Of the ones I have played with, I like Dotfuscator Pro, Demeanor (have only
seen assemblies from this one, ie have not played with the bits yet as you
have to email for a trial) and Salamander, although the feature sets on some
may not be at the level you desire. The cheapest of these products is about
$800.

Google for Dan Appleman's free obfuscator. Not as full featured as some, but
a great tool for the price (free). Most of the low priced options (less than
$100) do a bit of metadata scrambling and symbol renaming. When they overload
the symbols, it makes it more difficult to reverse engineer.

Apose has a free obfuscator that munges up the DLL fairly well, but creates
a map file. If a person only finds the DLL, you are golden. If they can get
at the map file, you are toast. But, you can't beat the price.

Look at Sharp Tool Box (http://sharptoolbox.com) under Code Protection for a
list. Most have free trials.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Blog: http://spaces.msn.com/gregorybeamer
***************************
Think Outside the Box!
***************************


"z f" wrote:

> which is the best reasonable price tool for code encryption / dotfuscation?
> I found that the dotfuscator community edition only rename method names but
> does not encrypt actual implementation.
> If someone can share from their experience it will very help.
>
> thanks.
>
>
>
>

http://www.xenocode.com/ is very nice.

--
William Stacey [MVP]

"z f" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
| which is the best reasonable price tool for code encryption /
dotfuscation?
| I found that the dotfuscator community edition only rename method names
but
| does not encrypt actual implementation.
| If someone can share from their experience it will very help.
|
| thanks.
|
|
|

z f wrote:
> which is the best reasonable price tool for code encryption /
> dotfuscation? I found that the dotfuscator community edition only
> rename method names but does not encrypt actual implementation.
> If someone can share from their experience it will very help.

I have been checking out several products over the last couple of days and
so far they all appeared useless to me.

Two of them who's names I won't mention crashed my app. One in a
reproducable way, the other just once which made me shy away from it just
the same. They wrap your assembly in a Win32 executable and unpack them on
the fly without producing files on disk. This is not absolutely save
(someone smart could find a way to dump the memory and take it from there)
but any attack would not be easy. The good part of this approach is that
your app, although from the outside no longer a .NET assembly, remains
unchanged an the IL that ultimately gets fed to the CLR will be your
original code (or so it should be, in theory, it crashed nontheless claiming
something went wrong in the default app domain and there's no way to debug
it). You original code being fed to the CLR is important, here's why.

After coming to the point that I would not trust the wrapper-type approach,
I continued with Dotfuscator which appeared to be no good either. I wrote
this magnificent framework that persists objects to XML and back. Each of
these classes has a constructor that takes an XmlElement which is used to
initialize the object. On the other end, it produces XmlElement objects when
the objects is about to be inserted in a DOM, using the class name for an
element name. The framework supports writing any common simple type
including enumerated types to XML attrubutes. To do that, it uses
reflection. Nothing fancy, just "Class.ToString()" and GetType().Name.

Now, do you already see what sucks here? Obfuscation can break your code.
Checking validity of XML input by comparing element names to class names is
not much good after your obfuscator just renamed "Configuration" to "dd".
Even writing enumerated type names will fail. Say I have

enum Colors { Red, Green, Blue }

and I start my app. My smart framework will complain that "Red" is not valid
attribute value, that valid names would be "aa", ac" or "d". Don't you love
it?

Now, you can exclude namespaces from obfuscation (which defeats its purpose
entirely) but the enumerations do not come from the configuration namespace
exlusively. I am only describing what I found so far, after I fix this (and
I'm not sure I will continue to try), who knows what the next bang will be
and I will never be sure I nailed down all the issues that may occur in
runtime.

What I want is some sort of public-private key protection that encrypts my
assembly and a platform I can trust. I can't wat to get the DRM stuff that
all those idiots claim to hate so much, it seems the only way to keep your
stuff safe in more than just the anti-hacking way.

Regards, Martin.