Serializing a python plugin
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 01/12/2012 at 20:47, xxxxxxxx wrote:
Howdy folks,
I've got a python plugin I've been working on for some time. I am wanting to make it require a serial number to run. I'm curious for some information on HOW to do this. How do people serialize their plugins? Like does it require a separate dialog to put in the serial, and then that somehow checks back to verify it or something?
I've seen people put it in actual CINEMA 4D Personalize dialog, which I'd like to do. If it's crazy complicated, then I can forgo it for now since time is becoming a factor.
I don't necessarily need SPECIFIC code...yet. But I just don't know where to begin with this. What's a normal process for setting this kind of thing up? Any help is welcome.
Cheers,
Bret -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/12/2012 at 04:31, xxxxxxxx wrote:
Look at the SNHookClass class, there's an example there (well, there is in the C++ docs) which shows how to do it.
If SNHookClass isn't available in Python you will have to do it separately with your own dialog for the user to enter a serial.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/12/2012 at 10:13, xxxxxxxx wrote:
Yeah, unfortunately the SNHook is not available in Python.
So I guess that means making it manually.
How does someone store a plugin serial number though? That's sort of what I don't understand. I need to make serials for different people, how does each get stored to each person? Does it check a database or something? That's part of what I don't get.
Do you like create a class with a SERIALNUMBER piece of data that you can then do like pluginIDHook.SERIALNUMBER=(Result from my serial dialog). But then how do you verify the serial is legit?
Sorry for all oif the questions, I'm very new to this part of plugin development.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/12/2012 at 11:35, xxxxxxxx wrote:
I have to admit, this was one of the hardest things to get my head round when I first serialised a plugin. It seems so sinmple, but it isn't. I keep meaning to write a tutorial for it, but never get round to it.
Anyway, the first thing you need is some way to generate a serial number. For this, you need the purchaser's C4D serial, the first 11 digits that is. How you generate a serial from that is up to you, but you can do anything you like as long as you can reverse the process and get the original C4D serial back out. You could manipulate it with a magic number known only to you, encrypt with an encryption algorithm, basically do whatever you want. Just make sure that you can reverse the process.
You will probably need another program (I usually build a small windows app in C#) or failing that a special plugin that only you have access to, in order to generate the serial - doing it manually or with a calculator is unreliable. However you do it, you end up with a string of digits and/or characters which encode the C4D serial of the purchaser. That's the licence key you give to the purchaser.
Secondly, you need to write a routine which goes in your plugin and which will extract the C4D serial from the licence key. That's easy because it just reverses what you do to encode it. All you do then is compare the serial number of the copy of C4D the plugin is running in (you get that by using GeGetSerialInfo()) with the serial you extract from the licence key the user has entered. If they match, it's a legit copy. If they don't it's not and you either tell the user with a dialog or print a console message, or whatever.
Once the user has entered a legitimate key, you save this to disk with the SDK function WritePluginInfo(). From then on, you just need to check the saved key at some suitable time - e.g whenever the plugin is invoked from the plugins menu. You would try to reload the serial from disk using the ReadPluginInfo() function. If it can't be loaded then the user hasn't entered the serial yet, so you prompt him to do that (or let a demo period expire if you like). If it has been entered and is correct, the plugin runs.
That's basically it. The hard part is finding some way to encode the C4D serial, but you are own your own with that - no-one will reveal how they do it because that's not information you want a hacker to have. Just don't spend too much time on it because they WILL break your protection system no matter what you do.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/12/2012 at 15:55, xxxxxxxx wrote:
My 5 cents...
Originally posted by xxxxxxxx
I have to admit, this was one of the hardest things to get my head round when I first serialised a plugin. It seems so sinmple, but it isn't.
Well, the whole SNHook thing is a bit weird at first, that's true. But you can also completely ignore it and use e.g. a license file.
Originally posted by xxxxxxxx
Anyway, the first thing you need is some way to generate a serial number. For this, you need the purchaser's C4D serial, the first 11 digits that is.
Well, you *could* use anything else, too. The licensee's name, his network adapter's MAC address, whatever. But yeah, the C4D serial is usually the best choise, and the easiest one for both, you and the customer.
Originally posted by xxxxxxxx
How you generate a serial from that is up to you, but you can do anything you like as long as you can reverse the process and get the original C4D serial back out. You could manipulate it with a magic number known only to you, encrypt with an encryption algorithm, basically do whatever you want. Just make sure that you can reverse the process.
That's one possibility. Use an encryption that can be reversed, too.
The easiest one would be a simple XOR. Then the encryption function is also the decryption function. But then, basically anybody with a scientific pocket calculator could create their own license key
Or you use something like AES or Blowfish, which enables you to only compile the decryption function into your plugin binary and keep the encryption to yourself. That would make it a bit harder for somebody to create a key generator for your plugin. Anyway, most of the times, the crackers just skip the license query instead of creating a keygen.
The other possibility is, to use a digestion algorithm that can't be reversed, such as e.g. MD5. In that case, You would not decrypt the customer's license key, but encrypt their C4D serial and compare the encryption result with the license key.Originally posted by xxxxxxxx
You will probably need another program (I usually build a small windows app in C#).
I used to do that, too (still use it for my two SPREAD plugins), but I found that it's easier to write it either in JavaScript or PHP, and keep it in a secured area on a server on the web, so I can create and deliver licenses from anywhere in the world, as long as I have my phone with me.
Originally posted by xxxxxxxx
All you do then is compare the serial number of the copy of C4D the plugin is running in (you get that by using GeGetSerialInfo()) with the serial you extract from the licence key the user has entered. If they match, it's a legit copy. If they don't it's not and you either tell the user with a dialog or print a console message, or whatever.
I would also advice you to only use the last 5 digits of the serial. That way, you don't have to send out a new license again, if the customer first purchased with his temporary C4D serial and later gets his final one, or if he upgrades his version e.g. from Vis to Studio.
Originally posted by xxxxxxxx
If it can't be loaded then the user hasn't entered the serial yet, so you prompt him to do that (or let a demo period expire if you like).
I never use a demo period. Too easy to cheat. I simply skip the complete license check if the plugin runs in the C4D Demo (or in a NET server / client).
People then have to use the C4D Demo to try out your plugin, but they have as much time to play with it as they want. Pretty fair, IMO.Originally posted by xxxxxxxx
That's basically it. The hard part is finding some way to encode the C4D serial, but you are own your own with that - no-one will reveal how they do it because that's not information you want a hacker to have.
Just use any common encryption (AES, DES, Blowfish; you can find Open Source C++ source for any of them) or digestion function (MD5, SHA, Whirlpool). IF you'Re afraid somebody's going to try a brute force attack, see that you use a slow algorithm. But really, in practice they're going at it with a disassembler and simply skip the check. If you're not an exceptionally smart programmer with lots of time and experience, they will always find a way.
Originally posted by xxxxxxxx
Just don't spend too much time on it because they WILL break your protection system no matter what you do.
EXACTLY. Keep it simple. They will crack it anyway, and whoever wants to use it for free, will know where to find the cracked version.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/12/2012 at 01:35, xxxxxxxx wrote:
Hi Jack,
Some good points there. Just to follow up on a couple of them:
* I prefer to use the C4D serial as opposed to something like the MAC address because then people who carry their Cinema installation around on a removable drive and don't always use the same machine aren't restricted to one computer.
* Good point about using a web page for generating serials, that is more convenient. However, you do then need a secure area on the server, not always possible for people using some commercial web hosts and probably not at all for free hosts. If you have your own server accessible from the net then of course there's no problem.
* I don't use a demo period any more, either. It's a point of attack for a hacker, and some people are happy to reset their computer's date every couple of weeks so they use the demo for ever. I do a free 'lite' version now with a lot of the code stripped out and which never expires.
Edit: I meant to ask, how do you handle the free student version if you let your plugs run in the demo? Do you check for the bit flag for the student version and not let the plugin run in the demo if that student bit is also set? I just don't let mine run in the demo version at all, whch bypasses that problem.
Hopefully Bret can now take all this info and get it working!
Steve
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 04/12/2012 at 07:28, xxxxxxxx wrote:
Originally posted by xxxxxxxx
I prefer to use the C4D serial as opposed to something like the MAC address because then people who carry their Cinema installation around on a removable drive and don't always use the same machine aren't restricted to one computer.
Right. I also use the C4D serial. That's just the easiest choice. I just wanted to point out, that one does not *have* to use the C4D serial.
Using both, the last 5 digits of the C4D serial and and customer's name might be an idea, too, especially if you use a reverable encryption for your license keys that way, you could print out something in the C4D console on startup, like "Plugin XYZ, licensed for John Smith".Originally posted by xxxxxxxx
Good point about using a web page for generating serials, that is more convenient. However, you do then need a secure area on the server, not always possible for people using some commercial web hosts and probably not at all for free hosts. If you have your own server accessible from the net then of course there's no problem.
I might be good enough to use a path on the server that nobody's ever going to guess, secure the folder with a .htaccess, and also include a password on the data entry form, so even if anybody finds the generation page, they can't generate anything without another password.
Originally posted by xxxxxxxx
I meant to ask, how do you handle the free student version if you let your plugs run in the demo? Do you check for the bit flag for the student version and not let the plugin run in the demo if that student bit is also set? I just don't let mine run in the demo version at all, whch bypasses that problem.
That's a very good question. I haven't thought about that at all yet
Maybe I should.