Decompiler.NET reverse engineers your CLS compliant code

[Guest]

Sorry but this was a joke to show you the kind of response that you would
have given to your own post. It is funny that suddenly you talking about
distorted perceptions.

There are 2 fundamental issues reported for your tool and 3 bug reports. You
simply ignored 3 of the issues as such and gave your own opinion rather than
listening to users (basically because you would have to admit that you tool
is mediocre). The 2 bug reports being left are minor sure but they have only
been reported to show that your tool has bugs because you claimed it
doesn't. It is easy to find more but you probably pissed people off enough
that no one will help you to do so.

The whole discussion is pointless since it is $500 mediocre against $0 cool
and original in the end. Even if some company wants to buy a high price
product for whatever reason they will go Salamander because those guys are
way more thrustworthy than you and your distored arguments.

Please stop trying to distort the perception of our product. You have
identified two tiny bugs which we have already fixed. We now once again
have no outstanding known bugs. On the other hand, we have reported over
20 bugs and reproduceable code snippets to Reflector's author and have
assisted him by confirming his fixes and testing his intemediate versions
before some of his public releases.

We do not actively search our competitors web sites looking for their test
cases, but we do notify them directly when we identify issues in their
products. We also fix any issues in our products as soon as we detect them
or they are reported to us by our customers or our competitors, or in this
case from you. We test and fix all bugs as soon as we are aware of them,
but we can't fix bugs that we don't know exist. Our product is tested on
itself and other large assemblies with every release and we ship
recompiled versions of code produced by decompiling the product with
itself with it's obfuscation feature enabled. Our competitor's products,
like ours, are developed by very small companies or development teams.
These including RemoteSoft's Salamander, Lutz Roeder's Reflector, and
Borland's Spices.NET. Our customers agree that our product is the only one
that produces code that compiles and runs correctly for all of the
assemblies that they have tried, and that they were not able to do the
same with any of our competitors products on the same assemblies.

It is not a mistake to share information you have about known bugs. We do
this for our competitors to improve the overall quality of all products in
this market, and compete with them based on the quality of the code we
produce, both in correctness, and it's high-level, and with features that
they do not offer in their products.

Thank you again for reporting these minor bugs to us. Please let us know
in the future if you identify any more so we can fix them. Please do not
make false general claims about the existence of lot's of bugs that you
are unwilling to discuss as reproduceable test cases, since we have many
customers who use our product with no problems, and statements that you
make that cannot be backed up by examples only serve as libelous knowingly
false attempts to discredit our products and distort the market perception
of them with inaccurate information that is a disservice to developers who
need them. If you don't like our product, don't use it, but stop posting
spam messages that waste everyone else's time since they only serve to
generate further publicity about the usefulness and completeness of our
product which is apparently not one of your goals.

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

Thank you for admiting that your product has serious issues with
scenarios that competitive
products have been able to address. Your competitors have been so kind to
release those
very important examples on their websites but you have been completly
unable to address
them in your product. Your customer support is not even aware of those
issues and your
company seems to be unable to ensure quality of the existing products by
hiring testers.

[...]

Thanks <a> for identifying these obscure test cases that Salamander
uses.

<a> wrote in message I've posted some links with code examples above, hope this helps.



Out of almost 200 messages in this thread, this it probably the first
focused reproduceale technical issue. As I said, we fix any bugs as soon
as they are reported so that we can maintain our status of having no
outstanding known bugs. You have identified two very minor bugs related
to formatting constant value doubles and nested arrays. We'll fix these
in the next day or so and post an updated version. By the way, we do
have a completed version with Whidbey support but it relies on the 2.0
runtime, so we haven't shipped it yet. It does decompile assemblies from
1.0, 1.1, and 2.0 versions and we will be releasing it soon as a beta
version since it relies on the beta version of the framework.

We will post an updated version in the next day or so that fixes these
issues that you have idenitified. We've reported more than 20 bugs to
our competitors about their products, so it's nice to get one reported
to us.

Jonathan

 

[Jonathan Pierce]

Sorry but this was a joke to show you the kind of response that you would
have given to your own post. It is funny that suddenly you talking about
distorted perceptions.

Your attempted jokes make it difficult for everyone here to know what you
are referring to.

There are 2 fundamental issues reported for your tool

Please identify them again for me since I don't know what you are referring
to. As far as Whidbey support goes, we do have a version that fully supports
all Whidbey constructs but requires the not yet released 2.0 runtime so we
can't make it our official product ion release yet. I don't know what other
issues you are referring to.

