what is the best obfuscator to buy

[Jonathan Pierce]

(If it incorrectly obfuscated a particular error case which had
The obfuscated code produced by our decompiler is recompiled so incorrectly
generated code would have been seen by the compiler, and it's runtime
behavior would affect that aspect of the product's runtime behavior, since
we ship the recompiled version of our obfuscated code produced by
decompiling the product with itself in obfuscation mode. This is also
evidence that it supports correct COM Interop code generation since COM
Interop code used in the product wouldn't run correctly if the code was
generated incorrectly when the product was decompiled and recompiled prior
to distribution.

Note that no specific claims were made about *your* obfuscator in the
passage you quoted - only about *most* new obfuscator products.

It is always better to identify specific reproducable examples and to cite
specific products, rather than making inaccurate general statements implying
that anything new that is less expensive, buggy, and incomplete. I
apologize if the author of the quote was referring to his personal
experience with some other unknown product, but our the only new product
that was recently announced for this market that has made these claims. If
he was referring to our products, I'd appreciate specific examples since
none of our customers have had as bug-related issues and have only expressed
positive feedback to us both directly and in public forums.

Jonathan

 

[Jon Skeet [C# MVP]]

The obfuscated code produced by our decompiler is recompiled so incorrectly
generated code would have been seen by the compiler, and it's runtime
behavior would affect that aspect of the product's runtime behavior, since
we ship the recompiled version of our obfuscated code produced by
decompiling the product with itself in obfuscation mode. This is also
evidence that it supports correct COM Interop code generation since COM
Interop code used in the product wouldn't run correctly if the code was
generated incorrectly when the product was decompiled and recompiled prior
to distribution.

I don't see how that argument applies. Not all incorrectly generated
code will fail to compile, and it's possible that the incorrectly
generated code only occurs in one particular execution flow which has
never occurred, or which (say) subtly affects the threading so that a
previously theoretically thread-safe piece of code becomes
theoretically unsafe, even if that lack of safety is never observed.
(It's very easy to write threading code which will work on x86 but
isn't guaranteed to work on all conformant CLRs.)

I'm not saying you have such a bug - just that your reasoning of "Well,
we use our products on themselves, therefore they don't have any bugs"
is seriously flawed.

It is always better to identify specific reproducable examples and to cite
specific products, rather than making inaccurate general statements implying
that anything new that is less expensive, buggy, and incomplete.

It didn't imply that *anything* new is buggy and incomplete. "Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

 

[Jonathan Pierce]

"Most"

doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

I understand and appreciate your knowledge and attempts to keep
statements made in these forums honest and based on logical facts. I
am glad that you do respond and challenge any statements made that
can't be substantiated. In this case, you were correct that there was
not enough info in the quote to assume the author was referring to our
product. I may have been reacting to other posts my "Alan Morgan" from
other threads that you were not aware of that support the idea that he
was referring to our products in his statements about new products
that claim to be less expensive.

In another thread regarding our product, "Alan Morgan" wrote:

"i can't find any PDB files. sucks."
"it is bad that you reverse-engineer full source code and make money
with it"

We responded to these statements appropriately in that thread. Thank
you again for taking the time to monitor and contribute to these
discussions and basing your arguments on logic, true facts, and
reproduceable specific examples.

Jonathan

 

[Jonathan Pierce]

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

Jon,

Thanks again for clarifying this. The authors of #ZipLib agreed that
we could have continued to rely on and distribute the unmodified
version of their original binary distribution.

We may want to move this license discussion to a different thread in
another group where other license enforcement authorities might want
to contribute.

Although we no longer require it, I would like to know your opinion
regarding whether this product and other product licenses that allow
distribution of unmodified binary versions would also permit
distribution of obfuscated pr encrypted versions of their original
binary distributions. I would expect that encypted versions should be
allowed since they get unencrypted back to the original version before
being linked, but obfuscated versions or bytecode translated versions
even packages as a seperate files might be considered derivative
works. I ask because the issue may come up again for us regarding
permissions to distributed encrypted binary versions of GPL and LGPL
distributions with our Deploy.NET product output for trusted computing
hardware.

Another example would be the IKVM distribution in Mono of the .NET
translated version of the classpath libraries. The original classpath
license refers to binary distribution of the classes for running on a
java VM, but IKVM compiles the java binaries to MSIL and distributes
the MSIL versions which might be considered a derivative work. They
could always distribute the compiled java distribution and JIT compile
it to MSIL at install time, but I don't think they should have to.

Can you clarify further your view of these licenses regarding
processing of unmodified binary distributions whether in advance, at
install time, or at runtime, and whether their form of distribution
matters, whether as seperate files, as embedded resources, as content
in a database image, merged into a common archive such as a jar with
classes from multiple sources, or even a merged dll like ILMerge would
produce from the original? I think these issues should be clarified
since they will resurface and are not explicitly defined in the
license terms of most licenses including GPL, LGPL, and the one that
classpath uses.

Jonathan

 

[Alan Morgan]

I wasn't refering to your product. I just started looking into this recently
and my experience is that Demeanor works great while most newer/cheaper
products fail on C++ stuff.

The problem with your obfuscator seems to be not price or features, more
that some people have not enough thrust: a) the way you argue and exaggerate
b) your claim that your decompiler can decompile and recompile obfuscated
code and c) your product is using code from various sources and you seem to
be unable to handle those partnerships. Most of the things you say about
your partners sound like you never talked to them beforehand and you view
them as enemies.

As a side note: I don't like people decompiling my entire source code into
files. This is already bad enough and you are collecting money for making
things easier.

"Most"

doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

I understand and appreciate your knowledge and attempts to keep
statements made in these forums honest and based on logical facts. I
am glad that you do respond and challenge any statements made that
can't be substantiated. In this case, you were correct that there was
not enough info in the quote to assume the author was referring to our
product. I may have been reacting to other posts my "Alan Morgan" from
other threads that you were not aware of that support the idea that he
was referring to our products in his statements about new products
that claim to be less expensive.

In another thread regarding our product, "Alan Morgan" wrote:

"i can't find any PDB files. sucks."
"it is bad that you reverse-engineer full source code and make money
with it"

We responded to these statements appropriately in that thread. Thank
you again for taking the time to monitor and contribute to these
discussions and basing your arguments on logic, true facts, and
reproduceable specific examples.

Jonathan


Jon Skeet [C# MVP] <[email protected]> wrote in message

I don't see how that argument applies. Not all incorrectly generated
code will fail to compile, and it's possible that the incorrectly
generated code only occurs in one particular execution flow which has
never occurred, or which (say) subtly affects the threading so that a
previously theoretically thread-safe piece of code becomes
theoretically unsafe, even if that lack of safety is never observed.
(It's very easy to write threading code which will work on x86 but
isn't guaranteed to work on all conformant CLRs.)

I'm not saying you have such a bug - just that your reasoning of "Well,
we use our products on themselves, therefore they don't have any bugs"
is seriously flawed.


It didn't imply that *anything* new is buggy and incomplete. "Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

 

[Alan Morgan]

You should informed all your Deploy.NET customers about this. According to
GPL link terminology their products right now violate the #ZipLib license.
It is unlikely they'll get sued over this but for aquisitions this might be
a show stopper (lawyers hit the breaks on GPL immediatly).

Jon Skeet [C# MVP] <[email protected]> wrote in message

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

Jon,

Thanks again for clarifying this. The authors of #ZipLib agreed that
we could have continued to rely on and distribute the unmodified
version of their original binary distribution.

We may want to move this license discussion to a different thread in
another group where other license enforcement authorities might want
to contribute.

Although we no longer require it, I would like to know your opinion
regarding whether this product and other product licenses that allow
distribution of unmodified binary versions would also permit
distribution of obfuscated pr encrypted versions of their original
binary distributions. I would expect that encypted versions should be
allowed since they get unencrypted back to the original version before
being linked, but obfuscated versions or bytecode translated versions
even packages as a seperate files might be considered derivative
works. I ask because the issue may come up again for us regarding
permissions to distributed encrypted binary versions of GPL and LGPL
distributions with our Deploy.NET product output for trusted computing
hardware.

Another example would be the IKVM distribution in Mono of the .NET
translated version of the classpath libraries. The original classpath
license refers to binary distribution of the classes for running on a
java VM, but IKVM compiles the java binaries to MSIL and distributes
the MSIL versions which might be considered a derivative work. They
could always distribute the compiled java distribution and JIT compile
it to MSIL at install time, but I don't think they should have to.

Can you clarify further your view of these licenses regarding
processing of unmodified binary distributions whether in advance, at
install time, or at runtime, and whether their form of distribution
matters, whether as seperate files, as embedded resources, as content
in a database image, merged into a common archive such as a jar with
classes from multiple sources, or even a merged dll like ILMerge would
produce from the original? I think these issues should be clarified
since they will resurface and are not explicitly defined in the
license terms of most licenses including GPL, LGPL, and the one that
classpath uses.

Jonathan

 

[Jon Skeet [C# MVP]]

You should informed all your Deploy.NET customers about this. According to
GPL link terminology their products right now violate the #ZipLib license.
It is unlikely they'll get sued over this but for aquisitions this might be
a show stopper (lawyers hit the breaks on GPL immediatly).

I don't believe that's true at all, as the #ZipLib has an exception for
linking. As it says on the #ZipLib website: "Bottom line In plain
English this means you can use this library in commercial closed-source
applications."

 

[Jon Skeet [C# MVP]]

Thanks again for clarifying this. The authors of #ZipLib agreed that
we could have continued to rely on and distribute the unmodified
version of their original binary distribution.

We may want to move this license discussion to a different thread in
another group where other license enforcement authorities might want
to contribute.

I think it's fine here for the moment - I certainly don't know of any
particular licensing groups (although I admit I haven't looked).

Although we no longer require it, I would like to know your opinion
regarding whether this product and other product licenses that allow
distribution of unmodified binary versions would also permit
distribution of obfuscated pr encrypted versions of their original
binary distributions. I would expect that encypted versions should be
allowed since they get unencrypted back to the original version before
being linked, but obfuscated versions or bytecode translated versions
even packages as a seperate files might be considered derivative
works. I ask because the issue may come up again for us regarding
permissions to distributed encrypted binary versions of GPL and LGPL
distributions with our Deploy.NET product output for trusted computing
hardware.

Right. I think I'd probably agree with your reading of it - encryption
is just another medium, effectively (like providing a zip of the binary
would be). Obfuscation is somewhat different. Of course, there's not
really much point in obfuscating an open source binary, I'd have
thought.

I'm really *not* an expert on these matters though - it's worth asking
a lawyer, unfortunately

 

[Jonathan Pierce]

I wasn't refering to your product. I just started looking into this recently
and my experience is that Demeanor works great while most newer/cheaper
products fail on C++ stuff.

The problem with your obfuscator seems to be not price or features, more
that some people have not enough thrust: a) the way you argue and exaggerate
b) your claim that your decompiler can decompile and recompile obfuscated
code and c) your product is using code from various sources and you seem to
be unable to handle those partnerships. Most of the things you say about
your partners sound like you never talked to them beforehand and you view
them as enemies.

Alan,

Thanks for letting us know that you were not referring to our product
in your earlier statement about buggy new obfuscator products. I hope
your experience testing our product continues to be positive.

a) Since are products are brand new, we need to be extremely careful
that the developer community become aware of the full power and
quality that they provide by monitoring statements that could be
perceived to be references to our products in these public forums. We
don't intend to exaggerate any of our claims, and welcome any
reproduceable examples that refute them. The size or age of the
company is less relevant than the merits of the actual products being
offered and we want each developer to spend a few minutes doing the
comparison themselves rather than relying on assumptions or reviews
that may not be available yet.

b)We never claimed that we could reverse obfuscated code created by
other vendor
s obfuscators. Obfuscator tools often intentionally scramble metadata
that the runtime no longer needs by decompilers and debuggers still
require. Our claim is that we recompile obfuscate code produced by our
obfuscator so this ensures that we detect many errors when we
recompile the code that users might not detect until runtime when
using the output of other obfuscator tools. This also minimizes the
need to preconfigure exception cases.

c)I do not view any of our competitors as enemies at all. I view them
as colleagues and respect them very much for their knowledge and the
quality of their work. I'm sorry that you got this impression from my
attempts to compare the quality of our products to theirs. I welcome
any examples from them and head on comparisons to our products, and
attempt whenever possible to help them improve their products to bring
the overall quality of products in this domain to a higher level. I've
suggested to Lutz several times that he consider offering a non-free
version of his tools so that he could justify providing even better
support then he is able to currently provide. We have interacted and
had many positive conversations with the authors of Reflector,
Salamander, and Spices. We regularly provide them with bug reports,
assist them with testing their products, and offered them free copies
of full licenses to our tools which some of them have accepted and
some have reciprocated with free copies of their tools for us.

Here are some email signatures if you don't believe me:

Best regards,
Victor Victorov
9Rays.Net (merger of Imca Systems and Dev4Net) .Net, Delphi, C++
Builder, ActiveX tools, components & controls


Date: Mon, 31 May 2004 14:25:20 -0700
From: Lutz Roeder <[email protected]>
Subject: RE: IL Reader bug fix

Date: Fri, 30 Apr 2004 20:50:06 -0700
From: Lutz Roeder <[email protected]>
Subject: RE: Reflector CodeModel and Parser

Date: Sun, 29 Feb 2004 12:31:41 -0800
From: Huihong Luo <[email protected]>
Subject: Whidbey support

Date: Thu, 11 Dec 2003 08:56:35 -0800

As a side note: I don't like people decompiling my entire source code into
files. This is already bad enough and you are collecting money for making
things easier.

I still don't understand why you object to this capability that
products in the decompiler domain provide. The decompilers also assist
you with translating your code across languages, improving your code
often, and our's also provides you obfuscation capability. Decompilers
should not be thought of any differently than other developer tools
that you use since they have many legal uses and we explicitly ask you
in our license to restrict your use of them to legal purposes. There
are many options available to you to protect your intellectual
property including patents and obfuscator tools offered by the same
decompiler vendors that you can utilize if you are concerned. The
tools provide a valuable use by allowing you to learn from and debug
assemblies whose license doesn't prohibit it by introspecting on their
source code.

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

"Most"

doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

I understand and appreciate your knowledge and attempts to keep
statements made in these forums honest and based on logical facts. I
am glad that you do respond and challenge any statements made that
can't be substantiated. In this case, you were correct that there was
not enough info in the quote to assume the author was referring to our
product. I may have been reacting to other posts my "Alan Morgan" from
other threads that you were not aware of that support the idea that he
was referring to our products in his statements about new products
that claim to be less expensive.

In another thread regarding our product, "Alan Morgan" wrote:

"i can't find any PDB files. sucks."
"it is bad that you reverse-engineer full source code and make money
with it"

We responded to these statements appropriately in that thread. Thank
you again for taking the time to monitor and contribute to these
discussions and basing your arguments on logic, true facts, and
reproduceable specific examples.

Jonathan


Jon Skeet [C# MVP] <[email protected]> wrote in message

(If it incorrectly obfuscated a particular error case which had
never cropped up, the bug in obfuscation wouldn't have been seen yet.)

The obfuscated code produced by our decompiler is recompiled so incorrectly
generated code would have been seen by the compiler, and it's runtime
behavior would affect that aspect of the product's runtime behavior, since
we ship the recompiled version of our obfuscated code produced by
decompiling the product with itself in obfuscation mode. This is also
evidence that it supports correct COM Interop code generation since COM
Interop code used in the product wouldn't run correctly if the code was
generated incorrectly when the product was decompiled and recompiled prior
to distribution.

I don't see how that argument applies. Not all incorrectly generated
code will fail to compile, and it's possible that the incorrectly
generated code only occurs in one particular execution flow which has
never occurred, or which (say) subtly affects the threading so that a
previously theoretically thread-safe piece of code becomes
theoretically unsafe, even if that lack of safety is never observed.
(It's very easy to write threading code which will work on x86 but
isn't guaranteed to work on all conformant CLRs.)

I'm not saying you have such a bug - just that your reasoning of "Well,
we use our products on themselves, therefore they don't have any bugs"
is seriously flawed.

Note that no specific claims were made about *your* obfuscator in the
passage you quoted - only about *most* new obfuscator products.

It is always better to identify specific reproducable examples and to cite
specific products, rather than making inaccurate general statements implying
that anything new that is less expensive, buggy, and incomplete.

It didn't imply that *anything* new is buggy and incomplete. "Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

 

[Jonathan Pierce]

You should informed all your Deploy.NET customers about this. According to
GPL link terminology their products right now violate the #ZipLib license.
It is unlikely they'll get sued over this but for aquisitions this might be
a show stopper (lawyers hit the breaks on GPL immediatly).

Alan,

As I said earlier, we haven't sold any licensed copies of Deploy.NET
yet. Customers who are considering it are only using it for internal
evaluation at this time. #ZipLib does not use GPL license, it uses the
one that classpath uses which is even less restrictive than the LGPL
one.

"As a special exception, the copyright holders of this library give
you permission to link this library with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting
executable under terms of your choice"

Their FAQ says:

Can I use SharpZipLib in my commercial application?
Yes you can, there is an exception in the licensing terms that allows
linking #Zip with any application.

The only additional requirement is that improvements made to the
#ZipLib source be made available to everyone, not the sources of
programs that use it. In our case, we didn't modify the source to
#ZipLib at all, we only processed it and packaged it with our loader
where it gets dynamically linked to our older loader code. We could
have just embedded the original unmodified #ZipLib dll in our loader
as an embedded resource, even encrypted, and processed it at runtime,
but we decided to remove it completely to preempt further licensing
discussions.

Since no customers have purchased Deploy.NET licenses from us, and we
have repackaged all of our products with the newer loader that no
longer even references the binary version, there is no issue, and
there probably never was in the first place. We have also confirmed
that the authors of #ZipLib are satisfied and they had no objection to
us continuing to use their binary unmodified version and
redistributing it with our product as it's license allows. We decided
to avoid pursuing the discussion about how the unmodified binary
version was packaged, since we didn't really need the product anyway
and only used it because we didn't expect any conflict with our
repackaging the unmodified binary version and their license terms
which are not clear on the issue.

Jonathan

 

[Jonathan Pierce]

Right. I think I'd probably agree with your reading of it - encryption

is just another medium, effectively (like providing a zip of the binary
would be). Obfuscation is somewhat different. Of course, there's not
really much point in obfuscating an open source binary, I'd have
thought.

I'm really *not* an expert on these matters though - it's worth asking
a lawyer, unfortunately

Jon,

I posted the same question to the IKVM developer group since I think
the same issue applies there. The IKVM distribution includes an
recompiled version of the classpath binary distribution as a generated
MSIL dll converted from compiled java bytecode. The modified dll is
required at runtime by any IKVM user for any application that they
develop, and the MSIL code produced by the IKVM compiler, although
starting from the binary classpath distribution, is certainly
different since it includes error checking instructions and converted
types that reference other IKVM runtime libraries. I would think that
the same issue would apply to anyone using IKVM for their applications
since they require a modified version of the classpath libraries
produced and distributed by the IKVM compiler. Even if these were
regenerated at runtime, the translated dll clearly directly links with
other IKVM runtime provided code that is not covered by the classpath
license. In this case, the classpath site even refers to IKVM as a
successful implementation example that utilizes their binary
distribution. IKVM currently provides source code as well, but it is
covered by a different license and I'm sure that it is not their
intention that anyone using the IKVM runtime with the required
modified version of the classpath binary distribution which includes
the code that #ZipLib is based on, should also revert to the GPL
license and be required to be open source. In this case, the modified
distribution is actually different code, not just obfuscated. I'd
appreciate your thoughts on this apparent inconsisency and will let
you know the feedback that I receive from that group regarding it.

Jonathan

 

[Jonathan Pierce]

Of course, there's not

really much point in obfuscating an open source binary, I'd have
thought.

I agree with you on this and we could have just continued to
redistribute the original binary version and even wrapped the calls to
the public interface with obfuscated stubs. We were more concerned
with the ability to encrypt the distribution and distribute it as an
embedded resource as a single file.

 

[Alan Morgan]

a) Fair enough. You won't achieve this by exaggerating and then arguing
about what you claim to be facts.

b) You got me wrong. The entire point of obfuscation is to make it
impossible to decompile (worse recompile) the code. This is not an advantage
of your product, it's a disadvantage.

c) Read some introductionary business books that explain the difference
between competitors and partners and what is meant by managing dependencies.

"Alan Morgan" <[email protected]> wrote in message

I wasn't refering to your product. I just started looking into this recently
and my experience is that Demeanor works great while most newer/cheaper
products fail on C++ stuff.

The problem with your obfuscator seems to be not price or features, more
that some people have not enough thrust: a) the way you argue and exaggerate
b) your claim that your decompiler can decompile and recompile obfuscated
code and c) your product is using code from various sources and you seem to
be unable to handle those partnerships. Most of the things you say about
your partners sound like you never talked to them beforehand and you view
them as enemies.

