TNX Rob - Re: Security of non-server code?

[Patrick Ireland]

Rob,

You are one of the thread responders I always following. Thanks for the
info. No question, native code is deconstructable given time. But for
really large (6MB+ programs) it will keep the amateurs at bay. Many of
my clients programs are EXEs & DLL's that approach 30MB. Definitely a
long assembler listing. How long ago was your post so that I might
follow it? My plan was to install on a single machine and XCOPY to
the other machines (CD actually) and since all the machines have the
same CPU (possible different step number on the P5) then it seems I
don't have a problem. 8-)

Thanks

Pat


"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>
>"Patrick Ireland" <ireland@airmail.net> wrote:
>>
>>In the current issue of VBPJ there is an article on the lack of code
>>security for disktop applications with any of the NET managed code
>>languages. I was under the opinion (wrongly apparently) that when and
>>install of a NET application is made that the IL code was not placed on
>>the target machine. Many of my clients have $$ invested in their apps
>>and for sure don't want the possibility of easily reverse engineered code
>>being distributed. Is my understanding flawed? If desktop apps must be
>>distruted in an IL form is this to be addressed in a future NET release.
>
>It's the same issue Java faced before with it's I.C.
>
>I believe this article is bit exagerated. MS will provide an obfuscator
(encryptor
>for the IL, if prefer the terminology), which is the same solution Java
has
>for it's I.C.
>As I mentioned in a different post, even PE "native" code is easily deconstructable
>by anyone with some assembly knowledge and a good hex editor (and lots of
>time on their hands). The only way to protect native PE code was to encrypt
>it as well. So basically, nothing's changed all that much. Sifting through
>a "real" program in IL is not much different than sifting through hundreds
>of thousands of lines of assembly, which is what hackers currently do.
>
>But there's also another point to make. You do not have to distribute the
>IL code per se. The IL can be "compiled" to native code either by the JIT
>at runtime, or *during install*. If it is turned to native code during install,
>the stuff on the client machine is pure native PE (without the IL embedding).
>
>-Rob

[Ronald Laeremans [MSFT]]

You do need to distribute the IL code to every client machine.Prejit is
ALWAYS done on the target machine in this version and not on some
intermediate machine and the original MSIL image is still needed at runtime.

Ronald Laeremans
Visual C++ compiler team


"Patrick Ireland" <ireland@airmail.net> wrote in message
news:3ad235fe$1@news.devx.com...
>
> Rob,
>
> You are one of the thread responders I always following. Thanks for the
> info. No question, native code is deconstructable given time. But for
> really large (6MB+ programs) it will keep the amateurs at bay. Many of
> my clients programs are EXEs & DLL's that approach 30MB. Definitely a
> long assembler listing. How long ago was your post so that I might
> follow it? My plan was to install on a single machine and XCOPY to
> the other machines (CD actually) and since all the machines have the
> same CPU (possible different step number on the P5) then it seems I
> don't have a problem. 8-)
>
> Thanks
>
> Pat
>
>
> "Rob Teixeira" <RobTeixeira@@msn.com> wrote:
> >
> >"Patrick Ireland" <ireland@airmail.net> wrote:
> >>
> >>In the current issue of VBPJ there is an article on the lack of code
> >>security for disktop applications with any of the NET managed code
> >>languages. I was under the opinion (wrongly apparently) that when and
> >>install of a NET application is made that the IL code was not placed on
> >>the target machine. Many of my clients have $$ invested in their apps
> >>and for sure don't want the possibility of easily reverse engineered
code
> >>being distributed. Is my understanding flawed? If desktop apps must be
> >>distruted in an IL form is this to be addressed in a future NET release.
> >
> >It's the same issue Java faced before with it's I.C.
> >
> >I believe this article is bit exagerated. MS will provide an obfuscator
> (encryptor
> >for the IL, if prefer the terminology), which is the same solution Java
> has
> >for it's I.C.
> >As I mentioned in a different post, even PE "native" code is easily
deconstructable
> >by anyone with some assembly knowledge and a good hex editor (and lots of
> >time on their hands). The only way to protect native PE code was to
encrypt
> >it as well. So basically, nothing's changed all that much. Sifting
through
> >a "real" program in IL is not much different than sifting through
hundreds
> >of thousands of lines of assembly, which is what hackers currently do.
> >
> >But there's also another point to make. You do not have to distribute the
> >IL code per se. The IL can be "compiled" to native code either by the JIT
> >at runtime, or *during install*. If it is turned to native code during
install,
> >the stuff on the client machine is pure native PE (without the IL
embedding).
> >
> >-Rob
>

