chaostheory

Soon I will be performing a piece of my own that will be manipulated live using a MaxMSP patch. Because I don't want to reload the patch between the rehearsal and the performance (i.e. keep it running on the computer) I thought of creating an application so my work is 'protected'.

I will be using a public computer and I don't mind if people take the application, but I am very hesitant to show the coding behind it so very early on after its completion. Therefore, if I create a collective application I would just like to know if it possible to reverse engineer the .mxo collective (contained package contents) such that someone could view and edit the source code?

Also, I am using the MacOS version of MaxMSP.

reverse-engineering-a-max-collective-is-it-possible

long answer: if you're nuts enough to attempt it, you'd have to reverse engineer the mxo file format. this would likely involve a LOT of testing. you'd write a simple patch, compile it to an mxo, and examine the result. then you'd modify the patch slightly and do the same thing. then you compare the two for differences. then you try varying other parameters.

so... unless you're very very very obsessive and good at this sort of thing (as in you have experience working with the underlying stucture of various file formats), the answer is no.

short answer: no.
long answer: if you're nuts enough to attempt it, you'd have to reverse engineer the mxo file format. this would likely involve a LOT of testing. you'd write a simple patch, compile it to an mxo, and examine the result. then you'd modify the patch slightly and do the same thing. then you compare the two for differences. then you try varying other parameters.
so... unless you're very very very obsessive and good at this sort of thing (as in you have experience working with the underlying stucture of various file formats), the answer is no.


> long answer: if you're nuts enough to attempt it, you'd have to 

A .mxo file is an external binary. I assume you mean .mxf.

Actually, I doubt that the .mxf format is that complex: it's designed 

for convenience, not for security. I've never looked at it, but 

wouldn't be surprised to find it no more complicated than TAR or ZIP.

> long answer: if you're nuts enough to attempt it, you'd have to  
> reverse engineer the mxo file format.

Actually, I doubt that the .mxf format is that complex: it's designed  
for convenience, not for security. I've never looked at it, but  
wouldn't be surprised to find it no more complicated than TAR or ZIP.

Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net


years ago, there was an explanation on how to achieve this by mr. 

ziccharelli himself. it's probably still in the mc gill max-list 

archives somewhere. that being said, the best way to make sure that 

even a reverse engineered mxf-collective doesn't work is to add some 

years ago, there was an explanation on how to achieve this by mr.  
ziccharelli himself. it's probably still in the mc gill max-list  
archives somewhere. that being said, the best way to make sure that  
even a reverse engineered mxf-collective doesn't work is to add some  
custom c-code to the soup.

Quote: jasch wrote on Fri, 22 February 2008 12:27

----------------------------------------------------

> years ago, there was an explanation on how to achieve this by mr. 

> ziccharelli himself. it's probably still in the mc gill max-list 

> archives somewhere. that being said, the best way to make sure that 

> even a reverse engineered mxf-collective doesn't work is to add some 

even then, if you were particularly crazy, you could write a program that exports functions with the same signatures as any detected max runtime calls, and then relink the binary external and have the program output the results of all calls to max functions, by which you could figure out pretty much everything that goes on in the setup function...

Quote: jasch wrote on Fri, 22 February 2008 12:27
----------------------------------------------------
> years ago, there was an explanation on how to achieve this by mr.  
> ziccharelli himself. it's probably still in the mc gill max-list  
> archives somewhere. that being said, the best way to make sure that  
> even a reverse engineered mxf-collective doesn't work is to add some  
> custom c-code to the soup.
>
> /*j
>
>
>
----------------------------------------------------

even then, if you were particularly crazy, you could write a program that exports functions with the same signatures as any detected max runtime calls, and then relink the binary external and have the program output the results of all calls to max functions, by which you could figure out pretty much everything that goes on in the setup function...


> by which you could figure out pretty much everything that goes on 

in the setup function...< And why not some mlp for guessing the output without thinking about 

> by which you could figure out pretty much everything that goes on  
in the setup function...< And why not some mlp for guessing the output without thinking about  
the external function ? :)


As far as I remember from earlier threads the format of collectives and 

>> long answer: if you're nuts enough to attempt it, you'd have to 

> A .mxo file is an external binary. I assume you mean .mxf.

> Actually, I doubt that the .mxf format is that complex: it's designed 

> for convenience, not for security. I've never looked at it, but wouldn't 

> be surprised to find it no more complicated than TAR or ZIP.

As far as I remember from earlier threads the format of collectives and 
stand-alones is now encrypted.

Nick Rothwell wrote:
>> long answer: if you're nuts enough to attempt it, you'd have to 
>> reverse engineer the mxo file format.
>
> A .mxo file is an external binary. I assume you mean .mxf.
>
> Actually, I doubt that the .mxf format is that complex: it's designed 
> for convenience, not for security. I've never looked at it, but wouldn't 
> be surprised to find it no more complicated than TAR or ZIP.


Thanks all. Just a bit of peace of mind really!

On 22 Feb 2008, at 19:32, Trond Lossius wrote:

> As far as I remember from earlier threads the format of collectives 

I just compared Emacs dumps of a patcher in binary with a collective 

built from it. Apart from some predictable topping and tailing, they 

> As far as I remember from earlier threads the format of collectives  
> and stand-alones is now encrypted.

I just compared Emacs dumps of a patcher in binary with a collective  
built from it. Apart from some predictable topping and tailing, they  
look pretty much identical.

> I will be using a public computer and I don't mind if people take the

> application, but I am very hesitant to show the coding behind it so

I wouldn't worry at all about that, usually the amount of work necessary 

to only understand how you patched it, even with sources, is more work 

Just look at the time you needed to create it, the amount of knowledge 

you have about your own piece. Imagine someone who would want to steal 

it... I can't imagine that... He would have to put more work into it 

I made my Ondes Memorielles for example just for myself. Even if I would 

publish the sources, nobody would be able to play them the way I do, I 

doubt anybody would use them as they are. To make something publicly 

usefull requires not only some, but a lot of extra work, usually more 

than was necessary to make it into a personal instrument...

Chris Robson schrieb:
> I will be using a public computer and I don't mind if people take the
> application, but I am very hesitant to show the coding behind it so
> very early on after its completion.

I wouldn't worry at all about that, usually the amount of work necessary 
to only understand how you patched it, even with sources, is more work 
than repatching the same thing...

Just look at the time you needed to create it, the amount of knowledge 
you have about your own piece. Imagine someone who would want to steal 
it... I can't imagine that... He would have to put more work into it 
than you did...

I made my Ondes Memorielles for example just for myself. Even if I would 
publish the sources, nobody would be able to play them the way I do, I 
doubt anybody would use them as they are. To make something publicly 
usefull requires not only some, but a lot of extra work, usually more 
than was necessary to make it into a personal instrument...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Reverse engineering a Max collective, is it possible?