Then why post such a suggestive remark?
Integrating plugin code with Pace is not free and also requires serious time from the developer.
You have at least scared me, as I am working on this for my first plugins.
1 Like
Then why post such a suggestive remark?
As many agreed, my point was about the uselessness of convoluted copy protection solutions, at least for a starting business with limited operations. That’s of course a personal opinion, and, if you have big plans for your plugin company (or not), you should go with the copy protection solution you evaluated being most appropriate for your needs.
Integrating plugin code with Pace is not free and also requires serious time from the developer.
That’s exactly the reason why I decided to avoid it and opt for something simple, at least in the beginning.
1 Like
Simply trust your honest customers. No fingerprinting, no telemetry, a simple key file will do it.
Fix bugs quickly, be helpful. You customer will love you.
This is a real competitive advantage.
6 Likes
A quick search here shows several companies using iLok have been cracked: https://upawg.ca/
There have been a few newsletters from PACE addressing the issue as well.
Regarding RSA, as others have said already, the public key goes into the plugin, and the private key goes into your server. Yes, they will swap the public key with their own, but they won’t be able to make a keygen that works on legit versions. They have to patch every new update that you release.
3 Likes
Regarding RSA, as others have said already, the public key goes into the plugin, and the private key goes into your server. Yes, they will swap the public key with their own, but they won’t be able to make a keygen that works on legit versions. They have to patch every new update that you release.
Yep, I’ll do, to make sure that the key is valid. And I’ll use some other encryption scheme to avoid showing the key in plain text in XML key file. Thanks!
I finally had some time to look more into this. Does anyone have a suggestion for a library to perform the needed RSA steps on the plugin side? I guess OpenSSL is the most used one?
There’s a library called JUCE that has an RSA implementation.
Note that I haven’t used this part of it though so don’t know whether to recommend it for this use case, just thought it was relevant.
I would also recommend doing this with JUCE and without the dependency of a huge library like OpenSSL. If I remember right, it was not possible to use the JUCE RSA classes directly, but you can use the big integer class for calculation. You can do this if you extract the RSA exponent and the RSA modulus from your public key:
BigInteger rsaExponent;
rsaExponent.parseString (privateKeyCommaSeparated.upToFirstOccurrenceOf (",", false, false), 16);
BigInteger rsaModulus;
rsaModulus.parseString (privateKeyCommaSeparated.fromFirstOccurrenceOf (",", false, false), 16);
juce::String moduloNumber10 = rsaModulus.toString(10);
encodedTextBigInteger.exponentModulo(rsaExponent, rsaModulus);
juce::MemoryBlock mbDecrypted = encodedTextBigInteger.toMemoryBlock();
const int EXPECTED_LENGTH = plainKeyLength;
if(mbDecrypted.getSize() >= EXPECTED_LENGTH)
{
std::unique_ptr<char[]> decrypted(new char[EXPECTED_LENGTH + 1]);
auto p = (char*)mbDecrypted.getData() + (EXPECTED_LENGTH - 1);
for(int i=0; i < EXPECTED_LENGTH; ++i)
{
decrypted[i] = *p;
--p;
}
decrypted[EXPECTED_LENGTH] = 0;
String plainText(decrypted.get());
return plainText;
}
I would suggest that you reach out to PACE to understand how to integrate iLok. They are quite friendly and in my experience willing to spend a fair bit of time with you to make sure you understand what they offer. I think it’s important to recognize that everything is hackable with sufficient effort. If you can make casual copying and sharing difficult, I think you’ve achieved a reasonable objective as a small independent developer.
I view of PACE’s acquisition of JUCE, I’m a bit surprised that there isn’t native support for iLok in JUCE, but I may have missed an announcement or something.
1 Like
@yairadix thank you. I checked it but it didn’t have everything I needed, it only offer a container for the RSA keys it seems like. I was looking into something to easily implement PKCS#1 v1.5.
@kunz Thank you very much. Your snippet is very helpful.
@AllanH I worked and am currently working for audio plugin manufacturers that use iLok, I know their offer and I know it’s not worth it for me at this time, but thanks for the suggestion.
1 Like
Hi!
If you need more crypto functions, I found this library to be fairly easy to integrate while not being too bloated: https://www.cryptopp.com
1 Like
JUCE’s RSAKey class is very stripped down, and only handles RSA encryption/decryption. It does not do RSA signatures & verification, which is a better option in my opinion for the XML license file schemes being discussed here.
It also only handles one format of RSA key, making its interoperability with other RSA code a bit tricky (like if you’re generating license files on a server for customers). The base64-encoded PEM format is a common RSA key format, and JUCE cannot read this in. (I did find this post, however, where @matkatmusic posted some code to help with that process.)
1 Like
It sounds like there’s some confusion here… the RSA key doesn’t go into an XML key file (I’ll call it a license file here, just to not confuse keys and licenses).
A license file could contain a user’s name and other bits of identifying info, in a set of XML elements. And then it would have an RSA signature as the “last” element, which verifies the contents of the rest of the file. There is no need to then additionally encrypt any of that – it is fine to put all of that as plain text in the XML license file.
(In fact, that’s one of the advantages of using a signature scheme, rather than an encryption scheme. The user’s name is in plain text, and they can’t remove it from the license file without breaking the validity of the signature. That creates somewhat of an incentive for them not to share the license file around, since they cannot do that anonymously.)
I finished porting the code that allows converting public/private PEM-formatted keys into the juce::RSAKey class.
I’ll share the link and a demo project at some point. for now, here’s the repo set to the branch with the functionality.
ignore the code in the readme.md, it is not correct and uses the wrong Forge functions
2 Likes
@jcomusic Thanks, I’ll check it out!
@refusesoftware Thanks for the link. Super helpful. Yeah, I now have a much better understanding of how this should work and just need to implement it!
I have updated the repo to include example code:
3 Likes
Example of obfuscation: In my software I split my public key string into a set of substrings, where smaller parts of the key string was removed at compile time and restored at runtime by computing a function that converted input indices to the missing sequence of letters by computing a curve fitted expression. This makes it harder to replace it by modifying the binary. The result is that the public key haven’t been replaced in 5+ years, although several versions with various attempts of circumventing the protection has been attempted by crackers.
2 Likes
Ciao @jacopoeftilo ,
Like you, I am also looking for an approach to copy protection for my solo project. Your idea is really very interesting and I am seriously considering using a solution similar to yours.
I have a couple of questions:
1 - why do you prefer an Offline approach? of a solution like this what do you dislike?
https://docs.juce.com/master/tutorial_online_unlock_status.html
In this case, with a little effort, you could also count the accesses / unlocks and if they exceed a certain threshold, investigate and suspend the license.
2 - From what I understand, since it is possible to “pass” the downloaded license between users (perhaps in the name of an invented person) a fundamental component is the trust in your future users 
Which other manufacturers use this policy based on trust? ValhallaDSP as you mentioned?
If your copy protection system doesn’t work offline, it doesn’t work (in a practical sense).
It’s fine obviously to need to fetch a license file online (as in, fetch it one time), but if every runtime use of the software requires unlocking from a server, users will not be happy.
In the post production world, machines are often kept offline for security reasons, so those users wouldn’t ever be able to use your product. But even for the more common case of a user doing audio work on a laptop, imagine they want to use your software in situations where they don’t have reliable internet, like while traveling or performing onstage or wherever.
4 Likes
This view is a little pessimistic. There are hybrid solutions where you fetch a new license daily but have a generous grace period (30 days?) for offline use.
99.9% of our customers had no problem with that at all.
There will always be a tiny, but very vocal, minority that wants everything to magically just work, has no copy-protection, and no online features but still somehow keeps itself up-to-date. Oh, and it better be free.
3 Likes