Decompiler.NET reverse engineers your CLS compliant code

[Vortex Soft]

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.

[Cor Ligthert]

Daniel,

Learn to read you ignomious buffoon

I never had expected from you that you would use such words. In my culture
where are a lot of debats, it means that you lost the discussion.

Cor

[Jonathan Pierce]

Nick,

Thank you for recounting your statement that our code had issues and
implying that our product doesn't work as advertised. We have gone to
tremendous lengths to make sure that our product works completely for our
customers and antogonistic statements can sometimes have a detrimental
effect on our target market since some potential customers might read and
believe them rather than taking the time to confirm our claims and the
claims made by others that our product works extremely well.

Unfortunately, satisfied users are much less vocal in these forums than
those who tend to post malicious antagonistic claims to intentionally
disrupt the accurate perception of our products in the target market to
fulfill their own agendas.

Jonathan

"Nak" <[e-mail]> wrote in message
news:OY**************@TK2MSFTNGP10.phx.gbl...

Jesus H christ. Look if anyone has to admit to being out of order, I
shall, I appologise for saying your code was dirty. This was meant as an
assumption not a declaration of an observation. But anyway, whether you
belive me or not, the statement was meant to antagonize, I put my hand up
and appologise. I do on the other hand think it was exceedingly sly to
post my personal email address in this group, I would have given it freely
if anyone asked for it, but in a format that could not be read by a
crawler.

Anyway, trust me, I have never decompiled anything, other than looking at
my own source in Reflector. I get a kick out of programming my own
solutions, not copying others. Anyway, I appologise for the remark I
made, I'm sure your product is fine, but still something I do not have the
need for.

Anyway, I'm off of this, it's gone too far for me.

Nick.

[Daniel O'Connell [C# MVP]]

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:uu*************@TK2MSFTNGP11.phx.gbl...

Daniel,

>> Learn to read you ignomious buffoon

I never had expected from you that you would use such words. In my culture
where are a lot of debats, it means that you lost the discussion.

My tounge can be sharp, I suppose, although I considered these words to be
fairly light.

Anyway, this was never a debate, it was pretty much an escalating argument.
There really isn't a way to win, you just yell and posture till someone gets
fed up and gives up. I will grant I got fed up rapidly and gave up first,
but nothing more.

I will agree that my response in a debate of issues or even a dispute on
technical or philosophical opinion would certainly have been uncalled for
and would have shown that I was losing ground rapidly, but this had
degenerated into name calling a few steps back. And, honestly, I'm pretty
sure I started it.

[Jonathan Pierce]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:uT**************@TK2MSFTNGP10.phx.gbl...

this had degenerated into name calling a few steps back. And, honestly, I'm
pretty sure I started it.

Daniel,

You may have started it in the subthread, but you definitely didn't start
it. In earlier antogonistic posts in this thread by some of the users that
you mentioned, our product was referred to as "crap", "a$$ bandit", "twat",
etc.

We were also told many times to "shut the f*ck up!"

All MVPs were also referred to as "hackers" among other things.

You certainly didn't start the name calling and I'm sorry that you felt that
it was necessary to respond on the same level.

Jonathan

[CJ Taylor]

Wow...

You have derailed...

P.S.

You *really* need to learn what the term "hacker" means...
"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:vV******************@twister.nyc.rr.com...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:uT**************@TK2MSFTNGP10.phx.gbl...

this had degenerated into name calling a few steps back. And, honestly, I'mpretty sure I started it.
Daniel,

You may have started it in the subthread, but you definitely didn't start
it. In earlier antogonistic posts in this thread by some of the users that
you mentioned, our product was referred to as "crap", "a$$ bandit",

"twat", etc.

We were also told many times to "shut the f*ck up!"

All MVPs were also referred to as "hackers" among other things.

You certainly didn't start the name calling and I'm sorry that you felt that it was necessary to respond on the same level.

Jonathan

[Steve McLellan]

You're right, we don't need cheering. Not that it matters, but (<g>) I meant
it as a compliment on the phrasing - as a student of language, I appreciate
any use of language that really seems to roll off the tongue :-) It
definitely is a time for us all to go and reflect, and I need some sleep
having been working for about 48 hours straight now :-)

