More copy protection...

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

I still have to open my mind much more, is all about being creative!
Thanks!!

Post

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

Post

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!
Urs wrote: Sun Nov 06, 2016 6:01 pm Obfuscating checks, i.e. doing checks much later than on app start, maybe weeks or months later, has been my most successful strategy against cracks. We have about 10 different checks in our stuff.
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?

Post

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:

Image

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:

Image

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:

Image

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:

Image

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.

Post

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.

Post

kmonkey wrote: Wed Jan 23, 2019 12:42 pm I was under impression U-he plugins don't do "home calling".
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.

Post

Here's the code:

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
Where "actionData" is a C-string containing the URL to open.

Not phoning home :)

Post

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.

Post

kmonkey wrote: Wed Jan 23, 2019 1:03 pm 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.
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...

Post

Urs wrote: Wed Jan 23, 2019 12:34 pm 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.
Awesome! Thanks again for the insights! I was afraid that I had overlooked something. :)

Post

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.

Post

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. :D )

And when are you making that Uhe DAW? :tu:
SLH - Yes, I am a woman, deal with it.

Post

Vertion wrote: Wed Jan 23, 2019 7:33 pm Developers cannot stop their software from being cracked from the determined, period.
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.

Post

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.
I do not like the idea of a depressed developer, especially depressed Urs.

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.

Post

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!
SLH - Yes, I am a woman, deal with it.

Post Reply

Return to “DSP and Plugin Development”