Alan,

Thanks for letting us know that you were not referring to our product
in your earlier statement about buggy new obfuscator products. I hope
your experience testing our product continues to be positive.

a) Since are products are brand new, we need to be extremely careful
that the developer community become aware of the full power and
quality that they provide by monitoring statements that could be
perceived to be references to our products in these public forums. We
don't intend to exaggerate any of our claims, and welcome any
reproduceable examples that refute them. The size or age of the
company is less relevant than the merits of the actual products being
offered and we want each developer to spend a few minutes doing the
comparison themselves rather than relying on assumptions or reviews
that may not be available yet.

b)We never claimed that we could reverse obfuscated code created by
other vendor
s obfuscators. Obfuscator tools often intentionally scramble metadata
that the runtime no longer needs by decompilers and debuggers still
require. Our claim is that we recompile obfuscate code produced by our
obfuscator so this ensures that we detect many errors when we
recompile the code that users might not detect until runtime when
using the output of other obfuscator tools. This also minimizes the
need to preconfigure exception cases.

c)I do not view any of our competitors as enemies at all. I view them
as colleagues and respect them very much for their knowledge and the
quality of their work. I'm sorry that you got this impression from my
attempts to compare the quality of our products to theirs. I welcome
any examples from them and head on comparisons to our products, and
attempt whenever possible to help them improve their products to bring
the overall quality of products in this domain to a higher level. I've
suggested to Lutz several times that he consider offering a non-free
version of his tools so that he could justify providing even better
support then he is able to currently provide. We have interacted and
had many positive conversations with the authors of Reflector,
Salamander, and Spices. We regularly provide them with bug reports,
assist them with testing their products, and offered them free copies
of full licenses to our tools which some of them have accepted and
some have reciprocated with free copies of their tools for us.

