DRM Guide, Cryptography, and What-not
2023-08-05
Let’s just get this part out of the way. Yes, I’ve pirated plenty of audio plugins. I ended up purchasing some of those later on, but never got around to paying for others. These days, partially out of solidarity with other indie devs and partially because I have a job, I opt to purchase my software.
In a way, I get it. It’s just software. You can copy it, information wants to be free, it’s a victimless crime, and blah blah. At the same time, it would be nice if there was a way to live off of the work I’m doing (perhaps this is why I work a job now). It’s not lost on me that music producers are in a similar predicament when selling tracks on bandcamp, and that if musicians made more money, they would buy more software too.
There are some creative solutions to this problem. Freakshow Industries lets you ‘steal’ their plugins, but really guilts you into buying them. I’m curious if this actually works for them. There’s the patreon model, where you release content on a regular basis and subscribers pay mostly out of the goodness of their hearts but also for easy access to the content. In my opinion, it’s tough to get software out frequently enough to support this. Though, a couple years ago I released a Max for Live device every other week for a few months, and I found it to be pretty successful. I burnt out on it though. A solution I’d like to try: a plugin that’s free after a certain amount of money has been spent on it. Imagine a plugin that’s free after 1000 downloads and $30 before that. Or a plugin where the price is inversely proportional to the number of people who have downloaded it. There’s some unexplored territory there, is all I’m saying.
The typical solution, however, is still to make it very hard to crack the plugin in the first place. I wrote this guide up a few months ago, and regardless of whether you are ethically pro or against pirating software, you may find it useful.
To prevent unwanted copying and distribution, developers tend to include some form of copy protection in their code. Copy protection often involves distributing unique licenses to each authorized user of a software with which they can confirm their identity. Copy protection falls under the larger umbrella of data rights management (DRM): any management of legal access to digital content.
Intentionally circumventing copy protection is referred to as cracking software. Cracked software is everywhere in the audio plugin industry – a quick google search of “cracked audio plugin” provides easy access to websites where users can download unofficial versions of popular plugins. Some anecdotes have only 3% of plugin users as legal owners of the software. In an unofficial poll of 373 producers on this audio forum, every single respondent reported using cracked plugins at least some of the time.
The truth is that there is no 100% reliable way to prevent bad actors from cracking software. With enough time, a sophisticated hacker will be able to reverse engineer any plugin and create a version that is trivially copyable to anyone else’s machine, for free. Thus, the goal of any good data rights management scheme should be to make the process of cracking sufficiently frustrating and time-consuming for the hacker. For a smaller plugin company, with a less popular or cheaper plugin, making software that takes a long time to crack is often enough to disuade bad actors.
At the same time, interacting with complex data rights management schemes can be frustrating on the developers end. It takes a lot of time and a decent understanding of cryptography to implement copy protection correctly. For a single developer or a small team, it might not be worth the hassle. Adding copy protection may also add unwanted friction to at the user-end; authorized users certainly shouldn’t have to struggle to get past copy protection code.
For developers who believe that cracking software is ethical, it may be worth releasing plugins open source under a free software license such as GPLv3. As an added benefit, this will greatly simplify the distribution process. Personally, I’ve chosen to include copy protection as a practical matter in an attempt to increase my profits and gain a better understanding of who is using my software.
For those who know that they want copy protection, but don’t want to implement it themselves, there is a third option: hiring a company like PACE to handle data rights management. There are some notable downsides to this approach, however. While these companies may have advanced DRM schemes, they may also be high priority targets for hackers. Furthermore, contracting DRM to a third party may be prohibitively expensive.
There are two main types of attacks that crackers use to bypass license verification based copy protection schemes. Key generators (keygens) are programs that exploit unsecured crypto-systems to generate fake licenses that will pass verification checks. Cracks are modified software that no longer contain or otherwise bypass verification checks. It is impossible to completely prevent cracks. However, it is possible to prevent keygens. Preventing key generators should be the goal of all but the bare-minimum copy protection schemes. Cracks, on the other hand, are difficult or impossible to completely prevent. In the best case, developers can make their plugin binaries extremely resistant to reverse engineering and cracking.
This section comes with a disclaimer: I am not a cryptography expert. Furthermore, RSA is not the only way to implement data rights management. That being said, here is one way to go about implementing a cryptographically secure data rights management scheme using the RSA crypto-system.
RSA, named after it’s creators Rivest, Shamir and Adleman, is a public-key crypto-system commonly used for sending encrypted messages over open channels. I will spare the actual implementation details of RSA - while they are interesting, it is not necessary to understand the RSA algorithm to implement an RSA scheme. Instead of implementing RSA, it is best to use a third party library for key generation, encryption, and decryption. Popular third party libraries will be less likely to contain errors that can be exploited by bad actors – just be careful about calling any third party code from the audio thread, as always.
In our case, we want to communicate between our plugin and a private web server which is able to validate licensed users. In particular, our server should be able to send an encrypted message to the plugin that determines whether a user is licensed. Importantly, only the server should be able to generate a message that passes the plugin’s check. Furthermore, that message should be specific to the particular machine the user is on; reading the message from another computer should not pass the plugin’s checks.
Here’s how it works.
Good news: RSA is cryptographically secure. As long as a cracker is not able to alter the plugin binary, they will not be able to activate the plugin. Keygens can not get past RSA.
Bad news: crackers are able to make changes to the plugin binary. Implemented naively, RSA encryption is only marginally better than no copy protection at all.
Consider the following code:
bool is_licensed = correct_RSA_scheme_check();
if (is_licensed) {
// do processing
}
else {
// fail
}This code has a single point of failure. No matter how complex it is
to break the RSA scheme, if a cracker can replace the
is_licensed variable with true, the program
will always run normally whether it is licensed or not.
Any data rights management scheme will encourage good-faith users to purchase plugins directly. However, for those who are concerned with preventing cracks, there are a few things to do beyond using a cryptographically secure DRM scheme. This section references Chase Kanipe’s talk “Tips From a Hacker on License Checking” at The Audio Developers Conference, 2022.
Diffusion: license verification checks should be spread across the codebase, and should occur at different points in time. There should be no single line of code that a hacker could change to crack the plugin. Consider including checks that happen a long time after the plugin loads, or a certain amount of time after it is downloaded.
Obfuscation: it should be difficult for a hacker to understand what is going on in the code. Debug symbols should be left out of the binary. Sensitive data like public keys should be encrypted at compile time. Consider including fake license verification checks to throw off the hacker.
Integrity: include checks that ensure that the code has not been altered. This can range from checking the hash value of certain critical bytes in the binary to simply checking that bad license files do not pass the checker at runtime.
Variety: Add many different types of checks in the code. If each license verification check uses the same underlying pattern, they may be searchable and easily identified. To get around this, use a different algorithm for each check and add variety between releases. Add variety by returning information from the server that can be decrypted using various hashing algorithms in addition to the section that is decrypted via RSA or by using multiple RSA key pairs that are used in different parts of the codebase.
Scarcity: Include some verification checks on rare conditions, with only basic checks happening consistently on startup. With scarce checks, hackers may produce only partial cracks of the software. Users of these cracks may still be prompted to download the software legally when one of the rare conditions is satisfied.
Isolation: Checks should not reference the same underlying variables. If multiple verification checks must reference the same variable, dynamically resolve references by calculating the address of pointers to important data at runtime.
Integration: Integrate license checks with important sections of code. Write code such that unexpected behavior will occur if the license check doesn’t execute. Integrations can occur on the message thread, on file reads, and in the set-up code on the audio thread. Be careful about preserving real-time safety when integrating checks on the audio thread.
What do you do if the server that validates license files is unable to send or receive messages? My position is that users should be able to run my plugins without verification if my server is down. For those who agree, consider the following method. Check the users internet connection; if the user is connected to the internet but is unable to access your server, consider letting them use your plugin without verification. This way, the software will function long into the future even if the server stops running.
One reason to crack a plugin is to test it if it does not offer a free trial. Consider implementing a free trial plugin so that customers can be confident before they buy. This may reduce the frequency of illegal downloads of the software. Be careful though, all of the data rights management tips that apply to license verification apply to free trial software as well. Make sure that there is no single point of failure in the code that would allow bad actors to bypass the trial.
If setting up a secure data rights management scheme sounds like too much work, or otherwise does not align with your priorities, there a few other options short of releasing a plugin with no DRM at all.
Nagware is perpetually free to use software that periodically asks the user to pay if they have yet to verify. In a nagware scheme, the goal is not to completely prevent cracks. Instead, the goal is to provide a safe and easy to access free version of the software that will convert users into paying customers over time. Because of this, any data rights management in a nagware scheme can be extremely lightweight. Crackers will be unlikely to go through the effort of removing nagware, as they can already access all of the functionality of the plugin for free. Examples of nagware include the popular DAW REAPER and the popular text editor Sublime Text.