Security for a Quartz Composition and bundling patches

When dealing with encryption, you're only as strong as your weakest link. And in that case, the QC framework is the weaklink, so there's nothing you can do about it. It's trivial (and by trivial, I mean 4 lines of code) to hook the NSData -> QCComposition/QCRenderer step above, and dump the decrypted contents to a file. No matter how fancy you get with encrypting the composition data, at the end of the day you've got seriously next to nothing in terms of protection.

In contrast, cracking CSS for DVDs is harder. cracking encrypted disk images is billions/trillions/more of times harder. cracking the SSH/SSL sessions we use to commit our changes, upload stuff, and check our emails with is on that order of difficulty.

Content providers who require their content to be available/visible in plaintext need to understand that they're in a position that makes them vulnerable, with no amount of technology available to help them. Like publishing a book, once it's in ink, anyone motivated can copy it (though copying books is more tedious, and more than 4 lines of code).

Thanks cwright. I was hoping for a situation analogous to compiled binary code that cannot be (easily) backwards converted to source code. As I have no understanding of the processes involved in that recipe, I take your word for it. Something to be said for deterrent effect on low-quality attacks though as few would be in a position to benefit and a 'padlock' may be enough in most cases.

Quote:
Content providers who require their content to be available/visible in plaintext need to understand that they're in a position that makes them vulnerable, with no amount of technology available to help them.

I appreciate that having content out there make's it 'out there' but there is a difference between being able to strip the imagery with screen captures of a shock wave file to having immediate access to the action-script that generates the animation which is available in the Flash file (and is buried in the shockwave file). Or difference between a render image and the CAD file it came from. It's not the end result I want to protect it's the work that goes into making it. Another analogy I know but that's the level of my ignorance re. XCode :)

Do you think the bundling of kineme patches inside a .qtz file so a comp could play in say Keynote on a foreign machine is possible? Presumably custom plug-ins can travel inside the file if I get what Troy is suggesting.

On the other hand, I could start worrying about this if and when it becomes an issue for me rather than in advance.

usefuldesign.au wrote:
Thanks cwright. I was hoping for a situation analogous to compiled binary code that cannot be (easily) backwards converted to source code. As I have no understanding of the processes involved in that recipe, I take your word for it. Something to be said for deterrent effect on low-quality attacks though as few would be in a position to benefit and a 'padlock' may be enough in most cases.

I guess my worry here is that it's a Hack-once, Run Everywhere exploit (it can be made into a QCPlugin of either official- or unofficial-api persuasions, trivially distributed) that requires absolutely no technical capability of the user. it's like a key gen, but even easier, as it can exploit every* possible protection system devised for QC with no additional work required. That's a rather dangerous cliff to hang from.

usefuldesign.au wrote:
I appreciate that having content out there make's it 'out there' but there is a difference between being able to strip the imagery with screen captures of a shock wave file to having immediate access to the action-script that generates the animation which is available in the Flash file (and is buried in the shockwave file). Or difference between a render image and the CAD file it came from. It's not the end result I want to protect it's the work that goes into making it. Another analogy I know but that's the level of my ignorance re. XCode :)

However, action script is available from SWFs (though it can be obfuscated, but there's no parallel in QC). By virtue of how QC works, you're distributing the source required to make a work, so you're giving out the CAD file, not the render. You cannot protect the work that goes into it with QC, because QC Simply Doesn't Work That Way.

usefuldesign.au wrote:
Do you think the bundling of kineme patches inside a .qtz file so a comp could play in say Keynote on a foreign machine is possible? Presumably custom plug-ins can travel inside the file if I get what Troy is suggesting.

No, it is not possible to bundle executable code into a composition (this would be a terrible idea).

usefuldesign.au wrote:
On the other hand, I could start worrying about this if and when it becomes an issue for me rather than in advance.

It's good to plan for/around. If you seriously want to solve this problem at all, it's going to take some very clever work to protect.

(*) -- not quite every; QuartzBuilder actually protects against the simple for of this attack, so exploiting it requires more work than the trivial 4-line case. I've seen /no/ other products on the market that can withstand the 4-line trick though.

Thanks crwight for clarifying these points for the sake of my understanding :) This stuff is truly beyond me, but it fascinates me.

One last roll of the dice if that's okay, when I try to open some of the free and demo noise industries .qtz files (Ken Burns and Yanamo's Motype) I get an XML error and rather than the editor loading the comp minus any missing patches, it gives the message and there is no file open.