Here are some email signatures if you don't believe me:

Best regards,
Victor Victorov
9Rays.Net (merger of Imca Systems and Dev4Net) .Net, Delphi, C++
Builder, ActiveX tools, components & controls


Date: Mon, 31 May 2004 14:25:20 -0700
From: Lutz Roeder <[email protected]>
Subject: RE: IL Reader bug fix

Date: Fri, 30 Apr 2004 20:50:06 -0700
From: Lutz Roeder <[email protected]>
Subject: RE: Reflector CodeModel and Parser

Date: Sun, 29 Feb 2004 12:31:41 -0800
From: Huihong Luo <[email protected]>
Subject: Whidbey support

Date: Thu, 11 Dec 2003 08:56:35 -0800

As a side note: I don't like people decompiling my entire source code into
files. This is already bad enough and you are collecting money for making
things easier.

I still don't understand why you object to this capability that
products in the decompiler domain provide. The decompilers also assist
you with translating your code across languages, improving your code
often, and our's also provides you obfuscation capability. Decompilers
should not be thought of any differently than other developer tools
that you use since they have many legal uses and we explicitly ask you
in our license to restrict your use of them to legal purposes. There
are many options available to you to protect your intellectual
property including patents and obfuscator tools offered by the same
decompiler vendors that you can utilize if you are concerned. The
tools provide a valuable use by allowing you to learn from and debug
assemblies whose license doesn't prohibit it by introspecting on their
source code.

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

"Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

I understand and appreciate your knowledge and attempts to keep
statements made in these forums honest and based on logical facts. I
am glad that you do respond and challenge any statements made that
can't be substantiated. In this case, you were correct that there was
not enough info in the quote to assume the author was referring to our
product. I may have been reacting to other posts my "Alan Morgan" from
other threads that you were not aware of that support the idea that he
was referring to our products in his statements about new products
that claim to be less expensive.

In another thread regarding our product, "Alan Morgan" wrote:

"i can't find any PDB files. sucks."
"it is bad that you reverse-engineer full source code and make money
with it"

We responded to these statements appropriately in that thread. Thank
you again for taking the time to monitor and contribute to these
discussions and basing your arguments on logic, true facts, and
reproduceable specific examples.

Jonathan


Jon Skeet [C# MVP] <[email protected]> wrote in message

(If it incorrectly obfuscated a particular error case which had
never cropped up, the bug in obfuscation wouldn't have been seen yet.)

The obfuscated code produced by our decompiler is recompiled so incorrectly
generated code would have been seen by the compiler, and it's runtime
behavior would affect that aspect of the product's runtime

behavior,
since

we ship the recompiled version of our obfuscated code produced by
decompiling the product with itself in obfuscation mode. This is also
evidence that it supports correct COM Interop code generation

since
COM

Interop code used in the product wouldn't run correctly if the

code
was

generated incorrectly when the product was decompiled and

recompiled
prior

to distribution.

I don't see how that argument applies. Not all incorrectly generated
code will fail to compile, and it's possible that the incorrectly
generated code only occurs in one particular execution flow which has
never occurred, or which (say) subtly affects the threading so that a
previously theoretically thread-safe piece of code becomes
theoretically unsafe, even if that lack of safety is never observed.
(It's very easy to write threading code which will work on x86 but
isn't guaranteed to work on all conformant CLRs.)

I'm not saying you have such a bug - just that your reasoning of "Well,
we use our products on themselves, therefore they don't have any bugs"
is seriously flawed.

Note that no specific claims were made about *your* obfuscator

in
the

passage you quoted - only about *most* new obfuscator products.

It is always better to identify specific reproducable examples and

to
cite

specific products, rather than making inaccurate general

statements
implying

that anything new that is less expensive, buggy, and incomplete.

It didn't imply that *anything* new is buggy and incomplete. "Most"
doesn't imply "all".

I agree that it's better to be specific - I just disagree with your
logic as applied to Alan Morgan's post.

 

[Alan Morgan]

Linking in GPL terms means linking to a separate binary module.

You'd have to deploy YourProgram.exe and ZipLib.dll

"The authors of #ZipLib agreed that we could have continued to rely on and
distribute the unmodified version of their original binary distribution."

It seems to be no one is buying these tools anyway so it doesn't really
matter.

 

[Alan Morgan]

Agree. I just played with this for a few minutes and it turns out the be
rather easy to decrypt the file even for a c# newbie like me. I just ran
ildasm on your file and found that you are using TripleDES on a byte[]
stored in a resx files that got renamed to .resources . Back to the
drawing board I guess...

 

[Jonathan Pierce]

a) Fair enough. You won't achieve this by exaggerating and then arguing
about what you claim to be facts.

b) You got me wrong. The entire point of obfuscation is to make it
impossible to decompile (worse recompile) the code. This is not an advantage
of your product, it's a disadvantage.

c) Read some introductionary business books that explain the difference
between competitors and partners and what is meant by managing dependencies.

