Are we seeing the decline of the plug-in industry?

[pdxindy]

To go back to Dux's argument: Imagine you have a total computer crash and maybe 700 Plug-Ins...all to set up again - a real time consuming and fuzzy work.

that is a lot of work regardless... even if there were no copy protection at all it is a lot of work... and downloading and installing 700 cracked plug-ins is arguably more work.

[Urs]

That's good. Everyone who uses a "crack" of our stuff and invests dozens of hours in a project or two is a sure sale once the "crack" decides not to be one.

We do analytics. Every single day we get visitors from a link in an "expired demo" who then buy

If I ever actually release a plugin, you have to tell me your secret.

It's simple: Patience.

There's extremely easy-to-implement and efficient ways to check if a plugin uses an invalid/blacklisted serial or if it's cracked. You just have to do it, well, after a song was stored 100 times or some such thing. If you have enough patience, the crackers will never find it, and you only need to spend a single day on it. More elaborate copy protection (encryption whatsoever) is useless.

The first law of copy protection however is, make your serial numbers un-keygennable. That's very easy too and takes about two days to implement from scratch.

[schnapsglas]

Urs, how do you make the serial number un-keygennable? The mathematician inside me is fascinated... could you share?

[Tricky-Loops]

Urs, how do you make the serial number un-keygennable? The mathematician inside me is fascinated... could you share?

I'm not Urs, but...

With a Internet connection the generated serial number (from the keygen) can be send to the software company and searched in their data bank, and if it is not detectable, the software cannot be activated. Simple as that. You have to make the activation process only possible with a Internet connection to the original software company...

[schnapsglas]

Urs, how do you make the serial number un-keygennable? The mathematician inside me is fascinated... could you share?

I'm not Urs, but...

With a Internet connection the generated serial number (from the keygen) can be send to the software company and searched in their data bank, and if it is not detectable, the software cannot be activated. Simple as that. You have to make the activation process only possible with a Internet connection to the original software company...

But Urs' plugins are not. If u-he has means to generate serials for new customers, that means without check over web, you can't check for authenticity even if the keygen provides only small subset of the whole range of serials.

[Urs]

Urs, how do you make the serial number un-keygennable? The mathematician inside me is fascinated... could you share?

Use one-way encryption.

Many developers - including myself when I started - think of the serial as something that's generated from important information: user name, some value needed to unlock the demo mode, you name it. This means, there's an algorithm that can create a serial from such information and there's also an algorithm that can go the other way round. This is classical encryption with private/public key schemes such as RSA or ECC. But for a serial number that's something around 15-20 characters, this is just too weak. Brute force or anything can crack it.

I'm not sure if any cracker ever sussed out just how painfully simple our protection is, so I won't get into details here.

The idea is this: If there's anything to check for in the serial, you're bound to be cracked or keygenned. If whatever you check is absolutely random information, you can "unlock" the plugin from just, say, 10 bytes and use the remaining ten or fifty whatsoever bytes on delayed checks anywhere else in the plugin.

#---

There's more ways. You can also test if a plugin is cracked by opening another instance and registering it with a bogus serial. If it's registered, it's cracked. This check is very simple but nearly impossible to find for crackers with Olly or IDA.

Also of course, interrupts on pointer access only works on up to 8 addresses, so you'd store your serial in a hundred locations to make Olly to tedious to use.

Finally, whatever you do on detecting a crack, don't be messy. Don't come across like a pissed of child. Think of something that makes the user buy your software rather than delete it.

[Tricky-Loops]

Urs, how do you make the serial number un-keygennable? The mathematician inside me is fascinated... could you share?

Use one-way encryption.

Many developers - including myself when I started - think of the serial as something that's generated from important information: user name, some value needed to unlock the demo mode, you name it. This means, there's an algorithm that can create a serial from such information and there's also an algorithm that can go the other way round. This is classical encryption with private/public key schemes such as RSA or ECC. But for a serial number that's something around 15-20 characters, this is just too weak. Brute force or anything can crack it.

I'm not sure if any cracker ever sussed out just how painfully simple our protection is, so I won't get into details here.

The idea is this: If there's anything to check for in the serial, you're bound to be cracked or keygenned. If whatever you check is absolutely random information, you can "unlock" the plugin from just, say, 10 bytes and use the remaining ten or fifty whatsoever bytes on delayed checks anywhere else in the plugin.

#---

There's more ways. You can also test if a plugin is cracked by opening another instance and registering it with a bogus serial. If it's registered, it's cracked. This check is very simple but nearly impossible to find for crackers with Olly or IDA.

Also of course, interrupts on pointer access only works on up to 8 addresses, so you'd store your serial in a hundred locations to make Olly to tedious to use.

