what is the best obfuscator to buy

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

If I want an obfuscator that works with .Net CF and for Web Services which one should I buy?

thanks,

p
 
picnic said:
If I want an obfuscator that works with .Net CF and for Web Services which one should I buy?

thanks,

p
Click to expand...

You may want to consider our Decompiler.NET product to meet your
obfuscation needs. It is the only product whose obfuscated output can
be recompiled or relinked and debugged. It is also much easier to use
since it requires no configuration of exception cases like most of the
competitive products. You can download a free trial version of the
product from http://www.junglecreatures.com/ to see how well it meets
your needs. It will work fine with .NET CF and Web Services code as
well as COM Interop and Windows API calls. We bundle together full
obfuscation capability and superior decompilation technology at a
price lower than comparable competitive obfuscator products alone and
provide free updates and far better support than any of our
competitors.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
Demeanor from WiseOwl is the best managed code obfuscator (it is used by
Reflector).

Remotesoft has a tool for translating your code into unmanaged code which is
more secure but comes with lots of issues (size increases, redistributing MS
binaries, exposing a managed API)

These two have been around for a while and work pretty well.
Most of the new obfuscator products that claim to be cheaper are quite buggy
and/or incomplete.
 
It is the only product whose obfuscated output can be recompiled or
relinked and debugged.

Wouldn't that be a reason to not even consider that product?
An obfuscator is supposed to obfuscate my code, not to make it possible to
decompile and recompile it?
 
Thanks for the replies so far.

Does Demeanor also do the Compact Framework, I've had a look on the web site and could see no mention on it?


picnic
 
It should work on Compact Framework assemblies. You might want to verify
this with the author.

picnic said:
Thanks for the replies so far.

Does Demeanor also do the Compact Framework, I've had a look on the web
Click to expand...
site and could see no mention on it?
 
These two have been around for a while and work pretty well.
This is an absolutely unfounded statement and you would be wise to do
your own evaluation. Our obfuscator is new, less expensive, more
powerful, easier to configure, and there have been no bugs reported
regarding obfuscation. In addition, we obfuscate our product with
itself each time we ship it so any bugs would prevent the product from
working at all. This is strong evidence that it works extremely well,
and our customers are extremely happy with it. The best way to
determine whether our claims are accurate is to try out our product
yourself and compare it to our competitor's products by downloading
our free trial version. We also provide support to our customers for
free with free upgrades, and are far more responsive than our
competitors. We also bundle both full obfuscation and full
decompilation in a single product priced lower than either feature
available from comparable competitors. Please download our trial
version of Decompiler.NET and evaluate it yourself from
http://www.junglecreatures.com/

We will be happy to respond to any issues that you encouter using the
product. Please attempt to keep these discussions based on facts and
real examples, rather than unfounded opinions and inaccurate claims
that interfere with developers interested in accurate information in
order to make correct choices.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
Jonathan Pierce said:
This is an absolutely unfounded statement and you would be wise to do
your own evaluation. Our obfuscator is new, less expensive, more
powerful, easier to configure, and there have been no bugs reported
regarding obfuscation. In addition, we obfuscate our product with
itself each time we ship it so any bugs would prevent the product from
working at all.
Click to expand...

