Stand Alone Copy Protection
I recently realized that when I make a stand alone on my mac, I can use the view package contents to get the collective, open that in max, unlock it, and then I have the code from it. I have seen professional distributed programs made with max and I am curious how it is they keep their source from being able to be opened like this?
Also, is there a way to do copy protection key/serial style inside max? I had thought about doing it with using the machine code using shell, but It seems that shell doesn't work in max 5... or did something happen to shell on my computer?? does it work for others on mac os10.4 max 5.05?
Thanks and have a great one!!!
You can take the .mxf from an app and open it in max, but you cant edit it.
Wait, I just try open a collective taken from an app with textwrangler and, yep, there's your code.
When you're developing apps, you really want to stay away from third party objects. To me it happened a few times that such objects were no longer supported or updated when I had to come with a new version of an app.
For protection, a scheme that I came up with once, but never used, is that the user needs to provide an email adress, which gets scrambled and is compared to a serial number generated by you based on that email adress. Both email adress is and serial are stored within in the app and it will only launch when they match. Still you could copy the app but a splash screen could show to whom it is authorized. Many shareware apps though don't make use of any checks and have simply a built in list of possible authorization codes.
The reason that I never used mentioned scheme is that I at some point found that apps can behave totally different and unexpected on machines different from the one you built it on. I decided that I didn't want to spend my days doing customer support.
_
johan
I would like to know how to do the protection to .app patches as well.
Maybe, if say there was a certain patch you had to built inside your own patch would be good like say [loadbang], message box [lockpatch], [thispatcher]. Or something like that, put in the main patcher window, then can maybe pop up with different ways to protect it, by either a password or by hiding it, or something.
Maybe something like that could be put into effect in maybe a later update version of Max. But who knows. But might be something for the C74 to maybe think upon. But obviously they need to get Max for Live out and Pluggo on top...
The long and the short of it is that a Max standalone will never be all that secure copy protetction-wise.
If you want a secure app, program it in C or C++ or something.
jvkr wrote on Sat, 28 February 2009 09:36You can take the .mxf from an app and open it in max, but you cant edit it.
Wait, I just try open a collective taken from an app with textwrangler and, yep, there's your code.
Prior to Max 5, the binary format was tricky enough that there was a bit more to cracking the collective than a copy/paste from an editor. Nonetheless, the format was breakable.
Presumably all the more so with Max 5's JSON-based storage.
If you're going to sell a Standalone, you're going to need to couple any kind of protection scheme with support, community, and other incentives to avoid unlicensed copying. And there will be copying anyway.
Quote:
When you're developing apps, you really want to stay away from third party objects. To me it happened a few times that such objects were no longer supported or updated when I had to come with a new version of an app.
First, using bundled externals is no guarantee of longevity--Cycling has orphaned its share of externals over the years. Have you tried using a graphics window on Max 5?
But more importantly, it depends on the 3rd Party objects. There have been plenty of 3POs thrown into the wilderness without support, but there are numerous well-supported ones. As just one example, Litter Power has been supported for over nine years, across Mac 68k, PPC, Windows, OS X, OS X Intel, and the new Max 5 platform changes. And the support continues as the package continues to grow.
You get what you pay for, Johan.
Sadly I think that unless some form of encryption is built into the MXF files stored in a standalone, there's not a very good way to do this - unless you want to set up a server somewhere that the app checks in with regularly (eww).
Axiom-Crux wrote on Sat, 28 February 2009 00:39I recently realized that when I make a stand alone on my mac, I can use the view package contents to get the collective, open that in max, unlock it, and then I have the code from it. I have seen professional distributed programs made with max and I am curious how it is they keep their source from being able to be opened like this?
Interesting thread, I had assumed the .mxf wasn't viewable like this, but it's true---there it is in a text editor, and it only takes a little fiddling to copy it into a new patch. Might there be a way that this gets encrypted somehow (as an option) when you create the executable/collective, which could only be loaded using a password, and therefore not runnable without it? So whoever buys it would be provided the password to run it on their machine only (which you set on a per-compile basis, and is automatically linked to the machine ID by Max when it's opened for the first time), and if they open the .mxf in a text editor, it's "binary garbage" which can't be pasted into a new patch?
Having some sort of user-enterable password via a dialog box and a select would be simple, as would having a password on the overall application (applied to the .zip archive) but of course this could still be copied at will. Guess it depends on the user to be ethical about it in this case, and of course it depends on the perceived worth of the app.
As mentioned on a thread awhile back, you could investigate a commercial version of copy protection like PACE. There's a decent start-up cost but if you sell a lot the per-unit authorization is quite low, and it is apparently very secure---many companies use it for their big-name products. I suppose if you have a dynamite app which can actually generate decent money, and you're really worried that someone would reverse-engineer and steal the goods, it would be worth looking into.
shoot haha maybe I shouldn't have said anything.. It seems like alot of people didn't know this before...
Or maybe it will give C74 the incentive to make stand alones more secure...
At any rate, I know Ive seen a few robust video and audio applications that were made in max, I seem to remember vidvox VDMX being made with max... but I dont remember..
This is not the first time this has been discussed. The issue's been around for around twenty years and you think you're the first person affected by it?
If your hopes rest on Cycling '74 investing energy into encrypting the innards of standalones, I would recommend looking through the archives. No harm in asking, but a reality check may be called for.
I didn't say Im the first anywhere did I? I said it seems like multiple people mentioned they didn't realize this until I posted. I didn't realize it until recently when I couldn't run someones applet and tried opening their collective inside the applet... I guess its not such a big deal if your audience is outside the max community, and wont have max to do this, but as alot of the people who would probably be interested in my forethcoming applets are in this scene I was just wanting to see if there was something. I don't think it will be a big issue for me since I plan to do things a bit differently and sell a subscription to my site where people will have access to all my patches, creations (A+V) and sound libraries, etc. I always assumed people will pirate no matter what so why not figure out a new way to do things that will entice people to pay a small amount to get way more stuff then they normally would.
I don't believe that anyone said you were the first to question this. The suggestion was that those before you may have been somewhat more circumspect about things for any number of reasons.
well.. I think peter did, literally...
"This is not the first time this has been discussed. The issue's been around for around twenty years and you think you're the first person affected by it?"-peter
Gregory Taylor wrote on Sun, 01 March 2009 18:28I don't believe that anyone said you were the first to question this. The suggestion was that those before you may have been somewhat more circumspect about things for any number of reasons.
Max has been and will continue to be the birthplace of cool applications and plugins. It's definitely grown into a capable development platform under C74's guidance. From what I can tell It wouldn't take so much for C74 to shore up Max 5 for 3rd party developers.
For Nortron Peter's written an external which pulls some low level identification bits from the customer machine which we then key the app bundle to. This works fine, but we haven't looked at how we're going to handle it on Max 5 since the app bundle sources are easily readable by any Max 30 day demo user. FWIW, we built a database to keep track of authorizations and do the new version emailings automatically from within Max. Also, we built a network authorization system but haven't needed it yet.
Perhaps Cycling could do an app store similar to Apple's iPhone App Store, except in this case sell 3rd party audio and video plugins and standalones. A sort of bridge between Max wizards and professional media authors.
Whatever support commercial Max developers can get seems positive to me so I'll keep writing
The issue has been discussed before. That was my main point. Really. The official response in the past has indicated that Cycling '74 does not see security of the innards of standalones as a high priority. At all. For instance:
<https://cycling74.com/forums/index.php?t=msg&goto=156934> (scroll down to Andrew Pask's comment for my main point, but follow the whole thread to get a feel for the context)
There are earlier examples. When a software product has a +20-year history, it's a safe bet that nothing is being discussed for the first time.
It's nothing personal, but in this context the comment on Saturday thatQuote:Or maybe it will give C74 the incentive to make stand alones more secure...
just seemed rather, um, naive.
OTOH, there were periods in Max' history where the app took greater note of of the desire to not communicate patch innards. The non-standard behavior of off-screen windows and the shroud message to pcontrol are examples. So policy might change. Ah jes' ain't holdin' mah breaf.
And, in the meantime, I write custom externals to deal with the problem.
In the meanwhile, you write custom...
Why not to solve partly this real problem of work protection at the MaxMsp editor lever (cycling74) ???
Why we all have to bother with custom externals to do at least little protection ? Even 25 years back, when basic was here, it was containing a very simple protection mode preventing source files to be read.
Anyone with basic C knowledge (read/write files), a hexdump utility, and 2 hours spare time can make a Max5 collective decompiler. Not more than 200 lines are needed, including blank lines.
I think the main issue is that collective mxf format is very very bad. For sure, it is very convenient. But very big (contain so many duplicate externals, images, ...).
Regards
Chris
Some logic, if you have spare time:
list is 20 years old=>it contains nearly all subjects
an already discussed subject coming again is useless and anoying
=>
list should be shut down
>Why not to solve partly this real problem of work protection at the MaxMsp editor lever (cycling74) ???
Because we prefer to be in the interesting software writing game, rather than the "continually trying to stay one step ahead of the hackers" game. Call it a lifestyle choice.
>=>
list should be shut down
Do you not know where the archives are?Hint: go to the home page and scroll down a bit.
-A
Be serious a few seconds. It's not a matter of game, but a matter of professional work for earning some money for daily life...
You, at Cycling74, put a lot of protection on MaxMsp. We, your customers are accepting this. We are using your tool because we think it is giving some added value to our work and that we can create income from that work. But the only way of distributing our maxmsp work is creating a collective.
It turns out that a collective is just a raw dump of our precious work into a file without any kind of simple obfuscaction. I'm not talking about racing with hackers.
With any editor (textwrangler, ...), we can open mxf, change something (eg: remove all ; max quit, ...)
We can extract so easilly content of any patch.
You, guys working with maxmsp, you don't know how to implements something in maxmsp ? Just have a look into mxf of others ! Its free and easy!
And don't tell me that we just create a C external for protecting this, that, ...
Yes, we can create externals for protecting whatever. But I'm not talking about anticopy, antieverything protection.
There is just need of something basic that changes the format of maxpat inside mxf, so that curious people need to do efforts to get our work and ideas. Actually, everybody can see all the content of our work without any effort.
Even in a C/Java external, it is not possible to check if mxf has been modified (I would like to know how to get mxf path+name, see my other posthttps://cycling74.com/forums/index.php?t=msg&th=38369&start=0&rid=2782&S=fa9337b203ca7abe6ce9f9d43853c419)
Without this, it is impossible to perform any crc checkup.
>Be serious a few seconds.
I tried once, but everybody laughed at me.
-A
There's never been an explicit aim to create copy-protection schemes for Max patches, to my knowledge. Everyone who required them - and that includes the firm itself - added functionality at the external object level to do so. When it comes to patches and collectives and standalones, what you're seeing is a side-effect of the nice new clean and easy to read XML format for Max patches [no good deed goes unpunished] in Max 5. The collective has never been presented as anything other than a way to collect the various pieces used by a complex patch to facilitate sharing said patch with others. Ditto for creating a standalone.
IIRC, the Standalone was actually previously referred to as a 'Binary' which has a slightly different connotation - releasing a binary of something implies that the source code has been compiled and is inaccessible to the end user. Sadly the OSX package-based application format is much more 'open' than the old OS9 binary program format, which is where we run into this problem.
My first thought was that it was unlikely that there was any mention of the word "binary" in the Max 4.6* documentation at all. The descriptions of collectives and standalones make no mention of it.
You do find a mention of it here (Max46Topics.pdf, page 18):
"On Macintosh, Max builds universal binary standalone applications. The standalone is an application package, which is also a folder that looks like a file in the Finder."
Perhaps that's what you were thinking of. I'm not sure I'd read the term "universal binary" the same way, however. In that context, it would refer to an executable file or application bundle that runs natively on either PowerPC or x86 (Intel)-based Macintosh computers.
>I tried once, but everybody laughed at me.
I'm not paying hundreds $ of maxmsp/jitter licenses + updates to hear something like that from somebody working for Cycling74. It's matter of a serious subject.
At least, respect the customers. If you have nothing usefull to say, don't say. Save your time for your gaming.
Gregory Taylor wrote on Tue, 03 March 2009 12:01My first thought was that it was unlikely that there was any mention of the word "binary" in the Max 4.6* documentation at all. The descriptions of collectives and standalones make no mention of it.
You do find a mention of it here (Max46Topics.pdf, page 18):
"On Macintosh, Max builds universal binary standalone applications. The standalone is an application package, which is also a folder that looks like a file in the Finder."
Perhaps that's what you were thinking of. I'm not sure I'd read the term "universal binary" the same way, however. In that context, it would refer to an executable file or application bundle that runs natively on either PowerPC or x86 (Intel)-based Macintosh computers.
No, I am not an idiot, and wasn't referring to universal binaries. I also wasn't referencing the documentation at all - I just remember build Max 4.6 apps, and having no easy access to the source code that the run time was using.
Never thought you were an idiot. I was merely checking on what the documentation had said about the matter, and it looks like we didn't say anything about the creation of binaries [except for UB Runtime versions of Max]. Any changes in the package format that Apple made along the way doesn't have much to do with us, and I'm not sure I'm of the opinion that going to xml-format files for Max patches is anything but an improvement [at least in terms of readability, if nothing else], although you may disagree. The relative ease with which some parts of a collective or standalone app could be pulled apart by the perspicacious has been around for quite a while - it's merely that it wasn't widely discussed. To the extent that things *were* more difficult to make sense of earlier on, I doubt it had much to do with any desire to support those who wished to obfuscate their code for the purposes of profit.
Gregory Taylor wrote on Tue, 03 March 2009 19:58.... I doubt it had much to do with any desire to support those who wished to obfuscate their code for the purposes of profit.
Cycling74 should consider is as feature request!
Chris
kawkhins wrote on Wed, 04 March 2009 00:43Gregory Taylor wrote on Tue, 03 March 2009 19:58.... I doubt it had much to do with any desire to support those who wished to obfuscate their code for the purposes of profit.
Cycling74 should consider is as feature request!
Chris
Seconded (and from the emails I've gotten about my little obscuring trick, tenthed or so). It'd be nice to have the option to release closed-source material, built in max and not C++ or C.
Everytime this comes up long-time users of Max/MSP express their interest in having "low grade" obsfucation of their collectives.
For some of us it's more of a packaging and end user perception issue than anything else. I'm happy to share *some* patches I create with the Max community but others I would like to distribute without source for commercial or artistic reasons. Sometimes we want to code something cool in Max and share it closed-source to encourage others to cook their own code. In these cases hiding the formula pushes others to innovate in ways we never thought of.
I've been involved in open source projects on and off since I started using computers and I really like them, but it's important to give coders options and Max/MSP is a programming language capable of developing commercial applications.
I think this is amazing, check out the variety of apps spawned by Max/MSP:
Radial, Nortron, Early Grid2, Ableton's early Prototypes, http://www.skrasoft.com/ (Turntable Surgeon)http://www.ruipenha.pt/en/Software.html (*.*!)
Max is capable of producing code that easily qualifies as IP.
It seems good for everyone to have a choice.
How hard would it be to add a build preference that encodes, *not encrypts*, the mxf into a binary format of some sort that only the standalone/runtime Max engine can load?
Sure someone can or will break it, but then the dishonest user has to visit some sleazy web site, download a weirdly named 'mxf transcoder', grab the 30 day demo of Max/MSP and load up their freshly broken app and then try to make heads or tales of it.
[Not to mention, Like Peter said, Max users who *really need* protection can use externals and/or networking.]
The great thing about a tiny bit of obsfucation is that the publisher and consumer or the artist and audience can continue on without the code availability being a talking point.
I intuit there are probably even valid process vs. product arguments that would support an artist's desire to obscure code.
I know how much work coding a software application is, even if it's a Max based one! So I don't lightly ask for feature requests of anyone let alone the C74 team, but I think this re-addition to Max would foster ground breaking applications being developed on the platform && make these conversations go away
or else,
Anthony (jk)
One other point: for every thread there has been on "why isn't the collective format more obfuscatory" (like this one) there has been a thread with someone saying "I lost my original patch, all I've got is the collective, how do I get an editable copy of my patch back?"
Both perspectives are defensible, although people blinkered into one PoV will probably have no understanding for the other. So be it.
The current JSON-based collective format is great for the second group. Your dog's eaten the hard disk with your original work? No problem. The second group is out in the rain.
Andrew, Joshua, David... if I may make raise a suggestion: how would you guys feel about adding an option to save standalone/collectives using the Copy Compressed format, with just enough modification to the begin/end tags that the code wouldn't copy/paste into Max?
This would have two advantages for users
- smaller file transfer bandwidth (minor isssue nowadays, but still...)
- a moderate amount of "code privacy"
I know the Copy Compressed format is supposed to be a simple concatenation of standard, documented formats. However, I know one Pretty Smart Guy who attempted a decoder and found It Wasn't All as Easy as It Was Cracked Up to Be. So there is modicum of privacy with the format (assuming the begin/end tags were a little less obvious...).
Any mileage in that idea? Worth it just to shut up all the whinging about the readability of JSON code? Worth it to add a small add'l layer of protection to Radial?
Thanks for listening,
-- P.
(And apologies to all the other developers whom I didn't name explicitly above... you are not forgotten, it's just the message was too long already).
OK, instead of arguing over whether or not anyone needs obfuscation, let's discuss some possible solutions that you could empower yourself with.
A good first step would be to make the icon for the .mxf file a little scarier. Think gargoyles. Another option is placing a text file inside the app bundle called "DoYouReallyWantToOpenThis?" or "ReadMEtoFindOutHowYouWillSufferUponOpeningMyPatch". Perhaps you could even patch something that checks if the patch is inside of a standalone and prints an error dialog saying "If you proceed, your entire OS will be slowly deleted over the course of the next 2 weeks". Finally, you could write a special encoder-ring object that converts your patch into scrambled text and then descrambles it on launch.
Andrew B.
Peter Castine's suggestions would be wonderful if implemented.
Yes - I am sure a hacker could break the code but most commercial Max apps are not competing with Live and go well under hackers radars. If it is trivial for any Max user to break your code then it is a different thing. Many users of Kenaxis are Max users as well but appreciate having a piece of software to use that does many of the things they want and benefit from me having spent 10 years working on it.
For those that would benefit from having the JSON code as they have lost there original code - just make the compressed format an extra option that has to be selected in the standalone object.
I have no interest in playing cat and mouse with hardcore hackers. I would like a reasonable sense of security for the underlying code I have worked on.
I am starting to create some open source projects but I want it to be my choice to make the code available.
Thanks for your serious consideration of this,
Stefan
PS - My teenage love of gargoyles still has a place in my heart but ten years of work on Kenaxis and hoping for another ten has a much larger place.
I've been thinking about writing an external that encrypts / decrypts mxf files. Perhaps contact me off list to discuss... if there's enough interest to make it worth me doing it I'll get on with it.
Simon
-zip-
Hey RabidRaja,
Having some limited obsfucation might never be needed by you, but there are many who could benefit and it would enhance their relationship with Max.
Suggesting that Max can do anything and that Standalones are merely a subset of Max's functionality is to misunderstand what a programming language enables the programmer to do (create entirely new computer user experiences). If DSPaudio or Tritone Digital or any of the fore-mentioned artists we're merely exporting features of Max to their audience then I'd be in your camp -- I'd write off the need for obsfucation as it would only allow people to get money & attention by exporting C74's hard work, but this is not the case at all!
Max is a well developed programming language and it allows serious programmers the ability to create new workflows and UI's that are entirely unique and useful in a context outside of Max/MSP. Creating Nortron in Max/MSP was a near full time job for/four years and involved 3+ people and remains a consistent development effort with 3 or more days per week put towards it's growth.
Anyway my point is simply that Max/MSP itself has outgrown the old label of "geeky environment for computer musicians" and for better or worse it's now a fully fledged visual development environment. If we look at where Microsoft wanted to go with visual basic circa 93/94 and more recently how IDEs have started incorporating visual UI building, we might conclude that Max or PD is actually ahead of the game and could embrace it's full potential by becoming a 3rd generation language that could in time spawn a 4th.
So, I love Max as much as you or the next person, but I hesitate to think its usefulness stops when I close it. It is capable of spawning interesting children and I vote for some obsfucation of the gene pool.
Cheers,
Anthony
PS, I'm surprised you are willing to pay for a programming language and then advocate a limit on your ability to create applications with it.
Supposing your patch is organised so that it displays in presentation mode you could make a copy of your patch add this javascript and then build your app. It moves every object to the same screen position in patching mode. Remember not to overwrite your original file as you can't undo actions performed by javascript. Obviously it's not doing very much but I for one don't have the time to sift through a large patch and move every object around until I can figure out what is going on. So hopefully it will dissuade a few people from stealing the guts of your favourite shared patches. You can also hold alt and drag to select all patchcords then select arrange > align from the menu to make it a bit messier.
lh
// oops.js
// move everything (except "patcher"s) to same position
function bang()
{
this.patcher.apply(eachobj);
function eachobj(x)
{
if (x.maxclass != "patcher")
x.message("sendbox","patching_position",100,100);
return true;
}
}
// EOF
andrewb@cycling74.com wrote on Wed, 04 March 2009 18:31A good first step would be to make the icon for the .mxf file a little scarier. Think gargoyles.
I'm using an icon of Sarah Palin.
Peter Castine wrote on Mon, 02 March 2009 04:27
It's nothing personal, but in this context the comment on Saturday thatQuote:Or maybe it will give C74 the incentive to make stand alones more secure...
just seemed rather, um, naive.
I never took it to any insult. I was just saying to gregory that he had possibly overlooked your comment, and said that nobody said that ... too complicated.. no hurt feelings here and this is kinda silly hehehe
In the end all Im saying is that I hope we can find an easy secure way to create apps with max. I think its a great development tool for creating of software that would otherwise be unrealistic to create.
andrewb@cycling74.com wrote on Wed, 04 March 2009 11:31OK, instead of arguing over whether or not anyone needs obfuscation, let's discuss some possible solutions that you could empower yourself with.
A good first step would be to make the icon for the .mxf file a little scarier. Think gargoyles. Another option is placing a text file inside the app bundle called "DoYouReallyWantToOpenThis?" or "ReadMEtoFindOutHowYouWillSufferUponOpeningMyPatch". Perhaps you could even patch something that checks if the patch is inside of a standalone and prints an error dialog saying "If you proceed, your entire OS will be slowly deleted over the course of the next 2 weeks". Finally, you could write a special encoder-ring object that converts your patch into scrambled text and then descrambles it on launch.
Andrew B.
when will the decoder rings be available?
Axiom-Crux wrote on Sat, 07 March 2009 06:25
when will the decoder rings be available?
Sometime after pluggo, I expect.
My own response to this whole thing is: Yes, Max is mainly aimed at artists. But while I make personal projects which I don't mind sharing, I also make tools that are relatively powerful (we used one for all the major design SFX in the new Day the Earth Stood Still). This is something that other people find value in, and which I enjoy creating, but don't really want to 'give away.'
Having the option to lock up creations doesn't harm the artist side of things in any way, and gives the toolmakers greater flexibility in releasing their work.
As to 'forcing a user base to depend on a developer who depends on another developer' - this is everyone developing any sort of software. People coding for mac OSX rely on Apple and their interfaces and SDKs. Cycling74 relies at least somewhat on the developers of JUCE, Java, CoreAudio, etc etc. If you run into a problem caused by someone higher on the chain than you, you make them aware of it (or try to convince them it's something worthwhile to change/fix) and then try to figure out a workaround in the meantime.
As an aside, who else in this thread is going to expo74?
Just had a thought, it's probably not ideal, but it's straightforward and will work to a degree:
1--Code your patch so that nothing of the "guts" is visible on the main layer, just UI objects that are simple to make and aren't giving anything away. The guts are in subpatches, ideally only a few, but could be as many as you want. Put a panel over everything you want hidden within them.
2--Use [active] so that any subpatches that get opened will auto-close immediately. Keep the last cord (to pcontrol) disconnected as you work, save a final version like this, then make your collective/application with it connected. Unless you put in some kind of passcode to deactivate this, you yourself won't be able to get at it easily. The quick flash of the subpatch would show nothing since the panel is on top; even if they were screen-capturing, they wouldn't see anything.
3--Since clever Maxers could figure out the [active] or maybe a [loadbang] which you use to hide things, or run the app with [loadbangs] deactivated, you'd need the object to do something else which allows the patch to run at all. This way, even if they take out the [active] in the text file, which is easy if you're looking for it, the patch won't work: maybe it scripts the creation of the real object which does everything (an included abstraction).
Well, looking over this, there's still plenty of loopholes, since one could always (in theory) find the guts in the text, but this would at least prevent them from being found super-easily (unless I'm missing something obvious, which is often the case regarding Max). Again, it would come down to how important it is for them to deconstruct it, how clever they are, and how long they want to take. Hopefully at that point they'd rather just pay you for your efforts and get some karma points.
IMO having some sort of copy-protection available as an option at the top level (when building an app) is definitely the best solution, and I would welcome it if it's possible for C74 to implement. I don't think it has anything to do with art vs. commercialism, you can make patches and distribute them however you want, free or not; nobody ever *has* to buy them unless they want to---it's like having copyright on any other artwork, though in this case, would be much stronger protection. There's also nothing that says you couldn't sell patches which could be modifiable (giving the buyer the details as a kind of reward), or give away free ones in which you *don't* want the functions copyable (you want people to use it freely but don't want them to steal from it). It would be nice for certain things you've worked on for a long time to not be so easily grabbed and re-used, or worse, for someone to use them in their own app which is then sold and protected... the ultimate in frustration for you, the creator!
The vast majority of stuff we create, it seems, people are willing to share---since as clever and difficult the functions may be, we realize that they're probably not worth much (if anything) monetarily, at least as-is. And that's the great part of a community like this, or like forums where you go to learn Java or whatever else---re-using and tweaking existing code is a great way to learn and to make big steps quickly, that you may not understand at first, but through deconstruction you learn a lot more than you would trying to build from scratch. The result is that more people know and can share more, and build upon everyone's past work. At the same time, if someone or a group or a company builds an amazing app which can make lots of money (meaning that people are willing to pay for it) this should be readily protectable, as it spurs on further development of these complex apps. That being said, I'm all about open-source and absolutely love it when a major app gets a worthy competitor which was made by a community effort of volunteers, and has its secrets available for all to see... like my favorite, Open Office.
Also wondering who will be at the Expo, I'll be there... can't wait!
CJ
the simplistic auto-close patch using [active]:
How about this:
1. all externals and ui objects etc are compiled into a c/c++/whatever binary library, a set of functions/classes.
2. accompanying the next major release of max (max 6, say) is a translator utility which translates your beloved max patch into c/ c++/whatever code. This code refers to and calls the classes that are embedded in the library provided by c74.
3. use your favorite compiler to create a true standalone app, written in c++/whatever (via the translator and linked libraries), which would execute at a much lower (and faster) level.
4. c74 could justify the great amount of work involved in implementing this scheme by charging (as an optional extra) for the translator utility.
doesn't really address copy protection directly, but no one could steal your beloved patch algorithms as it would be in true binary code, independent of any runtime environment
also probably not practical for various technical reasons that i've not thought about/are beyond me
I missed this thread! I have been selling standalones for a while now, for better or worse. At Livid, we have a registration scheme for Union, Cell, and DNA that authorizes a machine to use the software. It works pretty well, and our products are under the radar enough such that no one has earnestly tried to hack the cp scheme.
I haven't yet ported these to Max 5, so the exposure that JSON brings is not yet a factor. It is definitely a drag that someone who owns Max 5 or runs the demo could conceivably cut-and-paste the collective, make a few edits, and make a standalone to distribute the app free of protection. It would be great if there was an option for a bit of obfuscation of the collective. I know it's not the mission statement for C74 to make a programming environment for commercial applications, but it is a reality that it's used this way. I can't see that it would be too helpful for the Max community and the Max product to make that reality be cut-and-pasted away.
However, one thing I have done in my latest app, DNA is rather than make it more closed, I've made it more open to Max users. I purposefully make the standalone so that it scripts a lot of things into place, so I have to manually add those patches to the app package. Max users can now go into the package and dig around some of the effects and extras and hopefully make their own to extend the application and personalize it. This gives a Max user the opportunity to focus on video (or other) processes, rather than making an interface, which frees up more time for art and creativity.
Peter Nyboer
ps - yes, at expo.
kawkhins wrote on Tue, 03 March 2009 18:34Be serious a few seconds. It's not a matter of game, but a matter of professional work for earning some money for daily life...
recently i found a new way of copy proteecting my music.
to make sure that nobody makes illegal copies of my new CD i have invented the following process:
1. dont compose and dont produce the album.
2. dont clear the rights, and dont make a glass master.
3. dont make copies and dont sell them.
4. dont tell anybody you didnt release an album.
5. now burn all the originals you have never composed, recorded, copied and mastered in the oven, but dont forget to scratch the CDs you didnt make before burning them. you might also want to encrypt them.
6. you can now start selling dongle protection systems to other paranoids and become rich. when democracy does not really work out any longer, just move capitalism to china.
i believe this works for software too, but i have not yet tried it - due to the lack of a reason.
-110
Terry McDermott wrote on Sun, 08 March 2009 11:181. all externals and ui objects etc are compiled into a c/c++/whatever binary library, a set of functions/classes...[schnipp]
I don't know how you want to do any of this. Max has no access to the source code used by external objects. External objects are compiled machine code. A patch is a text-based description of how the objects communicate. There is a widespread but completely baseless notion that Max somehow translates a patch into some kind of conventional programming language to execute it. But that's about as close to reality as the notion that the moon is made of green cheese.
There are actually some practicable approaches for patch protection that a 3PD could build into an external. If I were between jobs (and finished with my tax returns)-: I might take this on as a project. But I'm not.
Nor am I convinced there's really a market big enough to finance the development effort. Someone else might want to try their luck, though.
oh btw, back in the days zack settel had that method of making patches unreadable by simply moving objects around randomly between -15000 and +15000 pixels. this is very easy to do, and will probably stop people from immediately coping parts of your patches.
Peter Castine wrote on Thu, 02 April 2009 21:49Terry McDermott wrote on Sun, 08 March 2009 11:181. all externals and ui objects etc are compiled into a c/c++/whatever binary library, a set of functions/classes...[schnipp]
I don't know how you want to do any of this.
I wouldn't do it, as i am not a software development company.
I stated as a _library_ -- not as the actual source code. Obviously i'm talking about C74 creating a _binary_ library from the source code, which is accessable through function calls or class definitions. These function calls would be created through a translation utility developed and sold by c74, (either embedded in the max app or provided separately) that translates patches into a set of function calls, but the source code for the functions remain opaque/inaccessible.
T
Terry McDermott wrote on Fri, 03 April 2009 00:04I wouldn't do it, as i am not a software development company.
Yeah, well, it's always easier when we expect someone else to do the work.-
I have read your explanatory comments. It still seems like you are seriously underestimating what's involved with your suggestion. But that's a moot point.
The question is whether Cycling '74 is really prepared to expend any resources at all on 'protecting' standalones. Their public response to date has been emphatically negative, as you have surely seen.
That may change some day. But ah ain't holdin' mah breaf.
Well i think at this moment in time. Cycling '74 do have one or two more things left to do, before they can start thinking about app protection.
Yes, it would be a great thing to have, and am more than sure they are taking notes on what people do have to say about this subject.
But what with Mx for Live to come out, plus Pluggo, whenever that is. I think we should more or less just get on with other things in the mean time.
Thats my 2 cents about this. I think i am just replying, because it keeps popping up in my mail with more ideas but no resolutions...
readable patches is always a bit like open source isnt it?
you can steal code - but if you redistribute it, the others
can see that you did. well, so far this is a working system!
if someone now encrypts his applications, i can no longer
see if he maybe copied half my app.
he is save then, but the other 10,000 are not.
i have copied and modified several patches from other
people without asking. it is not a problem, because i
dont redistribute stuff i cracked out of foreign patches,
at least not for money: about 15 of my 800 abstractions
are more or less copied from other peoples work.
so what? copy mine if thats required to fix my karma.
it is ok to think about hiding stuff a bit more but
actually this readability is completly overrated.
there are not so many maxmsp programmers who will
easily read each other patches with bad things in mind.
For me, the issue isn't if some other maxer snips my patches and attempts to intrude on my business (probably pretty unlikely), but that with Max 5 standalones , it would likely be fairly trivial to snip out the part that authorizes the machine, and then just re-distribute the full standalone free. Even that may not be so terrible (advertising?) but we are too wimpy to experiment with that right now, as part our business model is (perhaps unfortunately) built on the dated notion of selling units of software.
Quote:if i'm not mistaken, you're the one I met during my brief rabid time at Asphodel/Recombinant? ...hope you don't remember me from that time, hehehe
Well, the name "RabidRaja" doesn't exactly ring a bell, unless you are that scary-ass pit bull the neighbor used to have at the Compound. But yes, I was there doing video stuff. Current work is at lividinstruments.com.
By "dated" I mean selling software is probably going the way of the glacier ice, as we have to keep relying on absurd copy protection schemes that seem doomed to fail. Futurtopia seems rooted in open-source, free software, where you "make money" by trading credits on your karma futures.
thereishopeforus@hotmail.com wrote on Sat, 07 March 2009 05:32Supposing your patch is organised so that it displays in presentation mode you could make a copy of your patch add this javascript and then build your app. It moves every object to the same screen position in patching mode. Remember not to overwrite your original file as you can't undo actions performed by javascript. Obviously it's not doing very much but I for one don't have the time to sift through a large patch and move every object around until I can figure out what is going on. So hopefully it will dissuade a few people from stealing the guts of your favourite shared patches. You can also hold alt and drag to select all patchcords then select arrange > align from the menu to make it a bit messier.
lh
// oops.js
// move everything (except "patcher"s) to same position
function bang()
{
this.patcher.apply(eachobj);
function eachobj(x)
{
if (x.maxclass != "patcher")
x.message("sendbox","patching_position",100,100);
return true;
}
}
// EOF
Damn. I was hoping to use this for my expo74 science fair project, but I realized (and tested) that it utterly destroys order of operations, so while yes, it does totally obfuscate the source, it also breaks everything.
MuShoo wrote on Tue, 21 April 2009 00:11
Damn. I was hoping to use this for my expo74 science fair project, but I realized (and tested) that it utterly destroys order of operations, so while yes, it does totally obfuscate the source, it also breaks everything.
Ahhh, if only you'd used trigger for all that... yes it's more objects, but no worries with order of ops!
on a possibly more helpful note, one could go this route, using [pattr] with each object's patching_rect. "pattr (pattr-name) @bindto::(object-name)::patching_rect" will track the current position and size of each object. More clutter and work, but it also lets you store different layouts of your UI that can be accessed by the end user, pretty cool for things like "zoom" etc.
So using that, store one that's the desired one (or a bunch), but then store one where everything is totally screwy or laying on top of each other, off the screen, tiny, etc. This is the one which loads, and unless you know a specific passwork (dialog) or a sequence of clicks on some numbers or buttons, you'd never get anything uncovered and visible, much less usable. the pattrstorage would of course be inaccessible too, and only if they figure out which one to loadbang could they see anything.
Even without dealing with this issue, the pattr-->patching_rect is pretty neat, especially for things like pwindows, waveform~, function, or multislider, where you have a bunch of them and sometimes you want them small and sometimes big.
You know, pattr is one of those uber-powerful objects that I've been avoiding figuring out for quite some time now... I might just have to spend a weekend and delve in.
Would pattr>patching_rect allow, somehow, for resizing windows? I've been trying to figure out a way to resize patcher UI windows dynamically, with only certain objects changing size with the window. IE, an LCD object with a bank of tools, the tools stay the same size while the LCD resizes to match the window size.
For resizing windows I'd suggest javascript but you could always store some "window size 1 2 3 4" [thispatcher] messages in a [coll] and bang them out via [pattr]/[preset] to change the size.
lh
However if you had access to the patch wouldn't it be possible to find the pattr-family objects with scripting, js or [thispatcher], and then load in the presets manually. You'd even have xml file to look at. I'm not a pattr expert though so I could be wrong.
I will agree on one point: [trigger] is indispensible, it is one of my most used objects.
lh
If you want to learn about pattr, the X.FM synth in the examples/synths folder is a good starting point. This influenced the design of Livid Looper, which has some decent documentation of how pattr can be used. Additionally, it has ways of bridging pattr and osc messages, which is really nice for extending your app into the "cloud"
Hello all,
I know this is an old thread, but I'm interested in the idea of being able to open collectives using a text editor.
i am running Max 6 on OSX, and have tried opening collectives with text wrangler, which gives a load of code (it means nothing to me though!)
I'm wondering if someone could tell me how to use this code to return the collective back into a patcher?
Any help would be brilliant!
Cheers
Andy
Opening a Max collective in a hex editor will reveal what all of that code means. You can see the standard patcher ({"patcher" : etc.) is 'bookended' by other text. Remove all of that and save it as a .maxpat to make it editable in Max.
Conveniently, most of the best patches made by other people are open-source anyway, so there's no real need to do this. Equally, if someone's asking for something in return for their hard work, you'd be a bit of a knob not to pay for it IMO.
Completely agree with you Medd, don't worry - this is concerning one of my own patches!
Andy
Having shared quite a bit now, I dont feel bad about selling some products, and Ive already had some bad experiences with software piracy when I was on Reaktor. Someone in Germany took my work, reskinned it, and sold it himself. Then he even wrote to me how stupid I was because he could do it, and then generously offering to license my future products under his own company name. I contacted Excel software asking about including Internet authorization and whether they could support gen~, but I didnt hear anything back, so now Im not sure what to do next, and if any one has any advice, I would be grateful.
Ohh what a wonderful coincidence ...
Excel software people today are trying to convince a student of mine to buy your stupid code.
But it does even selling a demo to 50u $ s I have warned him about trusting companies that have this policy.
Usurers are everywhere ...
My students have to pay to "know" if the software does not interfere with the performance of a fairly complex patch. gen, poly~, externals.
Anyway, how casual coincidence, someone bump the post and just talk to that company.
PS: Too bad, that evil is the German thief.
what about coding an other app that virtualizes the environment that the standalone runs in or decrypts it? if there was a big enough demand you could sell it to other people. ;) or using gen? couldn't you use that to decrypt and/or generate parts of the patch on the fly and/or put the copy protection scheme inside the generated code? or just make the code confusing enough that most people wouldn't bother? :)
as far as c74 adding copy protection methods, afaik max isn't sold as a platform for making your own commercial products and copy protection is a fluid thing that would very likely have to be regularly updated. maybe thinking about what objects you'd need to make your own copy protection that have a more general usefulness would be the things to lobby for? also, i'd guess that by coding your own flavor of copy protection, even if it was kind of crappy you'd have better security long term...
oth, the features of the protection cracking tools would be great to come to max. gpu accelerated processing of markov chains / hidden markov models to "brute force" audio/visual structures, yes please. :)
wonder what system max 7 uses to authorize online? that could be fun to use for a lot of purposes if it was an object in max haha.
Well, part of the reason I switched to Max was that I prefer the quality of the user community, and actually I have no problem sharing here. but another reason I switched was that I can build standalones that do not require customers to own Max themselves. I am asking about copy protection and authentication, because I was selling some things for small sums, and had alot of contented customers, but after one person simply shared them in a forum to download, my sales dropped to zero almost instantly.
As for writing the software myself, the answer is resoundingly no. Having already had some encounters with pirates, I have no wish to be their direct adversary by providing a commercial product for them to thwart, it is not in my personality. But some people do seem to enjoy such things.
I was one of the first people to use Excel, and imagined that lots of other Max users would want to do the same. I'm in two minds as I've had a lot of help from them, and I can see why they wouldn't necessarily want to spend a great deal of time making sure things work in an environment where there is little return for their efforts. They could be better, could be worse, but I don't see that they're some evil money grabbing company - that's just my experience.
If this appears to be the only solution for people, I can build on Mac/Win with Max5/6/Gen if anyone needs to test things out.
It is clear that they can charge whatever they want for their software, but I think it is more expensive than Max himself, Msp, Jitter and Gen and infinitely less useful.
The companies engaged in computer security, do not usually have an attitude with which I sympathize a lot, especially when advertised, trying to create us fear.
If Excel cost four times less than the full suite, not the product A, product B which added to .. maybe it would be a good option.
Meanwhile my students are pursuing all alternatives and even contacted two programmers responsible for a project at some "hub" which would do the same as Excel and other apps, only gnu and free, just be something I told him to share in this forum.
Version 1 of my stuff is old now (2011), redesigning the site for version 2, which with any luck should be out in the next couple of months :)
edit - working on some max for live devices too
New angle of view - Investors WANT protection!
Well now that I ve developed an app with great effort, and we get some response from investors, I find that there is no way to actually protect the code I ve been working on for almost 2 years?!
We programmers can talk about the pros and cons all day long, and I get them - but investors want to see some protection mechanism in place, and don t really jump for: "well you know, they ll break the code anyway, so why go through the hassle of trying to make their life a little harder..."
Stealing the code in 2 min vs. 2 days - that s really a big difference if you worked on the code for 2 years...
I ll have a look at the solutions to be found on this thread:
https://cycling74.com/forums/fyi-successfully-protected-a-standalone-max-app-on-pc/
And see if I can come up with a solution myself - which I m very unlikely to share here BTW for safety reasons ;)
> Well now that I ve developed an app with great effort, and we get some response from investors, I find that there is no way to actually protect the code I ve been working on for almost 2 years?!
Sadly, if you put "album", "fans" and "music" instead of "app", "investors" and "code" you've described the plight of many of today's recording musicians (apart from the tiny proportion of super-famous ones). At least, the ones who put real effort into their work and can't tour non-stop.
I used to protect ( kind of...) my software some years ago on both mac and windows.
There are 2 levels of protection needed - first to run Software only on authorised computers,
second to hide programming code from being looked at.
At the end I gave up, not because it didn't work, but because I deliver custom software to
individual custommers together with dedicated hardware, so the whole protection stuff was only disturbing.
Having a simple ATmega with Vusb acting as Usb Dongle with individual ID was enough to get authorisation done.
Cost a few bucks.
Or extracting MAC Adress from Computer and creating challenge/response.
The other part , hiding the inner life of Standalone is a bit different thing, on Mac or Windows.
Windows has a lot of options, even a simple Installer that holds untill installed app quits
and wipes it did the job, even in XP days.
On Mac I used Vise Installer Packages that looked and acted like app, and would silently mount the encrypted Standalone DMG
in invisible Directory, run it from there and unmount it after app quits.
Who wants to protect custom externals in a Standalone has another challenge, because Max extracts them all
into temporary directories, path depends on Max version.
There are ways to prevent Standalone to extract all externals at runtime,
just remember old Ircam FTM standalone workaround.
Thanks Source Audio!
Do what I say but not what I do ...
I guess every user who requests time and again this function, simply is asking for the possibility to protect their work, just as it does Cyclyng74. Perhaps users expect something like a check box in the menu, build encypted (ok), pack (ok).
It annoys me a little receptivity and arrogance with which they respond.
Above all, the same people who use TR / Crypt.CFI.Gen and many years of Ilok ...
I think about the cracking scene: Cycling74 want to be one step or hours behind.
Perhaps the cycling74 policy is not open source, maybe: "open your source", ??? always shared your work ...
Perhaps there contradiction, almost a paradox in which programmers C, C ++ does not believe a patch in Max Msp is a program, or may be deemed "work".
Perhaps "the product" should not make a "product".
Perhaps it is not end with the spam: on the specific protection of standalones, carried out by a constant obscure company.
Hello Scott Manson,
So that javascript obfuscator prevents copy or paste your work , but do you know about running a downloaded software on a lot of computers ? It does not prevent the buyer to copy the entire app and install run it on many computers , does it ?