Let the slumbering hounds lie, I shall heed the call.
"Nak" <[e-mail]> wrote in message
news:O6**************@TK2MSFTNGP10.phx.gbl...

Steve,

Now that just doesn't make sense. So many people saying stop arguing, you all sound like children, and then you throw that one in. What is the point? Let it all die down, the argument has gone off on a tangent. I have
admitted that I only reacted due to what I deemed as an advert, nothing
else, then I mistakingly made a poor assumption towards someone else's code, which wasn't big and wasn't clever. And again I apologise, but what we
don't need is a seagull sitting on the sidelines cheering anyone on, because it only stokes the fire.

Nick.

"Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
news:e7**************@tk2msftngp13.phx.gbl...

Learn to read you ignomious buffoon. What I am saying, although I doubt
you'll understand this any better than anything else you've replied to on this thread, is that because I *AM* an MVP, you are acting like a crabby little peasent who's been stepped on by some Chaldean god.

I just wanted to say, regardless of context, this was a splendid and
magnificent wording. Bravo! :-)

Steve

[Jonathan Pierce]

> You *really* need to learn what the term "hacker" means...

I actually was around in the 80's when the "cracker" term was coined to
distinguish "crackers" from "hackers" but the term "hacker" can have either
a derogatory or complimentary meaning and in the context that it was used in
this thread, it was used in a derogatory way and later clarified by him to
say that he really meant "cracker". I didn't mean to imply that "hacker" was
always a derogatory term.

Nick wrote:

"Being more clear: is Microsoft ready to

put its hand on Bible to say that each of MVPs are not hackers or malware
people?

[CJ Taylor]

"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:Kc*******************@twister.nyc.rr.com...

You *really* need to learn what the term "hacker" means...
I actually was around in the 80's when the "cracker" term was coined to
distinguish "crackers" from "hackers" but the term "hacker" can have

either a derogatory or complimentary meaning and in the context that it was used in this thread, it was used in a derogatory way and later clarified by him to
say that he really meant "cracker". I didn't mean to imply that "hacker" was always a derogatory term.

Nick wrote:

"Being more clear: is Microsoft ready to

put its hand on Bible to say that each of MVPs are not hackers or malware people?

And if by Nick you mean Vortex Soft.. then yes... he said that... It's only
derogatory by people that don't know how to use the word.

IT's all because of that stupid "hackers" movie...

And he never clarified it... I did...

[Greg Merideth]

I tried that against the remotesoft decompiler and it finally threw them
a curveball. The resultant code is pretty much a jumble. This is the
first one I've seen that works nicely against their decompiler. Good find.

William Stacey [MVP] wrote:

Try this. Obfuscate with XenoCode on conservative or high setting and with
control flow obfuscations. Then run that dll or exe passed Jungle. In most
cases, you can't make heads or tails from the resulting code (I just tried
it.) once you get passed all the errors that are thrown. That said, looks
like they put some work into the product. Cheers.

[Nak]

> And if by Nick you mean Vortex Soft.. then yes... he said that... It's

only
derogatory by people that don't know how to use the word.

Aaah, ignore my statement.

Nick.

[Nak]

> Nick wrote:

"Being more clear: is Microsoft ready to

put its hand on Bible to say that each of MVPs are not hackers or malware
people?

Who wrote??

Nick.

[Mike Newton]

One word: Marketing.

If it weren't for the Massive Microsoft Marketing Machine, we'd all be
complaining about Delphi.
Brian Henry wrote:

if VB.NET was good for nothing but studying and playing hows come some major
corporations run applications they created in VB.NET? Because of the way IL
is compiled symbols are going to be included... this happens with any IL
language such as Java. and what is stoping you from reverse engineering C++
code? if you can understand assembly and have some time on your hands you
can decompile it also in a sense
"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:%2******************@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.

[Jonathan Pierce]

Greg,

Although we are not necessary interested in supporting decompiling code that
it intentionally confused by obfuscators, we do want to support the ability
to decompile arbitrary MSIL, even when it is created by hand and compiled
with ilasm. As a result we will be attempting to add support for decompiling
arbitrary code flow obfuscation, even when the obfuscator causes extra
branch instructions to jump around and process the instructions out of
order. Keep an eye out for a future release of our Decompiler.NET product if
this feature is important to you. We can't however, guarantee to undo all of
the other tricks that obfuscators play to confuse decompilers.

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

"Greg Merideth" <be*****@forwardtechnology.net> wrote in message
news:St********************@comcast.com...

I tried that against the remotesoft decompiler and it finally threw them a
curveball. The resultant code is pretty much a jumble. This is the first
one I've seen that works nicely against their decompiler. Good find.

William Stacey [MVP] wrote:

Try this. Obfuscate with XenoCode on conservative or high setting and
with
control flow obfuscations. Then run that dll or exe passed Jungle. In
most
cases, you can't make heads or tails from the resulting code (I just
tried
it.) once you get passed all the errors that are thrown. That said,
looks
like they put some work into the product. Cheers.

[remotesoft]

XenoCode inserts some branch instructions (br) here and there to confuse the
stack, which is very easy to remove. Our desktop version of the decompiler
works very well against those tricks, namely, you won't see those jumble
code. I will post that feature onto our online version in couple of months.

Huihong
Remotesoft, Inc.

"Greg Merideth" <be*****@forwardtechnology.net> wrote in message
news:St********************@comcast.com...

I tried that against the remotesoft decompiler and it finally threw them
a curveball. The resultant code is pretty much a jumble. This is the
first one I've seen that works nicely against their decompiler. Good find.
William Stacey [MVP] wrote:

Try this. Obfuscate with XenoCode on conservative or high setting and with control flow obfuscations. Then run that dll or exe passed Jungle. In most cases, you can't make heads or tails from the resulting code (I just tried it.) once you get passed all the errors that are thrown. That said, looks like they put some work into the product. Cheers.

[Shawn B.]

Huh? VB is very powerful and is good for exactly what C# is good for and
managed-C++/C++/CLI is good for. Due to problems with COM+, we created a
custom transaction manager/server that completely replaces COM+ and work
much faster and does much more and it was written in VB.NET... of course,
now that we learned of the upcoming System.Transactions namespace, I don't
know where that'll leave us... but the point being that we have just as many
projects in this company written in VB.NET as there are C# and there is no
difference between the functionality or featureset or potential of the two
except that the languages they were developed in reflect the comfort of the
developer who wrote them.

If you mean to say "but its good for nothing else but [for me] its good for
nothing else but studying or playing" then I'll buy that. But to make such
a general statement, is incorrect. As a very good VB.NET developer for a
solution and he'll provide one in VB.NET. Ask a very good C# developer for
a solution and he'll provide one in C# and the same with a developer of any
other language. In the .NET world, VB.NET is no more or less capable than
C# (except in the case of operator overloading ala 2003) except VB.NET is
much better with COM-Interop than C# (at least, its easier than C# I should
say) and the IDE support is superior for VB.NET than C#.

Apart from the fact that there are endless holy-wars and religious
discussions regarding C# vs. VB.NET, I say the best tool for the job. In
the end, VB.NET usually wins with me but I've found some unique places where
C# is better suited for the task (such as my .NET-based NES emulator (not
public material, BTW)).

Thanks,
Shawn

I like VB, it is an easy yet powerfull language, but it's good for
nothing else but studying or playing.

[Shawn B.]

