copy protection external

b-bamp

I've never heard of software_DNA, and they don't turn up in a Google search.

If they claim to support lots of languages, assuming it's true, go for the one you're most comfortable with. I would wonder whether they support Java without JNI linkage (in which case you might as well just go for C/C++ in the first place).

Bear in mind that if you want to protect standalones you don't have any control over the binary - it's the MaxMSP runtime - and can't stop people scraping off your patcher code.

The Max SDK explains how to write externals (specifically in C). You can't write an external just by pasting C example code into Xcode.

Visual Studio 2008 Express lets you write C/C++ externals for Windows. This is described at the beginning of the SDK documentation.

Thanks Nick, I have someone to encrypt the .mxf so with a bit of licensing it should be a pretty secure

I have a minute amount of experience in C++, will check the SDK, might be needing someone to do it for me soon if I can't figure it

Try searching for 'softworkz' instead.

I'm not aware of workable encryption schemes for Max collectives (given that the Max runtime has to be able to open them), but there might be something out there. It does mean that you're relying on two distinct security measures at once, which complicates matters.

Softworkz doesn't give much away on their site. I went through this process with another third-party DRM provider a while ago before settling on a home-grown solution more suited to protecting Max patcher code without modifying the runtime.

Hi Nick, I'm not worried about the Max patcher code, I have someone who can encrypt it.

This is basically to tie the software to one machine, so you're adding all the functionality of their copy protection in to a Max object, which then goes in to the application (not collective), which is then encrypted.

That seems simple enough to me, does it to you?

I guess it depends how the encryption works, and whether you can encrypt the entire package (both Max runtime and collective - standalones have a collective inside them) in a way that'll allow the Runtime to access what it needs to.

what is the runtime and what is the collective?!

confused

https://cycling74.com/docs/max5/vignettes/core/standalones.html

Some random thoughts…

There are a couple of approaches one can take to "protecting" standalones, with varying degrees of efficacy. One way might be to encrypt the .mxf and write a wrapper application that decrypts it at startup time, before the Max Runtime takes over. This may be more work than you anticipate, though.

Another way is to wrap some of the key functionality of your patch into a custom external that has some kind of CP built into it. There are probably other approaches.

You can combine these with a more heavy-duty general-purpose CP scheme, such as PACE or softworkz.

You do need to balance in your mind the effort into CP against motivations people might have make unauthorized copies. How much is CP likely to cost you and is it worth it? Depending on how your app works, you may find that support & documentation & similar are greater motivations to get people to license your software than CP.

Also, for all the Max5 collective format is an extremely weak link in any copy protection scheme, if your target group is small and not experienced in Max, they may be very unlikely to use this "back door" to circumvent a front door lock like Pace or softworkz or something home spun.