a) Let me repeat that none of claims about our products have been
exaggerated and all of them including the superior level of support
that we provide can be measured and supported by our customers
experience.

b) Some of our customers have chosen our product over the others and
told us that they consider the ability to recompile the obfuscated
code an advantage.

c) You should be able to be more specific about what you are talking
about rather than hiding behind vague business terminology. If have
something specific to say about a specific partner relationship that
we have made, then you should be able to identify it so we can discuss
it intelligently rather that continueing to make generalized and vague
argumentative statements that indicate that you have no supporting
evidence for them. I hope that you are not considering a career in the
legal profession.

 

[Jonathan Pierce]

Agree. I just played with this for a few minutes and it turns out the be
rather easy to decrypt the file even for a c# newbie like me. I just ran
ildasm on your file and found that you are using TripleDES on a byte[]
stored in a resx files that got renamed to .resources . Back to the
drawing board I guess...

Alan,

The encrypted data is also in a proprietary archive format, and the
contents have also obfuscated first. These extra levels of indirection
are just intended to be an extra level of protection on disk to make
it more difficult for casual hackers. Clearly it will be more secure
once trusted computing hardware is available.

You are obviously wasting much more of yours and our time than it
would cost you to just purchase a license to our product if you are so
interested in it.

Let me remind you that we are also rely on licensing schemes and
utilize the legal system as necessary to protect our intellectual
property. I strongly suggest that you not continue in your efforts to
hack our product further since you have already admitted that you have
violated our license agreement when you disassembled our product. You
agreed to our license when you downloaded the product and again when
you accepted the agreement in the about box when you launched it which
you admitted in earlier posts. You may want to consult your lawyer
before proceeding in continuing to violate our license agreement and
admit it in public forums.