[Dan Barclay]

On Wed, 18 Apr 2001 13:32:20 -0700, "Ronald Laeremans [MSFT]"
<ronlaere@microsoft.com> wrote:

>You do need to distribute the IL code to every client machine.Prejit is
>ALWAYS done on the target machine in this version and not on some
>intermediate machine and the original MSIL image is still needed at runtime.

Is it still needed at runtime even if you prejit? That is: IL can't
be removed after that and still have it run?

Hmmm... I know there is a lot of reference info in the assembly, is
that the reason? If so, why wouldn't that be stashed along with the
compiled native?

Am I reading you right on this?

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Ronald Laeremans [MSFT]]

Yes, it is. The reason is that we still need the IL for referencing
assemblies (not just the metadata). In that way the Jitter can e.g. still
inline trivial methods across assembly boundaries.

Ronald Laeremans
Visual C++ compiler team

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:equrdtc200um26jjb24re3ck28iv5c0es6@4ax.com...
> On Wed, 18 Apr 2001 13:32:20 -0700, "Ronald Laeremans [MSFT]"
> <ronlaere@microsoft.com> wrote:
>
> >You do need to distribute the IL code to every client machine.Prejit is
> >ALWAYS done on the target machine in this version and not on some
> >intermediate machine and the original MSIL image is still needed at
runtime.
>
> Is it still needed at runtime even if you prejit? That is: IL can't
> be removed after that and still have it run?
>
> Hmmm... I know there is a lot of reference info in the assembly, is
> that the reason? If so, why wouldn't that be stashed along with the
> compiled native?
>
> Am I reading you right on this?
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Dan Barclay]

On Wed, 18 Apr 2001 15:54:22 -0700, "Ronald Laeremans [MSFT]"
<ronlaere@microsoft.com> wrote:

>Yes, it is. The reason is that we still need the IL for referencing
>assemblies (not just the metadata). In that way the Jitter can e.g. still
>inline trivial methods across assembly boundaries.

Has anybody mentioned yet that this sucks?

Seems to me it's either pre-jitted or not. If it's pre-jitted and the
IL is gone, then the jitc should be smart enough to know it can't
inline and just make the cross assembly call. If you prejit all the
assemblies then, fine, let it inline while the IL is available... but
when IL's gone it's gone.

That is, unless this is just some sort of new-fangled interpreter
after all.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jeff Peil]

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:s68sdts4a2i6p0sk6aihqcblddbhnjvbc9@4ax.com...
> Has anybody mentioned yet that this sucks?
>
> Seems to me it's either pre-jitted or not. If it's pre-jitted and the
> IL is gone, then the jitc should be smart enough to know it can't
> inline and just make the cross assembly call. If you prejit all the
> assemblies then, fine, let it inline while the IL is available... but
> when IL's gone it's gone.
>
> That is, unless this is just some sort of new-fangled interpreter
> after all.

Dan,

Out of curiosity, exactly what benefit do you see to distributing a version
using an x86 instruction set here?

