Publishing Software on Mac (2015)
Chapter 4: Anti-piracy
Casual Copying/Softlifting
If you sell software, you're subject to people finding a way to get it free. In the past, the usual way to get software free is to have a friend copy it and give it to you. This is known as casual copying or softlifting. Those who engage in this are not professional hackers, just people who like things free.
Professional hackers will bust most security features. The tougher the security, the more inconvenience it is to valid users. The more you inconvenience your customer, the more you will see the sales drop.
Therefore, you need a system that allows you to maximize your revenues, while minimizing your losses due to softlifting.
If you're looking for a system for bulletproof security, this isn't it. If you're selling software packages, each in the thousands of dollars, you need to find security elsewhere.
Below is a scheme to help you. It requires a database table with the recorded name, email address, and product code of each sale. It requires the user to be online when installing. It provides the elements of security:
Obfuscated activation code
Online validation of purchase
Online limit of the number of installs via computer fingerprint
Sale Registration
When you process a purchase, you should record it in a database you control. Record the user's first name, the user's last name, the user's email address, and a product ID.
Registration Code
We use a system that creates a 15-character registration code seeded from the user's name and email address, and a "salt" from the product ID. Is it bulletproof? No; however, it slows someone who knows a valid user's name and email address from using an install allocation without buying it. You can use any encryption scheme or hash in your coding. We have provided, in the download, a few schemes for obfuscation/encryption. Remember this is only one level of the validation.
Our scheme only requires it match a part of the user's name and email, is different for each product, and it gives us the product code in plain text. Another scheme is shown here:
http://www.brandonstaggs.com/2007/07/26/implementing-a-partial-serial-number-verification-system-in-delphi/
Install Limits: Computer Fingerprint
When a user installs, the name, email address, and registration code are compared to an encryption algorithm and, if valid, permission is passed to the web server where the sale is verified. If the database shows the name, email address, and product ID match, it captures other information such as serial numbers, MAC address, I.P. address, i.e., the "fingerprint," and records them. Later, on a reinstall, it will find a match and grant permission. On new install on different computer, it will ensure there is an allocation available before granting permission and recording the new "fingerprint."
Below find a database table example. This table shows the name, email address, etc. for a product XYZ. It shows one allocation used, Computer 1, with various serial numbers, and I.P. address recorded. This database table resides on your webserver. It can be a MySql, Sqlite, or any database. Typically, you access it with some server language like PHP, ASP, or Asp.net. You'll find some ASP code, fingerprint.txt, in the download (folder: MiscCode)
The install routine captures the fingerprint, i.e., serial numbers. It captures the serial number of the unit, the CPU, the drives, the MAC address of the Ethernet port, the network name of the computer, and the I.P. address. It passes these on to the web server, usually with an http request, where they are recorded in the database. If the name, email address, product ID match and the install allocations have not been exceeded, the installation is authorized via a response to the http request. If the new request causes the recorded unique fingerprints to exceed the install allocations, the installation is denied. So, if you limit the installs to two, the customer can only share it with one friend, not the whole neighborhood. If he/she wants to install on a desktop, and a laptop...no sharing with friends.
The recorded fingerprint is also a good way to prove delivery when confronted with a charge-back.
Here is typical code (XOJO) to capture the fingerprint. This code executes the shell commands in parenthesis after s.Execute. You should be able to move the shell commands to your programming language of choice.
'***********get fingerprint hardware stuff & encodeURL for querystring
s= New shell
'this is hard drive serial number
s.Execute("ioreg -rd1 -w0 -c AppleAHCIDiskDriver | grep Serial")
if s.errorcode=0 then
HDS= s.result
HDS=TRIM(stripxtra(HDS))
HDS=EncodeURLComponent(HDS)
else
Msgbox "Error getting HDS"
end if
'this is main serial number (used in cpu serial)
s.Execute("/usr/sbin/ioreg -l | grep ""IOPlatformSerialNumber""")
if s.errorcode=0 then
CPUS= s.result
CPUS=EncodeURLComponent(TRIM(stripxtra(CPUS)))
else
Msgbox "Error getting CPUS"
end if
'this is mac address of Ethernet O
s.Execute("/sbin/ifconfig en0 | grep ether | cut -d' ' -f 2")
if s.errorcode=0 then
MBS= s.result
MBS=EncodeURLComponent(TRIM(MBS))
else
Msgbox "Error getting MBS"
end if
s.Execute("scutil --get ComputerName")
if s.errorcode=0 then
compName= TRIM(s.result)
ecompName=EncodeURLComponent(compName)
else
Msgbox "Error getting compName"
end if
The results of the commands are URL encoded to become a query string for an HTTP GET request. The web server script (see fingerprint.txt) will decode the query string to compare/place the elements in the database.
If the user needs to reinstall the software, and some of the elements of the fingerprint match, the reinstall is authorized. This allows a hard drive or other element to be replaced without denying a reinstall. Your server script should update the fingerprint. OK, I know this is a vulnerability. The professional hacker can get through this maze easily; however, he probably would not give up his cash anyway. So, you lose nothing other than pride someone got it for free.
Again, the object is not to be perfectly secure, but to enhance revenues. Prevent casual copying, for that is where you lose most of the revenue. Don't make it too hard for users to use your software, just inconvenient for them to casually copy your software for their friends. I know there are classes of software where hackers abound, for example, gamer software, or high price utilities for developers like Adobe. They will need to do more than this scheme.