More copy protection...
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
Creativity is one ingredient, the other is patience.
Patience because... when we get cracked and we add a fix in an update, we make it so that the crack will first work for a while. That's how we infiltrate their portals with cracks that suddenly stop to work. Like, blacklisting leaked serials only in November/December - in time for the holiday season. Or, as we just did, play a heartfelt "thank you for trying this demo!" after about half an hour into using the crack.
With all that you want to generally keep the protection code small and clean. Don't try to be super elaborate. Avoiding false positives is the highest priority. Document your what's happening where and when, and do a #define that allows you to test "as if cracked" builds, e.g. #TEST_CRACK_ON_ANY_DATE
Patience because... when we get cracked and we add a fix in an update, we make it so that the crack will first work for a while. That's how we infiltrate their portals with cracks that suddenly stop to work. Like, blacklisting leaked serials only in November/December - in time for the holiday season. Or, as we just did, play a heartfelt "thank you for trying this demo!" after about half an hour into using the crack.
With all that you want to generally keep the protection code small and clean. Don't try to be super elaborate. Avoiding false positives is the highest priority. Document your what's happening where and when, and do a #define that allows you to test "as if cracked" builds, e.g. #TEST_CRACK_ON_ANY_DATE
-
- KVRer
- 22 posts since 7 Apr, 2017
Sorry for waking up this old thread again, but it feels like an always relevant subject for us developers!
I've been able to use a lot information in this thread to start building my own copy protection, so thanks for that!
If some checks occur weeks or even months apart, I guess the outcome should be made persistent somehow, so the plugin is kept in restricted mode until a new license is entered? If not, the user just has to reload the plugin and use it for another couple of weeks/months before the check is triggered again.
I was thinking about adding something to the plugin state that's persisted in the host's project file, but then only those projects will be "blocked", and it's still quite easily circumvented by replacing all the instances of the plugin with new ones. I can make this a slightly bigger pain in the ass by having the "tainted" flag spread to all currently loaded instances via shared memory, so that every instance of the plugin would need to be deleted before starting to create new ones. But still....
Any other ideas on how to go about this?
I've been able to use a lot information in this thread to start building my own copy protection, so thanks for that!
The delayed checks are a really nice touch, but there's something I haven't been able to work out:
If some checks occur weeks or even months apart, I guess the outcome should be made persistent somehow, so the plugin is kept in restricted mode until a new license is entered? If not, the user just has to reload the plugin and use it for another couple of weeks/months before the check is triggered again.
I was thinking about adding something to the plugin state that's persisted in the host's project file, but then only those projects will be "blocked", and it's still quite easily circumvented by replacing all the instances of the plugin with new ones. I can make this a slightly bigger pain in the ass by having the "tainted" flag spread to all currently loaded instances via shared memory, so that every instance of the plugin would need to be deleted before starting to create new ones. But still....
Any other ideas on how to go about this?
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
Some thoughts.
The long term strategy is "make pirating more tedious than buying". If a delayed check fires once, it'll fire another time. A one day check is a good start.
This is from 2013:
At that time we had a delayed check in ACE which would verify the serial at every 17th in a month. So every 17th we would simply display a message "demo expired, buy here: link" in the UI. That's the spike of sales in the middle, accounting for more than 100 sales. The one around the 25th is from the day ACE was released (initial boost).
Displaying a link is pretty cool. Here's a bunch of links we displayed in cracks throughout 2013:
You see, the ACE one was great, and turnaround was above 10%.
What you really want is this though, which we got in 2015 after we learned more:
You see releases in July and October, cracks coming out, and backlinks immediately thereafter.
Once you are there, people in warez forums will start to distrust cracks. It'll look like this:
Sure, every now and then cracks will get better, but then you figure out what they did (keep symbol files!) and build another delayed check or two for the angle they found.
#----
Making stuff persistent... we never really did. We're looking into it though.
The long term strategy is "make pirating more tedious than buying". If a delayed check fires once, it'll fire another time. A one day check is a good start.
This is from 2013:
At that time we had a delayed check in ACE which would verify the serial at every 17th in a month. So every 17th we would simply display a message "demo expired, buy here: link" in the UI. That's the spike of sales in the middle, accounting for more than 100 sales. The one around the 25th is from the day ACE was released (initial boost).
Displaying a link is pretty cool. Here's a bunch of links we displayed in cracks throughout 2013:
You see, the ACE one was great, and turnaround was above 10%.
What you really want is this though, which we got in 2015 after we learned more:
You see releases in July and October, cracks coming out, and backlinks immediately thereafter.
Once you are there, people in warez forums will start to distrust cracks. It'll look like this:
Sure, every now and then cracks will get better, but then you figure out what they did (keep symbol files!) and build another delayed check or two for the angle they found.
#----
Making stuff persistent... we never really did. We're looking into it though.
-
- KVRAF
- 4855 posts since 17 Aug, 2004
I was under impression U-he plugins don't do "home calling". Obviously when i enter license plugin need to check is license valid. I get that. It's not that i mind it anyway but i remember conversation in past (it's burried here somewhere) and about people (legit people) being upset by such plugin behaviors. It was something about "who know what else is sent" discussion.
I think it was about Tone2 plugins calling home server something like that. I may be wrong. It was way way before. And people were upset.
From your chart it looks like your plugins do that daily. I may be wrong but i fail to understand how do you collect your flowchart if plugins aren't sending anything?
I will repeat i am not attacking, judging nor i am worried. Just surprised.
I think it was about Tone2 plugins calling home server something like that. I may be wrong. It was way way before. And people were upset.
From your chart it looks like your plugins do that daily. I may be wrong but i fail to understand how do you collect your flowchart if plugins aren't sending anything?
I will repeat i am not attacking, judging nor i am worried. Just surprised.
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
We don't. We simply display a link "buy now" which opens a browser window. It's the same link that's on our nagscreen, or "visit our website" in the drop down on our u-he logo.
All it does is tell the operating system to open a browser window with the given link - after the user actually clicks the link.
That's not "calling home" through some http socket or what have you going on the background. There is at no time an internet connection between our software and our servers.
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
Here's the code:
Where "actionData" is a C-string containing the URL to open.
Not phoning home
Code: Select all
#if MAC
CFStringRef website;
if ( actionData != NULL )
{
website = CFStringCreateWithCString ( kCFAllocatorDefault, (const char*) actionData, kCFStringEncodingASCII );
}
else website = CFSTR("http://www.u-he.com");
CFURLRef bla = CFURLCreateWithString( 0, website, NULL );
LSOpenCFURLRef ( bla, NULL );
#endif
#if WIN
if ( actionData == NULL )
ShellExecuteA(NULL, "open", "http://www.u-he.com", NULL, NULL, SW_SHOWNORMAL);
else {
ShellExecuteA(NULL, "open", (const char*) actionData, NULL, NULL, SW_SHOWNORMAL);
}
#endif
#ifdef __linux__
AM_PosixProcess process;
process.setDaemon(true);
process.setProgram("/usr/bin/xdg-open");
process.addArg("xdg-open");
process.addArg(((const char *)actionData) ? : "http://www.u-he.com");
if (!process.start())
AM_STD::log("failed to start xdg-open: %s", strerror(errno));
#endif
Not phoning home
-
- KVRAF
- 4855 posts since 17 Aug, 2004
All i understand is URL links but thanks anyway for your insights. I am actually worried you posted this on public forum but i am 99.99999% sure you know what you can post without crackboyz figuring out something.
Thanks and have a nice day.
Thanks and have a nice day.
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
Hehehe, if they crack the link away, they'd diminish the user experience. There'll be a link then which the user can not click. Too bad. They'll have to google us and take it from there. Less convenient.
If they crack the date away they basically render the preset browser useless. Even Hive's wavetables rely on date/time checks since they check for updated .wav files.
I'm preaching this over and over. Copy Protection needs to be based on the same routines which the software needs to work anyway. If you need file access, make file access a central function of your stuff, and use the same code for both. And so on...
-
- KVRer
- 22 posts since 7 Apr, 2017
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
Btw. I realized today that I did do a delayed check that persists. It counts how often a project file was reopened, and if a certain number is crossed, it'll check.
To do so, we simply take the time from plug-in instantiation to setChunk(). If it's less than a second, the preset certainly doesn't come by user interaction. We use this functionality for a lot of things now (per-project settings), so cracking it away will again diminish the user experience.
To do so, we simply take the time from plug-in instantiation to setChunk(). If it's less than a second, the preset certainly doesn't come by user interaction. We use this functionality for a lot of things now (per-project settings), so cracking it away will again diminish the user experience.
- Banned
- 697 posts since 29 Oct, 2016
Developers cannot stop their software from being cracked from the determined, period.
It's a deterrent to the non-technical freeloader. And, when designed properly, can frustrate the freeloader to cough up the dough for a license.
These programs rely on external variables to determine access, which can be found, altered or mimiced. Which is where black hats look for flags first. Even with a self-checking and self-modifying binary (which would cause every anti-virus to go crazy), there are basic tools to crack this situation as well.
IMO, Urs has the best model I've seen so far. As it uses the typical freeloader's mindset against them very efficiently. Every release he mixes it up, counters every crack he finds, adds random delays, embeds in unexpected locations, nullifies the bad regcodes, and other ingenious techniques. Making it painful for the typical cracker and freeloader. All the while releasing his own, for a hook, line, and stinker.
( Now, if I could only persuade Urs to give me a free ACE license. )
And when are you making that Uhe DAW?
It's a deterrent to the non-technical freeloader. And, when designed properly, can frustrate the freeloader to cough up the dough for a license.
These programs rely on external variables to determine access, which can be found, altered or mimiced. Which is where black hats look for flags first. Even with a self-checking and self-modifying binary (which would cause every anti-virus to go crazy), there are basic tools to crack this situation as well.
IMO, Urs has the best model I've seen so far. As it uses the typical freeloader's mindset against them very efficiently. Every release he mixes it up, counters every crack he finds, adds random delays, embeds in unexpected locations, nullifies the bad regcodes, and other ingenious techniques. Making it painful for the typical cracker and freeloader. All the while releasing his own, for a hook, line, and stinker.
( Now, if I could only persuade Urs to give me a free ACE license. )
And when are you making that Uhe DAW?
SLH - Yes, I am a woman, deal with it.
- u-he
- 28072 posts since 8 Aug, 2002 from Berlin
It's effort vs outcome. How much work do you put into it, and how much do you get out of it.
Btw. many developers are weary about serial numbers because they can get leaked easily. Thing is, a leak from 2011 or so is still around. People still share this and use it on our current line up of products. And it will work for a while, until it doesn't (hehehe). As far as I am aware, this generates more revenue than delayed checks in cracked software.
That said, I sometimes wondered if the optimal state is this: Be cracked on one platform but not on the other. So that all the platform B using friends of all the freeloaders on platform A must actually buy. While I still think the losses are much bigger than the gains, it's merely a comforting thought for when it happens.
If anything, I think the mental toll of piracy is much larger than the actual loss in revenue. The equivalent of a crack appearing on the net is, someone you can't sue is using your track in a TV commercial. Only, it happens every single time you release something. You don't get used to it, but you can minimize the depression by looking at charts like I posted.
- Banned
- 697 posts since 29 Oct, 2016
I do not like the idea of a depressed developer, especially depressed Urs.Urs wrote: ↑Thu Jan 24, 2019 7:06 amYou don't get used to it, but you can minimize the depression by looking at charts like I posted.
My brain produced a possible solution. Yay!
Each download of a product is unique to a single serial. One download is one serial.
Additionally, to further crack down on cracking, each download also has a different codebase by using combinatoric define flags. Could use a looping batch file to churn out unique copies, or compile on the backend as a webservice (freshly cooked for each download).
Instead of giving a serial code in your invoice, give a product unlock code to add to their user profile page. This page, then provides the only unique serial for the given unique download. (A one time challenge response to access the associated unique serial key for the unique download).
Combinatoric codebases, unique keys, and regular feature updates will frustrate crackers to no end. Creating a global crack would become exponentially harder since no 2 codebases are the same. If you implement it right, they cannot attack on pattern finding either.
This should help in the right direction.
No more depression for you. Only smiles, whistling, laughing, and dancing about in its stead.
Your serial model immortalizes your products. I will never part with the products (licenses) I bought from Uhe, which I cannot say for companies that require continual online challenge response anytime I might want to do an OS reinstall, or grt a new machine.
Cheers
SLH - Yes, I am a woman, deal with it.
- Banned
- 697 posts since 29 Oct, 2016
More ideas to share, as I care:
Please also consider the DAW idea. If marketed right, can catapult your already dominant plugin market position. Into the dominant DAW position, meaning you can call even more shots on the future of the plugin market. A built in compiler would help too, as people can write and sell there own plugs on your platform.
Then, you could dominate the hardware market similarly.
Given the reducing state of the global economy. 'Music unites us all' would be a great market strategy. 'We are the world' type construct as a uniting voice in so much deaigned division. To combine increased sales and real positive humanitarian results.
You music dsp developers have a LOT more political power than you realize. You effectively change the world with music and your products (add some lyrics for more influence). You just need to realize you can change the world with your gifts and believe in your own heart and purpose. You hidden Geniuses!
Please also consider the DAW idea. If marketed right, can catapult your already dominant plugin market position. Into the dominant DAW position, meaning you can call even more shots on the future of the plugin market. A built in compiler would help too, as people can write and sell there own plugs on your platform.
Then, you could dominate the hardware market similarly.
Given the reducing state of the global economy. 'Music unites us all' would be a great market strategy. 'We are the world' type construct as a uniting voice in so much deaigned division. To combine increased sales and real positive humanitarian results.
You music dsp developers have a LOT more political power than you realize. You effectively change the world with music and your products (add some lyrics for more influence). You just need to realize you can change the world with your gifts and believe in your own heart and purpose. You hidden Geniuses!
SLH - Yes, I am a woman, deal with it.