U-he Copy Protection/Licensing System Discussion

[Urs]

Cool, thanks for the response and explanation! I was under the impression that you had to have some kind of hash/salt represented in the code/assembly, and that was the reason i figured perhaps public/private key would be safer. It seems you’ve already considered that angle a long time ago!

Sounds very interesting, and would love to learn more, but obviously you can’t leak implementation details haha

Thanks Urs

Well, the .nfo of the current R2R cracks have a pretty accurate explanation. I provided a nearly 1:1 cookbook for this kind of protection to the developer community about a decade ago, and it looks like somehow it made its way to "them". Some language is identical.

Which really just means we have to finally simply do what we have come up with over the years, but which wasn't necessary until now. I.e. we were prepped for the day, and now we do what we have prepped for, in the form of moving to keyfile protection.

[AnX]

Cool, thanks for the response and explanation! I was under the impression that you had to have some kind of hash/salt represented in the code/assembly, and that was the reason i figured perhaps public/private key would be safer. It seems you’ve already considered that angle a long time ago!

Sounds very interesting, and would love to learn more, but obviously you can’t leak implementation details haha

Thanks Urs

Well, the .nfo of the current R2R cracks have a pretty accurate explanation. I provided a nearly 1:1 cookbook for this kind of protection to the developer community about a decade ago, and it looks like somehow it made its way to "them". Some language is identical.

So other devs are cracking/helping to crack your stuff now?

[Urs]

Cool, thanks for the response and explanation! I was under the impression that you had to have some kind of hash/salt represented in the code/assembly, and that was the reason i figured perhaps public/private key would be safer. It seems you’ve already considered that angle a long time ago!

Sounds very interesting, and would love to learn more, but obviously you can’t leak implementation details haha

Thanks Urs

Well, the .nfo of the current R2R cracks have a pretty accurate explanation. I provided a nearly 1:1 cookbook for this kind of protection to the developer community about a decade ago, and it looks like somehow it made its way to "them". Some language is identical.

So other devs are cracking/helping to crack your stuff now?

Depends on who you mean by "other devs", and the question whether crackers could be called devs only because they have some minimal knowledge of how computers work (but the might have no knowledge at all how to create something, which I think is what "develop" implies).

I believe that some shady guy might have posed as a developer and found entry into one of the audio dev communities, and that's how "they" got hold of the knowledge.

[DavidEkl]

Heheh, coder/developer, whichever you call it, someone with knowledge about how software works will probably have had to be involved in this.

And i think it’s fair to assume that there’s a few skilled software developers out there that religiously believe software should be free and are doing what they perceive as "the gods work" making sure that is the case.

[DavidEkl]

Well, the .nfo of the current R2R cracks have a pretty accurate explanation.

Not ashamed to say this makes no sense to me xD And i’m not about to go looking for it either

Thanks for your time Urs

[S950]

How much of your time/resources in relation to your entire operation are dedicated to copy protection?

The recent move to M1 by Apple has me wondering how many other considerations get in the way of the fun/nice/progress stuff that makes it to the end user. (Arguably the M1 thing is a user feature, but it seemed to distract from the really important stuff, like Z3 ).

[pdxindy]

How much of your time/resources in relation to your entire operation are dedicated to copy protection?

The recent move to M1 by Apple has me wondering how many other considerations get in the way of the fun/nice/progress stuff that makes it to the end user. (Arguably the M1 thing is a user feature, but it seemed to distract from the really important stuff, like Z3 ).

Interesting question...

For me as a user, the time spent for u-he to release M1 native plugins was well worth it cause my new Apple Silicon Mac is freakin awesome!

[S950]

How much of your time/resources in relation to your entire operation are dedicated to copy protection?

The recent move to M1 by Apple has me wondering how many other considerations get in the way of the fun/nice/progress stuff that makes it to the end user. (Arguably the M1 thing is a user feature, but it seemed to distract from the really important stuff, like Z3 ).

Interesting question...

For me as a user, the time spent for u-he to release M1 native plugins was well worth it cause my new Apple Silicon Mac is freakin awesome!

Absolutely recognize that’s the case for many users, however it did seem to disrupt a lot of developers, and in a roundabout way had me thinking of the drain that things like copy protection (especially in-house methods) have on developers. Or maybe there’s a lot of resource sharing about this between devs, which reduces the burden.

[pdxindy]

How much of your time/resources in relation to your entire operation are dedicated to copy protection?

The recent move to M1 by Apple has me wondering how many other considerations get in the way of the fun/nice/progress stuff that makes it to the end user. (Arguably the M1 thing is a user feature, but it seemed to distract from the really important stuff, like Z3 ).

Interesting question...

For me as a user, the time spent for u-he to release M1 native plugins was well worth it cause my new Apple Silicon Mac is freakin awesome!

Absolutely recognize that’s the case for many users, however it did seem to disrupt a lot of developers, and in a roundabout way had me thinking of the drain that things like copy protection (especially in-house methods) have on developers. Or maybe there’s a lot of resource sharing about this between devs, which reduces the burden.

Yeah... it must be tough to be a plugin developer. Glad I'm not one

[elxsound]

How much of your time/resources in relation to your entire operation are dedicated to copy protection?

The recent move to M1 by Apple has me wondering how many other considerations get in the way of the fun/nice/progress stuff that makes it to the end user. (Arguably the M1 thing is a user feature, but it seemed to distract from the really important stuff, like Z3 ).

Interesting question...

For me as a user, the time spent for u-he to release M1 native plugins was well worth it cause my new Apple Silicon Mac is freakin awesome!

Absolutely recognize that’s the case for many users, however it did seem to disrupt a lot of developers, and in a roundabout way had me thinking of the drain that things like copy protection (especially in-house methods) have on developers. Or maybe there’s a lot of resource sharing about this between devs, which reduces the burden.

Not to derail anything intentionally, but isn't this last part one of the motivators for Clap?

[HAL76]

It is going to be a keyfile. The keyfile stores the license holder's (chosen) name and email address, plus all serial numbers, the date of issue and a few watermarks to verify the legitimacy of the keyfile itself.

Yip. Plogue did it good - and that way of CP is fair.

[pgwalsh]

Slightly off topic but in the general area. Has there been any more thought into a universal installer and updater? I recall seeing a thread a long time ago but haven't been able to find it.

[crickey13]

that way of CP is fair.

It's not fair, it's awesome.

[Urs]

Slightly off topic but in the general area. Has there been any more thought into a universal installer and updater? I recall seeing a thread a long time ago but haven't been able to find it.

We've had some thoughts on this.

The lookout for installers depends on the options we have for the upgrade process, and of course also on the information stored in license cards.

Because plug-ins should/can/must not claim admin rights required to request access privileges, checking for updates in a plug-in is rather restricted. CLAP (see our forum about it) will let the host check for plug-in updates. If we can find a way to integrate the update process with the DAWs, then that might be way to go.

Otherwise we will need stand alone apps to reliably perform update checks, and maybe include download/install procedures.

A third option, if nothing else comes to pass is to create "all synths" and "all effects" installers for the various plug-in formats. This is a tad tricky as things are not commonly updated at the same time, and thus poses a whole lot of problems we can't even imagine at this point.

[pgwalsh]

Not sure if I worded my question properly. I was referring to one app to install all products. Seems you answered it either way though so thanks for the information and feedback, much appreciated.