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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 20

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

Hybrid View

  1. #1
    Patrick Ireland Guest

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


    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



  2. #2
    Ronald Laeremans [MSFT] Guest

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

    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

    >




  3. #3
    Dan Barclay Guest

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

    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)

  4. #4
    Ronald Laeremans [MSFT] Guest

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

    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)




  5. #5
    Dan Barclay Guest

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

    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)

  6. #6
    Jeff Peil Guest

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


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



  7. #7
    Dan Barclay Guest

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

    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)

  8. #8
    Ronald Laeremans [MSFT] Guest

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

    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)




  9. #9
    Rob Teixeira Guest

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


    "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

  10. #10
    Dan Barclay Guest

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

    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)

  11. #11
    Ronald Laeremans [MSFT] Guest

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


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



  12. #12
    Dan Barclay Guest

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

    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)

  13. #13
    Dan Barclay Guest

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

    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)

  14. #14
    Karl E. Peterson Guest

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

    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



  15. #15
    Ronald Laeremans [MSFT] Guest

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

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




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center