Finally, whatever you do on detecting a crack, don't be messy. Don't come across like a pissed of child. Think of something that makes the user buy your software rather than delete it.

So in your serial numbers some personal information about the user is stored that cannot be generated by a keygen? That sounds simple...even without a big algorithm...

[Urs]

If u-he has means to generate serials for new customers, that means without check over web, you can't check for authenticity even if the keygen provides only small subset of the whole range of serials.

You have to think out of the box

(otoh we're seriously toying with some web involvement... an online preset browser that's only accessible to registered customers would create a lot of extra value - and infliits fear on non-legit user)

[Urs]

So in your serial numbers some personal information about the user is stored that cannot be generated by a keygen? That sounds simple...even without a big algorithm...

No... no information at all. Just think of it as "the checksum of the serial done with algorithm this and that needs to match the checksum of the user name done with algorithm that or this"

So that, a brute force keygen could unlock the "immediate layer", but not the delayed checks, without finding all delayed checks first (and those implemented in subsequent updates).

[schnapsglas]

Use one-way encryption.

Many developers - including myself when I started - think of the serial as something that's generated from important information: user name, some value needed to unlock the demo mode, you name it. This means, there's an algorithm that can create a serial from such information and there's also an algorithm that can go the other way round. This is classical encryption with private/public key schemes such as RSA or ECC. But for a serial number that's something around 15-20 characters, this is just too weak. Brute force or anything can crack it.

I'm not sure if any cracker ever sussed out just how painfully simple our protection is, so I won't get into details here.

The idea is this: If there's anything to check for in the serial, you're bound to be cracked or keygenned. If whatever you check is absolutely random information, you can "unlock" the plugin from just, say, 10 bytes and use the remaining ten or fifty whatsoever bytes on delayed checks anywhere else in the plugin.

#---

There's more ways. You can also test if a plugin is cracked by opening another instance and registering it with a bogus serial. If it's registered, it's cracked. This check is very simple but nearly impossible to find for crackers with Olly or IDA.

Also of course, interrupts on pointer access only works on up to 8 addresses, so you'd store your serial in a hundred locations to make Olly to tedious to use.

Finally, whatever you do on detecting a crack, don't be messy. Don't come across like a pissed of child. Think of something that makes the user buy your software rather than delete it.

So you are using hash functions of some kind mapping from some information people wouldn't suspect with some hardcoded information in the plugin itself?

Or am I getting it completely wrong...

This is all very interesting to me, because I generally am [interested in these], and your plugins are the only ones that never get completely get cracked other than ones on iLok2 and few lucky ones on other dongles.

[Tricky-Loops]

So in your serial numbers some personal information about the user is stored that cannot be generated by a keygen? That sounds simple...even without a big algorithm...

No... no information at all. Just think of it as "the checksum of the serial done with algorithm this and that needs to match the checksum of the user name done with algorithm that or this"

So that, a brute force keygen could unlock the "immediate layer", but not the delayed checks, without finding all delayed checks first (and those implemented in subsequent updates).

And you're constantly changing the algorithms, too? So if a cracker would find the solution manually - by looking at the code -, in another update some other checks are used?

[Meffy]

Not sure this is the right forum for such detailed discussion, but it's up to Urs I guess.

[schnapsglas]

So in your serial numbers some personal information about the user is stored that cannot be generated by a keygen? That sounds simple...even without a big algorithm...

No... no information at all. Just think of it as "the checksum of the serial done with algorithm this and that needs to match the checksum of the user name done with algorithm that or this"

So that, a brute force keygen could unlock the "immediate layer", but not the delayed checks, without finding all delayed checks first (and those implemented in subsequent updates).

And you're constantly changing the algorithms, too? So if a cracker would find the solution manually, in another update some other checks are used?

If what Urs says is true and his plugins are "patient," it would indeed be very difficult to crack, unless the cracker runs hundreds of virtual machines with instances. You just cannot generate something that the plugin doesn't check for (yet.) I suppose then it isn't even necessary to change algorithms so often...

edit:

Not sure this is the right forum for such detailed discussion, but it's up to Urs I guess.

Oh yeah, Urs, sorry about getting so inquisitive... I was just too curious, I suppose. I wonder what I would do if I was launching my own plugin....

[Tricky-Loops]

Not sure this is the right forum for such detailed discussion, but it's up to Urs I guess.

I haven't cracked anything in my life...except my package of chips... And I don't think that Urs has uncovered something of value for the crackers...

[Tricky-Loops]

And it can help other software companies to make their programs unkeygen-able and un-crack-able...

And this can stop the decline of the plugin industry, to be on TOPIC again...