views:

225

answers:

7

I'm writing a commercial product which uses a simple registration mechanism and allows the user to use the application for a demo period before purchasing.

My application must somewhere store the registration information (if entered) and/or the date of the first launch to calculate if the user is still within the demo/trail period. While I'm pretty much finished with the registration mechanism itself, I now have to find a good way to store the registration information on the user's disk.

The most obvious idea would be to store the trial period in the preferences file, but since user tend to delete/tinker with those from time to time, it might be a good idea to keep the registration information in a separate, more hidden file.

So here's my question: What is the best place/strategy to keep and create such hidden files on Windows, Mac OS X and Linux? Here is what came to my mind so far:

Linux/Mac OS X

Most Unix-like systems are rather locked down when it comes to places a user can write files to. In most cases this is only the /tmp directory and the user's home directory. I guess the easiest here is probably to create a file with a dot-prefix to make it less visible, then give it a name that won't make it obvious that it's associated with my application.

Windows

Probably much like Linux/Mac OS X - more recent Windows versions become more restrictive when it comes to file system permissions.


Anyway, I'd like to hear your ideas and thoughs. Even better if you have already implemented something similar in the past.

Thanks!


Update

For me the places for such files is more relevant than the discussion of the question if this way for copy protection is good or bad.

A: 

POSIX systems should put app data in a hidden file in the user's home directory. Windows systems should put something under CSIDL_APPDATA.

Ignacio Vazquez-Abrams
A: 

To be honest, no matter what you do, you will be found out. If your system is self-contained, that is it does not require to be connected to the Internet or some other device at run time, then both your lock and key must be in your code or the data you write to disk. So while you can obfuscate the key (and may be even the lock), the owner of the system can invoke system trace tools or whatever to find you out. But I guess you knew that. Every major software vendor has tried various methods to make this work, but are broken every time.

I think your only real hope is to have your software phone home regularly to see if it still has a valid license.

martyvis
Yes, but no matter what protection you use, it can be cracked. While I'm planning on ciphering the data in that file a little, just to keep it from prying eyes, I guess that people will buy the software.Basically I just want to make it less obvious that you *can* rest the trial period by deleting said file, but 90% of the users won't start a trace tool and might buy the software instead.
BastiBense
@martyvis: Also, it depends on how you expect the software to be used. It might have to go without an internet connection for a long time. Inconveniencing a legitimate user is a bad thing.
David Thornley
I forgot to mention that computers where my software will be used are usually disconnected from the internet. I could implement something like a UDP "heartbeat" that possibly warns the user if a serial is blacklisted, but other than that I'm sure spending the time on documentation and bug fixing instead of copy protection might be good.
BastiBense
A: 

To illustrate the problems with this approach, there was a Linux-based media server that stored its free trial timestamp in /usr/bin/.tv. It only takes an strace for someone to realise that file is being accessed - in this case, simply deleting the file restarted the trial.

If you are a single developer you will have to spend a lot of money and/or time implementing a protection scheme that only needs to be cracked by one person to be available for everyone. Of course, your aim may only be to deter casual software pirates, in which case even the most basic protection (such as the method described above) will do the job.

rjh
Yep, that's what I want to do.I want to implement a "low barrier" that prevents novices and "casual pirates". Most of the targeted audience would rather pay for another license instead of spending a few hours trying to figure out a way to reset a trial period. Not to mention the loss of support and so on.
BastiBense
A: 

For Windows, you might try using Isolated Storage, which will store a file in a product unique location, which is usually sufficiently obscure (and has quite a deep path), and has the advantage of being completely transparent to the developer.

Allon Guralnek
A: 

Specifically on the Mac, this sort of file should live in ~/Library/Application Support/YourAppName if a user licence, or /Library/Application Support/YourAppName for a machine licence.

When a user licences my app I write the file to ~/Library/Application Support/MyAppName, as that requires no special permissions, but try to read it from both locations to allow for a machine licence if I ever create one.

Duncan McGregor
I believe that these names apply even in a different language through some filesystem jiggery-pokery.
Duncan McGregor
A: 

Use the registry for the windows version. It is build for keeping data in a central place, and as an added bonus, if the user deletes your entire folder, the settings ar still sitting in the register(*)

here on stackoverflow is an article describing how to access the registsry using the Java programming language.

I don't think Mac has something like this, and I know Linux certainly doesn't have it, but it is a start.

(*) the register is of course also not safe for tinkering users who can easily delete the keys belonging to your app.

Sven
+1  A: 

Who cares where you put the file. Its the contents you want to protect.

On the server side, encrypt/sign the user info with a private key and distribute it the user. Email a license file, have the application connect and download it, whatever.

In your application, include the public key. If you cant authenticate/decrypt the file, fail. If you can, continue to function. You only ever need to reconnect to the server if you can't authenticate the license file. You only need the most primitive "license server" to support this. If you email the file, the "license server" is just a script that encrypts a string and emails the user.

Nothing will protect you from sophisticated attempts to hack your application. But this solution will deny casual users the ability to break your license.

And if you want to prevent the user from re-registering multiple times or sharing the license file with their friends, record their MAC address server side and in the license file. Personally, I wouldn't do this. And it won't stop sophisticated hackers, but its up to you to decide how much time to spend in the cat and mouse game.

Abtin Forouzandeh