0

I try to make a trial version of our software. But I am not able do it properly. When the clock in my system is changed, it is not working.

SimpleDateFormat sdf = new SimpleDateFormat("dd/MM/yyyy");
Calendar expiredate = Calendar.getInstance();

try {
    Date date = sdf.parse("24/06/2015");
    expiredate.setTime(date);
    if (Calendar.getInstance().after(expiredate)) {
        JOptionPane.showMessageDialog(null, "Sorry your software has expired", "Expire",
            JOptionPane.INFORMATION_MESSAGE);
        System.exit(0);
    }
 } catch(ParseException e) {
    // ...
 }
GhostCat
  • 137,827
  • 25
  • 176
  • 248
Deepak Singh
  • 460
  • 2
  • 7
  • 19
  • 1
    you can save last started date somewhere when programe startup and check is lastdate > currentdate if so give a error "clock has changed " – Madhawa Priyashantha Jun 24 '15 at 10:03
  • What level of protection do you desire ? Should it be sufficient to work for average users only - e.g. ignoring ones that will decompile jar and locate logic for trial ? – John Jun 24 '15 at 10:11
  • @FastSnail it would not be impossible to decompile jar and find this location which would then be modified. Unless location is Server in control of OP. – John Jun 24 '15 at 10:14
  • yes of course ..and i don't think there is any solution to sure 100% secure – Madhawa Priyashantha Jun 24 '15 at 10:17

2 Answers2

5

You have to decide how much energy you want to spend. If your application only runs on the client's system (meaning: it doesn't need a connection to a central server) ... then your options are pretty much limited.

Of course, your application can save date/timestamps ... but that won't help when people start tampering with the system clock.

Long story short: you should balance between "easy to implement; but probably easy to circumvent" and "hard to implement; and thus probably easy to do get it wrong". In other words: keep in mind that such "licence checking features" could make it too hard for your potential customers to use the software. Or "worse": you spend a lot of time for some "great security solution" to this problem, and while implementing it, you add various bugs into your software. Don't underestimate the efforts that will be required to pull up a solution that can't be cracked by a motivated user ...

Final suggestion; try a different approach: focus on creating a great user experience with your application (but maybe with restricted feature set). Just convince your customers that your application is worth paying money for; and don't provide "trial licences"; but a free "trial version" with less functionality than the real product.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • +1 to point out that security is matter of balance between resources willing to invest and risks willing to accept. – John Jun 24 '15 at 10:20
1

$sql ='SELECT * FROM finsys.user WHERE username= "$user" AND password = "$pass" AND now() <= "20-Dec" ';

if yes, delete user record from database..

the customer does not change the system date change for a time-pass. if they show the trial over message then they may change the system date.

Do not provide any trial over message.. provide message as 'user authentication fail'.. They won't be able to know why this happened; before that DB will change..