http://www.junglecreatures.com/
Try it and tell me what's happenning in the Microsoft Corporation.
Notes:
VB, C# are CLS compliant
You can also use managed code with C++
Using what they call obfuscator, will not help you for a long time.
For each new obfuscator there will allways exist a new deobfuscator.
Your source's Symbols are written unchanged in the exe or dll file.
Looking to your Symbols, it's easy to understand your Source Code.
A honest compiler does not expose any Symbols, unless you Export them.
I like VB, it is an easy yet powerfull language, but it's good for
nothing else but studying or playing.
Nov 21 '05
245  7334 
=) With the assumption everyone here is an american
"Nak" <a@a.com> wrote in message
news:eT**************@TK2MSFTNGP14.phx.gbl... CJ,
You realize of course you will be deemed an "uncredible" source since
you proved his product doesn't work as well...
You can't say that!
Law suit law suit law suite, so on and so fourth and such like...
Nick.
"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
news:uc**************@TK2MSFTNGP09.phx.gbl... now thats funny...
;)
And the loop continues... ahhh...
=)
<a> wrote in message news:ep*************@TK2MSFTNGP14.phx.gbl... My testing shows that original Reflector creates better code and crash
less as your tool .
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:0z********************@twister.nyc.rr.com...
>
> "Rick" <nospam> wrote in message
> news:us**************@TK2MSFTNGP11.phx.gbl...
>
>> Your Reflector tool will cost $500 compared to the real Reflector
tool >> which free?
>
> Our customers prefer the decompilation capability offered by the real
> Decompiler.NET.
>
> Our product has many other capabilities that Reflector doesn't
include, > and we have many more planned. Some of our customers have requested
an > ability to browse assemblies simiilar to the way the class browser in
> Visual Studio and other decompiler tools like Reflector allow. The
prmary > value in our Decompiler is it'c core decompilation capability that
> produces higher level and more accurate code that Reflector, so we
> would
> also have to add our decompiler to it, and all of our other features
like > our refactoring tools, and wouldn't be retaining much from it's
> original
> value aside from it's user interface and plugin architecture. We
prefer to > continue to sell our products as standalone tools and soon integrated
into > Visual Studio when 2005 ships.
>
> Jonathan
>
Please provide a specific example. We have no known outstanding bugs, and we
recognize many constructs in code that Reflector misses. A good example is
our elimination of goto statements in switch cases that Reflector does not
eliminate. There are many other examples and we look forward to discussion
reproduceable test cases with you.
Jonathan
<a> wrote in message news:ep*************@TK2MSFTNGP14.phx.gbl... My testing shows that original Reflector creates better code and crash
less as your tool .
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:0z********************@twister.nyc.rr.com...
"Rick" <nospam> wrote in message
news:us**************@TK2MSFTNGP11.phx.gbl...
Your Reflector tool will cost $500 compared to the real Reflector tool
which free?
Our customers prefer the decompilation capability offered by the real
Decompiler.NET.
Our product has many other capabilities that Reflector doesn't include,
and we have many more planned. Some of our customers have requested an
ability to browse assemblies simiilar to the way the class browser in
Visual Studio and other decompiler tools like Reflector allow. The prmary
value in our Decompiler is it'c core decompilation capability that
produces higher level and more accurate code that Reflector, so we would
also have to add our decompiler to it, and all of our other features like
our refactoring tools, and wouldn't be retaining much from it's original
value aside from it's user interface and plugin architecture. We prefer
to continue to sell our products as standalone tools and soon integrated
into Visual Studio when 2005 ships.
Jonathan
> I tried assembly with security attribute and Reflector shows the right attribute while other tool doesn't.
Decompiler.NET does generate custom attributes including security
attributes. However, our implementation relies on Reflection and is not
designed to bypass security or obfuscation techniques in the assembly
intentionally designed to prohibit such access. Please provide a specific
example.
Jonathan
> =) With the assumption everyone here is an american
We have made no such assumption. There are international piracy and libel
laws as well, and we are aware of and can prove both CJ and Nak's
identities.
Jonathan
HA!
Wow, well you just have everything covered then don't ya!
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:3r*******************@twister.nyc.rr.com... =) With the assumption everyone here is an american
We have made no such assumption. There are international piracy and libel
laws as well, and we are aware of and can prove both CJ and Nak's
identities.
Jonathan
No known bugs?!
Well! I guess you've done it.. You've invented the perfect software!
Well done!
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:Ml******************@twister.nyc.rr.com... Please provide a specific example. We have no known outstanding bugs, and
we recognize many constructs in code that Reflector misses. A good example is
our elimination of goto statements in switch cases that Reflector does not
eliminate. There are many other examples and we look forward to discussion
reproduceable test cases with you.
Jonathan
<a> wrote in message news:ep*************@TK2MSFTNGP14.phx.gbl... My testing shows that original Reflector creates better code and crash
less as your tool .
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:0z********************@twister.nyc.rr.com...
"Rick" <nospam> wrote in message
news:us**************@TK2MSFTNGP11.phx.gbl...
Your Reflector tool will cost $500 compared to the real Reflector tool
which free?
Our customers prefer the decompilation capability offered by the real
Decompiler.NET.
Our product has many other capabilities that Reflector doesn't include,
and we have many more planned. Some of our customers have requested an
ability to browse assemblies simiilar to the way the class browser in
Visual Studio and other decompiler tools like Reflector allow. The
prmary value in our Decompiler is it'c core decompilation capability that
produces higher level and more accurate code that Reflector, so we
would also have to add our decompiler to it, and all of our other features
like our refactoring tools, and wouldn't be retaining much from it's
original value aside from it's user interface and plugin architecture. We prefer
to continue to sell our products as standalone tools and soon
integrated into Visual Studio when 2005 ships.
Jonathan
Try these files: http://www.remotesoft.com/salamander...zerDemo.cs.txt http://www.remotesoft.com/salamander...ralTest.cs.txt
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:_p******************@twister.nyc.rr.com... I tried assembly with security attribute and Reflector shows the right
attribute while other tool doesn't.
Decompiler.NET does generate custom attributes including security
attributes. However, our implementation relies on Reflection and is not
designed to bypass security or obfuscation techniques in the assembly
intentionally designed to prohibit such access. Please provide a specific
example.
Jonathan
I've posted some links with code examples above, hope this helps.
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:Ml******************@twister.nyc.rr.com... Please provide a specific example. We have no known outstanding bugs, and
we recognize many constructs in code that Reflector misses. A good example
is our elimination of goto statements in switch cases that Reflector does
not eliminate. There are many other examples and we look forward to
discussion reproduceable test cases with you.
Jonathan
<a> wrote in message news:ep*************@TK2MSFTNGP14.phx.gbl... My testing shows that original Reflector creates better code and crash
less as your tool .
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:0z********************@twister.nyc.rr.com...
"Rick" <nospam> wrote in message
news:us**************@TK2MSFTNGP11.phx.gbl...
Your Reflector tool will cost $500 compared to the real Reflector tool
which free?
Our customers prefer the decompilation capability offered by the real
Decompiler.NET.
Our product has many other capabilities that Reflector doesn't include,
and we have many more planned. Some of our customers have requested an
ability to browse assemblies simiilar to the way the class browser in
Visual Studio and other decompiler tools like Reflector allow. The
prmary value in our Decompiler is it'c core decompilation capability
that produces higher level and more accurate code that Reflector, so we
would also have to add our decompiler to it, and all of our other
features like our refactoring tools, and wouldn't be retaining much from
it's original value aside from it's user interface and plugin
architecture. We prefer to continue to sell our products as standalone
tools and soon integrated into Visual Studio when 2005 ships.
Jonathan
Original: [assembly: SecurityPermission(SecurityAction.RequestMinimum,
Assertion=true)]
Reflector: [assembly: SecurityPermission(SecurityAction.RequestMinimum,
Assertion=true)]
Decompiler.NET: not working.
This is not about prohibiting access, it simply doesn't work.
Decompiler.NET also fails to open .NET Compact Framework assemblies.
Decompiler.NET doesn't work on Whidbey assemblies either.
You say "no known outstanding bugs", well maybe you just dont have any users
reporting them?
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:_p******************@twister.nyc.rr.com... I tried assembly with security attribute and Reflector shows the right
attribute while other tool doesn't.
Decompiler.NET does generate custom attributes including security
attributes. However, our implementation relies on Reflection and is not
designed to bypass security or obfuscation techniques in the assembly
intentionally designed to prohibit such access. Please provide a specific
example.
Jonathan
Thanks <a> for identifying these obscure test cases that Salamander uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl... 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
> Out of almost 200 messages in this thread, this it probably the first focused reproduceale technical issue.
Because that was why the thread was started?
Last I checked this wasn't news.junglecreatures.net and certainly not
alt.junglecreatures.support.
CJ,
This thread is supposed to be about issues with decompiler capabilities as
they relate to the .NET Framework. I didn't start the thread, but I
centainly should respond to posts that directly reference our product. Since
our product is mentioned in the title of the thread, you probably don't need
to keep reading it if you are not interested in it, but the non-techical
comments that you keep posting to this thread wastes the time of anyone who
is generally interested in the topic. I will be happy to discuss technical
issues with you, but please stop posting derogatory and inappropriate
non-technical messages that waste the time of everyone here and distort the
accurate perception of our products and company.
Jonathan
"CJ Taylor" <[cege] at [tavayn] dit commmmm> wrote in message
news:Oe**************@TK2MSFTNGP09.phx.gbl... Out of almost 200 messages in this thread, this it probably the first
focused reproduceale technical issue.
Because that was why the thread was started?
Last I checked this wasn't news.junglecreatures.net and certainly not
alt.junglecreatures.support.
> > see it as tying to a specific machine. What happens if you go out of business in 2 years?
That won't happen. We're also only charging $500, not 5 million. There is
as much of a risk that you may get hit by a bus tomorrow and won't need the
software anymore.
How do you know that won't happen? Because you don't want it to? There
have been many many 3rd parties and small software vendors and large ones
that have come and gone. I'm not saying that will happen to you, but I'm
saying the possibility exists. For as long as the use of the software
depends on the existence of the vendor, that software has a very high risk
of becoming useless in the unfortunate case that the vendor dissappears.
Again, I'm not saying it will happen to you, but there aren't many software
vendors that don't eventually go the way of the do-do bird without becoming
the largest entity in the niche you are targeting or being purchased by a
larger company. Who's to say that larger company will continue to support
the product?
If the licensing didn't require such a strict lockdown, it wouldn't be a
problem. But because the ability to use the software depends on a
particular companies existance, it is a very high risk for me to purcahse
*any* product that follows suit (not just yours). Alos, with new laws being
passed every day, you could become outlawed and thus, out of business, or
arrested, or whatever, for providing a tool that can potentially be used
maliciously for whatever reason the media/software industry decides is
harmful to them... they have a powerful lobby, how powerful is yours?
The point is it is a risk to spend any money on software that depends on the
vendors existence to continue usage. A risk that it too great for my pocket
book. Nothing personal.
Besides, I didn't say I'd write my own decompiler, I just said if it was
that important I could, I'm more than capable, its just not a priority
and since I don't decompile non System.* assemblies, the price is not
justifyable.
We spent over two years writing ours. I imaging that two years of your
time is worth more to you than the $500 we charge for a license which our
costomers feel is a tremendous value to them.
I don't doubt you spent 2 years on this. My time is worth more, but then
again, since I only occasionaly review the System.* namespaces, $500 isn't
worth it to me. If I was going to look at some proprietary code other than
System.*, perhaps it would be. But if I was going to do that, I would just
create my own version and learn how to imitate a feature and learn from it,
rather than "cheat" and take the easy way out. Of course, since I'm
dependant on the System.* namespaces, I have no problem examining something
when I'm not sure about the documentation. Would I pay $500 for that? No.
It isn't *that* important. With Reflector, it is a convenience that I
exploit. Nothing more.
There's always Mono, but I'm much less inclined to actually look at GPL code
(I generally avoid it for reasons I won't discuss in this thread). Besides
that, Mono may not be programmed exactly the way that the System.* classes
are.
I'm not fine with being actively dependant on a vendor in
order to keep using the software despite all of my requirements.
You are not if you don't replace your motherboard or machine itself. Tivo
doesn't even let you move your lifetime subscriptions to newer hardware
that they themselves sell.
I don't use Tivo so I wouldn't know. But we're not talking about hardware
here, we're talking about software.
I just happen to dissagree
with that kind of licensing. It does nothing to keep prices low
Pirated copied cause vendots to raise their prices for their software
since their target market is cannibalized. Locking down licensed copies to
hardware reduces the amount of software piracy and therefore does keep
prices lower that without it.Although you may feel that $500 is high, we
intenitionally priced our product much lower than the cost to develop it
to make it accessible to small developers like yourself who might benefit
from it. If Reflector also charged $500 and there weren't any free choices
available with relatively good decompilation capability, you would
probably feel differently towards our product and be glad that a product like it
was available to you instead of having to invest the two years yourself trying
to write your own decompiler that works as well.
Name one commercial product that every lowered its price because they got
piracy under control. No, what actually happens is they complain more and
then justify the higher prices because they have to spend more money on R&D
to contantly come up with new anti-piracy measures. Now that they have the
average user inconvenienced and have thwarted "casual" sharing, prices
aren't any lower than they were previously. But the true pirate still has
no problems getting around it.
Again, if Reflector wasn't free, I agree, I wouldn't be using it. I
wouldn't be purchasing any tool to do the job, anyway. I can read IL, I
would be inconvenienced, but I can do it (I program in it sometimes, probly
because I program Win32 in assembly also) but, if I wasn't "restricted" to
my initial machine which changes often and "dependant" on a vendor, I might
consider it.
But since we're going in circles here, there's no more point in elaborating
why I don't purchase your product or any other that causes me to be
dependant on them and screwed, blued, and tattoo'd if they go out of
business. You obviously feel justified and confident in your product and
licensing terms, and I obviously feel like it creates a severe financial
risk for me to use the product and nothing is going to change that. If the
entire software industry follows suit, I'll use less software or will
eventually move to Free software (free as in beer, free as in speech)
because I just happen to refuse dependance on any particular non-Microsoft
software vendor. It has nothing to do with you, it has everything to do
with my freedom and getting value out of my hard-earned money.
Thanks,
Shawn
> We have made no such assumption. There are international piracy and libel laws as well, and we are aware of and can prove both CJ and Nak's
identities.
LOL, And if push came to shove Jonathan I could probably prove who put my
personal information on this web site without my prior consent. Thus
breaking the data protections act, which may I inform you, works for you
Americans also.
I can't believe your still on your high horse about something that didn't
happen. *I* appologised for upsetting you *and* your product, but you carry
on thinking you have won some great battle! Jonathan, listen, there was no
battle, there was no law suite, get over it!
Nick.
(without predjudice)
Happy V-[M.P.D.L.V] Day!!!
"Nak" <a@a.com> wrote in message
news:Od*************@TK2MSFTNGP11.phx.gbl... We have made no such assumption. There are international piracy and
libel laws as well, and we are aware of and can prove both CJ and Nak's
identities.
LOL, And if push came to shove Jonathan I could probably prove who put my
personal information on this web site without my prior consent. Thus
breaking the data protections act, which may I inform you, works for you
Americans also.
I can't believe your still on your high horse about something that didn't
happen. *I* appologised for upsetting you *and* your product, but you
carry on thinking you have won some great battle! Jonathan, listen, there was
no battle, there was no law suite, get over it!
Nick.
(without predjudice)
Please stop twisting the facts as you need them.
It doesnt matter if you fix those bugs or not - Decompiler.NET not needed.
It is simply a $500 piece of mediocre software that is lightyears behind the
Reflector.
It was definetly a mistake to report those bugs...
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:pU********************@twister.nyc.rr.com... Thanks <a> for identifying these obscure test cases that Salamander uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl... 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
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.
[...]
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:pU********************@twister.nyc.rr.com... Thanks <a> for identifying these obscure test cases that Salamander uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl... 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
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/
<a> wrote in message news:Od**************@tk2msftngp13.phx.gbl... 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.
[...]
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:pU********************@twister.nyc.rr.com... Thanks <a> for identifying these obscure test cases that Salamander uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl... 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
> It is simply a $500 piece of mediocre software that is lightyears behind the Reflector.
This is your own opinion. Our customers feel differently and we have sold
several copies this week to customers who have told us that the code we
produce is far better both in correctness, and it's high level than the code
that Reflector produces for them. We have also just added a browser user
interface to our latest version, have finished our development of our
version that supports Whidbey, and will be releasing Visual Studio
integration features soon. We also include obfuscation features which
Reflector does not have, and a Refactoring Add-On option that provides
automatic refactoring and analysis capabilities not offered by Visual Studio
alone.
We appreciate continuing these discussions with you since your posts assist
us by creating further opportunities to provide accurate information about
how our products can assist developers and serve those developers interested
in the subject of decompilation and obfuscation in these newsgroups.
Jonathan Pierce
President
Jungle Creatures, Inc. http://www.junglecreatures.com/
Email: su*****@junglecreatures.com
"Bobby Wietzel" <bm*@usps.com> wrote in message
news:ul**************@TK2MSFTNGP14.phx.gbl... No known bugs?!
Well! I guess you've done it.. You've invented the perfect software!
Well done!
Thanks Bobby for the compliments regarding the quality of our software. We
continuously test our products on themselves and fix any issues that we are
aware of before we ship each release.
Known bugs are defined as bugs that we are aware of either by discovering
them ourselves of having them reported to us by customers and trial users of
our product. We fix all bugs as soon as we are made aware of them. We never
said that the software was perfect, only that all of our customers and trial
users are able to use it 100% and have no outstanding issues or have not
reported them to us. If you have any specific issues to report to us, please
send them to us via email at su*****@junglecreatures.com and we will release
a new version to address any concrete issues that you identify immediately.
Jonathan
> Please stop trying to distort the perception of our product. You have identified two tiny bugs which we have already fixed.
Isn't that a matter of perspective? tiny to you... perhaps could have cost
a business money... Not too small to them is it?
We now once again have
no outstanding known bugs.
Whoo!!!!
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.
Him... must be why everyone on *here* says your product is inferior. Sure
you talk about how great it is. But I would figure some high level
programmers, especially in VB would be frequent members of the microsoft
newsgroups and perhaps may even come to defend your product. But the only
thing we have seen in defense of your product is this character Vortex Soft
and yourself. I would just figure *more* people would tell myself and Nak,
"Hey, I've really put this thing through the ropes and it's a great
product". I would secede to that. But I haven't. I just hear the same
speech over and over about how many bugs you've reported to other companies,
and how you have no bugs outstanding?
So does that mean they don't exist? Of course not. There are probably MANY
bugs in your software that your not aware of. That's software. Which makes
coming on here and bragging about 100% kinda foolish. After all, aren't
there known bugs within the framework itself, which you yourself admit to
using? Particularly the reflection namespaces? In order for your software
to be perfect it would mean Microsoft's software would have to be perfect.
Windows would have to be perfect and every other dependency you have on
other modules (whether its windows, the framework, or anything else you do
not have direct control of, INCLUDING hardware) in order for you to be
perfect? Can you guaruntee that 100%?
That's a pretty tall order...
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.
Why not? I would get as much info from my competitors as I could!
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.
Microsoft is 55k+ strong... they dont develop perfect software (NOR come on
here defending it like teenager with something to prove). That's more minds
than your shop. Wouldn't you be more prone to making mistakes?
Also do you test *every* assembly?
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.
And vise versa...
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.
*clap**clap*
*clap*
*clap*
*clap**clap*
*clap**clap*
*clap**clap*
*clap**clap*
*clap*
Oh... sorry... Every time I hear a long winded speech with absolutly no
substance to it except for the same thing written *over* and *over* again I
instantly think I have to start clapping at the end. Kinda like
televangelists or anything by John Kerry...
Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
<a> wrote in message news:Od**************@tk2msftngp13.phx.gbl... 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.
[...]
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:pU********************@twister.nyc.rr.com... Thanks <a> for identifying these obscure test cases that Salamander
uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl...
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
> Isn't that a matter of perspective? tiny to you... perhaps could have cost
a business money... Not too small to them is it?
Our customers test their own software. If they encounter any code generation
issues related to using our product, they would contact us and we would
resolve the issue by releasing an updated version that corrects the issue.
The small issues that you identified such as your nested array
initialization example resulted in generated code that would expose the
issue at compile tiime. Since noone reported it, the issue either didn't
affect them, or they fixed the generated code manually and didn't tell us.
Either way, it couldn't have cost them any money and I'm sure none were
aware of it since our customers enjoy the support that we provide to them
and would not hesitate to let us know if they detected any code generation
issues.
Him... must be why everyone on *here* says your product is inferior.
The people shouting on here are you, Nak, and <a>. None of you are respected
by anyone in this group, you only post intentionally malicious messages
designed to create controversy, and have been reprimanded by several others
in this thread besides myself. All of you attempted to remain anonymous, and
continue to post intentionally false statements about our company and
product. You have even commented that you are intentionally looking to start
up non-technical arguments just for your own entertainment at the expense of
the time that you continie to waste for everyone else still reading this
thread who is really interested in decompilation technical issues. Since you
are not, you and your friends should probably leave since you are not
interested anyway in our products, and you are wasting the time of the
entire developer community reading this thread because they are interested
in the technical content that it contains and have not yet given up trying
to filter out your spam messages.
I just hear the same
speech over and over about how many bugs you've reported to other
companies,
and how you have no bugs outstanding?
You read this thread voluntarily.Since you aren't interested in our
products, and noone else wants to read your non-technical posts, then why
don't you just stop reading the thread since it's title indicates that it is
related to our product which you are not interested in. Your false negative
statements about it serve no purpose except to waste everyone's time
including your own. You and your friends should stop attacking our company
and others in public newsgroups if you goal is to not give those companies
additional exposure, but we must respond to defend our products each time
one of you posts inaccurate and misleading information that interferes with
the success of serious developers who are genuinely intersted in the
technical topics that our product addresses.
There are probably MANY
bugs in your software that your not aware of. That's software. Which
makes
coming on here and bragging about 100% kinda foolish.
We are not bragging. We are asking you to support the false claims that you
make about fiicticious bugs and negative user experiences using our
products.
After all, aren't there known bugs within the framework itself, which you yourself admit to
using? Particularly the reflection namespaces? In order for your
software
to be perfect it would mean Microsoft's software would have to be perfect.
Again, we didn't say anything about perfect, you did. If we use a 3rd party
library or part of the framework, we adapt our implementation to avoid it
and report it to Microsoft or the vendor involved. We have posted several
Whidbey related bugs to the 2005 feedback center that were confirmed and
fixed for newer builds of the 2.0 framework.
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.
Why not? I would get as much info from my competitors as I could!
We do the best we can any anyone concerned will let us know if they become
aware of any actual problem in our software as opposed to the fictitiuos
statements that you and your friends keep making here. Instead of spending
so much time creating false propaganda, you could help the developer
community by posting real bug reports that you detect in the framework or
our products.
Oh... sorry... Every time I hear a long winded speech with absolutly no
substance to it except for the same thing written *over* and *over* again
I
instantly think I have to start clapping at the end.
You should be apologizing to everyone else here whose time you keep wasting
by posting these spam messages to this technical forum that require us to
respond and defend our products against your false claims. For our benefit,
yours, and everyone elses here, please stop posting messages that continue
to waste the time of all of us here. Go ahead and lurk if you like and
contact us offline, but I don't want to continue to assist you in filling up
these newsgroups with non-technical arguments that everyone has to filter
out to find the technical information that they are looking for. I probably
should never have responded to any of you in the first place, except that
your attacks on us and our products require us to respond to defend
ourselves and diffuse your intentionally misleading statements.
In short, please write us privately if you feel it necessary, but leave
these groups to technical discussions that developers here are interested in
reading. Some of the other people here have spoken up to discourage your
inappropriate behavior here, and you have probably scared a few people who
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.
Jonathan
Wow... a trolling we will go I see... Isn't that a matter of perspective? tiny to you... perhaps could have
cost
a business money... Not too small to them is it?
Our customers test their own software. If they encounter any code
generation issues related to using our product, they would contact us and we would
resolve the issue by releasing an updated version that corrects the issue.
The small issues that you identified such as your nested array
initialization example resulted in generated code that would expose the
issue at compile tiime. Since noone reported it, the issue either didn't
affect them, or they fixed the generated code manually and didn't tell us.
Either way, it couldn't have cost them any money and I'm sure none were
aware of it since our customers enjoy the support that we provide to them
and would not hesitate to let us know if they detected any code generation
issues.
Him... must be why everyone on *here* says your product is inferior. The people shouting on here are you, Nak, and <a>. None of you are
respected by anyone in this group, you only post intentionally malicious messages
designed to create controversy, and have been reprimanded by several
others in this thread besides myself. All of you attempted to remain anonymous,
and continue to post intentionally false statements about our company and
product. You have even commented that you are intentionally looking to
start up non-technical arguments just for your own entertainment at the expense
of the time that you continie to waste for everyone else still reading this
thread who is really interested in decompilation technical issues. Since
you are not, you and your friends should probably leave since you are not
interested anyway in our products, and you are wasting the time of the
entire developer community reading this thread because they are interested
in the technical content that it contains and have not yet given up trying
to filter out your spam messages.
I just hear the same
speech over and over about how many bugs you've reported to other
companies,
and how you have no bugs outstanding? You read this thread voluntarily.Since you aren't interested in our
products, and noone else wants to read your non-technical posts, then why
don't you just stop reading the thread since it's title indicates that it
is related to our product which you are not interested in. Your false
negative statements about it serve no purpose except to waste everyone's time
including your own. You and your friends should stop attacking our
company and others in public newsgroups if you goal is to not give those companies
additional exposure, but we must respond to defend our products each time
one of you posts inaccurate and misleading information that interferes
with the success of serious developers who are genuinely intersted in the
technical topics that our product addresses.
There are probably MANY
bugs in your software that your not aware of. That's software. Which
makes
coming on here and bragging about 100% kinda foolish. We are not bragging. We are asking you to support the false claims that
you make about fiicticious bugs and negative user experiences using our
products.
After all, aren't there known bugs within the framework itself, which you yourself admit
to using? Particularly the reflection namespaces? In order for your
software
to be perfect it would mean Microsoft's software would have to be
perfect.
Again, we didn't say anything about perfect, you did. If we use a 3rd
party library or part of the framework, we adapt our implementation to avoid it
and report it to Microsoft or the vendor involved. We have posted several
Whidbey related bugs to the 2005 feedback center that were confirmed and
fixed for newer builds of the 2.0 framework.
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.
Why not? I would get as much info from my competitors as I could!
We do the best we can any anyone concerned will let us know if they become
aware of any actual problem in our software as opposed to the fictitiuos
statements that you and your friends keep making here. Instead of spending
so much time creating false propaganda, you could help the developer
community by posting real bug reports that you detect in the framework or
our products.
Oh... sorry... Every time I hear a long winded speech with absolutly no
substance to it except for the same thing written *over* and *over*
again I
instantly think I have to start clapping at the end.
You should be apologizing to everyone else here whose time you keep
wasting by posting these spam messages to this technical forum that require us to
respond and defend our products against your false claims. For our
benefit, yours, and everyone elses here, please stop posting messages that continue
to waste the time of all of us here. Go ahead and lurk if you like and
contact us offline, but I don't want to continue to assist you in filling
up these newsgroups with non-technical arguments that everyone has to filter
out to find the technical information that they are looking for. I
probably should never have responded to any of you in the first place, except that
your attacks on us and our products require us to respond to defend
ourselves and diffuse your intentionally misleading statements.
In short, please write us privately if you feel it necessary, but leave
these groups to technical discussions that developers here are interested
in reading. Some of the other people here have spoken up to discourage your
inappropriate behavior here, and you have probably scared a few people who
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.
Jonathan
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.
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:gM*******************@twister.nyc.rr.com... 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/
<a> wrote in message news:Od**************@tk2msftngp13.phx.gbl... 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.
[...]
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:pU********************@twister.nyc.rr.com... Thanks <a> for identifying these obscure test cases that Salamander
uses.
<a> wrote in message news:u4**************@TK2MSFTNGP12.phx.gbl...
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
<a> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...
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 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.
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) 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
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)
> Happy V-[M.P.D.L.V] Day!!!
Very - [Manic.Posessive.Depresive.Longing.Valium]?
Nick.
(Without prejudice)
In WWII we had V.E. Day [Victory in Europe]
Today..
We have Victory in Microsoft.Public.DotNet.Languages.VB!!!
"Nak" <a@a.com> wrote in message
news:Ox*************@tk2msftngp13.phx.gbl... Happy V-[M.P.D.L.V] Day!!!
Very - [Manic.Posessive.Depresive.Longing.Valium]?
Nick.
(Without prejudice)
LOL, happy VMPDLV day then! :-)
Nick.
"CJ Taylor" <cege [ahh ttt] tavayn wooohooo hooo ohhh com> wrote in message
news:uQ**************@TK2MSFTNGP11.phx.gbl... In WWII we had V.E. Day [Victory in Europe]
Today..
We have Victory in Microsoft.Public.DotNet.Languages.VB!!!
"Nak" <a@a.com> wrote in message
news:Ox*************@tk2msftngp13.phx.gbl... > Happy V-[M.P.D.L.V] Day!!!
Very - [Manic.Posessive.Depresive.Longing.Valium]?
Nick.
(Without prejudice)
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.
--
William Stacey, MVP
"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:#h**************@TK2MSFTNGP14.phx.gbl... http://www.junglecreatures.com/
Try it and tell me what's happenning in the Microsoft Corporation.
Notes:
VB, C# are CLS compliant
You can also use managed code with C++
Using what they call obfuscator, will not help you for a long time.
For each new obfuscator there will allways exist a new deobfuscator.
Your source's Symbols are written unchanged in the exe or dll file.
Looking to your Symbols, it's easy to understand your Source Code.
A honest compiler does not expose any Symbols, unless you Export them.
I like VB, it is an easy yet powerfull language, but it's good for
nothing else but studying or playing.
"William Stacey [MVP]" <st***********@mvps.org> wrote: 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)
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...
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
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:eL*************@tk2msftngp13.phx.gbl... 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/
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/<cj*************@news.t-online.com>
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]
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/<cj*************@news.t-online.com>
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]
Hi Jonathan, "William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:eL*************@tk2msftngp13.phx.gbl...
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/
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
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/<cj*************@news.t-online.com>
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/<cj*************@news.t-online.com>
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]
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/<cj*************@news.t-online.com>
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/<cj*************@news.t-online.com>
>
> 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]
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
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:cj*************@news.t-online.com... 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/<cj*************@news.t-online.com>
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/<cj*************@news.t-online.com> >
> 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]
Since everyone is in the mood for impractical ideas here,I have one.
For every client that you have,generate a public key and a private key. Use
the public key to encrypt the assembly. Now, here comes the really wacky
idea. Take the Rotor souce code (or pay Microsoft a lot of money to do this
for you)..and build your own mscoree/mscorwks/mscorsvr dlls which have the
private key embedded in them. If you're really paranoid, you can do
something like Windows Activation and make sure that the CLR works properly
only on some hardware hashes.
Now, these runtimes will work normally with normal applications - but will
recognize your specially encrypted assembly and decrypt it using the private
key. This way, we make sure that every assembly runs *only* in its very own
version of the CLR. So when you send customers the assemblies, you send them
your custom CLR as well. Yes - this would inflict all sorts of versioning
conflicts on them - but you can sleep assuredly at night with the knowledge
that no one else can get at your code.
You know what the scary part is? That some paranoid person reading this post
might actually take this seriously and try it out. And even worse, somebody
somewhere will always find a way to get the public key out of our custom CLR
and crack your assembly.
--
Sriram Krishnan http://www.dotnetjunkies.com/weblog/sriram
"CJ Taylor" <cege [ahh ttt] tavayn wooohooo hooo ohhh com> wrote in message
news:ef*************@TK2MSFTNGP10.phx.gbl... 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
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:cj*************@news.t-online.com... 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/<cj*************@news.t-online.com> >
> 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/<cj*************@news.t-online.com> > >
> > 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]
Sriram Krishnan wrote: You know what the scary part is? That some paranoid person reading this post
might actually take this seriously and try it out. And even worse, somebody
somewhere will always find a way to get the public key out of our custom CLR
and crack your assembly.
*Really* scary are discussions about cryptography carried out
by clueless people. This includes myself! :-))) But I really
enjoy it! LOL!
bye
Rob
That was kinda the point dude. Hence the *very expensive* part...
I have said it before, how much do you think people *actually* care about
your source code...
"Sriram Krishnan" <ks*****@NOSPAMgmx.net> wrote in message
news:Ok**************@TK2MSFTNGP10.phx.gbl... Since everyone is in the mood for impractical ideas here,I have one.
For every client that you have,generate a public key and a private key.
Use the public key to encrypt the assembly. Now, here comes the really wacky
idea. Take the Rotor souce code (or pay Microsoft a lot of money to do
this for you)..and build your own mscoree/mscorwks/mscorsvr dlls which have the
private key embedded in them. If you're really paranoid, you can do
something like Windows Activation and make sure that the CLR works
properly only on some hardware hashes.
Now, these runtimes will work normally with normal applications - but
will recognize your specially encrypted assembly and decrypt it using the
private key. This way, we make sure that every assembly runs *only* in its very
own version of the CLR. So when you send customers the assemblies, you send
them your custom CLR as well. Yes - this would inflict all sorts of versioning
conflicts on them - but you can sleep assuredly at night with the
knowledge that no one else can get at your code.
You know what the scary part is? That some paranoid person reading this
post might actually take this seriously and try it out. And even worse,
somebody somewhere will always find a way to get the public key out of our custom
CLR and crack your assembly.
--
Sriram Krishnan
http://www.dotnetjunkies.com/weblog/sriram
"CJ Taylor" <cege [ahh ttt] tavayn wooohooo hooo ohhh com> wrote in
message news:ef*************@TK2MSFTNGP10.phx.gbl... 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
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:cj*************@news.t-online.com... 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/<cj*************@news.t-online.com> >
> 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/<cj*************@news.t-online.com> > >
> > 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]
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Vortex Soft |
last post by:
http://www.junglecreatures.com/
Try it and tell me what's happenning in the Microsoft Corporation.
Notes:
VB, C# are CLS compliant
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
