Java and avoiding software piracy?

A

adamorn

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Please let me know what your thoughts are as to how to achieve this.
Strategies? Resources?

Please send them my way!

Thanks!
 
A

Ashoka!

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Please let me know what your thoughts are as to how to achieve this.
Strategies? Resources?

Please send them my way!

Thanks!

Depends on how may people are going to be using the paid version you
can make a small application that collects several system properties
like size of hard disk etc and use these as a seeds for a random
number generator. The random number will be sent to your server to get
a corresponding key. You will then mark that key as used and not allow
future registration on it. On the down side every time the users
change system configuration they will require a new key. You can
manage this by asking them to enter private info like credit card
number (you already have this because you charged them the first
time).

Its not foolproof and needs some work on the concept but you get the
picture.

regards
Usman Ismail
 
K

~kurt

Ashoka! said:
Depends on how may people are going to be using the paid version you
can make a small application that collects several system properties
like size of hard disk etc and use these as a seeds for a random
number generator. The random number will be sent to your server to get
a corresponding key. You will then mark that key as used and not allow
future registration on it. On the down side every time the users

Lots of computers are not connected to the Internet - just internal
networks. One needs to take this into consideration.

- Kurt
 
R

Roedy Green

You can't. End of discussion.


You are wasting your time.

You don't have to make it impossible. You merely have to make it more
expensive and frustrating than writing the code from scratch. If you
can insist on an Internet connection, then new possibilities open up
to drive pirates insane. There is also the option of native
compilation of highly optimised (and hence naturally obfuscated) code.


See http://mindprod.com/jgloss/obfuscator.html
 
L

Laie Techie

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Please let me know what your thoughts are as to how to achieve this.
Strategies? Resources?

Please send them my way!

Thanks!

There are several free decompilers so it is next to impossible to do what
you're asking.

Jet Brains (the makers of IDEA) store a bunch of information:
* Client Name (hashed)
* Client Number
* Expiration Date
* Expiration Version
* Key

All that stuff is combined together in some undisclosed binary format.
None of their methods returns a simple boolean or Date object. The goal
is to use nondescript method names in nondescript classes. Use of
reflection also makes it harder to crack.

-- Laie Techie
 
B

Bent C Dalager

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Now, this depends a lot on the nature of your application and your
target market, but in the general case chances are that in doing this
you will be destroying whatever market you otherwise might have
had. If you're Microsoft, and therefore ubiqutous, or AutoCAD(*), and
therefore indispensable, you can get away with the unavoidable
inconvenience a copyright protection system causes your users.

In pretty much all other cases, however, your main problem is probably
in creating a user base that desires your product and the best way to
do this is to make it as easy as possible to use your software -
whether it's paid for or not. Adding registration keys, activation
schemes, etc., isn't doing this for you.


* - Or whatever it is they are using these days.

Cheers
Bent D
 
L

Lew

Laie said:
Use of reflection also makes it harder to crack.

and maintain.

Don't use such a thing heavily throughout your code because you think it will
protect you from hackers. Who would then protect you from yourself?

For a small authorization module reflection techniques can be useful. Just
don't go replacing viable algorithms with it wholesale in a vain attempt to
secure your app.
 
A

adamorn

Ive read all the posts, and have to admit requiring an internet
connection isnt bad, seeing how the user has to download the
application to their computer to begin wih. But still, easily
hackable with decompiled code. But the reality is that some people
will pay for it and others will find a way to hack it.

I think I just want to put a relatively thin layer of security behind
it, but I do admit that if it is too easy to hack that it will welcome
all types of hackers, and casual users... So I want to make it at
least somewhat challenging for them. In addition, my other concern is
that my server will go down (the one I pay some godaddy for), and then
the user will try to open their application and have it fail to reach
the server for license verification, making my paid users angry.

On the same thread, if I dont have them hit the server, or rather on
server verification I allow them entry to the application, then a
firewall that blocks the connection will simply give them access to
the full app.

As for a key only, perhaps it is a good way to go. But there are just
infinite key generators out there, so clearly anybody who wants to
will be able to find a hack, unless I release fake hacks.

Thanks for the feedback. While I think it is a bit of a lost cause, I
will do something based on the feedback here and post my final
decisions on the matter for any future reader of this thread.

Thanks
 
A

adamorn

(e-mail address removed) wrote:

..


Charge for support, and drop that other nonsense
of keys.


I think that charging for support will earn me very little $$$... as
it is a little application. But thanks for the interesting thought
 
K

~kurt

Ive read all the posts, and have to admit requiring an internet
connection isnt bad, seeing how the user has to download the
application to their computer to begin wih. But still, easily

What typically happens is the application is downloaded, burnt to a
CD or DVD (maybe even copied to a floppy if it is small enough),
virus scanned according to the company policy, and then installed
on the internal network. If you go this route, then you must have
some way for the user to call in to get their authorization code.
We ran into this with JBuilder - they only had email support listed,
and it took them over a week to get back to us. I'll never buy one
of their products again.

