New technique to protect Java (NOT obfuscation) ?

Discussion in 'Java' started by Koleho, Jul 17, 2003.

  1. Koleho

    Koleho Guest

    Hello,

    This company (http://www.new-era-soft.com) claims they have a new
    method to protect Java against de-compilation, and it is NOT
    obfuscation.

    Has anyone tried their product yet ?

    What do you think about it ?

    What tests can I do to check if it is really good ?

    Thanks.
     
    Koleho, Jul 17, 2003
    #1
    1. Advertising

  2. In article <>,
    Koleho <> wrote:
    >What do you think about it ?


    Since they obviously dare not suggest what, exactly, they are doing,
    my immediate guess is that they're full of crap.

    >What tests can I do to check if it is really good ?


    Create a very simple application (one trivial class file for instance)
    that you encrypt with their tool and then start looking into what they
    actually do. Most probably, they just encrypt the class file and then
    install a custom ClassLoader to decrypt it. If so, then find the
    bootstrap ClassLoader they use to decrypt their own library (if they
    require you to distribute such a library for your app to work) or find
    the one they added to your app to decrypt your own class files.
    Decompile that class to start finding out what they do. Chances are
    this will eventually lead you to the algorithm they are using, which
    should let you decrypt everything else at your leisure.

    At best, they have made considerable effort to make it difficult for
    you to find out what's actually going on. I seriously doubt they've
    found a bullet-proof way of securing the bytecode.

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jul 17, 2003
    #2
    1. Advertising

  3. Koleho

    Chris Smith Guest

    [Snipped non-existent group comp.lang.java.developer]

    Koleho wrote:
    > Hello,
    >
    > This company (http://www.new-era-soft.com) claims they have a new
    > method to protect Java against de-compilation, and it is NOT
    > obfuscation.
    >
    > Has anyone tried their product yet ?
    >
    > What do you think about it ?


    It's good for a laugh or two. I just love it when someone takes
    something that can be absolutely proven to be impossible and plays the
    "us versus them" card by saying "they say it can't done, but we did it
    anyway!" This generally indicates one of three things:

    1. The speaker is trying to trick you.
    2. The speaker really doesn't understand the problem they "solved".
    3. The speaker is God, so rules of logic don't apply.

    Perhaps you should ask them which one is the case?

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jul 17, 2003
    #3
  4. Koleho

    Koleho Guest

    > Since they obviously dare not suggest what, exactly, they are doing,
    > my immediate guess is that they're full of crap.


    That was my initial thought, and that's why I was surprised when I
    failed to break into their encryption.

    I already tried the following:
    1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in
    order to dump the classes there, and failed.
    2) I altered the method
    java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
    classes there, and also failed.

    > Create a very simple application (one trivial class file for instance)
    > that you encrypt with their tool and then start looking into what they
    > actually do. Most probably, they just encrypt the class file and then
    > install a custom ClassLoader to decrypt it.


    I already created an encrypted application (as you suggested).
    The encrypted application consists of a dll file, and a jar file
    containing entries that are probably my encrypted class files + an
    additional class which has practically nothing in it (only a main
    method which is calling a native method).

    My idea is that they are doing the loading of the classes from the
    dll, but even so, they must use some ClassLoader that is not
    encrypted, and I couldn't even see that class.


    > If so, then find the
    > bootstrap ClassLoader they use to decrypt their own library (if they
    > require you to distribute such a library for your app to work) or find
    > the one they added to your app to decrypt your own class files.


    I could not find any custom ClassLoader, but still it is impossible
    that they are using the default (system) ClassLoader.


    > Decompile that class to start finding out what they do. Chances are
    > this will eventually lead you to the algorithm they are using, which
    > should let you decrypt everything else at your leisure.


    I didn't succeed in decompiling anything besides the main class they
    added to my encrypted application, which has practically no content.


    > At best, they have made considerable effort to make it difficult for
    > you to find out what's actually going on. I seriously doubt they've
    > found a bullet-proof way of securing the bytecode.


    I also had serious doubts about that product, but I am already trying
    for some time now to decompile a test application that I encrypted
    with this product and till now, failed.

    I have already seen some products that suggested java code encryption
    in the past, and succeeded in breaking them in no time.
    This JEncoder seems to work surprisingly different.

    Is this JEncoder really does what it claims to ?

    Regards,
    Koleho.
     
    Koleho, Jul 17, 2003
    #4
  5. Koleho

    Chris Uppal Guest

    Koleho wrote:

    > I already created an encrypted application (as you suggested).
    > The encrypted application consists of a dll file, and a jar file
    > containing entries that are probably my encrypted class files + an
    > additional class which has practically nothing in it (only a main
    > method which is calling a native method).
    >
    > My idea is that they are doing the loading of the classes from the
    > dll, but even so, they must use some ClassLoader that is not
    > encrypted, and I couldn't even see that class.


    Perhaps they are using the JNI function DefineClass() to inject the decrypted
    byecode directly into the JVM.

    IIRC, the Sun and IBM JVMs allow a NULL classloader parameter to that function,
    so the class is actually loaded (I guess) by the primordial classloader. I
    have no idea whether that would bypass the debugging hook (or, indeed, whether
    using the default class loader in this way would trigger the hook), but it
    sounds possible.

    One indication would be that their encrypted classes don't work properly with
    with the BEA JRockit JVM which (at least up to V7) seems not to allow a NULL
    classloader for the DefineClass() function.

    Incidentally, if that *is* what they are doing, then setting up a "fake"
    jvm.dll that forwards the API to a real JVM, but also collects the decoded
    bytecode, would be an attack on their system. Off the top of my head, I can't
    think of a defense against that. (Or they may be using JNI to inject a
    decrypting classloader into the JVM instead, or as well, which would make it a
    little more awkward.)

    -- chris
     
    Chris Uppal, Jul 17, 2003
    #5
  6. Koleho

    Harald Hein Guest

    "Koleho" wrote:

    > This company (http://www.new-era-soft.com) claims they have a new
    > method to protect Java against de-compilation, and it is NOT
    > obfuscation.


    You work for them, don't you?
     
    Harald Hein, Jul 17, 2003
    #6
  7. Koleho <> scribbled the following:
    > Hello,


    > This company (http://www.new-era-soft.com) claims they have a new
    > method to protect Java against de-compilation, and it is NOT
    > obfuscation.


    > Has anyone tried their product yet ?


    > What do you think about it ?


    > What tests can I do to check if it is really good ?


    > Thanks.


    Its platform requirements specify it's for Windows only, so I won't be
    bothering.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "A bicycle cannot stand up by itself because it's two-tyred."
    - Sky Text
     
    Joona I Palaste, Jul 17, 2003
    #7
  8. In article <>,
    Koleho <> wrote:
    >> Since they obviously dare not suggest what, exactly, they are doing,
    >> my immediate guess is that they're full of crap.

    >
    >That was my initial thought, and that's why I was surprised when I
    >failed to break into their encryption.
    >
    >I already tried the following:
    >1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in
    >order to dump the classes there, and failed.
    >2) I altered the method
    >java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
    >classes there, and also failed.


    First, please keep in mind that I have next to no domain knowledge
    when it comes to classloading and the native API so will be stabbing
    around in the dark for a bit. Always fun, that :)

    I take it you have some experience with breaking into bytecode
    encryption schemes. Still, I would ask if the techniques you have
    tried are those that they suggest themselves. I would guess that of
    all the various ways of breaking in (or trying to), they will have
    listed the ones they know they are bullet proof against and omitted
    any they could think of that might threaten them.

    >I already created an encrypted application (as you suggested).
    >The encrypted application consists of a dll file, and a jar file
    >containing entries that are probably my encrypted class files + an
    >additional class which has practically nothing in it (only a main
    >method which is calling a native method).


    In very basic terms then, isn't what they are doing simply to write
    their classloader in a more obscure language than Java (i.e.,
    deliberately obfuscated C) and trusting this to become an unbreakable
    barrier? It would certainly have a higher threshold than Java
    bytecode, but still not bullet proof of course.

    I don't really know what native code could do to the VM in the way of
    class loading, Java thread starting etc.

    >My idea is that they are doing the loading of the classes from the
    >dll, but even so, they must use some ClassLoader that is not
    >encrypted, and I couldn't even see that class.


    Would a DLL-based native class loader be easy for you to spot?

    Did you try decompiling the DLL, or did you study its assembly?

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jul 17, 2003
    #8
  9. Koleho

    Roedy Green Guest

    On Thu, 17 Jul 2003 20:29:40 +0000 (UTC), (Bent C
    Dalager) wrote or quoted :

    >In very basic terms then, isn't what they are doing simply to write
    >their classloader in a more obscure language than Java (i.e.,
    >deliberately obfuscated C) and trusting this to become an unbreakable
    >barrier? It would certainly have a higher threshold than Java
    >bytecode, but still not bullet proof of course.


    They must decrypt it to Java byte code inside their custom
    classloader. The key to cracking their scheme is to replace that
    customclassloader with one that makes a side decrypted copy of the
    byte code for you to disassemble. Even if they use 128 bit
    encryption, they are vulnerable to that sort of attack.

    They may have written their custom class loader natively to make it a
    harder to crack.

    The problem with all these schemes is that the CPU has to capable of
    decrypting to run the code. Therefore a patient hacker in principle
    can too.

    With the internet, I would expect protection schemes that requires an
    outside connection periodically during execution. They can be orders
    of magnitude more fiendish.

    I think people waste far too much time trying to protect "secrets"
    from hackers. A clone written from a spec would be easier to write
    and maintain than one hacked by disassembling.

    To protect from stealing, I think the trick is to customise the
    product and preconfigure it before giving it to the customer. He can
    make all the copies he wants. That require frequent updates.

    If you don't want to go to all that work, require server involvement
    to customise.

    The proper solution is to rent rather than sell software. Peter
    Norton ripped be off "selling" me SystemWorks 2001, not telling me it
    would stop working in 2003 and he would do nothing about it. It would
    have been more honest to rent me the software for 2 years.


    see http://mindprod.com/projprebrandedsoftwarerental.html


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 17, 2003
    #9
  10. On Thu, 17 Jul 2003 07:38:07 -0700, Koleho wrote:

    >> Since they obviously dare not suggest what, exactly, they are doing, my
    >> immediate guess is that they're full of crap.

    >
    > That was my initial thought, and that's why I was surprised when I
    > failed to break into their encryption.
    >
    > I already tried the following:
    > 1) I ran the encrypted application with EVENT_CLASS_LOAD_HOOK, in order
    > to dump the classes there, and failed. 2) I altered the method
    > java.lang.ClassLoader.defineClass(ProtectionDomain ...) to dump the
    > classes there, and also failed.
    >
    >> Create a very simple application (one trivial class file for instance)
    >> that you encrypt with their tool and then start looking into what they
    >> actually do. Most probably, they just encrypt the class file and then
    >> install a custom ClassLoader to decrypt it.

    >
    > I already created an encrypted application (as you suggested). The
    > encrypted application consists of a dll file, and a jar file containing
    > entries that are probably my encrypted class files + an additional class
    > which has practically nothing in it (only a main method which is calling
    > a native method).
    >
    > My idea is that they are doing the loading of the classes from the dll,
    > but even so, they must use some ClassLoader that is not encrypted, and I
    > couldn't even see that class.


    I haven't looked at it, but maybe the classloader is implemented in the
    DLL as a native method, and the additional class that has practically
    nothing in it is the classloader?

    --
    Keep American Families united! Support H.R. 539 and H.R. 832
    For more information, see http://www.kkeane.com/lobbyspousal-faq.shtml
     
    Ingo Pakleppa, Jul 18, 2003
    #10
  11. On Thu, 17 Jul 2003 16:11:14 +0100, "Chris Uppal"
    <-THIS.org> wrote:
    > Incidentally, if that *is* what they are doing, then setting up a "fake"
    > jvm.dll that forwards the API to a real JVM, but also collects the decoded
    > bytecode, would be an attack on their system. Off the top of my head, I can't
    > think of a defense against that. (Or they may be using JNI to inject a
    > decrypting classloader into the JVM instead, or as well, which would make it a
    > little more awkward.)


    They are using an internal classloader. But your suggestion will
    work, just front end JVM_DefineClass in jvm.dll. I popped a test
    app into the msdev debugger and put a break point into JVM_DefineClass
    and voila, the fourth entry into this function is the main class
    of my test app. Following the buffer pointer leads me to the
    plaintext bytecode of my class. It took me all of an hour or so
    to find the plain bytecode.

    Another approach that will work is to make some custom mods to the
    JVM_DefineClass function using the JVM source code (which is free
    to everyone). On entry just dump the bytecodes out to a file and
    run through a decompiler. Very simple to do and you have a
    custom JVM made for cracking this encryption scheme.

    --Joe
     
    Joseph Millar, Jul 18, 2003
    #11
  12. Koleho

    Nigel Wade Guest

    Joona I Palaste wrote:

    > Koleho <> scribbled the following:
    >> Hello,

    >
    >> This company (http://www.new-era-soft.com) claims they have a new
    >> method to protect Java against de-compilation, and it is NOT
    >> obfuscation.

    >
    >> Has anyone tried their product yet ?

    >
    >> What do you think about it ?

    >
    >> What tests can I do to check if it is really good ?

    >
    >> Thanks.

    >
    > Its platform requirements specify it's for Windows only, so I won't be
    > bothering.
    >


    Quite.

    If you want your code to only be run on Windows why were you writing in Java
    in the first place?

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Jul 18, 2003
    #12
  13. In article <bf8l05$44p$>,
    Nigel Wade <> wrote:
    >
    >If you want your code to only be run on Windows why were you writing in Java
    >in the first place?


    Are you saying that multi-platform capability is Java's only redeeming
    feature?

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jul 18, 2003
    #13
  14. Bent C Dalager wrote:
    >
    > I seriously doubt they've found a bullet-proof way
    > of securing the bytecode.


    Which is a specious goal to begin with.
     
    Brandon Blackmoor, Jul 18, 2003
    #14
  15. In article <bf9c9h$cncp7$-berlin.de>,
    Brandon Blackmoor <> wrote:
    >
    >Which is a specious goal to begin with.


    Well, someone with more confidence than I would have pointed out that
    it's fundamentally impossible, sans some custom hardware within your
    computer working the deencryption magic very close to the CPU.

    And even then, it would only be unbreakable so long as electron
    microscopes are beyond the budget of the average cracker :)

    Cheers
    Bent D
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jul 18, 2003
    #15
  16. Koleho

    Roedy Green Guest

    On Fri, 18 Jul 2003 13:54:59 -0400, Brandon Blackmoor
    <> wrote or quoted :

    >> I seriously doubt they've found a bullet-proof way
    > > of securing the bytecode.


    It never has to be bulletproof, just more costly to break than
    reproducing the code from scratch.

    The ultimate way to keep out hackers is to keep some of the code on
    the server, never inspectable by the hacker. This requires a reliable
    high speed link for all your customers. We are almost there.

    For some sorts of calculation, you might even be able to do it faster
    that way.

    I have written about techniques to drive hackers mad trying to defang
    your protection. See http://mindprod.com/jgloss/obfuscator.html

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 18, 2003
    #16
  17. Roedy Green wrote:

    > On Fri, 18 Jul 2003 13:54:59 -0400, Brandon Blackmoor
    > <> wrote or quoted :
    >
    >
    >>>I seriously doubt they've found a bullet-proof way
    >>>of securing the bytecode.

    >
    >
    > It never has to be bulletproof, just more costly to break than
    > reproducing the code from scratch.
    >
    > The ultimate way to keep out hackers is to keep some of the code on
    > the server, never inspectable by the hacker. This requires a reliable
    > high speed link for all your customers. We are almost there.


    Ah an optimist. Most of my colleagues can only dream of high speed
    access (at home).

    Mark Thornton
     
    Mark Thornton, Jul 18, 2003
    #17
  18. Koleho

    Roedy Green Guest

    On Thu, 17 Jul 2003 16:11:14 +0100, "Chris Uppal"
    <-THIS.org> wrote or quoted :

    >Incidentally, if that *is* what they are doing, then setting up a "fake"
    >jvm.dll that forwards the API to a real JVM, but also collects the decoded
    >bytecode, would be an attack on their system.


    These poor locksmiths. They build magnificent locks and fail to
    consider all the ways around the lock.

    I remember the look of dreadful embarrassment when a team came to
    demonstrate their uncrackable encryption of user files to our PC user
    group. I cracked it in a few minutes by guessing they had failed to
    wipe the original user file after encryption.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 18, 2003
    #18
  19. Koleho

    Eric Sosman Guest

    Roedy Green wrote:
    >
    > On Fri, 18 Jul 2003 13:54:59 -0400, Brandon Blackmoor
    > <> wrote or quoted :
    >
    > >> I seriously doubt they've found a bullet-proof way
    > > > of securing the bytecode.

    >
    > It never has to be bulletproof, just more costly to break than
    > reproducing the code from scratch.


    No, it only needs to be more costly than the cost of
    paying for the program. (If you're able to charge more for
    the program than it cost to write, you've got an enviable
    business model ...)

    --
     
    Eric Sosman, Jul 18, 2003
    #19
  20. Koleho

    Roedy Green Guest

    On Fri, 18 Jul 2003 11:29:26 +0000 (UTC), (Bent C
    Dalager) wrote or quoted :

    >Are you saying that multi-platform capability is Java's only redeeming
    >feature?


    it is the source of most Java virtue. Multiplatform helps peel off
    silly barnacles.

    Java tends to do things is a straightforward way.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 18, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew Zimmer

    Java code obfuscation

    Matthew Zimmer, Feb 10, 2004, in forum: Java
    Replies:
    16
    Views:
    944
  2. Replies:
    18
    Views:
    9,945
    AdrianC
    Sep 19, 2010
  3. Biggmatt
    Replies:
    0
    Views:
    483
    Biggmatt
    Apr 19, 2006
  4. David A. Black

    a new delegation technique :-)

    David A. Black, Feb 24, 2005, in forum: Ruby
    Replies:
    3
    Views:
    78
    Robert Klemme
    Feb 24, 2005
  5. Julia Briggs
    Replies:
    1
    Views:
    120
    G Roydor
    Jul 5, 2004
Loading...

Share This Page