> For the complete documentation index, see [llms.txt](https://developer.musehub.com/muse-partners-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.musehub.com/muse-partners-help/resources/muse-drm.md). # Muse DRM Learn about Muse DRM and how to apply it to your products through the MuseHub Developer Utility. {% hint style="info" %} Applies only to commercial (paid) Applications and Plugins Muse DRM is not suited as a protection for **Electron apps**, that should use [Muse SDK](/muse-partners-help/resources/muse-sdk.md) instead. {% endhint %} Muse DRM is an important part of the MuseHub platform because it ensures product ownership, and enables commercial business models such as pay-once, subscription and free trials (as well as refunds) to be handled. For customers, they experience a seamless acquisition process and are never aware of any license management, since it's handled seamlessly by the Hub. For developers, this means you don't need to invest in costly and complex 3rd party solutions, or spend a long time building your own. ## MuseHub Developer Utility As a MuseHub Partner, you gain access to our developer tooling, including the MuseHub Developer Utility. This can be used to easily apply Muse DRM through a quick, simple process which can be optionally integrated into your build pipeline. The MuseHub Developer Utility is a no-code tool that integrates your product with MuseHub's technology. It creates a MuseHub compatible version of your application binary, enabling license verification. If a valid license is detected, the application or plugin binary executes. Otherwise, the binary is blocked, and a notification window informs the user of the invalid or missing license. The utility (also known as `musedrm` CLI tool) is made available during partner onboarding, if needed. Reach out to your assigned partnership contacts if you need it or have any questions. {% hint style="success" %} The macOS version of the Developer Utility can wrap macOS and Windows binaries. The Windows version of the Developer Utility can wrap Windows binaries **only**. {% endhint %} ## Usage The MuseHub Developer Utility can be operated via a simple command line interface (CLI), and can be easily built into scripts for automation. For Muse DRM to operate succesfully, your product must be free from other DRM solutions. Before you start, you'll need: * Your user-specific [API key](/muse-partners-help/getting-started/generate-api-keys.md) * The product's `product_id` which is generated when you add a product in the Partner Portal, and shown in the top left of the Partner Portal (labelled as either an application\_id or effect\_id). * An "open" build of your product free from any DRM or other license management systems. Once you're ready to go, run the musedrm tool with the following usage: {% code title="Application example" overflow="wrap" %} ``` musedrm --protect [your app.app] --api_key [your api key] --product_id [your application_id] --overwrite ``` {% endcode %} You can protect multiple binaries within the same command, as long as they correspond to the same product on the same platform. You must wrap macOS and Windows products separately. For example, to protect multiple plugin formats, such as VST3, AU and AAX, which you will later bundle together in a single installer, you would run: {% code title="Plugin example (distributed with installer)" overflow="wrap" %} ``` musedrm --protect [plugin.vst3 plugin.component plugin.aaxplugin] --api_key [your api key] --product_id [your application_id] --overwrite ``` {% endcode %} When submitting individual assets without an installer, each asset shall be wrapped separately: {% code title="Plugin example (distributed without installer)" overflow="wrap" %} ``` musedrm --protect plugin.vst3 --api_key [your api key] --product_id [your application_id] --overwrite ``` {% endcode %} ### Parameters * **--protect** \ bundle or standalone product, one or multiple assets are accepted (see the use cases for installer vs individual asset above) * **--api\_key** \ * **--product\_id** \ * -**-out** \ Cannot point to the original bundle, see --overwrite * **--overwrite** Replaces the software with the protected version in place, used in alternative to --out * **--help** Only display usage information, ignoring all other arguments * **--version** Only display the tool's version, ignoring all other arguments * **--is\_protected** \ \ ... Check if one or more assets are already protected by MuseDRM {% hint style="warning" %} Be sure to wrap the top folder of a bundle, **also on Windows** where "bundle plugins" are regular folders that contain the plugin binary. For instance, when wrapping **Windows VST3 bundles**, do not pass "plugin.vst3/Contents/x86\_64-win/plugin.vst3" to musedrm, but the top .vst3 folder: 
musedrm --protect plugin.vst3 --api_key [your api key] --product_id [your application_id] --overwrite
The same holds for .aaxplugin folders. {% endhint %} ### After wrapping If successful, the tool will return your protected binary, plus a unique `musedrm_id` which you'll need when uploading the application or installer to the Partner Portal later. You can then proceed to codesign and notarise the wrapped assets. Please use `codesign --force --deep` to make sure the protection files are codesigned correctly as part of the bundle. If using an installer, you can package your installer as usual with these wrapped and notarized products. {% hint style="warning" %} Be sure to **codesign and notarize the wrapped product** and mind the `--force --deep` flags. {% endhint %} ## Developer Notes On macOS, some Xcode toolchains over-optimize the binary's signature chunk, leaving less than the standard MachO space needed by codesigning and protections. The musedrm tool detects this occurrence and suggests to add a harmless `-Wl,-headerpad,0x1000` to the "Other Linker Flags" section of Xcode's build settings or to the CMake flags. The musedrm tool may also reject macOS binaries that contain internal symbols (i.e. function names and debug entries) that should not be exposed, since those facilitate reverse engineering and may jeopardize any kind of software protection. A way to check which symbols are exposed is `nm -a Plugin.vst3/Contents/macOS/Plugin`. The symbols *with displayed address* that are not APIs of the various plug-in formats (VST3/AAX/AU) must be kept in check with flags like `-fvisibility=hidden`. [^1]: This is the "plugin.vst3/" folder, NOT the "plugin.vst3/Contents/x86\_64-win/plugin.vst3" binary file in it!