and 3 bug reports. You simply ignored 3 of the issues as such and gave your
own opinion rather than listening to users

We constantly solicit feedback and listen to users.

. The 2 bug reports being left are minor sure but they have only been
reported to show that your tool has bugs because you claimed it doesn't.

We never said that it wasn't possible for a bug to exist in our product. We
said that we have fixed any bugs that we know about whether we found them or
customers reported them to us.

It is easy to find more but you probably pissed people off enough

No one is pissed off here and everyone knows that all software may
potentially contain bugs. The important thing is that the bugs don't remain
outstanding and that customers are fully satisfied with resolutions that we
provide immediately to them to resolve any questions or issues that they
encounter.

The whole discussion is pointless since it is $500 mediocre against $0
cool

Our customers feel that our product is also cool and superior to the older
ones that you keep referring to.

Even if some company wants to buy a high price product for whatever
reason they will go Salamander because those guys are way more
thrustworthy than you and your distored arguments.

Both our product and RemoteSoft's Salamander product serve a critical need
for the developer community by providing tools that customers feel provide
value to them that more than justifies their cost. We have intentionally
priced our product much lower than RemoteSoft to make it accessible to small
developers who might have other constraints that prevent them from
purchasing it. Most of our customers are business users who save money for
their employers by purchasing tools like ours that save them time whuch has
a real cost to their employers as well.

What is your reason for attempting to remain anonymous by using a generic
email address? This gives the impression that your posts are more likely to
contain inappropriate content and are not credible or even worth reading. If
you were willing to stand behind any of the statements that you keep making,
you would be willing to identify yourself openly and not be afraid to be
help accountable as I have done here.

Jonathan

 

[Guest]

It is not a mistake to share information you have about known bugs.

In your case it is a mistake. You can't admit failure.

 

[Guest]

Please identify them again for me since I don't know what you are
referring
to. As far as Whidbey support goes, we do have a version that fully
supports all Whidbey constructs but requires the not yet released 2.0
runtime so we can't make it our official product ion release yet. I don't
know what other issues you are referring to.

1) $500
2) Limited .NET Compact Framework support
3) No Whidbey support (your future solution even if available is still
behind competitors)
4) No support for security attributes

 

[Nak]

Jonathan,

don't want to have to waste their own time arguing with you, but I'm sure
that the majority of the people in this newsgroup and the ones reading
this thread would like you, Nak, and <a> to just go away from this thread,
this group, and any news server that they are interested in for it's
technical content

Hahaha, your opinion alone is not worth even being sniffed at, I have
asked if anyone else has problems with myself in a completely separate
thread, and there doesn't appear to be. I have used this newsgroup allot,
and I hope that my posts help others, as even if I find the answer myself I
still post a reply to my initial question, as weird as that might seem. I
also contribute quite allot of code to the open source community. I have
also helped others extend the functionality of their Standard VB.NET
products, so my posts aren't completely useless. But I haven't helped the
software world as much as you claim to have, so got any tips for a little
guy?

By the way, I had a junk email the other day that I should forward on to
you, it was about buying prescription meds online, apparently Valium is
good for people who have disorders with similar symptoms to what you are
showing. Though I may be wrong, you appear to be a little tense. But
anyway, such is life, we all live and learn.

I have 1 really big tip that you should pay attention too.

* This thread is doing *nothing* for you, so let it die!

Nick.
(Without prejudice)

 

[Nak]

Jonny boy,

Your attempted jokes make it difficult for everyone here to know what you
are referring to.

Nope, your lack of a sence of humour prevents that.

Please identify them again for me since I don't know what you are
referring to. As far as Whidbey support goes, we do have a version that
fully supports all Whidbey constructs but requires the not yet released
2.0 runtime so we can't make it our official product ion release yet. I
don't know what other issues you are referring to.

NO!, Don't you get it?!?! This is NOT a newsgroup for your company! Go
and discuss bugs in your software elsewhere!

I was going to reply to more of your post but I can't be bothered to
read it, your posts are too long winded.

Nick.
(Without prejudice)

 

[Nak]

Happy V-[M.P.D.L.V] Day!!!

Very - [Manic.Posessive.Depresive.Longing.Valium]?

Nick.
(Without prejudice)

 

[CJ Taylor]

In WWII we had V.E. Day [Victory in Europe]

Today..

We have Victory in Microsoft.Public.DotNet.Languages.VB!!!

Happy V-[M.P.D.L.V] Day!!!

