All the programs I have written to date, I have done for free or given away for free. So now I'm on a project that is going to have a small pricetag on it. How do I go about, copy protecting my work in LB? Or is it basically impossible, or excessively expense to do. I have a very limited audience so cost is a factor for sure.
Post by Chris Iverson on Aug 1, 2020 3:37:54 GMT -5
It's not impossible, and cost really depends on how far you go with it.
A keygen with a custom algorithm will be a lot simpler and cheaper than an internet-connected auto-activation setup tied into a web shopping store, but it's also more more vulnerable to being bypassed, or worse, having the keygen algorithm leak(in which case, people can just generate any key they want for themselves.)
There are benefits and tradeoffs to various methods of copy protection, in terms of cost needed, infrastructure needed, staff needed, and how user-hostile it is.
You can generally group apps in a few ways:
1) Offline. The application performs no activation communication itself; it provides the user with necessary data(if needed) to obtain an activation license/key/whatever, and the user manually communicates that to the seller, and the seller provides a corresponding licensed that can be input/imported into the app. This is how Liberty BASIC itself works; you go online to buy a license, and they ask for your name as part of obtaining the license. Once the sale is complete, you get a key tied to your name, and you input both in LB to complete the activation.
2) Semi-online. The application itself communicates with the seller to obtain a license, but once it has one, communication is no longer needed. Nowadays, applications will often provide both 1 and 2, if they provide one of them. They use online activation as default, and fall back to offline if needed. This is how Windows works; you get a key when you purchase windows, and you input that key during install. Windows will go online to make sure the key is valid, but if it's unable to do so, you can call Microsoft for a special override key that will let the system activate even offline.
3) Always online. The application must have a connection to the seller's server in order to run, and will refuse to do so if it can't connect. This is one of the more secure methods, but it's also one of the most user-hostile and fragile. If there's any problem with the Internet connection between then or your server, or if your server goes down, they can't use the product they bought. Nowadays, always on DRM is usually restricted to applications where one is required to be online to function in the first place. (For example, internet server-hosted multiplayer games; to be able to play the game in the first place, you already have to be online, so it just checks if you're allowed to play the game as you connect.)
You can also generally separate apps in how they're restricted.
Generally, applications will choose to restrict per-user, per-device, or both.
LB is an example of per user; you're the only one legally allowed to use your license key, but you can install it on every single computer you have, if you wish.
Windows is an example of a program that's per-device. You need a new key for each device you install Windows on, if you're installing it yourself.
The subscription version of the Adobe Creative Suite is (kind of) an example of both; you need to sign in to your Creative Suite account to use your applications, but they can generally only be installed on one machine at a time. (Sometimes you can get away with more as long as you're not using them at the same time.)
One idea I had that I've been meaning to put together an example for is an RSA signature based method. You embed an RSA public key in your application, tied to a secret key you hold. When generating a license, you sign whatever activation material you have(user name, device ID, whatever) using that key, and your application can verify the signature using the embedded public key.
Hi, I'm working on this very same thing. I'm producing some software that requires registration. It will generate a random customer key (and generates an internal product key from this) that is emailed to an auto responder email. This will get the key, generate an encrypted version of the product key and emails it back. The software verifies it then gets the hard drive serial number, encrypts it and embeds this in the TKN file.
When the software is run, it gets the drive SN and verifies it with the embedded version.
If the software is copied to another machine, the hard drive number will differ and asks to be registered.
If you want an in depth run though of this let me know.
I'm on with finding an email app that will save off emails on receipt.