I've never seen original variable names being shown in the source when I run
ILDASM or Reflector... but of course you'll see all the other meta data that
needs to be there.

"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:u4**************@TK2MSFTNGP11.phx.gbl...

If you try the Decompiler.NET, you will get the full source code.
All Class, Function, Variable names are shown as in the original source!

CJ Taylor wrote:

There was more to that sentence... that being, is it *really* worth the
effort?

"Nak" <[e-mail]> wrote in message
news:Od**************@TK2MSFTNGP10.phx.gbl...

Whoah!

"RSA encryption can be cracked too"

How much time do you have on your hands??

Nick.

[Shawn B.]

Its not like everyone developing an application is so unique that no one
else is, just that the management is "convinced" they are the only ones
doing it. I consulted for a company 2 years ago that wanted me to make an
online calendar and contact management system. They even tried to get
patents on it because they were convinced that no one else was using a
calendar quite the way they were (except yahoo calendars, hotmail, and a few
others...).

They had everyone sign NDA and Trade Secret documents and everything... its
a friggin' calendar. I copied the look-and-feel from Yahoo and the same
work flow (which incidentally happened to be the same that this company
wanted) only I implemented it myself and they thought that theirs was the
only one until I showed them a few others that were out there.

My point is that everyone wants to protect their work (rightfully so, I
suspect I'm the same way only I don't care as much since I realize a
determined person will uncover my "secrets" in no time, anyway) all equally
convinced that they are doing something that no one else is doing only, many
people are doing it all equally convinced that they need to "protect" their
IP because no one else is doing it. Its a vicious cycle of nonsense.

In all the places I've consulted and been full-time employed... the only
thing different about their respective business applications is some take
the concept to one extreme while others take it to another... functionality
might be greatly improved in some companies, but in the end, they are all
the same application over and over and over...... input custom info,
generate invoice, balance the books, keep a list of contacts for follow-ups,
post the invoice... post the payment... post this, reverse that, input this,
data-mine that... its all the same, relatively. Nothing novel about it.

Occasionally I see something that is actually quite inique and impressive so
it is the exception... I'd say a good 80% of business apps out there share
much in common with each other and aren't worth "protecting".
Thanks,
Shawn

"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

CJ Taylor wrote:

Thanks for the compliments regarding our Decompiler.NET product. The
product includes a built-in obfuscation option that generates
obfuscated source code that you can recompile that still runs like the
original code. You may want to try this feature to see how readable
the obfuscated code is.
It's the .NET programmers comunity that should thank you for exposing
it's weakness and allow us to protect owselfs since Microsoft doesn't
you are a f#(*@#($* moron...

Get off your knees, I think you've satisified Jon's ego enough...

So many people became really upset because the .net programmers who read
this thread will be more careful. The dog's barking can be heard miles

away.
What kind of people is interestered in hidding critical security
information?
Nick258

[Shawn B.]

I've on many original source code bases that have no comments... don't need
a decompiler cause me to agree with your statement...

We'll written code, on the other hand, doesn't need comments except in
complex "workflows" more or less explaining a process or business rule, but
in the end, the code itself rarely needs comments. I find it very difficult
to read code with too many comments or the damned C# XML documentation ...
500 lines of XML docs for only 30 lines of C# code... ugh. I document the
XML comments externally using a utility I created...

* Too many comments: bad
* Not enough comments: ok for well-written code, bad for poorly written code
* No comments: see above.

Code without comments is rather worthless.

[Shawn B.]

Totally agreed. You really articulated my thoughts much better than my
first earlier attempt.
Thanks,
Shawn
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

My view is that in essence, comments should serve to explain code which
either has some quirk in it to compensate for an inadequacy or issue with
classes which it interacts with or is dealing with some particularly complex or intricate algorithm.

Otherwise, my beleif is the same as yours, well written code needs little
explaination when being read by someone competent.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
If U Need My Email ,Ask Me

