We’re finding that those pesky hackers are easily cracking our private key and creating working keygens for our plugins.
We’re looking at ways to slow them down and are planning on implementing the following steps.
Every update will use a different private/public key pair, thus breaking the old keygen and requiring the crackers to re-crack the private key.
Currently the encrypted keyfile contains human readable xml which the hackers can use for checking if the private key they are testing works. Removing the human readable xml will make it more difficult for them to be know the private key they are checking is working. However, we do store the mac address in the keyfile (which the hackers also know), so any further ideas on how to further hide this would be helpful.
As they are brute force cracking the keyfile, are there any other libraries outside JUCE that we should have a look at that provide better protection than 512 RSA (512+ elliptic curve)? Obviously increasing the number of bits is the first option, but any experience others have had and what they found worked would be much appreciated.
We know it is impossible to stop crackers, what we want to achieve is to eliminate ( or slow down) is their ability to make a keygens.
Our first copy protection scheme, 10 years ago, used RSA too, but we went for a 2048 bits key. That was what my searching at the time yielded as the “unbreakable” size.
But note that even if a keygen isn’t possible then crackers could still always crack by modifying your binary. Sadly no scheme is guaranteed to work, and we prefer spending our dev effort in actual plugin development, so nowadays we use PACE.
@yairadix, generally, the crackers are not what they used to be, the days of Paradox emulating a USB key to crack Cubase are definitely over, what we’re seeing is unsupported macOS key-gens and people struggling to get the crack to work. In-fact, every time a crack is released, we see a doubling in sales, due to people not being able to get it to work.
I think what we’re trying to do is make it hard for them, we update the plugin on a regular basis and want to make the effort of cracking each version hard so they either give up or at the very least it it takes them a couple of months to get around to doing it. They seem to be able to crack the private key easy enough in its current state. As for cracking the binary, I don’t see the current cracking teams doing this so often, also with macOS hardening maybe this won’t even be possible?
@hill_matthew, I’m not sure iLok is the answer for us, it limits the market to people who own the key already. I’d like to think that our plugin is special enough that someone would go out and buy a key, but alas I don’t think this is the case
PACE has a software only cloud based solution or something, IIRC. Anyway, agreeing so much about the cat and mouse game that we decided not to include any protection scheme in our products. Sure there’s still the risk of seeing the product copied everywhere on warez sites etc, but surprisingly, only a very old version is available. Nothing to crack, so no fun no game, maybe.
So why would you want to make it hard for them if you see a doubling in sales?
edit: I just checked this 512-bit RSA Keys Cracked in Four Hours for only $75 - SoylentNews so I guess my 256 bit RSA pk can be brute forced in a matter of minutes
tbh I didn’t spend a huge amount of time on protection, I really only added it to time limit betas, and to stop people just sharing without any effort what-so-ever. In fact I probably get more support requests from people who can’t register the plugins than anything else
@Gav The ingenuity of the approach used in the Windows-only Pace compromise of Oct 2016 was impressive. I think it would be unwise to dismiss the talent and tenacity of those that enjoy the challenge of compromising a well-protected product.
I would not care about cracks and keygens if your product is fair priced.
Most of the people that are using the cracked version would never buy your product. They just have it because it was available and most of them will never really use it.
But some of them maybe buy it later when they finished the school and have some money.
A cracked version is also some kind of promotion. Some people like students just haven’t the money to buy the product. They take the risk installing spy software and viruses and use the cracked version instead.
Real pro’s will always buy the software. They want to support your company and make sure it exists also in the future.
I agree with the statement: the crackers wouldn’t buy your software anyway. But at the same time, you should have a hurdle for casual crackers.
The idea to at least remove known plaintext and change the key more often makes a lot of sense to me.
I haven’t looked in the latest updates, since at the company I work we use pace, but a good crypto library is NaCL (salt) or the fork sodium: https://libsodium.gitbook.io/doc/
“I guess my 256 bit RSA pk can be brute forced in a matter of minutes ”
Exactly @richie, I think we want to first avoid that scenario. If we release an update then it would be nice to have a couple of months before the keygen arrives.
For the doubling in sales, it’s hard to know what the actual baseline of sales in the absence of any crack is.
An idea to get around the mac address (known plaintext) being stored in the key-file, would to further encrypt the mac address internally in the key-file and to change the key pair every version. You first have to decrypt the key-file and parse out a second public key which you then use to extract the mac address. Without having the mac address as a known entity for checking the private keys success against during a brute force attack, it might slow things down?
Public Key1-> decrypt key file, access Public Key2 -> Decrypt the mac address with Public Key 2 (both key pairs changing on a per version basis)
Are you sure they are really cracking the 512 bit key, instead of simply replacing it in the binary with their own key? I usually see that technique in the cracks of my products. A remedy is then to check later/somewhere else whether your key has been modified.
100% they are cracking the key. The keygen is windows only and when I generate a keyfile on our windows computer and transfer it over to macOS and debug the plugin, the keygen generated keyfile is decrypted correctly using the current public key and I can view the correct contents in memory.
If that’s the case, why don’t you just increase the size of the key to 2048 or something? That would still take a very long time to brute-force wouldn’t it?
I personally didn’t see any shopkeepers shrugging their shoulders when my mates stole penny sweets off them and ran away. It cost them next to nothing, but they were not consoling themselves that maybe their friends would come and buy instead, or maybe they would be back when they were older to buy cigarettes and alcohol. Theft is theft, but I must admit I do admire it when people are able to put a positive spin on it.
But Pace isn’t just about fighting the cracks.
It’s a sophisticated license management platform that many smaller vendors would struggle to better. A large number of professionals are already a part of it and appreciate the convenience. When they move to a new machine they don’t have to think about re-licensing any of the plugins that use iLok, saving hours during a system upgrade. When travelling to work in other studios they can take their favourite plugins with them, and not have to think about de-licensing them when leaving (which is going to be great for catching extra sales through indirect referrals).
It also allows you to kill licenses remotely that are subject to card fraud, and easily fulfil your EU obligations on software resale by allowing you to cleanly and automatically deauthorise in-service licenses.
Although many of the costs are less tangible when you roll your own of anything, there comes a time you have to weigh them against the costs that appear on the balance sheet, then make a decision where your time is really best spent.
@hill_matthew, I’m not sure Pace would work for us. While the professionals you mention are probably familiar with the idiosyncrasies of Pace and they might be more historically used to paying higher prices for Pace protected plugins, I also feel that the size of that group is very small in comparison to the larger group currently into music production on computers. We decided to decrease the price of our new plugins by 66% and saw a 10 fold increase in sales, so while the revenue per plugin sold dropped by 66%, we were now selling 1000% more plugins. Obviously, if you’re in the game of modeling vintage compressors, where the nuances in colouration between plugins is where their value lies and you’re looking to charge $150+ due to the smaller market for these types of plugins, then yes it might be a good idea. I do feel though that putting Pace on anything else would be commercial suicide.
I can see this at work even with the keygen, they try it, it doesn’t work or requires some extra fiddly steps and they just go “F*** it, its only $XX dollars, I’ll stop wasting my time and just buy it”. Which leads back to the original question about making things just hard enough for people to go “F*** it, I’ll just buy it”. That can also be achieved if the current version has some feature they really want, but the older cracked version doesn’t, hence why it is important to slow the crack releases down
It’s not only the high-end market charging $150+ per plugin using Pace. The most obvious example being subscription services marketed with a low price to cast the net as wide as possible.
Hey @hill_matthew, I’m aware of the model for sure. My feeling on this is that it worked well early on for something like Serum or Slate Digital, there was a novelty in the value proposition, which I think has since worn off. If you were renting to own a single plugin on subscription and you forgot about it, you’d be down 7.99 a month, not a big problem. Now with the increase in plug-ins available, you could easily have $40 or $50 dollars chipping away at your account each month if you’re not careful, so I imagine people (especially in the larger group who are unwilling to pay >$80 for a plugin) are more conscious of subscriptions now and are turning on/off as needed. “Subscription fatigue” is the business term being bandied about recently to describe this phenomenon. If you do the math, 3 months on at $7.99 is ~$24.00, if you factor in the cut the platform takes, it reduces that down further. At this point it make more sense to sell direct, or at least for the first year. When the initial interest has died down a bit, maybe then move over to a platform. But out the blocks with a brand new product, I’d advise against it.
Subscriptions are based on the marketing strategy that it is x times harder to get a new costumer than keeping an existing one. The user has the advantage that he always has the latest version of the product without buying updates.
IMO this makes sense for expensive software like DAWs or Adobe that evolve over time. I don’t like that model on plugins or software that stays the same. It makes not much sense for me in this case.
People with a subscription will more likely also subscribe another product from that company, because it’s just a mouse click away. This makes only sense if you are a bigger player with a lot products. I think it will hurt small companies over time.
I don’t think I was really aiming to present an opinion on whether subscriptions are a good thing for businesses or consumers, I am more trying to illustrate that Pace isn’t only for the high end. If you want to try their tools they are pretty easy to integrate, affordable for virtually all viable businesses, and come with various other benefits to workflow in terms of your business and the consumer’s end experience.
Maybe I am starting to sound like a shill at this point. Sorry for distracting from your original line of enquiry. As others say, if you would like to continue with a public/private key scheme it would be much better to move to a 2048 bit key size to avoid a brute-force attack which has been possible for a lot of years now at a 512 bit key size. Unless you make a mistake in the implementation of stronger keying the result will almost certainly be the binary is going to be cracked instead as you just move the weakest link to another point in the chain.
I can’t see the point in doing anything more complex given it will almost certainly be subject to a successful attack, and likely more quickly than you anticipate.
The more you try to play little tricks to slow them down, you’ll just provide motivation. You can play whack-a-mole with that forever.
”