- Kurt
 
R

RedGrittyBrick

my ... concern is
that my server will go down (the one I pay some godaddy for), and then
the user will try to open their application and have it fail to reach
the server for license verification, making my paid users angry.

I may be wrong but I thought that what was being suggested was accessing
an Internet server for initial *registration* after installation, not
for ongoing *verification* on each invocation of the program.

At registration you would retrieve and store a token that the
application would then check at startup - to see if the stored token
matches the gathered hardware fingerprint.

E.g. the token could be the fingerprint and expiry date signed using
your private RSA key. The app would hold your RSA public key and use it
to verify the signature of the fingerprint. Of course a miscreant could
probably hack the bytecode to skip the verification check.

An alternative is to make your application a web-hosted application like
"Google Docs & spreadsheets".
 
T

Twisted

Don't waste your time and effort trying to lock up information. It
will always be either easily copied or unusable, one or the other.

Instead, make money off your ancillary expertise in the software, its
internals, and the problem domain. Your talents in that area are
scarce and rivalrous, so they make sense as private or metered goods.
Charge for customization of someone's install of the software, or for
support beyond basic bug-fixes and how-tos. Open a consultancy, with
the software as testament to your competence in the field. Whatever.
 
J

Joshua Cranmer

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Put only what pertains to the free version in the free version. Don't
even try to have the free version be the pay version with the features
locked out. The pay-only features MUST NOT BE PRESENT IN THE BYTECODE /AT
ALL./ Then only distribute the pay version after people order it.
Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop them
entirely.. I want to do as much as I can to ensure that IF they want to
crack/keygen it, that it will be as difficult as possible.

You're trying to do what just about every major software company is
trying (and failing) to do. Simple online license key verification would
be sufficient; if you're really willing to go far, some code sanity tests
for verification (involving java bytecode assembly and knowledge of
obscure parts of the Java VM specification) would probably trip up 90% of
decompilers. Then again, nesting a few synchronized, finally, conditional
break/continue, and loop statements is practically guaranteed to trip up
a decompiler.
 
L

ldv

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Please let me know what your thoughts are as to how to achieve this.
Strategies? Resources?

Please send them my way!

Thanks!

I'd suggest you take a two step approach:

1. Compile your application down to native code using GCJ or Excelsior
JET:

http://gcc.gnu.org/java/
http://www.excelsior-usa.com/jet.html

It will become about as hard to decompile as if you wrote it in C++.

You may also use a name obfuscator for extra protection:

http://www.excelsior-usa.com/kb/000023.html

2. Protect the resulting native application using a tool of your
choice. Note that Excelsior's tool requires you follow a special
procedure, discussed in their forum:

http://www.excelsior-usa.com/forum/index.php?topic=744.0

Hope this helps,

LDV
 
P

Philipp Leitner

Instead, make money off your ancillary expertise in the software, its
internals, and the problem domain. Your talents in that area are
scarce and rivalrous, so they make sense as private or metered goods.
Charge for customization of someone's install of the software, or for
support beyond basic bug-fixes and how-tos. Open a consultancy, with
the software as testament to your competence in the field. Whatever.

This is only a valid business model under certain circumstances:
- the tool under discussion has to be something "enterprisey", since
only at least medium-sized companies pay for customized software,
support or consultants. If you wrote e.g. a RSS reader or anything
else that definitely targets the single end user you're out of luck.
- the tool has to be obscure / complex / buggy / ... enough so that
consultancy is even necessary. Again: if you have a well-written
little RSS reader it is unlikely that enough questions arise that a
paid support is even necessary.
- you as the author have to be able and willing to dedicate a lot of
the time following into consulting and/or maintaining the software. If
you already have a day job you're unlikely to have enough spare time
that you can spend to follow this business model. Customization takes
time. So does maintaining and supporting an application.

Conclusion: I am definitely a friend of OSS, but the idea that seems
to go around that an OSS business model is the one and only way to
earn some money with software is just bogus.

And for the OP: I wouldn't care too much about crackers and key
generators. Unless your software /really/ catches on the problems
arising from these guys are marginal.

/philipp
 
O

Oliver Wong

Hi,

Im *hoping* to release an application that I developed in Java, and I
want to release a free version as well as a pay version.

Clearly I want to be able to avoid people cracking it, or creating key
generators... Although i know that it is unlikely to actually stop
them entirely.. I want to do as much as I can to ensure that IF they
want to crack/keygen it, that it will be as difficult as possible.

Please let me know what your thoughts are as to how to achieve this.
Strategies? Resources?

Please send them my way!

If you have no idea how to do start, forget about doing it on your
own. All the crackers out there have way more experience than you (because
you have zero experience!) and so you don't stand a chance.