Jonathan

 

[Alan Morgan]

Sorry :-( -- I deleted the files already and uninstalled your product.

"Alan Morgan" <[email protected]> wrote in message

Agree. I just played with this for a few minutes and it turns out the be
rather easy to decrypt the file even for a c# newbie like me. I just ran
ildasm on your file and found that you are using TripleDES on a byte[]
stored in a resx files that got renamed to .resources . Back to the
drawing board I guess...

Alan,

The encrypted data is also in a proprietary archive format, and the
contents have also obfuscated first. These extra levels of indirection
are just intended to be an extra level of protection on disk to make
it more difficult for casual hackers. Clearly it will be more secure
once trusted computing hardware is available.

You are obviously wasting much more of yours and our time than it
would cost you to just purchase a license to our product if you are so
interested in it.

Let me remind you that we are also rely on licensing schemes and
utilize the legal system as necessary to protect our intellectual
property. I strongly suggest that you not continue in your efforts to
hack our product further since you have already admitted that you have
violated our license agreement when you disassembled our product. You
agreed to our license when you downloaded the product and again when
you accepted the agreement in the about box when you launched it which
you admitted in earlier posts. You may want to consult your lawyer
before proceeding in continuing to violate our license agreement and
admit it in public forums.

Jonathan

 

[Alan Morgan]

b) Some of our customers have chosen our product over the others and

told us that they consider the ability to recompile the obfuscated
code an advantage.

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?

 

[Jon Skeet [C# MVP]]

b) You got me wrong. The entire point of obfuscation is to make it
impossible to decompile (worse recompile) the code.

No, that's *not* the entire point of obfuscation, in my view. The point
of obfuscation is to vastly reduce the value of decompiled code - make
it unintelligible to the point that it would take more effort to
understand the obfuscated code than to write it from scratch.