Very - [Manic.Posessive.Depresive.Longing.Valium]?

Nick.
(Without prejudice)

 

[Nak]

LOL, happy VMPDLV day then!

Nick.

In WWII we had V.E. Day [Victory in Europe]

Today..

We have Victory in Microsoft.Public.DotNet.Languages.VB!!!

Happy V-[M.P.D.L.V] Day!!!

Very - [Manic.Posessive.Depresive.Longing.Valium]?

Nick.
(Without prejudice)

 

[William Stacey [MVP]]

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

 

[Sam Jost]

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind
of
encryption may work with the clr the only thing that could unencrypt it.

a real good compile time optimizer would be good. Optimized code would be
tougher to decompile.

You still would see lib calls, but hey, you can see those in compiled c++ as
well.

If the CLR can decrypt something there will be tools coming doing that, too,
I see no future down that road.

Sam (just my 2 cent)

 

[Joep]

Long ago I tried something that consisted of blocks. Those blocks were used
as a key to decrypt the next block. Simply disassembling it was not enough.
Putting in INT3 and the like got me only a few blocks but not all of them so
I failed there.
If some critical core used a similar scheme what would that mean to
debuggers? I don't know if that is feasible.

Another thing I was not able to break Cops CopyLock II, even though I
rewrote the bios int 13 and related stuff. This one used a diskette with a
different sector layout and it checked whether the layout was ok (a normal
copy creates a normal layout, not the one on the key disk). This is a no go
but I liked to mention it anyway.

Well, I think making it harder is all one can do unless hardware is
involved.

Just my thought...

 

[Robert Jordan]

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

 

[Jonathan Pierce]

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind
of
encryption may work with the clr the only thing that could unencrypt it.

Hi William,

The CLR needs to decrypt the assembly in memory in order to execute the
code. Without trusted hardware, you can't prevent someone from dumping
memory or running a seperate process in the same memory space that grabs the
unencrypted code. Trusted hardware will ensure that only the OS can access
it's private memory space and prevent other processes or devices from
running concurrently in the same space. That being said, we do offer a
product that protects your assemblies on disk using encryption technology
and packages encrypted versions of them in a seperate loader application as
an embedded resource. We use it as a second level of protection on our
products after we obfuscate them. You can download a fully functional trial
version of our Deploy.NET product intended for this purpose from the
products page on our web site at http://www.junglecreatures.com/

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

 

[Richard Blewett [DevelopMentor]]

if it used an asymetric algorithm (encryption key <> decryption key) then the CLR would only need the decryption key so it wouldn't be a problem as that is how PPK encryption works now (or one flavour of it) everyone has the decryption key only one party can encrypt. However, with this prize a cherry on offer it would be brute forced very quickly I would assume (you could get loads of samples to base your brute force on my submitting loads of assemblies to be signed)

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

 

[Robert Jordan]

Hi Richard,

if it used an asymetric algorithm (encryption key <> decryption key) then the CLR would only need the decryption key so it wouldn't be a problem as that is how PPK encryption works now (or one flavour of it) everyone has the decryption key only one party can encrypt. However, with this prize a cherry on offer it would be brute forced very quickly I would assume (you could get loads of samples to base your brute force on my submitting loads of assemblies to be signed)

I *thought* about asymetric encryption but did't wrote it ;-)

- the assembly gets encrypted with my private key and with MS public key
- my public key gets attached to the assembly
- the CLR unencrypts the assembly using my public key and
the MS private key, which has to be deployed with every
CLR, right?

I was talking about that MS private key. No way to secure it.

thanks

bye
Rob

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

 

[Robert Jordan]

Hi Jonathan,

Hi William,

The CLR needs to decrypt the assembly in memory in order to execute the
code. Without trusted hardware, you can't prevent someone from dumping
memory or running a seperate process in the same memory space that grabs the
unencrypted code. Trusted hardware will ensure that only the OS can access
it's private memory space and prevent other processes or devices from
running concurrently in the same space. That being said, we do offer a
product that protects your assemblies on disk using encryption technology
and packages encrypted versions of them in a seperate loader application as
an embedded resource. We use it as a second level of protection on our
products after we obfuscate them. You can download a fully functional trial
version of our Deploy.NET product intended for this purpose from the
products page on our web site at http://www.junglecreatures.com/

Your product is probably better then "just obfuscated",
but the assemblies must be unencripted to be executed,
unless you replaced parts of the CLR, which I don't belive.
That's the momement when they can be dumped.
Anyway, I wish you a lot of paranoid customers ;-)