Is this relevant/of benefit to me? Having the FxFactory tools installed or not doesn't seem to effect it. Just bad luck with the Ken Burns and Pan&Zoom .qtz files or is this by design?

usefuldesign.au wrote:
One last roll of the dice if that's okay, when I try to open some of the free and demo noise industries .qtz files (Ken Burns and Yanamo's Motype) I get an XML error and rather than the editor loading the comp minus any missing patches, it gives the message and there is no file open.

Is this relevant/of benefit to me? Having the FxFactory tools installed or not doesn't seem to effect it. Just bad luck with the Ken Burns and Pan&Zoom .qtz files or is this by design?

This happens because NI encrypts the compositions (but doesn't change their file extension) -- that way, you can't directly edit the compositions. By itself it's difficult to undo, but if you can get NI to load the composition ever (during the trial period, for example), the hook trick works, and you've bypassed it without breaking a sweat.

Similarly, PulpMotion has .qtza's or something (which are also encrypted), and some other apps have as encrypted compositions well.

This is of little to no use in the terms of Keynote, but on the topic of... "obsfucation" ... of files... it seems that you can make your own app (like Photobooth), and then "build" the patch into the application, so that when you open up the qtz outside of the application environment, it makes little sense. I don't "see" any plugins or patches inside of Photobooth in the typical QC sense, or lurking anywhere else... I don't see any documentation about how to do that, but then again, I haven't really looked!

If you take some of the internal qtz's from Photobooth and open them, it seems that they hinge on patches that are built into the application, but that aren't "plugins" like we think of them. Like the "mosiac" patch that is "missing".

This method only works for stand-alone apps -- I don't think plugins can do it (they can include QC plugins, of course, but other apps can then load your plugin, and gain them as well...)

(you noted this, I'm just confirming it).

This is the stuff I find fascinating (then again, I really liked Colombo and Perry Mason when I was a kid)...

Inside of iPhoto there are a ton of "plugins" that are just "folders" and then some that are compiled and have plugin icons. Some of the "plugins" look like they are actually things that describe qtz's, like the "transition" plugins. Some of the compiled plugins actually have CI kernels...

Does the way any of that works have any usefulness in the pantheon of QC cool stuff? I haven't really even gotten into putting any of the CI Kernels into the QC CI patch... I suspect some of the plugin/kernels are just duplicating QC patches, but I'm not sure.

Ditto Colombo and Perry Mason!

Interesting all the core .qtz files in the NI FxFactory app are +not+ encrypted. (Most of them aren't very earth shattering re: quatz hacks just useful productions tools.)

One final attempt to tease cwright into discourse re securing a patch:

Quote:
crwight wrote: However, action script is available from SWFs (though it can be obfuscated, but there's no parallel in QC). By virtue of how QC works, you're distributing the source required to make a work, so you're giving out the CAD file, not the render. You cannot protect the work that goes into it with QC, because QC Simply Doesn't Work That Way.

Okay, I understand a .qtz file is at the very minimum procedural (instructions) and more besides, not flat content. My render/CAD analogy was poor. As I mentioned, I was discussing possibility of changes to Quartz Composer/ OS X/ Keynote application (with Apple) to given them a better relationship. Do you think it's possible that Quartz Composer Application itself could be developed to accommodate some kind of encrypted file protection, like say Adobe has for PDFs (which I believe is still good) or even swf (which you suggested is weak)? Calls for speculation on your part, cwright, I know but who better on this forum to do so. Last post from me on this, promise!

usefuldesign.au wrote:
Interesting all the core .qtz files in the NI FxFactory app are +not+ encrypted. (Most of them aren't very earth shattering re: quatz hacks just useful productions tools.)

right -- the in-app ones aren't their selling point; their plugins (motype, et.al.) are -- those are what get encrypted. (I've actually done an FxFactory plugin, so I'm not just guessing/waving my hands -- this is how it's done.)

usefuldesign.au wrote:
One final attempt to tease cwright into discourse re securing a patch:

cwright wrote:
However, action script is available from SWFs (though it can be obfuscated, but there's no parallel in QC). By virtue of how QC works, you're distributing the source required to make a work, so you're giving out the CAD file, not the render. You cannot protect the work that goes into it with QC, because QC Simply Doesn't Work That Way.

Okay, I understand a .qtz file is at the very minimum procedural (instructions) and more besides, not flat content. My render/CAD analogy was poor. As I mentioned, I was discussing possibility of changes to Quartz Composer/ OS X/ Keynote application (with Apple) to given them a better relationship. Do you think it's possible that Quartz Composer Application itself could be developed to accommodate some kind of encrypted file protection, like say Adobe has for PDFs (which I believe is still good) or even swf (which you suggested is weak)? Calls for speculation on your part, cwright, I know but who better on this forum to do so.

Actually I found your CAD/Render analogy spot on -- turning a 2D rendered image into a CAD file is much more labor-intensive than turning a CAD file into a 2D rendered image. the former isn't perfectly possible (invisible stuff cannot be recreated), while the latter is always "perfect". QC is the same way, except that the only way it works is to use the CAD portion. Thus, there's no way to distribute just the "rendered" portion (unless you sell .movs from QuartzCrystal or QuickTime Pro or something).

PDF's encryption is "wrong" -- it's not really protection at all, it's just software-enforced limitations (if you can see the document on the screen, there's absolutely no technical reason why you cannot print it -- the PDF software simply prevents that, but that can be worked around.) If you're talking about "locked" PDFs (ones that need passwords to open), that's possible, but then you need to embed your password somewhere for the end user to extract it (thus it's extractable by an enterprising user).

QC Editor could be developed to do anything, including file encryption, but that doesn't actually protect you -- Sing It With Me: "If the user can ever view the content in plain text (which QC fundamentally requires), they can copy it."

You keep attacking the wrong problem -- it's not about passwords, or app integration, or anything like that. It's about how a composition is fundamentally represented. Currently, it's from a File (already plaintext) or from NSData, which is the decrypted content. (top secret hack: [(NSData*)theData writeToFile:@"/Users/cwright/Desktop/sploit.plist" atomically:NO];)

Even if the QC framework added an additional API that allowed you to supply a crypted composition and a password, you're still dead: that method can be hooked, and the user can dump the cipher text and the password, decrypt themselves, and it's done.

Even if they make it impossible to hook those methods (using some kind of magic that isn't possible), a plugin can traverse the composition from the inside and write out what it sees -- nodes, connections, notes -- effectively working around the protection from the inside. (KinemeCore had to do similar stuff to this for the publish-to-root extensions, for example).

usefuldesign.au wrote:
Last post from me on this, promise!

You can continue posting/discussing this, it's actually interesting and I don't mind -- but one side having read and comprehended the Red Book does make the discussion a bit one-sided ;)

cwright wrote:
You can continue posting/discussing this, it's actually interesting and I don't mind -- but one side having read and comprehended the Red Book does make the discussion a bit one-sided ;)

Okay I'm in!

Now I have a Red book to read after the Orange Book which I may read after Proust's "Remembrance of Things Past". Had a look at the Red Book TOC and it looks like pretty standard 2nd year CompSci to me (joking, my info comes from cryptography docos on the enigma, a very irritating Dan Brown novel I read waiting beside somebody in hospital (her book not mine) and the odd New Scientist article).

When I said the render/CAD analogy was poor I meant my use of it in implying a .qtz file could end up a 'flat render' when of course it never can be a reduction of it's own data and still work. (Non-redundant data that is).

I think we are still slightly at cross porpoises, but coming from different (but both valid) viewpoints. I am talking about a useful level of security built into the core of the application design like password protected PDFs and you seem to be saying, well any attempt at securing a file that has to be decoded into "plaintext" to view or use inside the end-users environment is ultimately futile.

Further it may spawn automated hacks which create the illusion of protection for the document creator when for the intrepid user (read anybody with the right tool) there is no effective barrier to the source code. From a 100% solid protection point of view I am totally convinced you are right ;) – just look at how effective DRM is. (and that's without the NSA's universal backdoor, thank-you for your contribution Dan Brown)

I would posit the PDF password protection is more than adequate for my needs if it were feasible for .qtz files. With PDFs you can have a password to allow viewing but not editing for example, so Acrobat Pro or Reader has to decode the PDF document on my machine but still stops me from saving the data in a altered state or highlight + copy/pasting to another application. So if QC refused to open a .qtzencrypted file in it's editor without the password I'd be happy despite possible work arounds at the XCode level

I have a friend who was a programmer at EA several years back and a group of them tried to break PDFs. Half the group went online for hacks the other half tried to do it 'manually' and all being low-level coders (writing machine code animation calls for the higher-level (C variant) game coders) they gave it a serious shot for a few days. They weren't able to do it at that time (I think it was several-bytes worth of encryption key) or find any useful resources online (maybe that was before tpb!). Not sure if they were testing password fully locked documents or password view but not edit PDFs, to be truthful.

I wasn't aware swfs can be easily converted to Flash files (don't write much flash). Even that level of deterrent may be okay for stopping another designer who might consider overtly borrowing hot QC code and flood the market with (crap) imitations or improved code too soon for my liking if you know what I mean, well perhaps.

What-ever NI did would prob be satisfactory for my needs if it was built into QC and Apple Applications that play QComps. If it was built into QC and Apple Software perhaps it would prompt a Patcher style automated tool of the type you described earlier though.

Ok, I'm glad we actually both agree more than I had thought -- I was thinking you were looking for something bullet-proof, but now I see that you understand the limitations. I can deal with that :) (Previously, I was under the assumption that you were hoping to have powerful protection, which I still assert isn't tractable for QC at present, or even in foreseeable incarnations)

I don't know much about swf/flash stuff, but what I do know is that the action script portion (the "software" aspect) has a large market for obfuscators.

if NI's approach was satisfactory for you, then simply rolling it yourself in a thin plugin wouldn't be a big deal -- getting that to work in keynote would be pretty tricky without the extensions you outline, but I'm not sure apple could be easily persuaded to add the appropriate extensions to both KN and QC to make it happen any time soon.

My biggest personal concern with this endeavor is how ridiculously simply it is to exploit currently -- a user need only know how to install a QC .plugin, and they can have powerful automated composition decryption. The barrier to entry there is so low that I really consider it no protection at all -- with or without encryption in place, you're still relying on users doing the right thing (which they do an overwhelming majority of the time, except perhaps in certain circumstances). So with that set up, it works out something like this:

• Leave it as-is (no work required), trust users to not steal

• design an easily defeated protection system, integrate into the QC framework, write docs so other apps can use it, integrate with iWork and elsewhere (significant amount of work), trust users to not steal (billable hours to make an exploit plugin can be counted on 1 hand for a competent objc developer).

Since I'm a programmer, I'm very lazy, and option 1 looks way more compelling ;)

