putting a licence key in a java program

A

Andy Fish

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
 
R

Roedy Green

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

JScoobyCed

Andy Fish said:
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
-------------
 
M

Michael Borgwardt

Andy said:
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.
 
T

Thomas Weidenfeller

JScoobyCed said:
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
 
J

JScoobyCed

Thomas Weidenfeller said:
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.
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
-------------
 
R

Rene

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

Andy Fish

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
 
R

Roedy Green

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

Roedy Green

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

Michael Borgwardt

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

Roedy Green

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.
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top