bye
Rob

 

[Richard Blewett [DevelopMentor]]

If you could send the assembly to MSFT to get signed with their private key then only the public key woul dneed to ship with the CLR. I thought thats what you suggested with hte Microsoft Remoting encrytping service.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi Richard,

if it used an asymetric algorithm (encryption key <> decryption key) then the CLR would only need the decryption key so it wouldn't be a problem as that is how PPK encryption works now (or one flavour of it) everyone has the decryption key only one party can encrypt. However, with this prize a cherry on offer it would be brute forced very quickly I would assume (you could get loads of samples to base your brute force on my submitting loads of assemblies to be signed)

I *thought* about asymetric encryption but did't wrote it ;-)

- the assembly gets encrypted with my private key and with MS public key
- my public key gets attached to the assembly
- the CLR unencrypts the assembly using my public key and
the MS private key, which has to be deployed with every
CLR, right?

I was talking about that MS private key. No way to secure it.

thanks

bye
Rob

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

 

[Robert Jordan]

Hi Richard,

If you could send the assembly to MSFT to get signed with their private key then only the public key woul dneed to ship with the CLR. I thought thats what you suggested with hte Microsoft Remoting encrytping service.

Supposing the MSFT public key is really "public",
then everybody would be able to unencrypt the assembly, isn't it?
I thought we wanted to prevent that.

bye
Rob

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi Richard,

if it used an asymetric algorithm (encryption key <> decryption key) then the CLR would only need the decryption key so it wouldn't be a problem as that is how PPK encryption works now (or one flavour of it) everyone has the decryption key only one party can encrypt. However, with this prize a cherry on offer it would be brute forced very quickly I would assume (you could get loads of samples to base your brute force on my submitting loads of assemblies to be signed)

I *thought* about asymetric encryption but did't wrote it ;-)

- the assembly gets encrypted with my private key and with MS public key
- my public key gets attached to the assembly
- the CLR unencrypts the assembly using my public key and
the MS private key, which has to be deployed with every
CLR, right?

I was talking about that MS private key. No way to secure it.

thanks

bye
Rob

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

 

[CJ Taylor]

That's not how public keys work. PKI uses a Public Key and Private Key
combination. A Public key can encrypt data, while a private key can encrypt
and decrypt.

It's all done through prime numbers, really really really really really big
prime numbers that are added together to make the key pair. Hence the
conundrum of PKI that you have half of what you need to crack it, however,
trying to do so is either pure luck or brute force.

I mean REALLY big prime numbers.

----

Responding to Williams comments. I have actually thought about this as
well. And true microsoft would have to have a single key using asymm enc...
Or you could do something how RSA does it's SecureID's using a Half Life
Formula of some material (I don't know what they use or how they seed it).
And that would prevent using the same key over and over. However... that
could be really expensive...

Just my thoughts.

-CJ

Hi Richard,

key then only the public key woul dneed to ship with the CLR. I thought
thats what you suggested with hte Microsoft Remoting encrytping service.

Supposing the MSFT public key is really "public",
then everybody would be able to unencrypt the assembly, isn't it?
I thought we wanted to prevent that.

bye
Rob

then the CLR would only need the decryption key so it wouldn't be a problem
as that is how PPK encryption works now (or one flavour of it) everyone has
the decryption key only one party can encrypt. However, with this prize a
cherry on offer it would be brute forced very quickly I would assume (you
could get loads of samples to base your brute force on my submitting loads
of assemblies to be signed)

I *thought* about asymetric encryption but did't wrote it ;-)

- the assembly gets encrypted with my private key and with MS public key
- my public key gets attached to the assembly
- the CLR unencrypts the assembly using my public key and
the MS private key, which has to be deployed with every
CLR, right?

I was talking about that MS private key. No way to secure it.

thanks

bye
Rob

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

Hi William,

Just a random thought...
Forget about obfuscators for one minute. What are some other ideas on
protecting code that would work with the CLR (or not) to protect your code
so it could not be decompiled? I had thought at one time that some kind of
encryption may work with the clr the only thing that could unencrypt it.

This shouldn't be a big problem, but since all assemblies will be
encrypted with the same key(s) (otherwise the CLR wouldn't be able
to unencrypt them), I bet the key(s) will be cracked within days.

Even when those assemblies were encrypted by MS (using some
fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
contain the decryption keys somewhere.

It's not worthwhile.

bye
Rob

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004



[microsoft.public.dotnet.framework]