copy protection / IP protection

G

g

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

Luc The Perverse

g said:
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.
 
O

Oliver Wong

Luc The Perverse said:
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
 
L

Lasse Reichstein Nielsen

Oliver Wong said:
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
 
R

Roedy Green

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

Luc The Perverse

Oliver Wong said:
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.


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 ;)
 
L

Luc The Perverse

Roedy Green said:
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.
 
R

Roedy Green

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

James McGill

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

James McGill

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

Roedy Green

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

Roedy Green

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

James McGill

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

James McGill

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

Luc The Perverse

James McGill said:
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.
 
L

Luc The Perverse

James McGill said:
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
 
J

James McGill

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

Luc The Perverse

James McGill said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,043
Latest member
CannalabsCBDReview

Latest Threads

Top