The metadata can't be eliminated (as things like Reflection and the GC
require it), do you think that metadata rich x86 code is magically much more
difficult to reverse engineer than MSIL (it's not.) It's the metadata more
than anything else that makes reverse engineering .NET binaries easier than
Win32 x86 binaries.

You also have to consider the problems with prejitted code (very-JIT
specific)

The only benefit I see to distributing post-jitted code is reducing install
times.

[Dan Barclay]

On Wed, 18 Apr 2001 17:02:49 -0700, "Jeff Peil" <jpeil@bigfoot.com>
wrote:

>Dan,
>
>Out of curiosity, exactly what benefit do you see to distributing a version
>using an x86 instruction set here?

Still learning. Apparently none <g>.

>The metadata can't be eliminated (as things like Reflection and the GC
>require it), do you think that metadata rich x86 code is magically much more
>difficult to reverse engineer than MSIL (it's not.) It's the metadata more
>than anything else that makes reverse engineering .NET binaries easier than
>Win32 x86 binaries.

True enough. I had in mind closed application code (no other
references *to* it from the outside) but perhaps it is not possible to
make the distinction between that and an open library.

Given a closed application I would have thought that metadata needs
would be pretty minimal once it was compiled. Then again, I pictured
"jit compiled" to included all linking that was required (ready to
run), and that the code was fairly well optimized at the native code
level. In that case I would expect reverse engineering to be fairly
difficult.

>You also have to consider the problems with prejitted code (very-JIT
>specific)
>
>The only benefit I see to distributing post-jitted code is reducing install
>times.

Given the current information that sounds right.

I am certainly interested in the subject, though. Lots to learn on
that. Sounds like making client apps secure could be painful, but I
don't see anything in the technology that would prevent it yet.
Sounds like it just hasn't been done (yet?).

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Ronald Laeremans [MSFT]]

No, this doesn't suck. It provides for very significant performance
benefits. Inlining of the small accessor functions (i.e. properties) that
are so prevalent in the .Net framework is essential. I can't quite
understand how you equate a very important means to get high performance for
this style of API (that isn't possible with fully compiled dynamically
linked code) as being an interpreter when it goes beyond even what a static
code compiler can do.

Ronald Laeremans
Visual C++ compiler team

"Dan Barclay" <Dan@MVPs.org> wrote in message
news:s68sdts4a2i6p0sk6aihqcblddbhnjvbc9@4ax.com...
> On Wed, 18 Apr 2001 15:54:22 -0700, "Ronald Laeremans [MSFT]"
> <ronlaere@microsoft.com> wrote:
>
> >Yes, it is. The reason is that we still need the IL for referencing
> >assemblies (not just the metadata). In that way the Jitter can e.g. still
> >inline trivial methods across assembly boundaries.
>
> Has anybody mentioned yet that this sucks?
>
> Seems to me it's either pre-jitted or not. If it's pre-jitted and the
> IL is gone, then the jitc should be smart enough to know it can't
> inline and just make the cross assembly call. If you prejit all the
> assemblies then, fine, let it inline while the IL is available... but
> when IL's gone it's gone.
>
> That is, unless this is just some sort of new-fangled interpreter
> after all.
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Rob Teixeira]

"Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
>No, this doesn't suck. It provides for very significant performance
>benefits. Inlining of the small accessor functions (i.e. properties) that
>are so prevalent in the .Net framework is essential. I can't quite
>understand how you equate a very important means to get high performance
for
>this style of API (that isn't possible with fully compiled dynamically
>linked code) as being an interpreter when it goes beyond even what a static
>code compiler can do.

Now you've got my attention! Are you saying that this inlining is possible
even across assemblies? Is this a JIT feature?

But getting back to security stuff...
I'm not sure how metadata is any more unsafe than a type library would be.
You're mostly exposing type information. I think it's the IL that people
are concerned about. Is it possible that the IL could be entirely encrypted,
with a private key that only the JIT has access to? At run time, the JIT
could decode chunks of the encrypted IL and do it's native code tranlation
magic. I assume there would have to be metadata that identifies these chunks
or offsets, if that doesn't already exist. Anyway, I'm just thinking out
loud. I haven't gotten too deep into the JIT workings.

-Rob

[Dan Barclay]

On Wed, 18 Apr 2001 20:03:07 -0700, "Ronald Laeremans [MSFT]"
<ronlaere@microsoft.com> wrote:

>No, this doesn't suck. It provides for very significant performance
>benefits. Inlining of the small accessor functions (i.e. properties) that
>are so prevalent in the .Net framework is essential.

Apparently I wasn't very clear. I wasn't saying that inlining sucks
(sheesh... I'm not the compiler expert but I'm not quite that dense
<g>). What sucks is that the IL needs to remain on the machine.

What I said was that it isn't clear why the inlining can't take place
during pre-jit... then remove the IL. Secondly (as a fallback) have
the code still work (via non-inlined call) if the IL isn't available.
From other comments here I should say "IL and associated info".

> I can't quite
>understand how you equate a very important means to get high performance for
>this style of API (that isn't possible with fully compiled dynamically
>linked code) as being an interpreter when it goes beyond even what a static
>code compiler can do.

The problem isn't really whether the thing is an interpreter or not so
far as I'm concerned. That's really a red-herring (sorry <g>). The
issue, as the Subject indicates, is really code security.

However, the things that go along with an interpreter (closer to the
source, etc) are a problem. The more it quacks like a duck the more
it looks like a duck, even if it isn't.

It seems to me that if it can be "beyond even what a static code
compiler can do" then the optimizations themselves should be making it
more difficult to decompile.

In any case, picture it this way, and forget any *real* value of
decompiled IL (or native code for that matter). Consider the "concern
factor":
----
You've got an app you've done for a bank. Take your pick in this
scenario: it's either your own app or something you bid on as a work
for hire. They've got Joe Consultant with the handy-dandy decompile
tool. In the bid meeting (or the turnover meeting) Joe decompiles
your super-app in front of the customer's eyes.

Now, Customer has no clue what the source means, but Joe Consultant
(or even Jack IT) tells him it's the source for the app, that he can
see the internals and perhaps even change some things. Remember: this
is a bank, the app deals with their customers and money. What you say
in response ("you can't really tell much", "it doesn't matter", yada,
yada) has no bearing on the matter: He sees the internals before his
eyes. Result: door hits you in the *** on the way out (yes it will,
leaving a very expensive bruise).

I could argue that decompiling can be a real (as opposed to perceived)
problem. However, that doesn't really matter. If it is a perceived
problem, it is an expensive problem.

To be clear: I actually don't care if it's interpreted, native
compiled, or somewhere in between. Performance is certainly an issue,
but even that doesn't matter if the app can't (or won't) be accepted
as a deliverable.

In a lot of cases (most vertical apps, I would argue) one requirement
is some mechanism to make the source unavailable outside the
developer's machine. There are a zillion ways of doing that (well,
several dozen anyway). Please don't take my comments as some
expectation of how it is done, but you need some mechanism for it.

Some SOB will build a decompiler if it's not a *seriously* difficult
thing to do.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Ronald Laeremans [MSFT]]

"Dan Barclay" <Dan@MVPs.org> wrote in message
newsfosdt0pu65c5i2an0sipadi3qsuni5pl7@4ax.com...
> On Wed, 18 Apr 2001 20:03:07 -0700, "Ronald Laeremans [MSFT]"
> Apparently I wasn't very clear. I wasn't saying that inlining sucks
> (sheesh... I'm not the compiler expert but I'm not quite that dense
> <g>). What sucks is that the IL needs to remain on the machine.

> What I said was that it isn't clear why the inlining can't take place
> during pre-jit... then remove the IL. Secondly (as a fallback) have
> the code still work (via non-inlined call) if the IL isn't available.
> From other comments here I should say "IL and associated info".

The IL needs to be on the machine to enable newly installed components that
call the Pr-jitted assembky to still benefit from the cross-assembly
inlining.

[...]
> It seems to me that if it can be "beyond even what a static code
> compiler can do" then the optimizations themselves should be making it
> more difficult to decompile.
This is one specific case. In general a JIT does less optimizations, and
especially less of the heavy duty ones that tend to obscure code flow than a
development time compiler.

