Shareware licensing techniques

I have been meaning to write about this topic for ages due to a huge response to this article, but with four exams in two days and a few more still left, there’s been very little time. So instead of a full-fledged post / tutorial, here is my view on writing solid security measures into your shareware applications. Note that I haven’t actually written a shareware app myself, so most of this is theoretical (ie. in my crazy mind).

Before we get into the different strategies, I would like recommend this article on software piracy by Ambrosia Software (Snapz Pro X). It really shows how vulnerable Mac apps really are and the effect they can have on small and individual developers. Ambrosia now uses what I believe to be one of the strongest and most fraud-free licensing system of any developer (including Apple). However, the method they use does have drawbacks in slight annoyances for the user. There is no perfect way of protecting your application, and no matter what you do, those that want to crack your application will; Even Microsoft, Apple, and Adobe have their software cracked and pirated. It’s about finding the right balance between safety and resources. How much time are you willing to spend hack-proofing your app? Do you need to go hard core encryption and daily online checks or is storing a hidden encrypted file enough? It’s up to you to review the alternatives and decide.

Using the plist

What a lot of apps these days are doing, is storing everything (registration info, no. of launches left, etc.) unencoded in the preference file. Umm… what’s the first thing you’re told to when an application starts behaving erratically? What does Mac OS X do when an application crashes?

Camino Crashed

Clean your preferences. In the case of most shareware, you get the added joy of having to dig up your registration information and re-register the app (or worse, buy another one). If you hadn’t registered it, most of the time you discover guiltily that the demo period has restarted and you can use if for longer. So, it’s clear that storing the information in the preferences isn’t the ideal way to go, but if you have no other option, you can try to utilize the following strategies:

Have a separate hidden plist

As well as your standard preferences, you can make another hidden file where you store sensitive information. It can be a standard plist file, but it could just as well be a file with the contents of the no. of launches remaining or the registration info. Applications that do this include most WidgetMachine widgets, Snapz Pro X, …… Most users who download a shareware application will spend ten minutes seeing if they can crack it, after which they’ll give up and buy the license, or resign to the demo. Hiding a second plist file is a great way to baffle average users who don’t delve very far into their Mac.

For further security against tampering, you can encrypt the contents of the hidden plist, then decrypt it when you read it from your app. Again, if you can decrypt, chances are someone geeky could too, but remember, nothing is foolproof.

I mentioned earlier the plist file doesn’t have to be an actual plist. You could call it “.myappdata.abc” (notice the lack of the words “registration”, “hidden”, and “demo”). The period at the start saves you from having to set is as hidden. Using this method, the sequence of events could be as follows:

Application is launched for the first time, .myappdata.abc is created with the contents of the current date.
Application is used in demo mode, with the demo expiring 30 days from the date in myappdata.abc.
User uses app… and loves it
Demo expires!
User, in his delirious state, delete the .plist file in the hope of resetting the demo period. Obviously this fails as the demo info in in the file .myappdata.abc.
When that fails, the user deletes and reinstalls the app, first manually, then using AppZapper. Again, this fails as AppZapper doesn’t pick up our hidden file.
User scours his hard drive, looking for a sign of something that could be the key to hacking this very difficult app, neglecting to search through the hidden files.
Finally, giving up, the user either registers the app, or deletes it.
Assuming registration, our application deletes the contents of “.myappdata.abc” and replaces it with the registration name and serial number.
Life goes on.

In this example, the user neglects to check hidden files, and misses .myappdata.abc in his Preferences folder. However, what if he was clever enough and got out Tinker Tool (or Terminal) and enabled viewing hidden files? Firstly, because the hidden file is named “.myappdata.abc”, he may not bother to look in it. I mean, he’s looking for something along the lines of “H1dd3n_registration_info.plist”, right? But what if he’s desperate and goes through it? If he opens it in Textedit and the contents appear to be a date, it can be a very strong clue to the fact that we’re housing demo information. To overcome this, we can encrypt the file so it’s harder to read. Having said that, if the user decides to delete the file, the information will be lost anyway, and the demo will be reset. Now it’s time to go even further.

The timestamp is your friend

This can be a great way to battle piracy. Repeat after me: I should check the timestamp of my plist file. If your app has a 30 day demo, and the key for days remaining says 999999 and the plist was created 30 days ago, it’s probably a good idea to credit that to tampering and bring the value back down where it belongs (AppZapper and Disco are very big culprits here). If you utilize a hidden plist as well as the standard one, you can check the timestamp of both standard files, to check for tampering. If they’re not the same, one of them has been deleted. Of course, this only works for time based demos.

Catch the cheats

In Cocoa, there is a very nice class by the name of “WebView” that enables you to access the internet (an easier way would be through CURLHandle). Via a simple PHP script or similar, you can log all registration attempts in a database. It’s even possible to access Cocoa from Javascript in the WebView, then use a setXMLHttpRequest to post the data; something I may look at further in a future post. As an example, the following PHP script would store the registration name, email, serial key, date and IP address in a MySQL database, by accessing POSTed variables.


<?php
mysql_connect("localhost","user","password");
mysql_select_db("myRegoDatabase");

$reg_name = $_POST['regName'];
$reg_email = $_POST['regEmail'];
$reg_serial = $_POST['regSerial'];
$reg_timestamp = time();
$ip = $_SERVER['REMOTE_ADDR'];

$result = mysql_query("INSERT INTO regInfo (id,name,email,serial,timestamp,IP)".
      "VALUES ('NULL', '$reg_name', '$reg_email', '$reg_serial', '$reg_timestamp', '$ip')");
?>

Obviously you don’t want this to be visible to the user, and you’ll need to ensure against MySQL injection, which the above script doesn’t. However, I hope you get the general idea.

And the winner is…

In truth, there is no winner; no perfect method of securing your great application against theft and piracy. You need to safeguard your property, but at the same time licensing schemes can end up being overly expensive for no real benefit. Take the time to evaluate how much you want to spend (both time and money) on developing security for your application. If it’s between $0-10 then there shouldn’t be a need to implement hard core techniques, but just enough that the average user would give up trying to crack it and decide that there’s no point wasting time on a relatively inexpensive application anyway. As shops and stores suffer from theft, so developers suffer from piracy. It’s not something we can eradicate, but a little time spent planning can go a long way in ensuring you get a daily feed.

An overview

Options available for licensing and demo management:

Make a hidden plist
Encrypt license information in plist file
Encrypt license information in hidden plist file
Always check correctness of info (for tampering)
Make file name / extension weird to throw people off
Don’t make information obvious (as in nice XML)
When entering license, log in online database
Check for fraud (multiple licenses all over the place)
Match start demo date with date plist was created
Use your head, think abstract!

Remember, use that big lump of grey and white matter in your cranium, and innovate. If you want the user to have only three uses of your app before registering, store uses 1, 2 and 3 as NSColors or random strings, such as the first use is blue, the second use is green, then the third is yellow. Being yellow, the app finishes the demo and asks for registration. There’s no such thing as too lame. If it works, why not. Good luck, and let me know your thoughts and views.