Yes, yes I came to same conclusion: option 1 and I'm not a programmer (did I mention redundant data) and prob as lazy as you are (I think more so given the stellar work of Kineme!).

I guess I was really looking for speculation and arguments supporting the case for Apple to do it which I could to feed to Troy et al and let him work on the Keynote dev team. (Hence my PDF example).

I'm not worried at all about single users stealing code. I'm just concerned if a really big effort of mine into a product like a Keynote Theme got 'gazumped' by a Bigger Player and I lost my investment in the value of the code (for me that would be weeks fo work). I guess I need to be more positive about what I have brought to it – I think as Americans you are more inclined to be positive in business philosophy than Australians. I've heard we have really dog eat dog mentality too often. (With not enough Dog to go 'round lol)

I for one think proper Keynote integration of Quartz would be great. There's another thread just going now with some Kineme regulars speculating why QC isn't more mainstream. Proper integration into KN would give it a small push I know for sure, I'm always promoting QC on the Keynote Discussions, if it could do more inside KN all the better (needs bindings to mouse/keyboard for starters followed closely by custom patches and iTunes style published inputs for KN data)

cwright wrote:
My biggest personal concern with this endeavor is how ridiculously simply it is to exploit currently -- a user need only know how to install a QC .plugin, and they can have powerful automated composition decryption.

