views:

76

answers:

3

I have to store a demo install date somewhere on a client PC. The app demo period is calculated on the install date. Obviously it must be impossible for users to edit or delete this value.

How can this be done ?

  • We can't use HKLM registry because of Citrix
  • Can't use /Program Files because of Vista
  • Can't use /Documents and settings because of Citrix
  • erm ... is there anything left ... besides asking the user "Choose the location you want to store the install date" .. :-)

A solution would be to connect to a server and validate it there, but that would mean an internet connection is Required, which, .. sucks ..

+2  A: 

You could create a simple file with the date, together with some machine specific information and sign it.

The rule would be: if the file is present and the signature is valid and the environment is correct and the date is still in the future, only then the demo will start.

This prevents from changing the file or using a file from a different machine. It doesn't cover the problem, that one might change the system date...


About your concerns - if the license file is missing, the software will not start. And the user can't create the license file, he'll get it from you (you need to sign it - the use can only validate if the signature is correct). You may ask him for a MAC address, add the address to the license file, just to make sure, that the license file cannot be used on a different machine.

And about uninstall - the user can keep it - it will be worthless the day after the demo period ends.

Andreas_D
This seems the correct answer, however, since our assemblies are just obfucated .NET assemblies, it would'n make sense to protect the install date with 128-bit encryption. (You have to pay for a digital signature if I'm correct). So we're just gonna obfuscate the install date , for example ((DateTime.ToUtc() * 2 ) + 12345) , but then something better :-)
Run CMD
I'd sign the file with a standard MD5. Just something that makes it had enough to change values and calculate a matching checksum. I've seen it in license files and that's basically what you want: a limited license for a certain period.
Andreas_D
On a second tought, this wouldn't work ... What on uninstall ? Do you leave the file ? What if the user just deletes the file, it would be possible to just reinstall the app ...
Run CMD
MMM yeah the only solution seems to generate the Date/file/setting on a remote server instead of making the demo generate it itself... thanks Andreas.
Run CMD
+2  A: 

If you want something that is satisfies the 'must be impossible for users to edit or delete this value.' than you cannot store it on the user's machine.

So, with this requirement, you're only option is to store it on a remote machine and access it through some sort of network connection.

Another possible solution to reach your goal would be to use asymmetric encryption. During installation you request a signed signature from your own server (based on identifying information from the clients machine, date, etc), which is then stored on your client's machine and decrypted with the public key. In this case you would only need an internet connection on install.

Jacco
Run CMD
+1  A: 

I would probably choose one of two possibilities:

  1. Hard-code a "use before only" date into the EXE, so that all copies of the EXE will stop working after a given date. Of course, then you may have to upload new EXEs every now and then, with new dates. Depending on your situation, this may be a good enough solution.

  2. A variant of Andreas_D's suggestion: Upon installation, create a binary file that contains a lot of bloat and the date of installation in a non-trivial fashion. This is really easy to implement. The average user could never update the date in such a file using a hex editor (no less Notepad, which will destroy the file, treating it like an ANSI or UTF-8 or ... plain-text file). The user can of course delete the file, but your app won't start without this file, and the date in the right range.

Of course, non of these methods are safe against a system-wide date modification, but few users would want to run their main computer with an incorrect date. (In addition, many applications will not work with an incorrect date.)

Andreas Rejbrand
Please don't do option 1. If you've ever used .NET Reflector you know how annoying it can be.
Luke
@Luke: Really? I do not know a thing about .NET.
Andreas Rejbrand
.NET Reflector has a built-in kill date that forces you to upgrade every so often. If you choose not to upgrade then the program exits and *deletes itself* without warning.
Luke
Option 1 seems tedious and error-prone. Option 2 is what we gonna do. No need to pay for a digital signature if you're just gonna obfuscate your assemblies :-). Thanks Andreas.
Run CMD