Muse DRM

Learn about Muse DRM and how to apply it to your products through the MuseHub Developer Utility.

Applies only to commercial (paid) Applications and Plugins

Muse DRM is not suited as a protection for Electron apps, that should use Muse SDK instead.

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.

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.

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

• 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:

Application example

musedrm --protect [your app.app] --api_key [your api key] --product_id [your application_id] --overwrite

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:

Plugin example (distributed with installer)

musedrm --protect [plugin.vst3 plugin.component plugin.aaxplugin] --api_key [your api key] --product_id [your application_id] --overwrite

When submitting individual assets without an installer, each asset shall be wrapped separately:

Plugin example (distributed without installer)

musedrm --protect plugin.vst3 --api_key [your api key] --product_id [your application_id] --overwrite

Parameters

• --protect <Product.vst3> bundle or standalone product, one or multiple assets are accepted (see the use cases for installer vs individual asset above)

• --api_key <your API key>

• --product_id <your product's GUID, shown at the top left of its product page in the Partner Portal>

• --out <destination path> 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 <Product.app> <Product.vst3> ... Check if one or more assets are already protected by MuseDRM

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.

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.

Be sure to codesign and notarize the wrapped product and mind the --force --deep flags.

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.