If you really need copyprotection for your software, license a scheme
from a third party. Just be careful not to get a scheme that people
really, really hate (e.g. StarForce).

- Oliver
 
T

Twisted

- the tool under discussion has to be something "enterprisey", since
only at least medium-sized companies pay for customized software,
support or consultants. If you wrote e.g. a RSS reader or anything
else that definitely targets the single end user you're out of luck.
- the tool has to be obscure / complex / buggy / ... enough so that
consultancy is even necessary. Again: if you have a well-written
little RSS reader it is unlikely that enough questions arise that a
paid support is even necessary.

If it's something like a little RSS reader, there's no money to be
made off it anyway, certainly not in a competitive market if you play
fair. If there's no market for the ancillary expertise due to anyone
and his brother being able to do it, there's no market for the
software itself for the same reason. Someone will make something
compatible and sell it cheaper. Someone else will do it and make it
FOSS. You won't be able to compete on price OR quality in this case.
The reason to write such software is when it directly benefits your
own productivity through your own in-house use, and then there's no
reason to be stingy and not open-source it since you derive the
benefits of its direct use anyway, and releasing it encourages quid
pro quo (you may get nice free tools and not have to write them; you
might get bug fixes or suggestions from other users of such stuff
savvy enough to modify the code).
- you as the author have to be able and willing to dedicate a lot of
the time following into consulting and/or maintaining the software. If
you already have a day job you're unlikely to have enough spare time
that you can spend to follow this business model. Customization takes
time. So does maintaining and supporting an application.

If you already have a day job you already have a steady paycheque and
no need to charge for the software.
Conclusion: I am definitely a friend of OSS, but the idea that seems
to go around that an OSS business model is the one and only way to
earn some money with software is just bogus.

The only ways to earn money with software that depend on charging for
access to the software itself are by their nature coercive and
extortionate. They are also doomed in the long term because your
competitors can always undercut you on price without any loss in
quality. Microsoft is learning this lesson right now. They're reaching
for any legal bludgeon they can invent (software patents for example,
or a "trusted computing" mandate) to kill open source competitors by
criminalizing them, all because they cannot compete in a fair and open
market. Only aggressive marketing and questionable business practises
enabled them to become rich in the first place, that and a lack of
access to alternatives for most consumers for a long time before
widespread access to broadband developed in the industrialized parts
of the world.
And for the OP: I wouldn't care too much about crackers and key
generators. Unless your software /really/ catches on the problems
arising from these guys are marginal.

Anybody using such wasn't ever going to pay for the software anyway.
Actually, scratch that -- some of those using such methods would never
pay no matter what. Making it harder might force them to use a
competitor's software but it won't get your hand into their pockets
successfully. On the other hand, some of those who crack it might
later pay, if they derive benefit from the software and decide it's
worth subsidizing its further development and maintenance. More than
those who just play with your crippled free version, who will just be
annoyed by random and arbitrary restrictions and have a generally
terrible user experience that will put them off ever sending you a
dime.

Why not make the full version free, but offer a registration
certificate or something for a certain amount of money? It may turn on
frivolous features of the software or just a personalized greeting or
something, or let you get early access to bugfix-test beta versions or
something. Plenty will just use the software and never send you a
dime, but they'd likely never have sent you a dime no matter what you
did. Others may gladly pay if they know it will finance further
development of the software, including some that never would have if
subjected to any sort of coercion or made to feel obligated to pay.

You could probably get away with giving the fully-functional version
for free and selling a snazzy "pro skin" even. This works for the
Limewire folks. (They also sell T-shirts. The "pro" version isn't
actually any faster than the free one, despite what they claim; it
just tends to make more redundant connections to hubs to make it
slightly more stable in connectivity perhaps.)

Oh there are lots of creative ways to make money without ticking off
your prospective customers, denying the use of your software to the
poor, or using threats, extortion, gratuitous cripplage, or any copy
protection crap that just adds bugs and subtracts features. Nobody
wants to pay for added bugs and fewer features! Outmoded "copyright"
business models just use the increasingly unenforceable copyright laws
as a crutch to lean on in a futile attempt to avoid the obligation to
innovate. It's red queen syndrome though -- you have to run faster
just to stay in the same place. If by some means (becoming a complete
fascist police state?) the US began to really successfully enforce
copyrights, it would just cause the US to rapidly fall behind other
countries, particularly China, which looks set to topple it and take
on the role of world superpower in the next few years *anyway*. If
they don't, copyright-reliant businesses within the US are quickly
outcompeted by innovative firms with other business models. It's the
whole protectionism-vs.-free-trade thing again, only with information
flow and services instead of physical trade goods. History repeating
itself in the usual manner when someone failed to learn from it. Free
trade won the last few rounds. Anyone want to bet against the proven
champ this game?
 

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,902
Latest member
Elena68X5

Latest Threads

Top