what is the best obfuscator to buy

  • Thread starter Thread starter Guest
  • Start date Start date
Alan Morgan said:
Linking in GPL terms means linking to a separate binary module.
Click to expand...

That seems very odd given that the very start of the exception stated
on the #ZipLib home page says:

"Linking this library statically or dynamically with other modules is
making a combined work based on this library."

Clearly linking statically does *not* involve a separate binary module
afterwards.
 
I have to agree on this. However, different users need different kinds of
obfuscation and it is not only about rewriting. There are also the
posibility of reusing obfuscated code among other scenarios.
 
Alan Morgan said:
I have to agree on this. However, different users need different
kinds of obfuscation and it is not only about rewriting. There are
also the posibility of reusing obfuscated code among other scenarios.
Click to expand...

Well if anyone is using obfuscator in the hope that it can never be
decompiled, they're likely to be disappointed. Even if an obfuscator
removes metadata which is required by *current* decompilers, that's not
going to stop decompilers from decompiling it in the future.

If the code can be run, it can be decompiled.
 
Alan Morgan said:
Do you have an explanaition for this? This seems to make it easier for the
bad guys to reverse-engineer the code and reuse it? What benefit do these
customers get out of it?
Click to expand...

Two different customers provided unsolicited positive comments about
this design. They liked the ability to verify that none of the
generated obfuscated code looked readable to them by being able to
browse all of the obfuscated code before distributing their final
build. Their reasoning was that as the author of their own code, if
they couldn't understand the generated code, then noone else would be
able to either. They considered that if the code wasn't readable, it
adequately protected their intellectual property and were less
concerned with the ability to hack a specific method.
The other customer liked the ability to debug the obfuscated code and
relink it with changed or new code during their debug process. I've
done this as well, when tracking down code generation bugs that caused
the obfuscated version of Decompiler.NET to behave differently from
the original code, and found the ability to debug code very useful.

Jonathan
 
Alan Morgan said:
Sorry :-( -- I deleted the files already and uninstalled your product.
Click to expand...

Alan,

This was a smart decision. The revenue that we derive from the sale of
these products is critical to our ability to improve them and offer
new ones. We have no objection to your contining to evaluate our
product consistent with the terms of it's license, and potentially
purchasing a license from us for either it's decompilation or
obfuscation capabilities.

We do however, need to maintain a level of concern about preventing
pirated copies that violate our license enforement strategy from being
created or distributed. We have tried to price our products low enough
to discourage piracy, but should such an event occur, we would be
forced to raise our prices for new customers which would be
detrimental to their interests.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
Here's what that author of IKVM responded on the licensing question.
His interpretation was similar to my own original interpretation, so
we may have to ask the authors of classpath and ziplib to confirm that
this is also what they mean by the exception.

Jeroen Frijters [[email protected]] wrote:

"IKVM.GNU.Classpath.dll is clearly a derived work and therefore falls
under the GNU Classpath license (GPL + exception [1]). This is part of
the reason why I renamed it (to make that more clear).

The IKVM runtime and tools, however, are not derived works and only
link with GNU Classpath. By my understanding of the GNU Classpath
license (specifically the exception part), this does not require the
IKVM runtime and tools to licensed under the GPL and thus it falls
under its own license (the "zlib license")."

[1] http://www.gnu.org/software/classpath/license.html

The exception part of the license says:
"If you modify this library, you may extend this exception to your
version of the library, but you are not obligated to do so."

I interpret this to mean that my modified version of GNU Classpath
must be licensed under the GPL *or* the GPL + exception. I choose to
license it under the GPL + exception.

I believe that the intention is to force people to release the source
to their modifications of Classpath, but not to their independent
applications.
Perhaps you could ask them to clarify the wording to say something
like:
Click to expand...

Feel free to ask them, but I think it is unlikely that they will do
so.
I'm sure the current wording was written (or at least reviewed) by the
FSF lawyers, so I'm assuming they already feel it is clear enough.
 
Yes, but think about these scenarios:

- Someone decompiles your product (which has a public interface) copies the
code into his codebase and recompiles the code. If the decompiled code is
not recompilable the bar for this becomes much higher.

- Someone takes your code, decompiles it, removes some copy protection and
recompiles it. Sure this could in theory be done with ILDASM as well but
having higher level code makes it even simpler.

The ability to recompile the stolen code can be seen as a motivator for the
bad guys in most cases. After getting the code to compile and run, why not
spend more time on undoing the other stuff...? If it just fails to compile
the bar is much higher.
 
What I really wanted to get at is: It feels weird to adverise a door lock
toolset by saying how it can be broken with the same tools used to install
it.
 
Chris said:
Yes, but think about these scenarios:

- Someone decompiles your product (which has a public interface) copies the
code into his codebase and recompiles the code. If the decompiled code is
not recompilable the bar for this becomes much higher.
Click to expand...

Sure - but being non-recompilable *now* doesn't mean it won't be
recompilable later. I'll rephrase my earlier statement: if the code can
be run, it can be decompiled into a form which allows recompilation. It
may be that some of it ends up as IL rather than C#, but that doesn't
make much difference to this scenario.
- Someone takes your code, decompiles it, removes some copy protection and
recompiles it. Sure this could in theory be done with ILDASM as well but
having higher level code makes it even simpler.
Click to expand...

I've done this in a few products in the past (with the owner's
permission, just to see how secure it is). While it's not usually
*very* difficult, a large obfuscated app can be *very* hard to
understand. It's certainly not something that just anyone can do - and
if the bar is already high enough that it takes someone with a pretty
high level of competence, raising it a little bit higher doesn't help
much.
The ability to recompile the stolen code can be seen as a motivator for the
bad guys in most cases. After getting the code to compile and run, why not
spend more time on undoing the other stuff...? If it just fails to compile
the bar is much higher.
Click to expand...

Only temporarily.
 
Chris said:
What I really wanted to get at is: It feels weird to adverise a door lock
toolset by saying how it can be broken with the same tools used to install
it.
Click to expand...

Hi Chris,

I see your point, but with most other obfuscators, you can still
decompile with ildasm, edit the MSIL, and recompile with ilasm. Even
if the interface is not public, you can change internal and sealed
classes in the MSIL and recompile with ilasm. The obfuscated code is
not really readable in either case. This is always a risk when your
MSIL code is accessible, even as an embedded resource.

We currently also remove string literals and will be adding a feature
that obfuscates calls to external public interfaces by moving them and
replacing them with anonymous stubs.

It is usually a good idea to include license enforcement code in
multiple places throughout your application.

Our Deploy.NET product adds some additional protection for your MSIL
code on disk by encrypting it and embedding it in an archive embedded
resource and dynamically loading it from a native loader. Until
trusted computing hardware is available, this doesn't protect against
someone dumping process memory with unecrypted MSIL loaded. We will be
adding support for trusted computing hardware when it becomes
available to fully hide your MSIL code.

You may want to try out both products to see how readable the
obfuscated code is, and how we package the encrypted MSIL.

You can download evaluation versions of both from
http://www.junglecreatures.com/

We appreciate this and other feedback that you provide to us about our
products and are always looking for additional ways to improve them.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
Back
Top