Time flies when you don't know what you're doing

[Jonathan Pierce]

> I've never seen original variable names being shown in the source when I

run
ILDASM or Reflector... but of course you'll see all the other meta data
that
needs to be there.

The local variable names are in the pdb file, and you are correct that
although Decompiler.NET does retain local variables names when you decompile
your assembly with it and have the pdb file, these other two tools that you
mentioned do not support this capability. I recommend that you try the
product that is mentioned in the title of this thread and not make any
asseumptions regarding it's quality or capabilities based on your experiece
with other products that you have tried in the past. Please let me know if
at any point you feel that any of our claims are not 100% accurate or
experience any issues that you want to discuss further based on your use of
the product.

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

[Shawn B.]

I was referring to my decompiles of the System.* namespaces, of which, we do
not have the pdb files, and so therefore, there is no product that will
provide such functionality. I do not decompile assemblies for which I have
the source code for and presumably, I won't have pdb files for assemblies
that I don't have the source code for anyway. I'm not in the habbit of
peeking at other peoples code unless they provide it to me in some way (and
I don't peek at GPL code either as I dissagree with the license terms in
general) and it is so much more fun to come up with my own implementation
and learn along the way, anyway. The System.* namespaces are the only
exception and there is much to be learned about their internal workings and
at the very least, microsoft doesn't condemn doing so and so I feel no
guilt. Of course, there's always Rotor... but... not to go off-topic.

I was not making any comments about the capabilities of your product as I
really have no clue about its capabilities. I was only stating an opinion
of mine and it was not meant to be an authoritive, definitive, factual
conclusion of the matter.
Thanks,
Shawn


"Jonathan Pierce" <su*****@junglecreatures.com> wrote in message
news:cr***********************@twister.nyc.rr.com. ..

I've never seen original variable names being shown in the source when I
run
ILDASM or Reflector... but of course you'll see all the other meta data
that
needs to be there.
The local variable names are in the pdb file, and you are correct that
although Decompiler.NET does retain local variables names when you

decompile your assembly with it and have the pdb file, these other two tools that you mentioned do not support this capability. I recommend that you try the
product that is mentioned in the title of this thread and not make any
asseumptions regarding it's quality or capabilities based on your experiece with other products that you have tried in the past. Please let me know if
at any point you feel that any of our claims are not 100% accurate or
experience any issues that you want to discuss further based on your use of the product.

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

[Vortex Soft]

Shawn B. wrote:

I've never seen original variable names being shown in the source when I run ILDASM or Reflector... but of course you'll see all the other meta data that needs to be there.

Try BinText 3.0

This is a partial extract of one of my exe dump:

FilePos Mem pos ID Text
0056B45E 1156C45E 0 Countries
0056B468 1156C468 0 CountryCode
0056B479 1156C479 0 CountryName
0056B48F 1156C48F 0 MinTime
0056B497 1156C497 0 Compile
0056B49F 1156C49F 0 Events
0056B3E0 1156C3E0 0 GetText
0056B3E8 1156C3E8 0 FrameSize
0056B3F2 1156C3F2 0 DecodeText
0056B3FD 1156C3FD 0 FileName1
0056B407 1156C407 0 Props
0056B40D 1156C40D 0 get_INIFileName
0056B41D 1156C41D 0 get_Prop
0056B426 1156C426 0 Section
0056B432 1156C432 0 set_Prop
0056B43B 1156C43B 0 Write
0056B441 1156C441 0 INIFileName
0056B452 1156C452 0 Values
0056B45E 1156C45E 0 Countries
0056B468 1156C468 0 CountryCode
0056B479 1156C479 0 CountryName
0056B48F 1156C48F 0 MinTime
0056B497 1156C497 0 Compile
0056B49F 1156C49F 0 Events
VS

[Vortex Soft]

Shawn B. wrote:

In all the places I've consulted and been full-time employed... the only
thing different about their respective business applications is some take
the concept to one extreme while others take it to another... functionality
might be greatly improved in some companies, but in the end, they are all
the same application over and over and over...... input custom info,
generate invoice, balance the books, keep a list of contacts for follow-ups,
post the invoice... post the payment... post this, reverse that, input this,
data-mine that... its all the same, relatively. Nothing novel about it.

Occasionally I see something that is actually quite inique and impressive so
it is the exception... I'd say a good 80% of business apps out there share
much in common with each other and aren't worth "protecting".

If you used the CLS to develop any application (not an applet)
containing non public domain algorithms and released it to the public,
post it's Demo URL here if you don't fear it to be reverse engineered.
Thanks

VS

PS - I put my hand on the Holy Bible and swear not even think about
reverse engineer it even if it has any value (for me:).

[Jonathan Pierce]

These are not local variable names. They are symbols that are probably field
or property names which are in the compiled assembly. The local variables
are only present in the pdb file.

Jonathan

"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:uL**************@TK2MSFTNGP15.phx.gbl...

Shawn B. wrote:

I've never seen original variable names being shown in the source

when I run

ILDASM or Reflector... but of course you'll see all the other meta

data that

needs to be there.

Try BinText 3.0

This is a partial extract of one of my exe dump:

FilePos Mem pos ID Text
0056B45E 1156C45E 0 Countries
0056B468 1156C468 0 CountryCode
0056B479 1156C479 0 CountryName
0056B48F 1156C48F 0 MinTime
0056B497 1156C497 0 Compile
0056B49F 1156C49F 0 Events
0056B3E0 1156C3E0 0 GetText
0056B3E8 1156C3E8 0 FrameSize
0056B3F2 1156C3F2 0 DecodeText
0056B3FD 1156C3FD 0 FileName1
0056B407 1156C407 0 Props
0056B40D 1156C40D 0 get_INIFileName
0056B41D 1156C41D 0 get_Prop
0056B426 1156C426 0 Section
0056B432 1156C432 0 set_Prop
0056B43B 1156C43B 0 Write
0056B441 1156C441 0 INIFileName
0056B452 1156C452 0 Values
0056B45E 1156C45E 0 Countries
0056B468 1156C468 0 CountryCode
0056B479 1156C479 0 CountryName
0056B48F 1156C48F 0 MinTime
0056B497 1156C497 0 Compile
0056B49F 1156C49F 0 Events
VS

[Vortex Soft]

Jonathan Pierce wrote:

You need to post your code snippet then to make your example complete. I
still don't agree with your assessment.
Post the code here that goes with your claim about what you see in BinHex.

Jonathan

First:
I believe that you din not read clearly my post, I did not refer to your
useful program, I refeered to a public domain program named ------
bixtext.exe --------- a small utility that displays any 'suposed' string
in any file, no mather if it is exe, dll or whatever.

Second:
I think that you did a great contribution to the programmers comunity
exposing what a malware person would hide.

Third:
My code is not public domain (unless the m...f... who entered my system
got it) and the full code has 40+ modules and classes.
Resume:
I am not fighting against you or MicroSoft
Bye

VS

[DonutWine]

Well my bum is on your lips.

"Nak" wrote:

Hi Daniel,

While I appreciate that you are rather fervent about this, you are really
starting to push the point here. Up to this point I have seen no behaviour
by Jungle Creatures outside of supporting their product(and suggesting it
when people ask about decompilers).

Not that I ever denied that, I just absolutly hate that method of
advertising and that is what I percieved it to be. That isn't what the
newsgroup was intended for. If by any chance it wasn't a sales push then as
mr "Vortex" is a possible client or end user of JungleCreatures /
Decompiler.NET, they should conduct their chit chat elsewhere. This isn't a
forum for JungleCreatues to offer support on their products is it?

Your comments on this thread have been inappropriate, as have several
others(CJ Taylor and Brian Henry come to mind), and you comprise what I
would consider those who should go away, atleast from this thread.