No - only bugs that affected obfuscation of your code would prevent the
product from working at all, and not necessarily all of those bugs
even. (If it incorrectly obfuscated a particular error case which had
never cropped up, the bug in obfuscation wouldn't have been seen yet.)
This is strong evidence that it works extremely well
Click to expand...

Well, it's evidence that it works on your own code.
and our customers are extremely happy with it.
Click to expand...

That's certainly more convincing, as it'll cover a wider code base.
We will be happy to respond to any issues that you encouter using the
product. Please attempt to keep these discussions based on facts and
real examples, rather than unfounded opinions and inaccurate claims
that interfere with developers interested in accurate information in
order to make correct choices.
Click to expand...

Inaccurate claims such as the implied, "It works with our code
therefore there can't be any bugs"?

Note that no specific claims were made about *your* obfuscator in the
passage you quoted - only about *most* new obfuscator products.
 
I was looking at your tool using ildasm and the obfuscated code in
launcher.exe looks nice. However, one thing I noticed is that it seems to
include an obfuscated version of #ziplib in every DLL to read compressed
resource files?? The reason I'm asking: #ziplib comes with a GPL license
with link exceptions. In my interpretation this says that any software which
uses your tool could be claimed to be GPL as well?
 
a said:
I was looking at your tool using ildasm and the obfuscated code in
launcher.exe looks nice. However, one thing I noticed is that it seems to
include an obfuscated version of #ziplib in every DLL to read compressed
resource files?? The reason I'm asking: #ziplib comes with a GPL license
with link exceptions. In my interpretation this says that any software which
uses your tool could be claimed to be GPL as well?
Click to expand...

The generic lauhcher code is inserted by our Deploy.NET tool which
loads the main obfuscated app from an embedded compressed obfuscated
resource. The Decompiler.NET product itself doesn't use compression.
We do use our Decompiler.NET product to obfuscate the loader code used
by Deploy.NET. We are removing the compression code and posting a new
version in the next few days since the compression code isn't really
needed by either product. We may add back compression in our loader
when 2.0 ships using System.IO.Compression.GZipStream.

Jonathan
 
a said:
I was looking at your tool using ildasm and the obfuscated code in
launcher.exe looks nice. However, one thing I noticed is that it seems to
include an obfuscated version of #ziplib in every DLL to read compressed
resource files?? The reason I'm asking: #ziplib comes with a GPL license
with link exceptions. In my interpretation this says that any software which
uses your tool could be claimed to be GPL as well?
Click to expand...

Thank you again for your compliments regarding our obfuscation
technology, and for alerting us to your licensing concerns.

To alleviate any further licensing concerns, we have removed all use
and reference to the #ZipLib product including binary usage from all
of our products and posted updated versions to our website.

We no longer have any requirement to link or redistribute this library
in any form in any of our products and have posted updated versions of
all of our products so that they no longer reference the #ZipLib
library in any form. Feel free to download the new versions and verify
this statement.

Users of older versions of our Decompiler.NET product would not be
affected anyway since the Decompiler.NET product itself has never used
#ZipLib in any form at any time other than the loader module inserted
by older versions of our Deploy.NET product. This includes code
generation, obfuscation, and runtime of user generated code.

We appreciate your alerting us to your concerns.

Best Regards,

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
a said:
I was looking at your tool using ildasm and the obfuscated code in
launcher.exe looks nice. However, one thing I noticed is that it seems to
include an obfuscated version of #ziplib in every DLL to read compressed
resource files?? The reason I'm asking: #ziplib comes with a GPL license
with link exceptions. In my interpretation this says that any software which
uses your tool could be claimed to be GPL as well?
Click to expand...

Thank you again for your compliments regarding our obfuscation
technology, and for alerting us to your licensing concerns.

To alleviate any further licensing concerns, we have removed all use
and reference to the #ZipLib product including binary usage from all
of our products and posted updated versions to our website.

We no longer have any requirement to link or redistribute this library
in any form in any of our products and have posted updated versions of
all of our products so that they no longer reference the #ZipLib
library in any form. Feel free to download the new versions and verify
this statement.

Users of older versions of our Decompiler.NET product would not be
affected anyway since the Decompiler.NET product itself has never used
#ZipLib in any form at any time other than the loader module inserted
by older versions of our Deploy.NET product. This includes code
generation, obfuscation, and runtime of user generated code.

We appreciate your alerting us to your concerns.

Best Regards,

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
a said:
I was looking at your tool using ildasm and the obfuscated code in
launcher.exe looks nice. However, one thing I noticed is that it seems to
include an obfuscated version of #ziplib in every DLL to read compressed
resource files?? The reason I'm asking: #ziplib comes with a GPL license
with link exceptions. In my interpretation this says that any software which
uses your tool could be claimed to be GPL as well?
Click to expand...

I believe that even if the obfuscator were GPL'd, files it produced
normally wouldn't be. (For instance, files compiled with gcc aren't
automatically GPL'd.)

In this case, I don't believe the obfuscator's use of #ZipLib would
affect anything, as it's covered by the exceptions.
 
Good to know, basically anybody using Deploy.NET is affected by this?

When are you going to release the source code for the pervious version of
Decompiler.net?
 
The scenario is different from gcc. They included a copy of #ziplib in every
obfuscated assembly. So it is not only decompiler.net being affected by the
link license but all the deploy.net obfuscated assemblies as well.

I'm probably correct on this since it took them just a few hours to remove
the #ziplib dependency. The impact this could have on their customers is
quite scary.
 
a said:
The scenario is different from gcc. They included a copy of #ziplib in every
obfuscated assembly. So it is not only decompiler.net being affected by the
link license but all the deploy.net obfuscated assemblies as well.
Click to expand...

Ah, I see. Sorry to misunderstand.
I'm probably correct on this since it took them just a few hours to remove
the #ziplib dependency. The impact this could have on their customers is
quite scary.
Click to expand...

I don't think so - surely the obfuscated assemblies would still be only
linking to #ZipLib anyway, which is allowed by the licence.
 
I don't think the GPL applied even to his earlier version, so I can see no
reason he should release the source. See Jon Skeet's comments above.
 
a said:
The scenario is different from gcc. They included a copy of #ziplib in every
obfuscated assembly. So it is not only decompiler.net being affected by the
link license but all the deploy.net obfuscated assemblies as well.

I'm probably correct on this since it took them just a few hours to remove
the #ziplib dependency. The impact this could have on their customers is
quite scary.
Click to expand...
Let me repeat that the Decompiler.NET product never used #ZipLib in
any form. The Decompiler.NET product itself does not use any
compression technology itself or for any code that it produces as
output, obfuscated or not. Older versions were packages within a
seperate obfuscated loader application for distribution that did use a
binary version of #ZipLib consistent with it's license.

You are arguing that if you use a GPL based installer or loader, than
any program that it installs would be GPL as well. The license does
not require this - See Jon Skeet's comments above. The Decompiler.NET
application itself and other applications packaged with the Deploy.NET
loader are treated as data by the loader and are not directly linked,
but instead are launched in a seperate external process. The loader
just serves to decrypt the packaged applications and launch them as
seperate processes in memory. The loader source code is also fully
obfuscated prior to being compiled so it's source would not be
readable to anyone anyway. The loader application is a completely
seperate application that dynamically loads the Decompiler.NET
application which does not directly or dynamically link the #ZipLib
assembly.

We decided to remove the #Ziplib binary assembly from our loader
distribution application to avoid further licensing discussions, since
the loader itself didn't really require any compression technology. We
could have repackaged our distribution to include the binary version
of #ZipLib as a seperate file but wanted our distribution to be
packaged as a single file with embedded resources. I don't think the
license mentions anything regarding packaging of the binary version of
the #ZipLib anyway, so we probably could have just included the
unmodified binary version of it directly as an embedded resource.

As far as Deploy.NET is concerned, so far we have only used it
internally and shipped it in evaluation form so none of our customers
have used it for distributing any of their products. Our updated
loader does not reference #ZipLib at all although we still would be
permitted to include the binary version of #ZipLib with our loader
distribution produced by Deploy.NET, possibly even as an embedded
resource. We decided that it wasn't really needed by the product
anyway, and distributing a seperate file would be contradictory to the
intended use of the product which is to package multiple dlls in a
single file. A seperate file distribution of the #ZipLib DLL would be
inconsistent with the product's design. The #ZipLib only served to
reduce the file size of the distributed loader application with it's
embedded dynamically linked sub-applications. We may add back
compression support using System.IO.Compression.GZipStream when
Whidbey ships but none of our products really require it.

In general, the license is not intended to propagate from programs
that package or manipulate other programs as data to these other
programs which are not directly linked.

I'm not sure whether the same would be true about using the ILMerge
tool with GPL assemblies since it merges assemblies into a new dll
that directly links them.
Jonathan
 
Jon Skeet said:
Ah, I see. Sorry to misunderstand.


I don't think so - surely the obfuscated assemblies would still be only
linking to #ZipLib anyway, which is allowed by the licence.
Click to expand...

Jon,

Thanks for the support and clarifying this issue.

Decompiler.NET does not produce obfuscated assemblies, it produces
obfuscated code that you recompile. String literals and other data
used by your source code are encrypted, but are not compressed and the
generated obfuscated code does not use #ZipLib in any form.
Decompliler.NET also does not use #ZipLib or any compression
technology in any form at any time. The binary version of #ZipLib was
only used for the distribution of the Decompiler.NET application, not
by the application itself or any compiled assemblies that you process
with it.

Jonathan
 
I'm not sure whether the same would be true about using the ILMerge
tool with GPL assemblies since it merges assemblies into a new dll
that directly links them.
Click to expand...

That would certainly be a significantly stickier situation.

I'm sure you were fine as you were - but I can quite see how removing
#ZipLib entirely pre-empts further questions :)
 
Back
Top