"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
From: Huihong Luo said:
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/
Jonathan Pierce said:
"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.
