3

We would like to be able to create intermediate releases of our software that would time-bomb or expire after a certain fixed time or number of uses that would not easily be manipulated. We are using Visual C++ with mixed native and managed assemblies.

I imagine we may need to rely on a registry tag but this seems to be insecure.

Can anyone offer some advice on how to do this?

Tom Zych
  • 13,329
  • 9
  • 36
  • 53
Nigel
  • 500
  • 5
  • 10
  • I think you will find there is no 100% way to do this. Anything you come up with can be countered by *some* one, but if it's very difficult, it might be good enough. – FrustratedWithFormsDesigner Dec 02 '10 at 15:56
  • 1
    There is a good discussion here: http://stackoverflow.com/questions/203229/preventing-copy-protection-circumvention – Simon Mourier Dec 02 '10 at 15:59
  • Thanks for the answers and comments. We do not have a database component and but perhaps a server authentication would be viable. Another solution I am considering is to make it remotely accessible (run it as a server or via remote desktop) rather than give out executables of the release. – Nigel Dec 02 '10 at 22:53

6 Answers6

1

I was working on a "trial-ware" solution a while back and it used a combination of registry keys, information stored in a flat-file at a certain position surrounded with junk data, and then also had an option to reach out to a webservice that would verify it back with the software creators.

However, as FrustratedWithFormsDesigner stated, there is no 100% fool-proof way to do this. There is always a way that a hacker can get around whatever precautions you put in place.

light
  • 816
  • 5
  • 16
0

If you are using a database for the application, then it might be better to store a install (datetime) and a numberofusers (int) and then make code that checks those fields when the program is starting / loading / initing. If they are past a certain number or time (this could also be in the db) then exit the program.

Tony Abrams
  • 4,505
  • 3
  • 25
  • 32
  • The database would have to be local and encrypted for better chances of this to work. – FrustratedWithFormsDesigner Dec 02 '10 at 16:01
  • Encrypted yes, but it could be either local or remote. It depends on the needs of the application ... which we don't know that much about. – Tony Abrams Dec 02 '10 at 16:04
  • Remote (meaning off-site, hosted by OP's company) would mean that if the db is inaccessible (network failure or something) then that app wouldn't work. If the app is to be used on an isolated network (such as a test lab) or where internet connectivity is bad, this would hurt the users of the app. Or it could allow *n* uses without connecting to main DB but that just adds more complexity... – FrustratedWithFormsDesigner Dec 02 '10 at 16:13
  • Like I said it depends on the needs of the application :P – Tony Abrams Dec 02 '10 at 16:29
0

This is very hard if not impossible to do in a foolproof way. In any event, there's nothing to stop somebody removing and reinstalling the software (you do support that, right?).

If you cannot limit the function of these intermediate releases (a much better incentive for people to move to official bits), it might be more trouble than it's worth to implement such a scheme.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
0

Set a variable to a specific date in the program then every time the program is run access the system date and check if that date is equal to or greater than the specified date. If true then start the expiry process and display a message or alert panel to the user.

Developer
  • 114
  • 2
  • This would work if he wants a global kill date for the application, but if he wants every install to work for 3 months after installation then this will not work. – Tony Abrams Dec 02 '10 at 16:06
  • I'm pretty sure this could be easily defeated by messing with the system clock. That would cause problems with other things, but to some users it might be worth it. – FrustratedWithFormsDesigner Dec 02 '10 at 16:20
0

Have the binary download a tiny bit of code on startup from one of your servers.

Keep track of the activation counter on the server, when the counter reaches the limit, return a piece of code that displays the 'sorry!' message.

Florian Doyon
  • 4,146
  • 1
  • 27
  • 37
0

You could deploy it as a ClickOnce application with a certificate that expires at a certain date. If I recall correctly, the app will err on startup after that date.

A couple caveats:

  1. The only option for the user may be to uninstall the app, which is a jerk move.
  2. You will end up maintaining a ton of different deployments.
  3. It will be a shock to the user as it will just happen without warning.
Austin Salonen
  • 49,173
  • 15
  • 109
  • 139