Yup, my comments can be *very* inappropriate at times, but I am not
leaving this newsgroup, I've been here long enough now and respect many of
the hard working participants. Just because I am not an MVP, or CJ or
Brian, that is the only reason you are making this statement, which
personally I believe to be unfair. But expected from an MVP, no offence but
sometimes they can get a little too authorative, the status doesnt come with
a uniform does it?

Believe it or not, I am a regular of this group and do not always get
irate by this kind of thing, but sometimes I do. If *you* don't like what
you read, put it in your "block list".

The original poster is frustrating, to be sure, but you are being just as
bad. This is not a forum for conspiracy theories or for bashing other
people, even if they make a product you don't care for.

Oh well, pots and kettles, but you are not the referee, so there is no
need to start blowing your whistle.

At the moment "mate" *I* don't even make products I care for, it's been
one of those days!

Nick.

[CJ Taylor]

>(the m...f... who entered my system

got it) >

hmmm.........

[Jonathan Pierce]

I understand that you find the product useful and fully appreciate it.and
are not complaining about anything.

We are just discussing here whether or not you understand that the local
variable names are present in the compiled dll or not.

Go ahead and compile this simple code intoa dll nd post the output from your
magic bixtext.exe program.

public class TestLocalVariables

{
public void Method1 ()

{
int theIntLocalVariable = 0;
bool theBoolLocalVariable = false;
object theObjectLocalVariable = null;
}
}

Now, if what you claim is true, we should see these symbols in your
bixtext.exe output that you ran on the dll.
theIntLocalVariable
theBoolLocalVariable
theObjectLocalVariable

-Jonathan


"Vortex Soft" <No****@NoSpam.Net> wrote in message
news:O7**************@TK2MSFTNGP15.phx.gbl...

Jonathan Pierce wrote:

You need to post your code snippet then to make your example complete. I
still don't agree with your assessment.
Post the code here that goes with your claim about what you see in
BinHex.

Jonathan

First:
I believe that you din not read clearly my post, I did not refer to your
useful program, I refeered to a public domain program named ------
bixtext.exe --------- a small utility that displays any 'suposed' string
in any file, no mather if it is exe, dll or whatever.

Second:
I think that you did a great contribution to the programmers comunity
exposing what a malware person would hide.

Third:
My code is not public domain (unless the m...f... who entered my system
got it) and the full code has 40+ modules and classes.
Resume:
I am not fighting against you or MicroSoft
Bye

VS

[Nak]

Indeed.

"CJ Taylor" <cege at the123 dont use this part till here tavayn dot com>
wrote in message news:O2**************@TK2MSFTNGP10.phx.gbl...

(the m...f... who entered my system
got it) >

hmmm.........

[William Stacey [MVP]]

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

--
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.

[Sam Jost]

"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)

[Joep]

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

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

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

Just my thought...

[Robert Jordan]

Hi William,

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

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

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

It's not worthwhile.

bye
Rob

[Jonathan Pierce]

"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/

[Richard Blewett [DevelopMentor]]

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

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<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]

[Robert Jordan]

Hi Richard,

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

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

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

thanks

bye
Rob

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<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]

[Robert Jordan]

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

[Richard Blewett [DevelopMentor]]

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

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<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]

[Robert Jordan]

Hi Richard,

If you could send the assembly to MSFT to get signed with their private key then only the public key woul dneed to ship with the CLR. I thought thats what you suggested with hte Microsoft Remoting encrytping service.
Supposing the MSFT public key is really "public",
then everybody would be able to unencrypt the assembly, isn't it?
I thought we wanted to prevent that.

bye
Rob

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<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]

[CJ Taylor]

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

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

I mean REALLY big prime numbers.

----

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

Just my thoughts.

-CJ

"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]

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]

[Robert Jordan]

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

[CJ Taylor]

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]