copy protection / IP protection

Discussion in 'Java' started by g, Apr 18, 2006.

  1. g

    g Guest

    Hello,

    I need to build a WAR/JAR that will need to fulfil the following
    requirements:

    1. The code will only work for a trial period (30 days)
    2. The code can be unlocked with a key
    3. Unlocking the code will watermark the WAR/JAR with a unique key

    I do not want to reinvent the wheel and would love to hear from other
    folks that have experience with this type of packaging. Are there any
    off-the-shelf solutions?

    Cheers,
    Godfrey Hobbs

    blog: http://blogs.ebusiness-apps.com/godfrey/
    g, Apr 18, 2006
    #1
    1. Advertising

  2. "g" <> wrote in message
    news:...
    > Hello,
    >
    > I need to build a WAR/JAR that will need to fulfil the following
    > requirements:
    >
    > 1. The code will only work for a trial period (30 days)
    > 2. The code can be unlocked with a key
    > 3. Unlocking the code will watermark the WAR/JAR with a unique key
    >
    > I do not want to reinvent the wheel and would love to hear from other
    > folks that have experience with this type of packaging. Are there any
    > off-the-shelf solutions?


    Keep in mind you will likely be limited by the system clock - your app won't
    know if the time has been tampered with.

    It wouldn't be hard to encrypt a single vital class and then have it loaded
    with a class loader.

    Keep in mind that marking the JAR file as "Activated" will leave the system
    open to simply copying the activated JAR file.

    I'm not familiar with off the shelf products for this - but I imagine that
    trying to keep it strictly non platform dependant would inhibit your ability
    to copy protect. You might want to consider special cases for the most
    likely platforms to be pirated. Many windows Apps hide a special key deep
    in the registry.

    --
    LTP

    :)
    Luc The Perverse, Apr 18, 2006
    #2
    1. Advertising

  3. g

    Oliver Wong Guest

    "Luc The Perverse" <> wrote in message
    news:...
    > "g" <> wrote in message
    > news:...
    >> Hello,
    >>
    >> I need to build a WAR/JAR that will need to fulfil the following
    >> requirements:
    >>
    >> 1. The code will only work for a trial period (30 days)
    >> 2. The code can be unlocked with a key
    >> 3. Unlocking the code will watermark the WAR/JAR with a unique key
    >>
    >> I do not want to reinvent the wheel and would love to hear from other
    >> folks that have experience with this type of packaging. Are there any
    >> off-the-shelf solutions?

    >
    > Keep in mind you will likely be limited by the system clock - your app
    > won't know if the time has been tampered with.


    To mitigate against this, the app could store (perhaps within the
    encrypted class file) the current time at reasonable intervals, and if it
    detects "going backwards in time", to assume the user is doing something
    illegal and act accordingly.

    >
    > It wouldn't be hard to encrypt a single vital class and then have it
    > loaded with a class loader.


    Except to decrypt it, you'd have to store the key somewhere within the
    JAR, and a sufficiently intelligent hacker could find that key and defeat
    your system. This might not be too difficult since, for example, you could
    use the Eclipse debugger to step through the JAR and see what's going on
    (and the contents of all variables, for examples).

    >
    > Keep in mind that marking the JAR file as "Activated" will leave the
    > system open to simply copying the activated JAR file.


    I think the OP already took this into consideration, which is why the
    activation key should watermark the JAR (so that the company can track down
    the source of the leak).

    >
    > I'm not familiar with off the shelf products for this.


    Me neither. I only have theoretical knowledge on the topic, nothing
    practical. Sorry.

    - Oliver
    Oliver Wong, Apr 18, 2006
    #3
  4. g

    Guest

    , Apr 18, 2006
    #4
  5. "Oliver Wong" <> writes:

    > Except to decrypt it, you'd have to store the key somewhere within
    > the JAR, and a sufficiently intelligent hacker could find that key
    > and defeat your system.


    A sufficiently intelligent hacker can defeat any system that can run
    standalone once.

    If the key is stored in the jar file, and it is digitally signed, then
    the key itself could be used as the "brand" of an activated version.

    The signed key file must then contain enough information to identify
    it, and could also contain an expirery date (so the 30 day trial period
    would just be a normal key that expires).

    Again, a sufficiently intelligent hacker will be able to reverse
    engineer the class that checks the signature (or does whatever check
    or decryption that is not necessary to the functionality of the
    program) and create a functionally identical one without that check.
    It's the curse of any program that doesn't communicate with a server,
    it's impossible to prevent it being cracked. That's why people usually
    settle for "hard", not "impossible".

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Apr 18, 2006
    #5
  6. g

    Roedy Green Guest

    On Wed, 19 Apr 2006 00:19:02 +0200, Lasse Reichstein Nielsen
    <> wrote, quoted or indirectly quoted someone who said :

    >A sufficiently intelligent hacker can defeat any system that can run
    >standalone once.


    You can make cracking considerably harder if you insist on an online
    connection at least to start the app.

    That makes it much harder to do experiments without being detected,
    and allows you to change the rules as often as you please.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 19, 2006
    #6
  7. "Oliver Wong" <> wrote in message
    news:M4b1g.71357$K11.23128@clgrps12...
    >
    > "Luc The Perverse" <> wrote in message
    > news:...
    >> "g" <> wrote in message
    >> news:...
    >>> Hello,
    >>>
    >>> I need to build a WAR/JAR that will need to fulfil the following
    >>> requirements:
    >>>
    >>> 1. The code will only work for a trial period (30 days)
    >>> 2. The code can be unlocked with a key
    >>> 3. Unlocking the code will watermark the WAR/JAR with a unique key
    >>>
    >>> I do not want to reinvent the wheel and would love to hear from other
    >>> folks that have experience with this type of packaging. Are there any
    >>> off-the-shelf solutions?

    >>
    >> Keep in mind you will likely be limited by the system clock - your app
    >> won't know if the time has been tampered with.

    >
    > To mitigate against this, the app could store (perhaps within the
    > encrypted class file) the current time at reasonable intervals, and if it
    > detects "going backwards in time", to assume the user is doing something
    > illegal and act accordingly.
    >
    >>
    >> It wouldn't be hard to encrypt a single vital class and then have it
    >> loaded with a class loader.

    >
    > Except to decrypt it, you'd have to store the key somewhere within the
    > JAR, and a sufficiently intelligent hacker could find that key and defeat
    > your system. This might not be too difficult since, for example, you could
    > use the Eclipse debugger to step through the JAR and see what's going on
    > (and the contents of all variables, for examples).



    You will find this problem with ANY non hardware based solution.

    I think the idea is to keep most people honest, not everyone.

    I for one would not hesitate to change a registered = NO to registered = YES
    in an INI file - but would draw the line at disassembly of the jar file ;)

    --
    LTP

    :)
    Luc The Perverse, Apr 19, 2006
    #7
  8. "Roedy Green" <> wrote in
    message news:...
    > On Wed, 19 Apr 2006 00:19:02 +0200, Lasse Reichstein Nielsen
    > <> wrote, quoted or indirectly quoted someone who said :
    >
    >>A sufficiently intelligent hacker can defeat any system that can run
    >>standalone once.

    >
    > You can make cracking considerably harder if you insist on an online
    > connection at least to start the app.
    >
    > That makes it much harder to do experiments without being detected,
    > and allows you to change the rules as often as you please.


    As Microsoft has discovered and employed.

    --
    LTP

    :)
    Luc The Perverse, Apr 19, 2006
    #8
  9. g

    Roedy Green Guest

    On Tue, 18 Apr 2006 23:04:56 GMT, Roedy Green
    <> wrote, quoted or
    indirectly quoted someone who said :

    >That makes it much harder to do experiments without being detected,
    >and allows you to change the rules as often as you please.


    It makes it harder for the hacker to do experiments and allows the
    vendor to change the copy protection scheme as often as he pleases.

    Aspect programming might be a way of weaving the copy protection
    through everything so there is not one easy code point to defang.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 19, 2006
    #9
  10. g

    James McGill Guest

    On Wed, 2006-04-19 at 00:19 +0200, Lasse Reichstein Nielsen wrote:
    > "Oliver Wong" <> writes:
    >
    > > Except to decrypt it, you'd have to store the key somewhere within
    > > the JAR, and a sufficiently intelligent hacker could find that key
    > > and defeat your system.

    >
    > A sufficiently intelligent hacker can defeat any system that can run
    > standalone once.


    Real copy protection involves punitive terms in the lease contract and a
    stipulationt that no one shall have physical access to the system except
    while accopmained by your representative.

    Fortunately that scenario more or less ended when the mainframe/leased
    datacenter stopped being the norm. Unfortunately, we still find people
    who seriously desire the benefits of that model, but have no way to
    deploy such a thing.

    Now in the contemporary scenario, to have your cake and eat it too, you
    must compromise. You want to allow people to anonymously obtain and use
    your software (have your cake). You also want to limit their use
    through some form of cryptographic protection scheme. So you have to
    give them a key. Maybe you can go old-school, and give a field agent
    some key that will boot the system, but will not be disclosed to the
    customer. Or maybe you can do it like Microsoft does and force the
    system to call home and get a one-way hash based on hardware parameters
    or something like that. Or maybe you can use a dongle like ILok.

    If you don't do something like this, then you have to give the customer
    the key (eat it too). Sure, you might be able to hide it. Very
    intelligent attempts have been made, and failed. The bottom line is,
    either you give the customer the unlock key, and take the risk that it
    will be discovered, or you keep the key, and take on the expense and
    complexity of managing that relationship.

    In the old days, when the equipment was leased from Unisys or IBM, and
    simply would not be operated without the contractor present, it might
    have been possible to control distribution, at least to the extent you
    could trust your employees. Likewise, in a military scenario, you can
    control distribution, because you can make it a crime for which the last
    person who knew or should have known that the disclosure would be made,
    can be executed for treason or whatever.

    I suppose there are less extreme cases for which you must make a
    due-diligence effort to put some kind of controls in place, but I
    personally do not prefer illusory security to no security.

    An example. I had a lock on the security screen door, the outer front
    door to my house, which would sometimes not lock. It looked like it
    locked, but sometimes you could turn the inner barrel without a key.
    I found this to be inferior security to simply removing the lock.
    Opinions vary on this, but I stand by mine.
    James McGill, Apr 19, 2006
    #10
  11. g

    James McGill Guest

    On Tue, 2006-04-18 at 17:10 -0600, Luc The Perverse wrote:

    > As Microsoft has discovered and employed.


    Hi! We consider you and your employees to be thieves! That said, we
    also think we have enough market force to make you forget about that and
    buy our product anyway!
    James McGill, Apr 19, 2006
    #11
  12. g

    Roedy Green Guest

    On Tue, 18 Apr 2006 18:21:47 -0700, James McGill
    <> wrote, quoted or indirectly quoted someone
    who said :

    >Hi! We consider you and your employees to be thieves! That said, we
    >also think we have enough market force to make you forget about that and
    >buy our product anyway!


    First of all it is statistically most likely true that you and your
    employees are thieves. People don't buy software if they can steal
    it. They don't consider it stealing since they don't deprive others of
    use.

    It is legit to prevent theft so long as you don't inconvenience
    legitimate users. Microsoft has gone to extreme lengths so antagonise
    honest users making backup/restore impossible without a full
    reinstall from scratch (similarly for migrating an app to a different
    drive, or upgrading a hard disk.)

    Second, just because I have a lock on my door does not mean I believe
    everyone who comes to it intends me harm. Even if only one in 10,000
    does, you still need the lock. For software, you would not need the
    lock if only 1 in 100 stole, since you are not actively harmed, just
    deprived of potential revenue by a theft.

    There is a ratio of about 15,000 to 1 downloads to shareware
    registrations if the registration is purely voluntary, with no
    hobbling.



    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 19, 2006
    #12
  13. g

    Roedy Green Guest

    On Tue, 18 Apr 2006 18:15:11 -0700, James McGill
    <> wrote, quoted or indirectly quoted someone
    who said :

    > It looked like it
    >locked, but sometimes you could turn the inner barrel without a key.
    >I found this to be inferior security to simply removing the lock.
    >Opinions vary on this, but I stand by mine.


    I can see someone deterred, discouraged by the dummy lock, not
    bothering to try. Under what circumstances would no lock at all be
    superior to that? Is the attacker supposed to presume there must then
    be some much more serious device installed?

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Apr 19, 2006
    #13
  14. g

    James McGill Guest

    On Wed, 2006-04-19 at 02:15 +0000, Roedy Green wrote:
    >
    >
    > First of all it is statistically most likely true that you and your
    > employees are thieves.


    Perhaps, but that doesn't make it a good opener for your sales pitch.
    James McGill, Apr 19, 2006
    #14
  15. g

    James McGill Guest

    On Wed, 2006-04-19 at 02:18 +0000, Roedy Green wrote:
    > Under what circumstances would no lock at all be
    > superior to that?


    I did not rest assured that the door appeared to be locked, even though
    I knew the lock was defective. It wasn't the only lock on the house,
    otherwise it would have been *an emergency*. As it happened, with the
    lock removed, I did not have any excuse to pretend the door was locked,
    but since it was a relatively minor risk, I could take a day or two
    before going to the hardware store.

    Had I left the defective lock on there, it might still be there.
    James McGill, Apr 19, 2006
    #15
  16. "James McGill" <> wrote in message
    news:...
    > On Wed, 2006-04-19 at 02:15 +0000, Roedy Green wrote:
    >>
    >>
    >> First of all it is statistically most likely true that you and your
    >> employees are thieves.

    >
    > Perhaps, but that doesn't make it a good opener for your sales pitch.
    >


    Well they have done a good job of marketing it.

    And yes - most of us are thieves - and I stopped being a thief because I was
    afraid of Microsoft and didn't like hacks and stuff. It worked - and they
    have probably directly gained from me.

    --
    LTP

    :)
    Luc The Perverse, Apr 19, 2006
    #16
  17. "James McGill" <> wrote in message
    news:...
    > On Wed, 2006-04-19 at 02:18 +0000, Roedy Green wrote:
    >> Under what circumstances would no lock at all be
    >> superior to that?

    >
    > I did not rest assured that the door appeared to be locked, even though
    > I knew the lock was defective. It wasn't the only lock on the house,
    > otherwise it would have been *an emergency*. As it happened, with the
    > lock removed, I did not have any excuse to pretend the door was locked,
    > but since it was a relatively minor risk, I could take a day or two
    > before going to the hardware store.
    >
    > Had I left the defective lock on there, it might still be there.
    >


    I'm sorry but I think you are taking the simile a bit too far.

    Some hacked copies of software are generally considered acceptable.
    However, the security of a house being compromised seems a little more
    serious

    --
    LTP

    :)
    Luc The Perverse, Apr 19, 2006
    #17
  18. g

    James McGill Guest

    On Tue, 2006-04-18 at 21:06 -0600, Luc The Perverse wrote:
    >
    > Well they have done a good job of marketing it.


    Only the biggest players get away with it. It's not a strategy that can
    be generally adopted with any expectation of success.
    James McGill, Apr 19, 2006
    #18
  19. g

    Roedy Green Guest

    Roedy Green, Apr 19, 2006
    #19
  20. "James McGill" <> wrote in message
    news:...
    > On Tue, 2006-04-18 at 21:06 -0600, Luc The Perverse wrote:
    >>
    >> Well they have done a good job of marketing it.

    >
    > Only the biggest players get away with it. It's not a strategy that can
    > be generally adopted with any expectation of success.
    >


    Perhaps not, but the little guy has a hard enough time just getting people
    to believe his/her product is worthwhile. I hardly doubt that many people
    would be returning the product if they found out it needed to be activated
    after they had already paid money for it.

    And if it is a shareware package as was suggested by the OP - the
    registration/activation could be transparently integrated with purchasing.

    --
    LTP

    :)
    Luc The Perverse, Apr 19, 2006
    #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. John

    Copy protection software

    John, Feb 15, 2006, in forum: ASP .Net
    Replies:
    20
    Views:
    4,112
    sotwr9
    Apr 28, 2009
  2. Max

    Best Copy Protection Methods

    Max, Dec 9, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    612
  3. ed091maf

    J2ME copy protection

    ed091maf, Aug 4, 2003, in forum: Java
    Replies:
    1
    Views:
    1,010
    Darryl L. Pierce
    Aug 5, 2003
  4. Alex
    Replies:
    2
    Views:
    1,203
  5. Replies:
    26
    Views:
    2,092
    Roland Pibinger
    Sep 1, 2006
Loading...

Share This Page