views:

552

answers:

8

I'm coding a software on java and i almost finished, i would like to know how can we create a trial version which work for example for 30 days, because i will to send it to some companies

so how to make it like shareware or trialware, also can we block access to the .class in the jar file?

Thank you

+4  A: 

Why not just hard code an expiry date into the trial program so that you don't have to continue to support it? You could put this in main().

// Die after October 1, 2010
Calendar expireDate = Calendar.getInstance();
// January is 0 (y, m, d)
expireDate.set(2010, 9, 1);
// Get current date and compare
if (Calendar.getInstance().after(expireDate)) {
  // Die
  System.exit(0);
}

This is how Microsoft distributes their large scale beta software. They just give it an expiry date.

If you're talking about preventing reverse engineering or modifying the code, you can't. You could obfuscate the compiled program, but this won't stop the people who would be reverse engineering your code anyway.

Marcus Adams
And if the user sets his system clock back, it fools your system.
Paul Tomblin
@Paul, that's true, but it is simple, and at least I won't be supporting it.
Marcus Adams
thank you, it a good idea but as @Paul said the system clock can be modified :(
tuxou
+3  A: 

I would just do something really simple and just hard enough such that non-programmers wouldn't be able to figure it out.

I would something like write to a file the number of milliseconds when the program was first installed in a 64-bit long in binary to a file. And have your main class check and enforce the time limit. Yes people can change their clocks to work around this, but really you don't want to sell to those people anyways. Also ensure the current time is strictly within 30 days of the install. Most users will just set their clocks back one year and it works with most programs because they just did a simple less than the difference check. You should also check that the difference in number of days from current to install is also greater than 0.

If you feel you need more protection than that, then you have a business model problem more than a software one. Its basically impossible to make it unhackable, especially since you can just extract and disassemble the class files.

Pyrolistical
+1 for "business model problem".
Paul Tomblin
@Pyrolistical: can you explain me how Blizzard has a business model problem, seen that they basically made *Battle.net* unhackable? In this day and world of ubiquitous Internet connection slowly people will start to realize that when sufficient computation happen on the server side software can become effectively impossible to crack (short of rewriting them).
Webinator
@WizardOfOdds: If everyone used your method, the entire energy consumption of the world would raise by 200% and every internet line would be flooded 24/7. Please, this isn't an "end-all" solution. What if you are selling a product that has nothing to do with the internet? _Why_ would I _ever_ buy something that needs to contact the internet to operate correctly, even though the product domain has _nothing_ to do with the internet... I would first think to myself, "why is this contacting the internet to do computations, trojan much?".
Longpoke
@WizardOfOdds Obviously OP wasn't providing a service over the Internet and your point proved my point. If OP needed more protection then their current business model of selling software is flawed and therefore they need to consider other models like Blizzard selling a service over the Internet. Blizzard's model is different than OPs
Pyrolistical
+3  A: 

The problem with trying to limit the dates is that the naive solution of just checking the date is easily fooled if the person sets back their system clock. I worked with a guy who kept a VMWare virtual box just for running time limited software. A better approach would be to record the time of the last time it was run, and if the time ever goes before that time, you know the clock was set back and you can abort. The problem is figuring out how to stash that file somewhere where the user can't find it an overwrite it. Again, in the the VMWare or VirtualBox environment, the user could just roll back to an earlier snapshot.

In other words, you can limit some of the people some of the time, but not all of the people all of the time.

Paul Tomblin
@Paul Tomblin: ah ah, I am that kind of guy ;) *The* place to stash a file that the user can't find is on the server-side, on your own server :) Then your co-worker and myself shall re-image/re-use/copy a "clean install" of, say, Windows, forging the MAC adress, and re-install a new "30 days" copy evaluation :) Note that I only do it to understand cracking attempts (see my answer) in order to better protect our software :)
Webinator
@Paul it is totaly true
tuxou
+2  A: 

Regarding the class files, you can't block access to them, but you can make their de-compiled version totally unreadable by obfuscation.

Eyal Schneider
+1  A: 

I work on a commercial Java software and it is protected.

Is mandating an Internet connection acceptable in your case? In our case, our software only makes sense if there's an Internet connection and hence we can make reverse engineering impossible by simply following this mantra:

make sufficient part of the computation happen on the server side

There's nothing against this an attacker can do besides:

  • rewrite the part of your software that is happening on the server side

  • pirating your server

If our potential users are not happy with the fact that our software mandates an always-on Internet connection they can either buy or pirate one of our competitor's inferior product.

Think of it this way: nobody ever succeeded in playing on Blizzard's battle.net using fake/generated license keys.

Sure, a pirate could try to fake the whole battle.net, but then the pirated version wouldn't allow people to play in, say, the real WoW economy nor to compete on the real Starcraft ladder, etc.

Why did no-one managed to do that: because Blizzard made sufficient part of the computation happen on the server side.

Sufficient part of the computation happening on the server side effectively means: "good games pirates".

The more we move to an always-connected world, the easier it is to protect apps against piracy. Same for content (DRM), for the better or the worse.

Webinator
Please, for the love of God, if you use this method, digitally sign all data received from the server. Otherwise you are just making the client vulnerable for your own profit, and when some hacker exposes this, it will make you look _really_, _really_, bad.
Longpoke
"Think of it this way: nobody ever succeeded in playing on Blizzard's battle.net using fake/generated license keys." Bullshit. You need a key to play a game online (otherwise the server wont let you connect....), but you can make your own servers etc if you want for free. http://en.wikipedia.org/wiki/Battle.net#Controversy
Longpoke
What happens if (really when) your company goes out of business?
Kevin Brock
@Longpoke: You call names? I call b**** on *your* answer: I specifically stated *sure, a pirate could try to fake the whole battle.net servers,* **but then the pirated version wouldn't allow people in, say, the real WoW economy nor to compete on the real Starcraft ladder** How far can your intellectual dishonesty go?
Webinator
@Kevin Brock: pretty easy: you release the source code for the server-side (or simply make one final build, in which you put no copy-protection and release that one as a free upgrade)... Note btw there are companies in the business since decades that have always selled software with super-restrictive anti-copy protection (like hardware dongles) in some specific domains. Several companies are 150 years old btw ;)
Webinator
@Longpoke: *you are just making the client vulnerable for your own profit* Can I have some of the stuff you're smoking?
Webinator
you know the funny thing with facts all naysayers? It's that it's difficult to argue against facts ;)
Webinator
@WizardOfOdds: "but then the pirated version wouldn't allow people in, say, the real WoW economy nor to compete on the real Starcraft ladder" This is a *completely* different concept, you are deciding that someone can't play in your server. Nothing is stopping him from playing in his own server. This is what happens on many multiplayer games, people make their own pirate servers, and they usually aren't as good and/or prevalent as the legitimate servers, thus you have some level of semantic protection of your product. This method only works for games.
Longpoke
@WizardOfOdds: "Can I have some of the stuff you're smoking?" Do you not see the security flaw here? Your program will act on arbitrary logic dictated by the server, a simple man in the middle attack now becomes enough to possibly compromise any client. If you digitally sign the server logic responses, this is prevented.
Longpoke
for my case it wont be good, i do will sale a yearly licences so the idea of @Jon is better for my case
tuxou
+2  A: 

Here is an idea:

  1. Create a database (such as a SQL Server database) that is publicly available on the web. It will keep a list of "trial version" license keys. You can use the same system for full-version license keys when your product is purchased.

  2. When your Java software is first run, it'll cause a trial license to be created which will be stored in the database

  3. The Java software checks for a valid license each time it is run. The date that the license was created is stored in the database so it doesn't matter what the client clocks are set at.

  4. The software stops functioning when the license is expired

Standard windows software can look up the CPU ID and use that as part of the license, so that each computer can only run the trial software once. Does anyone know if there is a "JVM ID" of some kind that can be used for this purpose?

Maybe there is free or open-source license-related code out there already?

Jon
@Jon very ingteresting idea thank you
tuxou
+1  A: 

I've had success using True License in the past. It has a support for a trial period. Use it in combination with an obfuscation tool like ProGuard and it certainly makes it non-trivial to crack.

Cogsy
A: 

I recommend functional limitions. I have little post it note program. The program works fully, but you can create only 10 notes in unregistered mode. So i try to be nice to user. No date limitions, nag screens or someting else evil. Only small status line that has limition text and and register button.

Tuukka