[... snipped very large part of code security]
I won't go into this argument, since I am certain both sides will not see
one another's viewpoint and I am very much on the other side, as you will
find most people to be that have worked on software/network security issues.
And actually quite a bit of the work I did in that field was for financial
institutions.

-Ronald-

[Dan Barclay]

On Thu, 19 Apr 2001 14:05:45 -0700, "Ronald Laeremans [MSFT]"
<ronlaere@microsoft.com> wrote:

>
>"Dan Barclay" <Dan@MVPs.org> wrote in message
>newsfosdt0pu65c5i2an0sipadi3qsuni5pl7@4ax.com...
>> On Wed, 18 Apr 2001 20:03:07 -0700, "Ronald Laeremans [MSFT]"
>> Apparently I wasn't very clear. I wasn't saying that inlining sucks
>> (sheesh... I'm not the compiler expert but I'm not quite that dense
>> <g>). What sucks is that the IL needs to remain on the machine.
>
>> What I said was that it isn't clear why the inlining can't take place
>> during pre-jit... then remove the IL. Secondly (as a fallback) have
>> the code still work (via non-inlined call) if the IL isn't available.
>> From other comments here I should say "IL and associated info".
>
>The IL needs to be on the machine to enable newly installed components that
>call the Pr-jitted assembky to still benefit from the cross-assembly
>inlining.

benefit: Yea, I understand that. Also true that it *must* be able to
do cross-assembly inlining? That is, if it can't do the inlining it
simply can't be made to run with a Call... or is a fallback Call mode
just not yet implemented?


>[...]
>> It seems to me that if it can be "beyond even what a static code
>> compiler can do" then the optimizations themselves should be making it
>> more difficult to decompile.
>This is one specific case. In general a JIT does less optimizations, and
>especially less of the heavy duty ones that tend to obscure code flow than a
>development time compiler.

Quack? <g>

>[... snipped very large part of code security]
>I won't go into this argument, since I am certain both sides will not see
>one another's viewpoint and I am very much on the other side, as you will
>find most people to be that have worked on software/network security issues.
>And actually quite a bit of the work I did in that field was for financial
>institutions.

I'm confused here. I wouldn't say that hiding source is *always*
never... but are you saying it's *never* needed?

Assuming dotnet is to be deployed on all of server/distributed/client
environments I can say with some certainty that it will be expected,
particularly in rich client or client/only environments.


Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Dan Barclay]

On Fri, 20 Apr 2001 11:02:27 -0500, Dan Barclay <Dan@MVPs.org> wrote:

err.. make that:
====
I'm confused here. I wouldn't say that hiding source is *always*
needed... but are you saying it's *never* needed?
=====

But then, maybe right now it's "always never" <g>.

Dan

Language Stability is a *feature* I wish VB had!
(#6)

[Karl E. Peterson]

Hi Jeff --

> Out of curiosity, exactly what benefit do you see to distributing a version
> using an x86 instruction set here?

Well, just offhand, I've yet to see an ASM-->VB conversion tool. (And no one would
suggest that there wouldn't be *quite* a market for one, right?) Yet I did see an
IL-->C# conversion tool, rigged up by one guy on a Saturday afternoon.

Hmmmm... Karl
--
http://www.mvps.org/vb

[Ronald Laeremans [MSFT]]

Hi Karl,

If you are talking about Exemplar, I think the author would be a bit
dismayed about your comments on his work. It requires quite a bit of skill
and decidedly more than one Saturday afternoon to get to the stage Exemplar
is in.

-Ronald-

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:3ae476e5$1@news.devx.com...
> Hi Jeff --
>
> > Out of curiosity, exactly what benefit do you see to distributing a
version
> > using an x86 instruction set here?
>
> Well, just offhand, I've yet to see an ASM-->VB conversion tool. (And no
one would
> suggest that there wouldn't be *quite* a market for one, right?) Yet I
did see an
> IL-->C# conversion tool, rigged up by one guy on a Saturday afternoon.
>
> Hmmmm... Karl
> --
> http://www.mvps.org/vb
>
>