Where to create/keep secret files for license information/trials on Windows/Mac OS X/Linux? [closed]

Question

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/trial 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 thoughts. 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.

Mouser

Not a very reliable method. Would you consider using a licensing server? – Baxter

No. My strategy is to use the most simple software protection possible, so that fair, paying users won't suffer from it. People who don't want to pay, won't pay anyway. People who want to crack the software, will do that, no matter how much effort you put into protection. – Mouser

@Allon: There is no reliable method that will not inconvenience the user. Everything I know of past this fairly primitive method is likely to inconvenience a legitimate user. In addition, a licensing server is a responsibility that the OP may not want to take on. – Pinot

@BastiBense, truer words have never been spoken. @David, great point. So considering both, why use any sort of DRM? Isn't poor DRM worse than no DRM? – Baxter

@Allon: Writing a license file won't inconvenience the user noticeably, and it does provide a barrier to indefinite use. It's a trivial barrier to get around, but it likely will spur some people to pay for the extension or unlimited version or whatever. It's kind of like a spring-loaded lock on a door: anybody can open it in five seconds with random pocket stuff, so it's no good against criminals, but it does signal to the law-abiding that the door is deliberately closed. – Pinot

This is a partial-duplicate (for Windows): #992796 – Baxter

Answer 1

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.

Refuge

How would you handle the scenario where the user deletes the license file? – Devonian

registering the MAC address.. could lead to buying a second-hand computer, re-installing OS, installing your software and immediately get greeted with a expired trial license message :) – Zoarah

Answer 2

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.

Baxter

Answer 3

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

Orientation

Answer 4

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.

Dignity

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. – Mouser

@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. – Pinot

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. – Mouser

Answer 5

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.

Protoxylem

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. – Mouser

Answer 6

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.

Fermi

I believe that these names apply even in a different language through some filesystem jiggery-pokery. – Fermi

Answer 7

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.

Rudy

Restoring registry hives from a backup is probably one of the most easy thing that can be done. It is as secure as rallying on the system clock. – Ellie