Mike S

I'm in touch with a company called software_DNA, who offer copy protection / licensing solutions which I need for my standalones.

They have source code available in a variety of different languages (C, C++, Java). Here is a quote from them...

' The main criteria for integration with our system is for you executable/application be able to make and interpret API calls to our DNA external library'

So, this is within the scope of a Max external I presume?

1. Which language should I choose? Perhaps it doesn't matter?

2. How do I build externals for Max? I had a little look at the SDK but I'm in over my head. I presume I should be able to copy the source code in to Xcode and from there make the application (it seems there are a few lines to be drawn between dots here!)

3. What environment can I use to build externals on Windows?

They have source code available in a variety of different languages (C, C++, Java). Here is a quote from them... 

' The main criteria for integration with our system is for you executable/application be able to make and interpret API calls to our DNA external library' 

So, this is within the scope of a Max external I presume? 

copy-protection-external

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

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?

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?!

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

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.

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. 

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.


MAX Encryptor, AppProtect and QuickLicense/AddLicense are tools to encrypt, protect and license MAX code and applications. See 

MAX Encryptor, AppProtect and QuickLicense/AddLicense are tools to encrypt, protect and license MAX code and applications.  See http://www.excelsoftware.com/max5


I have a strange, but perhaps stupid question:

If i don't care about whether people can steal my software itself, but i care more about hiding the math behind it, am i protected from this when writing an external in C?

can someone take the compiled form of an .mxo or .mxe and decompile it pretty easily to get to... say the perform_routine in my .c code?

(i realize it sounds weird, but i am thinking more like an old-school guitarist who has found his specific amp/pedal/cabinet setup/sound, and doesn't want to share the specifics/math on how to build it, but doesn't mind if others play a couple of their songs on the same setup for free, since it is still 'my sound' :D ...i am normally all for providing free education to the masses(c'mon now! it's me! i'm an asswipe, but i'm a helpful asswipe! :D), but there are a couple tricks up my sleeve i never want to expose fully or at least not so quickly... and for fear of that, i never share even the end-result... but it would be nice, just to hand out the tool without exposing the math until i'm truly ready(within myself) to reveal it...)

If i don't care about whether people can steal my software itself, but i care more about hiding the math behind it, am i protected from this when writing an external in C?
can someone take the compiled form of an .mxo or .mxe and decompile it pretty easily to get to... say the perform_routine in my .c code?

(i realize it sounds weird, but i am thinking more like an old-school guitarist who has found his specific amp/pedal/cabinet setup/sound, and doesn't want to share the specifics/math on how to build it, but doesn't mind if others play a couple of their songs on the same setup for free, since it is still 'my sound' :D ...i am normally all for providing free education to the masses(c'mon now! it's me! i'm an asswipe, but i'm a helpful asswipe! :D), but there are a couple tricks up my sleeve i never want to expose fully or at least not so quickly... and for fear of that, i never share even the end-result... but it would be nice, just to hand out the tool without exposing the math until i'm truly ready(within myself) to reveal it...)


no, once compiled into a c external there is no way to look at the source code.

^ah nice. this inspires me... thank you so much!

I've only skimmed the SDK docs for Max externals but they're dynamically loaded from Max. That means they have entry points (and addresses) that can be displayed with nm

In particular, there are some well defined names at you have to use so that Max can be informed where your perform code lives

So probably wouldn't be very hard to find the address of the perform code with nm

In particular, there are some well defined names at you have to use so that Max can be informed where your perform code lives 

So probably wouldn't be very hard to find the address of the perform code with nm


ah, now i've learned about and read up on 'nm', very helpful, thanks!

(haha, not that i'm asking further, but now i'm curious about whether it's possible to obfuscate the address of the perform code a little by indirectly referencing the perform_method from another method first...

void myobj_dsp64(t_wrecker *x, t_object *dsp64, short *count, double srate, long vecount, long flags)
{
   object_method(dsp64, gensym("dsp_add64"), x, myobj_trickperform, 0, NULL);
}

void myobj_trickperform(t_myobj *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sframes, long flags, void *userparam)
{
//maybe put code here using gensym to generate a misleading symbol as well...
//perhaps address a dummy struct...
//then pass args to the real perform:
myobj_realperform(x, dsp64, ins, numins, outs, numouts, sframes, flags, userparam);
}

void myobj_realperform(t_myobj *x, t_object *dsp64, double **ins, long numins, double **outs, long numouts, long sframes, long flags, void *userparam)
{
//real perform method goes here.... hopefully slightly disassociated from the "dsp_add64" symbol?
}


but no, i'm probably being a ridiculous noob and there's much much more to it, so i'll keep learning C and looking into it... ;) ...plus, it would probably break everything since the perform method needs to be one method/routine called within the callback of the audio driver...

(haha, not that i'm asking further, but now i'm curious about whether it's possible to obfuscate the address of the perform code a little by indirectly referencing the perform_method from another method first...
for example:

but no, i'm probably being a ridiculous noob and there's much much more to it, so i'll keep learning C and looking into it... ;) ...plus, it would probably break everything since the perform method needs to be one method/routine called within the callback of the audio driver...


@RAJA Anybody with experience reading assembly language would see through that in a moment. They'd find the 'perform' and see there was a subroutine call somewhere else (generally a relative address) and they could just trace it. Done it many times myself in the good old days. These days most people don't know what an opcode is and think it's just the company that used to sell Max (grin)

@vendredi Stripping the symbol table (or even not saving them in the first place, a compiler option normally) will not eliminate names that are needed for dynamic loading. Think about it --- if you have a routine in a dynamically loaded library that has to be called from the loading host program, that program HAS to be able to find the address of that entry point. That means any app can find it.

These days most people don’t know what an opcode is and think it’s just the company that used to sell Max (grin)

hehe, ya, i'm so young i first(in the 90s) associated the word to CSound :p

(i've only programmed simple assembly onto firmware before, never used it on an actual 'computer' :O... lions, and tigers, and bears?! ohhh my!)

hehe, ya, i'm so young i first(in the 90s) associated the word to CSound :p
(i've only programmed simple assembly onto firmware before, never used it on an actual 'computer' :O... lions, and tigers, and bears?! ohhh my!)


copy protection external