Explaining the Quartz Composer / QuickTime for Java security hole
by Chris Adamson
6 Comments
| Jonathan Wight 2006-12-20 21:04:14 |
Nice write-up and calm explanation of the issues. The exact apis used in the Red Hound sample are different (looks like it uses the QD layer in QT for Java) but the result is the same. |
| Red Hound 2006-12-21 01:46:49 |
The demo applet I did does in fact use the qd layer. (How'd you figure that?) The main reason for that is that I don't really write GUIs in java and don't know those interfaces well. I found the QuickTime api to retrieve the pixels before I found the JComponent API. Had I found the JComponent API first, my code would have been shorter and PPC users would not have gotten a blue tint.
|
| Chris Adamson 2006-12-21 03:02:31 |
Actually, I used the Swing approach (JComponent) largely because I thought there'd be more people who could follow the Swing stuff than could read equivalent QuickDraw stuff. But obviously we're all on the same track, and it's one of those things where once someone else shows you that it can be done (like Red Hound's applet did), it's a lot easier to stay on track and see things through. In QuickDraw, maybe one could use EndianOrder.isNativeBigEndian() to figure out if the user's pixels are ARGB or BGRA. |
| Jonathan Wight 2006-12-21 07:10:42 |
Red Hound: I used a Java Decompiler (http://www.kpdus.com/jad.html). It did a relatively good recreating useable source.
|
| Red Hound 2006-12-21 17:04:55 |
@Jonathan: Wow. The output of jad is strikingly close to the original source, at least for my own code. The base64 stuff is public domain anyway :-). I thought I was being nice by waiting until the software update cycle had time to run its course before posting source, but there was no need to bother.
|
| Chris Adamson 2007-10-20 18:58:50 |
I'm closing comments on this blog due to massive link-spam. Sorry. |
