Could you direct your feedback a bit? I just want to make sure I wasn’t misunderstood. At least it wasn’t my intention to discourage anybody
It’s the “42” comment that I found non-constructive, not yours, but I think it is better to stop here or I’ll end up doing the same.
But even returning an integer or double, wouldn’t it be a boolean in the end too?
LIke if (isAuthorized == 42.01)
No, it can be part of a formula already used in your program. I’m not saying that it helps a lot but if it is part of a formula, you don’t have to add an “if” statement to check it.
I think this problem boils down to: creating license check logic that doesn’t reduce to a boolean at the lowest level. That’s not easy to do.
It was a joke. (Douglas Adams, HitchHiker’s Guide To the Galaxy). Sorry for my levity. 
3 Likes
What about encryption?
Say may product is sampl(eplayer)er. I make it freely avalable for no cost. It’s on my exquisit, hand made and outstanding sample packs I make my money. Á la cheap ink printers with expensive ink cartridges.
Each sample pack is distributed as an individually encrypted (zip-) file with a unique password that I submit with every paid for pack.
The user enters the password for their new pack in the sample player, which deencrypts the sample pack internally for the session. If it’s a small package (less than a few hundred MB) it stores the pack in its RAM stomach, otherwise it puts the deencrypted pack on a temporary file, where from it reads parts when needed.
Do I have winner here?
If the sample pack is ever released alongside the password then anyone can access it.
Once it’s decrypted into memory I guess there is the opportunity to perform a memory dump to get to the contents too. At which point maybe they can release a version that skips the decryption step?
Does the user have to enter this password every-time the session starts? if not then the question is how is the password stored in the session data (no need to answer that on here), as that may also be a vulnerability.
1 Like
Yes, apparently if you were to buy my stuff you could copy both the player and the sample pack together with the code and put it out on darknet… Need to think a bit more on that part…
About reading the memory dumps, you could make it harder by 1. possibly delay the encryption (or part of it) till needed, 2. Rearrange the dump so as to split it in seemingly random chunks thatis harder to put togeher
OK, lets see now…
I make each of my distributed sample players unique (e.g put in lots of nop´s in random places of the code or make the linker rearrange the sections in a random manner that doesn’t interfere with the function).
The owner sends back the players crc together with Juce unique machine ID. They get back a sample pack that can only be locked up with a code that’s unique for that particular player on that particular machine.
Edit:
A sinister person could crack the sample player into reading the same machine code that was submitted to get the sample pack with the unique code. Then they could distribute the sample pack together with the cracked player. 
I was a hacker in a former life, you really can’t prevent it. Modern interactive reverse engineering tools are incredible and people have lots of time on their hands to play what amounts to a fun game. You can buy a little time, and you can decide if that amount of time equates to enough profit, if that’s what you’re optimizing for. I pretty much decided not to even play that game and to sell to users who feel like voluntarily paying. I’m sure it won’t be financially optimal for my single-person company, but it is the best choice from the user’s perspective, which is what I’m optimizing for.
4 Likes
I laud your attitude but at the same time I haven’t seen many (any?) donation projects survive (even ardour.org now makes you pay for the binary). The vast majority are abandoned. I personally don’t use free plugins because I know they probably won’t be maintained in 5-10 years and may not even run in newer machines. I think you are idealising users to a certain degree, some are a bit cheeky, I’d say… I think that a more balanced aproach has better chances to survive (limited protection that delays cracking, fair pricing, regular updates and online contents).
1 Like
(even ardour.org now makes you pay for the binary)
I can’t see any proof thereof in the link you provide.
And I think it is absolutely fair.
Haha, a fact hidden deeply, revealed first after you have selected archtecture … 
This is all very interesting! And also a bit demotivating to write a plugin. I have an idea for a very nice plugin so I want to write one. It is a complex one, so it will cost me probably 12 months. But if it is cracked the first day I will go bankrupt.
How are the big companies like Steinberg doing this? I guess crackers like to crack those tools a lot.
When I read all this, the only solution seems to be to make it the crackers more difficult. And you need to be cracker yourself to now how to do that good enough. So it seems more logical to use existing solutions because the companies making them did probably a lot of thinking about this. Like iLok PACE Keygen or what ever.
Or is that not true? If you can afford it, would that be the best choice?
And is there a difference in quality (more er less difficult to crack)?
Which paid method would be a good one?
1 Like
If you are going to invest a year of your time and don’t want something cracked use Pace to protect it if you can afford to, it’s going to be the most robust approach available to you.
2 Likes
Pace-based plugins get cracked too. Perhaps it’s more difficult for crackers, but I’ve just googled a few iLok-based plugins released in the last couple of years and was able to find cracked versions easily.
The half-life to compromise is way way longer, and for smaller devs the situation is even better because only the very best crackers stand a chance against Pace as they’re mostly busy going for the bigger releases.
But from the posts above I learned that it all depends on how your code is written. If you have one spot in the code that does the check, it will be cracked easily. You should spread it over your code and use all kind of obfuscation like inline checking code. And all these licensing services give you some API to call a specific function to check the license. So that can never be good, can it?