Writing a plugin that extends the functionality of CINEMA 4D is often only the first step towards a finished product. At one point or another during the work on your plugin you will have to spend some thought a proper license system.
This first article explains how licensing basically works, discusses aspects of different license systems, and points out some things about crackers.
Important note: This article just presents some common approaches and solutions for licensing CINEMA 4D plugins. It is neither guaranteed to be free of errors, nor to be complete. The author of this article is not be held responsible for any damage that might occur due to an implementation based on this article.
This is a series of five articles:
Contents of the series
- Part I – Introduction
- Part II – Implementing a license class
- Part III – Implementing the license validation
- Part IV – Implementing a key generator
- Part V – Extensions and improvements
The “Licensing Plugins” articles will concentrate mainly on the technical implementation of a license system, however one should also pay close attention to how licensing is presented to the user and how it should work. Here are some thoughts about that…
So many questions
How restrictive will your license policy be? Which information should be used for license key generation? Are you only going to limit usage of a plugin license to the user’s CINEMA 4D serial, or are you going to use more information, like e.g. the network adapter’s MAC address? Are you planning on a demo version of your plugin? How will that demo version look like, how is the protection going to be?
You should have your license system thought-through, also sales-wise, before you actually implement it.
Putting out a demo version of your plugin is always a good idea. It gives users the chance to play around with it and get to love it (hence, creating the unresistable urge to buy the full version).
A “demo version” might very well be the same binary as the version for the customers. The plugin is simply in “demo mode” until a valid license is found.
Usually – there might be exceptions – a demo version of a plugin comes in one of the following flavors:
Demo version works (fully functional) for a certain amount of time. After that, the program will either refuse to work or have some limitations, like e.g. only providing very basic functionality.
This is a very easy way of limiting a demo version. As long as you stick to the “refuse to work” idea, it is also very simple to implement.
However, a time limit can be easily cheated by the user: They simply set back their computer’s system clock and date. Even with more effort, you’ll never be really sure that people don’t cheat it.
The demo version runs for an unlimited amount of time, but only provide very basic functionality. Some more creative applications let the user choose which feature he wants to test in the demo version, and then only that specific feature gets unlocked. I have also seen applicatoins that unlock a different set of randomly chosen features each time the demo is started.
Anyway, this option is also not ideal, since the user only gets to use some of the features. They won’t be able to have a look at the nicer features of your plugin that might have actually convinced them to buy it. Another downturn is that – depending on the complexity of your project – it might be quite a lot of work to implement this.
Limited to CINEMA 4D DEMO
This is the most commonly chosen way. It’s very easy to implement, and everybody can run the demo for as long as they want, and test all the features. Even better, if they register their CINEMA 4D Demo at Maxon, they even get to save their scenes for 42 days. That gives them plenty of time and all features they need to test your plugin demo and decide whether they want to purchase it.
How does licensing basically work?
Is most cases, a license is technically a key that is uniquely assigned to a customer. The key lets the user (and ideally only this user) unlock the plugin and use it. That means, a license system must handle both: Generating licenses, and validating licenses.
The generating part is done by a license generator (not necessarily running inside CINEMA 4D) and basically performs the following steps:
- Take user information
- Feed information into key generation function
- Generate key
- Give key to customer
The license validation (will run inside CINEMA 4D) does the following on the customer’s side:
- Look for key
- Validate key
- If valid, activate product
Creating the license key is the first big step to take.
Which user information to include
To generate a license key, you need some data from the customer to generate it from. A common choice is using the customer’s CINEMA 4D serial number. That would make the plugin license work on all the user’s computers that use the same CINEMA 4D serial. Some developers make it more restrictive and include hardware-related data in their license keys, e.g. the network adapter’s MAC address.
Preparing for key generation
The gathered information will now be handed over to the license generator, that will transform the information to a license key.
In our example project, we only use the CINEMA 4D serial and a prefix, but we could also include other information, as discussed above, and add it all together into one big string.
Encryption vs. Digestion
You now have two options what you want to do with the user information:
Encryption / Decryption
If you use an encryption that can be reversed (decrypted), you have an advantage: Since Encrypt() and Decrypt() are two different algorithms (except if you’re using something very simple, e.g. XOR), you can link the Decrypt() function into your plugin, but leave the Encrypt() function out of it. That makes it harder for crackers to come up with a KeyGen.
If you go this way, you would encrypt the user’s information to create the key; and the plugin would decrypt the key to get the original information and compare it to what it finds on the user’s machine. If the user has the same serial C4D serial that was used for the key, the license is considered valid and the user is good to go. If not, the plugin will not register.
Common encryption algorithms are AES or Twofish.
A digestion algorithm performs an irreversible encryption on the data. That means, from the license code you can not retrieve any data about the customer. It’s simply used to scramble the given data and create a quasi-unique fingerprint of it. To validate a license, the plugin would take the information if finds on the user’s machine and apply the same digestion algorithm to it, thus creating a new license key. Then it would simply compare the user’s license key with the key it just generated. If both keys are the same, the license is valid.
Common digestion algorithms are MD5, SHA or Whirlpool.
Validating a serial key means: Finding out if the serial key matches the user’s local data (his C4D serial, or whatever data you used to generate the key) and then – in case of a valid license – unlocking the plugin. Depending from the key algorithms you have chosen, you either decrypt the user’s license key and check if the decrypted data matches the user; or you create a new license key from the user’s data and compare it to the user’s license key.
SNHook vs. license files
The SNHook is a builtin class of the CINEMA 4D API. It allows you to prompt the user for the license key, automatically when CINEMA 4D starts up, and to add a text field for your plugin’s key in the “Personalize” dialog of Cinema. It’s a nice solution, since it conforms with CINEMA 4D standard licensing workflow.
Using a license file, however, frees you of CINEMA 4D’s licensing concepts: The license key is not asked from the user, but simply read from a license file that the user has to copy to a specific location (e.g. the plugin’s directory, the “Plugins” directory, or the user’s User Folder).
Both approaches have their pros and cons: While the SNHook is very comfortable for the user (e.g. even if he is not logged in as an administrator, he can still input the license key and save it), it’s considerably more work for the developer. And while license files are very simple to implement, it requires the user to copy (maybe even unzip before) a file to a specific location… believe it or not, you will find that many customers have their troubles with this simple task. Other users really like license files, because they can simply copy all their plugins’ license files over to another computer or a new installation to make their plugins work, while with an SNHook, they would have to enter all license keys manually.
After all, it’s a question of taste. In my most recent plugins, I actually used a combination of both: The license key is usually input by the user via an SNHook, but license files can optionally be used, too. That is also the solution that you will implement if you read all the articles from this series.
The key generator
A key generator is a little tool that takes the user’s data (serial number, or whatever) and generates the license key that the user needs to unlock his plugin. There are two basic ways to go from here:
Local key generator binary or script
It would take the user data (either from a text file, or e.g. passed as command line parameters) and return the key.
Such a tool is quickly written and it’s a handy way to generate licenses locally on your computer. Also, it allows you to use any encryption algorithm you want.
Online key generator on web server (PHP example)
Especially if you are going to send out A LOT of licenses, you might find that a local binary is not flexible enough: Does it run on both, Mac and Windows? What if you’re on holiday, some people purchase plugin licenses from you, and all you have is your cell phone? And do you have to write or at least send the delivery mail manually every time?
A smart way of coping all these questions is, to write the key generator as an online script (PERL, PHP, JSP, et cetera) that you can simply open in your web browser, and that will generate a license key and maybe even send it out to the user.
Of course, you are going to need a web server with some kind of scripting language. In our implementation later in this article, we are going to use PHP.
A word about crackers
If you hope that a plugin license system will prevent your plugin from being cracked, give up that hope now!
Whatever neat thing you do to try preventing crackers from writing a key generator for your plugin, they will either reverse engineer the code and find out what you do, or – much easier – they will just take a look into the assembly code and simply skip your license check call (or negate its result). Sooner or later, if your plugin is interesting enough, someone will crack it.
Therefore, a license system is mostly just meant to increase the hurdle of illegal use and keep track of your customers. But there will always be people who crack plugins, including yours. Get used to it, it has always been this way, and it’s not very likely to change anytime soon.
By the way, if you look for cracked versions of your plugin and browse the relevant warez forums, you might find that the amount of illegal users who later decide to purchase a real license is actually bigger than you thought. And another great amount of illegal users just collect plugins without ever really using them; those guys will not do any professional productions and wouldn’t have purchased the plugin anyway. I know this is a very controversial topic, but I daresay the financial loss caused by cracked plugins is not as dramatic as some people want to make us believe. However, having your plugins cracked by some punks not the most pleasant experience; and some developers even see it as a personal insult. Again, get used to it.
As said at the beginning, there is a lot of stuff to consider before you start writing your plugin’s license system. Now we have already explained and considered a lot, but we have not yet written a single line of code. That’s going to change in the next part of the article, when we implement a custom license class.