putting a licence key in a java program

Discussion in 'Java' started by Andy Fish, Jun 21, 2004.

  1. Andy Fish

    Andy Fish Guest

    Hi,

    I want to add a licence key to my java program - some kind of encrypted
    string that tells the program what features are and aren't available etc.

    Here's the problem - say I have a class like this:

    class LicenceKey()
    {
    LicenceKey(String s) {...}
    Date getLicenceExpiryDate() {...}
    boolean isFeatureXEnabled() {...}
    boolean isFeatureYEnabled() {...}
    }

    then someone else can just delete that class out of my JAR, and replace it
    with their own class with the same method signatures that behaves as if any
    licence key was valid.

    is there any "proper" way round this (i.e. other than obfuscation)?

    Andy
     
    Andy Fish, Jun 21, 2004
    #1
    1. Advertising

  2. Andy Fish

    Roedy Green Guest

    On Mon, 21 Jun 2004 07:47:59 GMT, "Andy Fish"
    <> wrote or quoted :

    >then someone else can just delete that class out of my JAR, and replace it
    >with their own class with the same method signatures that behaves as if any
    >licence key was valid.
    >
    >is there any "proper" way round this (i.e. other than obfuscation)?


    If you think about it, the problem is intractable. Anything your
    program can do so can the hacker.

    If you insist on an internet connection, you can put part of the
    program on the server, away from the hacker's prying eyes. Then your
    problem becomes keeping the hacker off your website, or shutting him
    out once you discover what he is up to.

    See http://mindprod.com/jgloss/obfuscator.html
    for some of the tricks of psychological warfare.

    You pretty well have to weave your security code all through your app.
    If you nicely fence it off, you make the hacker's job very easy.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jun 21, 2004
    #2
    1. Advertising

  3. Andy Fish

    JScoobyCed Guest

    "Andy Fish" <> wrote

    > Hi,
    >
    > I want to add a licence key to my java program - some kind of encrypted
    > string that tells the program what features are and aren't available etc.
    >
    > Here's the problem - say I have a class like this:
    >
    > class LicenceKey()
    > {
    > LicenceKey(String s) {...}
    > Date getLicenceExpiryDate() {...}
    > boolean isFeatureXEnabled() {...}
    > boolean isFeatureYEnabled() {...}
    > }
    >
    > then someone else can just delete that class out of my JAR, and replace it
    > with their own class with the same method signatures that behaves as if

    any
    > licence key was valid.


    That's sooo right

    >
    > is there any "proper" way round this (i.e. other than obfuscation)?
    >


    Unfortunately, there is no real solution. Let's say you calculate the
    MD5/CRC/whatever of your LicenceKey.class and store it in the jar, then each
    time you access the class you calculate it and compare with the stored one,
    there is still a possibility :
    1. to replace your stored MD5 ;
    or 2. to replace the method the compute the differences
    At the end there is always a way to replace your code by other, and sign it,
    encrypt it, do whatever you want of it. This is a truely Open-Source world
    :)
    Now you could find some solutions through JNI, but 'adios' the
    cross-plateforme solution. Or you can compile a native library for each OS
    you need the software to run (and provide an update for each new versions of
    OS...)

    Now this is only my point of view, there might be something working (a
    strong brainstorming is probably the origin of it, or some genius Java
    Guru)... And if any please post on this forum :)

    JScoobyCed
    -------------
     
    JScoobyCed, Jun 21, 2004
    #3
  4. Andy Fish wrote:
    > is there any "proper" way round this (i.e. other than obfuscation)?


    No. If you give them the code, you cannot prevent them from changing
    it, only make it more difficult, basically through obfuscation.
     
    Michael Borgwardt, Jun 21, 2004
    #4
  5. Andy Fish

    Jacob Guest

    Andy Fish wrote:

    > is there any "proper" way round this (i.e. other than obfuscation)?


    Open Source.
     
    Jacob, Jun 21, 2004
    #5
  6. JScoobyCed wrote:
    > Now you could find some solutions through JNI, but 'adios' the
    > cross-plateforme solution.


    It won't help anyway. At some point the native code will be called from
    some other Java class to make a decision. Change that Java class to not
    call the native method, or just replace the native code with something else.

    > Now this is only my point of view, there might be something working (a
    > strong brainstorming is probably the origin of it, or some genius Java
    > Guru)... And if any please post on this forum :)


    The whole issue is not Java specific at all. All these simple license
    management schemata can be hacked the same way: Find the place where the
    decision is made, and replace the decision-making code. Nothing new
    here. Java maybe makes the code replacement simpler. You don't have to
    patch a binary, you can replace a class in a jar. But it is still the
    same old game. You can raise the bar by adding more checks, and checks
    of checks, but in the end, it can be hacked.

    /Thomas
     
    Thomas Weidenfeller, Jun 21, 2004
    #6
  7. Andy Fish

    JScoobyCed Guest

    "Thomas Weidenfeller" <> wrote
    > JScoobyCed wrote:
    > > Now you could find some solutions through JNI, but 'adios' the
    > > cross-plateforme solution.

    >
    > It won't help anyway. At some point the native code will be called from
    > some other Java class to make a decision. Change that Java class to not
    > call the native method, or just replace the native code with something

    else.
    >


    That's right.

    > > Now this is only my point of view, there might be something working (a
    > > strong brainstorming is probably the origin of it, or some genius Java
    > > Guru)... And if any please post on this forum :)

    >
    > The whole issue is not Java specific at all. All these simple license
    > management schemata can be hacked the same way: Find the place where the
    > decision is made, and replace the decision-making code. Nothing new
    > here. Java maybe makes the code replacement simpler. You don't have to
    > patch a binary, you can replace a class in a jar. But it is still the
    > same old game. You can raise the bar by adding more checks, and checks
    > of checks, but in the end, it can be hacked.
    >


    Sure... Just see how much software companies are spending money on license
    or serial numbers, and how easily it is hacked on some crackers/hackers
    webistes :)

    JScoobyCed
    -------------
     
    JScoobyCed, Jun 21, 2004
    #7
  8. Andy Fish

    Rene Guest

    > I want to add a licence key to my java program - some kind of encrypted
    > string that tells the program what features are and aren't available etc.
    >
    > Here's the problem - say I have a class like this:
    >
    > class LicenceKey()
    > {
    > LicenceKey(String s) {...}
    > Date getLicenceExpiryDate() {...}
    > boolean isFeatureXEnabled() {...}
    > boolean isFeatureYEnabled() {...}
    > }
    >
    > then someone else can just delete that class out of my JAR, and replace
    > it with their own class with the same method signatures that behaves as
    > if any licence key was valid.
    >
    > is there any "proper" way round this (i.e. other than obfuscation)?


    Dunno about proper, but if it is worth the time, consider writing your own
    Classloader and make the "licence-key" contain the actual needed code in
    encrypted form. For example, key one contains the (encrypted) byte-code for
    method B and C and key two contains the byte-code for method A. Easy mixing
    of the keys can be prevented by using proper encryption and integrity
    mechanisms. Simply switching some feature on is also not possible since the
    code for that (method F) just isn't there in the first place.

    Be aware, however, that it is still possible to defeat this scheme by
    having the proper key and changing the code somewhere else so that they can
    get at the encrypted byte-code after validation and save it down in a
    normal class. For every feature the attacker would need to have a valid key
    first though. But it can also be defeated (to avoid a recurring cost or so)
    - but it is quite a bit more difficult to do so. The drawback is, it is of
    course also more difficult to implement.

    Another method is to use a system that loads classes from your server via
    internet and URLClassLoader. Can be defeated the same way as above and
    requires an internet connection to your server but is easier to deploy.

    The problem in itself is non-solvable as others have already commented.
    It's up to you to decide how much effort and time you want to invest in
    order to make it more difficult for an attacker. Evaluate market share and
    "value" your product will have and how much incentive an attacker has to
    break your system - then decide what you'll do. Maybe making the license
    cheaper but forget any protection might also be an option, depending on the
    evaluation.

    CU

    René

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    Rene, Jun 21, 2004
    #8
  9. Andy Fish

    Andy Fish Guest

    "Rene" <> wrote in message
    news:20040621095802.122$...

    > The problem in itself is non-solvable as others have already commented.
    > It's up to you to decide how much effort and time you want to invest in
    > order to make it more difficult for an attacker. Evaluate market share and
    > "value" your product will have and how much incentive an attacker has to
    > break your system - then decide what you'll do. Maybe making the license
    > cheaper but forget any protection might also be an option, depending on

    the
    > evaluation.
    >


    Thanks for all the replies.

    To be honest, my customers are corporates and I mainly want to discourage
    accidental or semi-accidental violation of the licence conditions.

    I've decided that I will put an encrypted key in, but have the functionality
    that processes that key inside another class that is required for correct
    operation of the software. That way someone who wants to circumvent it will
    have to decompile and reconstruct the class rather than just substititing
    one of their own

    Andy
     
    Andy Fish, Jun 21, 2004
    #9
  10. Andy Fish

    Roedy Green Guest

    On Mon, 21 Jun 2004 15:32:20 +0700, "JScoobyCed" <>
    wrote or quoted :

    >Now this is only my point of view, there might be something working (a
    >strong brainstorming is probably the origin of it, or some genius Java
    >Guru)... And if any please post on this forum :)


    You don't have to make code uncrackable, just difficult enough that
    the game is not worth the candle. If you offer frequent updates and
    code that is time limited, then the hackers have to keep starting over
    from scratch.

    It also works on customers who don't pay bills. You send them code
    that stops working after two months unless they key in a passcode.
    You don't give them the passcode until they pay the bill.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jun 21, 2004
    #10
  11. Andy Fish

    Roedy Green Guest

    On Mon, 21 Jun 2004 17:03:31 +0700, "JScoobyCed" <>
    wrote or quoted :

    >Sure... Just see how much software companies are spending money on license
    >or serial numbers, and how easily it is hacked on some crackers/hackers
    >webistes :)


    The key is to overwhelm them with what LOOKS like complicated security
    code but is actually just insanity. You wear them out proving to
    themselves it is nonsense. Further you layer your defences so they
    think they have won, only to discover days or weeks later they have
    not. They never know when they have fully hacked the program.

    You must disguise security code as application code and vice versa.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jun 21, 2004
    #11
  12. Casey Hawthorne, Jun 21, 2004
    #12
  13. Roedy Green wrote:
    > It also works on customers who don't pay bills. You send them code
    > that stops working after two months unless they key in a passcode.
    > You don't give them the passcode until they pay the bill.


    Also known as "trial version".
     
    Michael Borgwardt, Jun 22, 2004
    #13
  14. Andy Fish

    Roedy Green Guest

    On Tue, 22 Jun 2004 10:00:14 +0200, Michael Borgwardt
    <> wrote or quoted :

    >Also known as "trial version".


    in my case this is custom written software.

    Writing custom software for customers you meet on the Internet can be
    problematic. If they don't pay, you can't very well take them to
    small debts court.

    The main clue you get the guy is going to stiff you is the way he
    makes many unusually strenuous demands.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jun 22, 2004
    #14
    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. JavaJug

    Java licence

    JavaJug, May 19, 2004, in forum: Java
    Replies:
    0
    Views:
    446
    JavaJug
    May 19, 2004
  2. Saurabh
    Replies:
    6
    Views:
    4,617
    Chris Smith
    May 30, 2004
  3. Ravi Shankar
    Replies:
    6
    Views:
    37,494
    Eugen Kocak
    Jan 30, 2010
  4. Dave
    Replies:
    2
    Views:
    607
    Kai-Uwe Bux
    May 16, 2005
  5. NH
    Replies:
    2
    Views:
    291
    Michael Nemtsev [MVP]
    Feb 21, 2008
Loading...

Share This Page