Does such a plug-in currently exist? Not asking for it just wondering (I've read yanamo's thanks to you guys)!

usefuldesign.au wrote:
Does such a plug-in currently exist? Not asking for it just wondering (I've read yanamo's thanks to you guys)!

errr... not publicly? ;) [that's the kind of code that never leaves my machine -- even the kineme source repository doesn't have that black magic]

THX Chris ;)

Hey I actually meant others (bad-asse hacker types) putting this [potential] plug-in around not cwright (seeing as he built some of the FxFactory dope)!

What about just building a patch that duplicates functionality of several stock Apple patches, and making the patch need serial authorization? That way, the composition is meaningless if it's opened without buying the patch (ala Kineme3D... except way more boring, and just duplicating already builtin function)?

Then you could just build your compositions around that patch.

I don't really LIKE this idea, but it's one of those things... gotta spit it out there :)

Brilliant, gtoledo3 – I was actually wondering when you were going to illuminate this discussion from left field. (That's a complement to you and in no way a slight to cwright btw). I'm not crazy about all this "only the apranoid survive" attitude either FWIW. Interesting though...

I thought about adding a 'required' custom-patch for client situations but then thought, as soon as the patch gets publicly distributed as in the case of Keynote Themes for public download, then the games up. Didn't think of the serialisation angle ;)

Guess it's not fair to ask cwright to pick holes in his own serialisation schema but it would make for compulsive reading?!

Also I indicated in earlier post Keynote needs to add support for 3rd party quartz patches - this was a slip on my part. I do use Kineme GL Tools (specifically GL Line) inside .qtz files embedded inside Keynote files and they're fine so presumably Kineme3D would work.

Correction: Spelt "Yanamano", RRR'spct, sir.

Thinking about that further, the simplest approach along those lines would be to have the theoretical plugin implement a macro that you place your consumer patches in, so that if you open up the qtz without the plugin, it breaks the connections.

It doesn't sound like that method would withstand anything that Chris is talking about, backwards hack wise. It would be really obvious what you were doing, and it seems like the connections and port states would still be observable... and it is obvious that it is just a macro you are implementing. It would make it a bit of a pain though, for the average person opening up the qtz without the plugin. All connections would be broken, or any that went through the macro.

This isn't brilliant... the opposite! It is a logical thought progression from a thing last night where I thought that I had some kind of hidden Apple macros that were actually from a plugin I have installed.

Yeah, I've been going for too long without sleep. In a serial number scenario, you need to ship the S/N to use the composition thereby giving anybody with it full access to the entire .qtz comp in QC to view and copy the design (which is all I care to sort-of protect as opposed to maximising commercial distribution which is not the aim), or am I double tired and totally missing the point?

I guess some kind of plugin that auto-generates a significant amount of otherwise 'missing code' when the composition gets loaded could be something, is that what you are describing? I'm not familiar with XCode processes/plug-ins interacting with QC compositions and actively generating patches and publishing nodes inside a composition.

I think I prefer to hope Apple will come up with something al la PDF security and until then I can just get along with it ... the serial number thing got me hoping I could encourage (by way of gold coin) Kineme to adapt the Kineme3D serialisation code into a new product to do this at some time but now I'm thinking there's false logic involved. (Was interesting reading the Afterword in the Red Book about the Ten Rules of why Encryption fails btw)

Besides cwright may have said it's do-able and worthwhile if he saw a way of adapting his existing techniques from K3D and qtzBuilder.

Thanks to you both for giving this so much attention I appreciate it greatly, esp Chris's marathon like tolerance for amateurs like me.

usefuldesign.au wrote:
Yeah, I've been going for too long without sleep. In a serial number scenario, you need to ship the S/N to use the composition thereby giving anybody with it full access to the entire .qtz comp in QC to view and copy the design (which is all I care to sort-of protect as opposed to maximising commercial distribution which is not the aim), or am I double tired and totally missing the point?

I guess some kind of plugin that auto-generates a significant amount of otherwise 'missing code' when the composition gets loaded could be something, is that what you are describing? I'm not familiar with XCode processes/plug-ins interacting with QC compositions and actively generating patches and publishing nodes inside a composition.

I think I prefer to hope Apple will come up with something al la PDF security and until then I can just get along with it ... the serial number thing got me hoping I could encourage (by way of gold coin) Kineme to adapt the Kineme3D serialisation code into a new product to do this at some time but now I'm thinking there's false logic involved. (Was interesting reading the Afterword in the Red Book about the Ten Rules of why Encryption fails btw)

Besides cwright may have said it's do-able and worthwhile if he saw a way of adapting his existing techniques from K3D and qtzBuilder.

Thanks to you both for giving this so much attention I appreciate it greatly, esp Chris's marathon like tolerance for amateurs like me.

We should all get together to give Chris some kind of trophy!

When I do Audio Engineering work, I don't care ANY about giving someone the entire session file with all of the automation info, edits, etc. I just make sure I'm getting paid for it. They might find that a compressor setting works with a similar drum setup in the future. I try not to lose sleep. (though, I am with you, no one likes to be ripped off).

It is a bit different with visual programming stuff though, because it tends be easier to apply to multiple settings.

Hopefully something like Quartz Builder would end up providing as much protection as anyone would typically need...

I agree with the comment that maybe Apple should consider some encryption stuff, but if you stop and think about it, they can't/don't even do that with their own code.

As far as PDF security stuff goes, in my own experience, it takes about 3 clicks to get through!

gtoledo3 wrote:

We should all get together to give Chris some kind of trophy!

True

gtoledo3 wrote:

Hopefully something like Quartz Builder would end up providing as much protection as anyone would typically need...

For stand alone uses, yep. Guess one of us is going to have to make a .qtz keynote application and put it inside the Quartz Builder!

gtoledo3 wrote:
I agree with the comment that maybe Apple should consider some encryption stuff, but if you stop and think about it, they can't/don't even do that with their own code.

I think Open Sourcing the OS and (some Apps?) was a conscious decision to encourage Mac Development, right? Overlap between my potential market and Apples = pretty miniscule!

gtoledo3 wrote:
As far as PDF security stuff goes, in my own experience, it takes about 3 clicks to get through!

Really?! What environment Xcode or a GUI tool? I know Adobe warn that other applications may not observe the same security rules as Reader and Acrobat I took that as a legal disclaimer not a shown fact.

Next you're going to say you picked OS Xs File Vault while you were reading this post 'cause you had nothing better to do. Speaking of which I'm having major bugs with Vhistorian and KAudio File Input... time for a new thread.

Hi usefuldesign, Don't be hurt and don't take my thanks to Chris as an offence against you. I have spend to many nights developing in QC to not understand that you need to secure your work. I'am just sometime thankful to Chris, Steve and other brillants coders to understand what part of their hacking science they can spread in public forums ;)

Cool, THX

I just want to add that I'm trying to do something like this - something keep average users from modifying my composition (like removing watermarks, etc).

I'm not looking to build Fort Knox - just to avoid polite thievery...

Great thread well overdue, we all muck around for fun... its been a fun toy more than anything, but I sense its starting to get a bit more serious for us all. Imo QC is not really going to produce expensive software ever, so in this context, the psychological merits of hacking a $5-10 app are not huge, but inevitable regardless. I second integration into something like Quartz Builder. Just enough to keep "the kids" at bay. On that note.. cwright get the kineme 3d licenses happening! Everyones work salable, retailing with a little Kineme fee... be a nice little earner for you!

theepilepsy wrote:
I second integration into something like Quartz Builder. Just enough to keep "the kids" at bay.

Please read https://kineme.net/product/QuartzBuilder -- you'll find the following:

QuartzBuilder Product Info wrote:
Your compositions are encrypted, and Official API plugins, Unofficial API plugins, and simple resources are automatically bundled with the generated application.

emphasis mine

QuartzBuilder, right now, today, will encrypt your compositions. It also employs some basic counter-malicious-plugin dumping measures. Far from fort knox, but more proactive than anything else I've seen that uses QC.

theepilepsy wrote:
On that note.. cwright get the kineme 3d licenses happening! Everyones work salable, retailing with a little Kineme fee... be a nice little earner for you!

Working on it :) (SL's announcement stuff has shifted around priorities yet again...)

hi finding this thread on a search for 'Quartz Composer protection', I read it through, and CWright seemed to explain (as far as I could understand him with my limited expertise) that it wasnt possible to 'protect' qtz compositions. Then, at the end the link to Quartz Builder was given with the note that it does provide encryption and some other protection. Will gladly buy it, but would be grateful if CWright could briefly explain the protection abilities of QB more in relation to the earlier posts?

I have an elaborate video synth built in QC and want to issue free patches as standalones which yet wont allow users to fully edit them/copy the whole synth...

Thanks x Matt Black

You can use Quartz Builder to make a native OS X application that has keeps your composition(s) stored, not as a plain-text .qtz file, but as encrypted data. As to the strength of the encryption and the methodology employed, I'l leave it for the creators of Quartz Builder to explain.

Side note: @cwright is probably no longer directly involved in Quartz Builders development since he started working in Apple's QC dev team.

Pretty sure someone from Kineme will answer your questions more fully soon. If not email them info {at} kineme {dot} com

Unfortunately the demo is very restricted on the QC patch count — so will not be much use for your elaborate Video synth but you can at least get a feel for what it does. QB installs a composition Template file which appears for selection when you are creating a new file (well in Leopard it does not sure about 10.6+). You can use this to control some aspects of your OS X application, like audio, cursor and background (which might otherwise appear transparent).

Thank you. I purchased QB and it worked on my QC synth! so its a help. I will ask Kineme for more info. best Matt

Cool. QB is one of my favourite Kineme technologies now I've finally started playing with it.