Discussion Over Apple's Modification Of Sun's DTrace

[milo]

Not iTunes, but the Quicktime framework that Apple hosed with the 7.4 update.

So how does this dtrace issue cause a problem? Apps can access the QT framework while iTunes isn't running, right?

As industry tightens its grip more and pushes content with advanced encryption that can be only played on "trusted" devices - this includes a plan to make computers trusted (by the overlords) - you will no longer see 1080i rips coming - it will be impossible to do that

They said that about DVD. They said that about the hidef DVD formats. "Unbreakable" has been claimed many many MANY times. And so far, that claim has always been wrong.

Forgive me for being skeptical, but I'll believe it when the hidef rips disappear. I'm not holding my breath.

 

[parapup]

DRM is different in that you as the consumer of the content are given the key with the content or else you can't view it. Because you have both the key and the content it's trivial to decode it if you know the decoding method. So the only defense DRM has is obfuscation. That’s why horrible things like DMCA exist, which try to limit your right to understand the thing you own.

DRM is way way way weaker than encryption for this reason.

The previously cited examples of TCM and hardware DRM obfuscation schemes are extensions of a faulty premise that DRM can be secured.

Have you read this yet? How do you get to the key if the Software and "Trusted Hardware" device handle the key exchange securely?

Vista already has much of what is needed to do this sort of extremely hard to break in reality DRM. Yes it is a cat and mouse game but both cat and mouse have equal chance at bettering each other.

Note that I am not saying fool proof means exist yet to enforce DRM in a meaningful way - but situation will not remain the same. If people have brains to break encryption other people will have the brains to build and deploy something that cannot be broken, even if it means making the lives of consumers painful.

 

[stokessd]

So how does this dtrace issue cause a problem? Apps can access the QT framework while iTunes isn't running, right?

Yes and no. The new Quicktime checks the file you are working on every 10 minutes and if it thinks there is a problem, locks the permissions on it so the application using it can't write to it anymore. This is currently breaking After Effects renders that take longer than 10 minutes. Apparently after effects writes a lot of metadata after the render (which makes sense) and after 10 minutes the mid-render file appears like a corrupt/hacked movie file and the quicktime framework (or whatever is monitoring these things) locks the file down. So sure, you can access it, but not like you could last week, and make sure you don't do anything hinky with the quicktime file you are writing.

This is all in the links above...

Sheldon

 

[diamond.g]

Have you read this yet? How do you get to the key if the Software and "Trusted Hardware" device handle the key exchange securely?

Vista already has much of what is needed to do this sort of extremely hard to break in reality DRM. Yes it is a cat and mouse game but both cat and mouse have equal chance at bettering each other.

Note that I am not saying fool proof means exist yet to enforce DRM in a meaningful way - but situation will not remain the same. If people have brains to break encryption other people will have the brains to build and deploy something that cannot be broken, even if it means making the lives of consumers painful.

AFAIK, HDCP is susceptible to spoofing+man-in-the-middle attacks. It requires hardware to do it, but it can be done. There are also HDCP strippers.

Encryption (which is a form of DRM), is really designed to stop casual piracy. The pro's are able to get around it in relatively short order.

 

[eastcoastsurfer]

Have you read this yet? How do you get to the key if the Software and "Trusted Hardware" device handle the key exchange securely?

Vista already has much of what is needed to do this sort of extremely hard to break in reality DRM. Yes it is a cat and mouse game but both cat and mouse have equal chance at bettering each other.

Note that I am not saying fool proof means exist yet to enforce DRM in a meaningful way - but situation will not remain the same. If people have brains to break encryption other people will have the brains to build and deploy something that cannot be broken, even if it means making the lives of consumers painful.

You should read what you link to. In his conclusion he states that content protection was easily broken within a week in Vista. He also goes on to show that as long as software players exist, DRM will continue to be broken. I would add that as long as the consumer must have the device to decrypt the content, it will be possible to break the encryption scheme. The key and or algorithm has to be somewhere on my possession or I wouldn't be able to access the content.

 

[milo]

Yes and no. The new Quicktime checks the file you are working on every 10 minutes and if it thinks there is a problem, locks the permissions on it so the application using it can't write to it anymore. This is currently breaking After Effects renders that take longer than 10 minutes. Apparently after effects writes a lot of metadata after the render (which makes sense) and after 10 minutes the mid-render file appears like a corrupt/hacked movie file and the quicktime framework (or whatever is monitoring these things) locks the file down. So sure, you can access it, but not like you could last week, and make sure you don't do anything hinky with the quicktime file you are writing.

This is all in the links above...

Sheldon

None of that even mentions iTunes. So this issue happens when iTunes is not running, correct? Meaning that you could run dtrace in this situation and it would work fine, correct?

Sure, it's a bummer that quicktime has this bug. But how would the ability to run dtrace while iTunes is running help at all?

 

[ChrisA]

And why does a developer really need to use the debugging tool on itunes? Or while iTunes is running?

Quit iTunes. Debug your program.

The most subtle kinds of bugs are those that are a result of indirect interaction with other parts of the system. It would be nice to know that your product can work with iTunes. Say I was writing software to capture video and I need real time performance. Do I really want to tell my users to quit iTunes if they want to use my software. No.

It seems that anyone seriously using Dtrace will be using a version of Dtrace with Apple's hack removed. So this whole issue may be moot.

 

[mooncaine]

Actions speak louder than words

"...the issue may eventually become moot with Apple's stated desire to move towards DRM-free music."

They can state it all they want, but their actions belie their words, as demonstrated by the revelation that QuickTime 7.4 scans *your* Quicktime files [not merely *their files*, or someone else's files, but even files *you* are creating] every 10 minutes to decide if you have the right to own them -- and if it thinks you don't, it takes away your user permissions on those files.

This breaks some important rendering functions for Adobe After Effects and Premiere users, who can't batch render anything that takes longer than 10 minutes to render, because Apple checks their in-progress Quicktime movie, decides it fails the DRM check, and changes permissions on it, right in the middle of rendering.

It should be illegal, I say. This smacks of Sony's root kit escapade.

 

[Rocketman]

I think you all missed the point. They added Dtrace, yes, long needed. Fine. They did a minor tweak to it to temporarily support DRM for a while longer. Fine. It probably was also one of the check boxes the government required in "these perilous times©".

I just like that they did it with a sense of (Easter egg) humor:

"Move along, nothing to see here."

Rocketman

 

[Westside guy]

Not picking on you particularly but even this has been proven wrong.
It seems that Apple announced this at MacWorld in the developers forums.

Well that would change my take on it a bit - but do you have some direct evidence of this (e.g. a first-hand account)? I didn't see anything about it in the Sun developer's blog.

My main problem with this sort of thing, which is probably already evident from my other post, is when it's done in secret. An analog (trying to carry this over to my world) would be if, say, the Apache developers decided they needed to disable perl's "system" call inside of mod_perl. If they told people about it, then it's fine. If they just do it on the sly, it ends up unnecessarily wasting a bunch of my time trying to figure out why one or two of my systems have suddenly broken slightly.

 

[hayesk]

Wow, this is just ridiculous. Why shouldn't Apple be able to prevent their app from being traced? Seriously - it's their code. And this doesn't affect anyone - really.

 

[hayesk]

...the point Apple was trying to make here. Preventing iTunes from being traced when there exist things like QTFairUse which rid the DRM in Apple sold music and continue to support latest iTunes versions.

QTFairUse doesn't strip the DRM - it just recompresses for you - equivalent to burning and ripping a CD.

There is no real DRM stripping for the latest iTunes. Feel free to prove me wrong.

 

[hayesk]

that's why I don't use iTunes.
Sad.

Really? You don't use iTunes because you can't DTrace it? Wow, I wish that was my biggest problem in life.

 

[mdriftmeyer]

Apparently there aren't many low level developers surfing Mac Rumors.

Shooting your mouth off on issues with kernel level system tracing requires the background to know what the hell it is.

Landon Fuller who worked in the Kernel Group prior to leaving Apple has released a workaround

http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html

NONE OF THIS MATTERS TO ANYONE WORKING OUTSIDE THE KERNEL.

Turning your iTunes off while doing system-wide debugging only matters when working on Kernel Extensions.

This scare about not being able to dtrace your application is false. You can dtrace your application code sandbox while running iTunes.

The original complaining Blog:
http://blogs.sun.com/ahl/entry/mac_os_x_and_the

This is about being able to trace system-wide whenever you want.

He got pissed that dtrace was being denied low-level access probing to iTunes.

Guess what? Apple doesn't want their iTunes code reverse-engineered. Go figure.

Turn off iTunes and dtrace system-wide.

Turn iTunes on and dtrace application wide.

Turn iTunes on and attempt to dtrace system-wide and watch dtrace puke when it attempts to dynamically trace the calls within iTunes.

Visualizers inside iTunes are using the Cocoa QTKit, CoreAnimation and the Quartz Composer. They are high level abstraction frameworks that don't depend on using dtrace at the kernel level to debug where memory allocation resides. If you're going to be debugging Quartz directly then I suspect you're working at Apple.

This argument that you can't develop Visualizers is bunk.

 

[parapup]

You should read what you link to. In his conclusion he states that content protection was easily broken within a week in Vista. He also goes on to show that as long as software players exist, DRM will continue to be broken. I would add that as long as the consumer must have the device to decrypt the content, it will be possible to break the encryption scheme. The key and or algorithm has to be somewhere on my possession or I wouldn't be able to access the content.

Well well well - hold on. I did not say unbreakable DRM exists and is deployed today. I was saying it is possible to devise schemes which even though harder to deploy commercially can and will provide DRM which is very highly improbale to break.

Take the case of Xbox 360 - can you do anything you want with the Xbox 360 games apart from playing it on one Microsoft/Game maker dictated piece of hardware? Can you load your own OS on to it? Has anyone succeeded so far? There you have it - successful hardware and software assisted DRM which has proven to be a large deterrent to breaking.

Don't be naive to think only people with intent of breaking the DRM have larger brains.

 

[pohl]

one time pad

Sounds like it involves quantum physics. I'm interested in knowing more.

There is no quantum physics involved. Just math. The technique is known as One Time Pad.

 

[savar]

For those interested, from Adam's blog... the code that was added.

#if defined(__APPLE__)
        /*
         * If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
         * then this enabling is not permitted to observe it. Move along, nothing to see here.
         */
        if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
            continue;
        }
#endif /* __APPLE__ */

I debugged itunes in the past when I was trying to figure out the QTKit for Cocoa.

It was pretty easy to workaround the "don't debug me" flag -- just stubbed out the call in GDB. I imagine that this is an easy workaround as well.

 

[TitoC]

Not picking on you particularly but even this has been proven wrong.
It seems that Apple announced this at MacWorld in the developers forums.

Personally, I think that everyone should really check their emotions and their hyperbole at the door on this one, starting with the original "discoverer" of the feature. One can only make a "tempest in a teapot" by stirring things up rather furiously no?

I find even the original "Wow" statement kind of disengenous in that all of this is rather obvious. The basic idea of disabling dtrace on DRM apps is hardly surprising, (certainly not worthy of the "Wow"). The fact that they wouldn't announce it loudly to the world at large is also kind of obvious isn't it? Doesn't anyone work for a private company on this forum or understand what kind of things should be announced in prime time and what should not?

They did announce it on the sly to the developers (it seems) so as to not let them get caught up in a bad dtrace output and anyone who knows how to use dtrace would have discovered it fairly quickly. There are many other debug options available.

I find it amazing that Apple offers dtrace in OS-X at all. It's really kind of cool and amazing. I find it also kind of two-faced that all the developers were cheering at the fact just a short while ago. Then this is discovered and Apple passes (yet again) from "hero" to "evildoer" in the space of an afternoon. 😕

Isn't it ironic that a group of developers who are supposed to be so logical and analytical, get all riled up like a bunch of kids and start spitting bile over something as completely predictable as this is. I think that some people on this forum should seriously calm down, take a breath and think about whether this is really the end of the world they seem to think it is.

Apparently there aren't many low level developers surfing Mac Rumors.

Shooting your mouth off on issues with kernel level system tracing requires the background to know what the hell it is.

Landon Fuller who worked in the Kernel Group prior to leaving Apple has released a workaround

http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html

NONE OF THIS MATTERS TO ANYONE WORKING OUTSIDE THE KERNEL.

Turning your iTunes off while doing system-wide debugging only matters when working on Kernel Extensions.

This scare about not being able to dtrace your application is false. You can dtrace your application code sandbox while running iTunes.

The original complaining Blog:
http://blogs.sun.com/ahl/entry/mac_os_x_and_the

This is about being able to trace system-wide whenever you want.

He got pissed that dtrace was being denied low-level access probing to iTunes.

Guess what? Apple doesn't want their iTunes code reverse-engineered. Go figure.

Turn off iTunes and dtrace system-wide.

Turn iTunes on and dtrace application wide.

Turn iTunes on and attempt to dtrace system-wide and watch dtrace puke when it attempts to dynamically trace the calls within iTunes.

Visualizers inside iTunes are using the Cocoa QTKit, CoreAnimation and the Quartz Composer. They are high level abstraction frameworks that don't depend on using dtrace at the kernel level to debug where memory allocation resides. If you're going to be debugging Quartz directly then I suspect you're working at Apple.

This argument that you can't develop Visualizers is bunk.

I think both of you (Virgil-TB2 & mdriftmeyer) are dead-on. It's not like this method of obscuring DTrace is system wide. It is only implemented into iTunes for obvious reasons. And, on top of that, it can be circumvented if needed to.

People need to stop crying "Conspiracy" and move on.

 

[milo]

Take the case of Xbox 360 - can you do anything you want with the Xbox 360 games apart from playing it on one Microsoft/Game maker dictated piece of hardware? Can you load your own OS on to it? Has anyone succeeded so far? There you have it - successful hardware and software assisted DRM which has proven to be a large deterrent to breaking.

Did you even do a quick google search before posting this? 360 HAS been hacked, there are mod chips and people playing burned copies of games.

I doubt people have loaded other OS's on it, but that's because the CPU is different from mac OR pc. There probably aren't any general purpose OS's that are compatible - it's not a DRM issue. That's like saying intel code can't run on G5, so there must be really good DRM stopping it.

 

[eastcoastsurfer]

Well well well - hold on. I did not say unbreakable DRM exists and is deployed today. I was saying it is possible to devise schemes which even though harder to deploy commercially can and will provide DRM which is very highly improbale to break.

Take the case of Xbox 360 - can you do anything you want with the Xbox 360 games apart from playing it on one Microsoft/Game maker dictated piece of hardware? Can you load your own OS on to it? Has anyone succeeded so far? There you have it - successful hardware and software assisted DRM which has proven to be a large deterrent to breaking.

Don't be naive to think only people with intent of breaking the DRM have larger brains.

I'm fairly certain you can rip xbox360 games. I'm also pretty sure you can put a mod chip in the 360 to play games that you downloaded and burned yourself. Of course MS can detect the chip and prevent you from playing on xbox live, but you have still circumvented their protections. And no xbox360 emulator exists part b/c of the security and part b/c most machines out now wouldn't be powerful enough to run it.

I don't think people trying to break it have larger brains, just generally more brains on the problem. Also, I think breaking something is easier then creating it in the first place. When my only goal is to get by I have a lot more leeway in how I approach the problem than when I have lots of goals like security, cost, accessibility, technical feasibility, time to market, etc...

 

[savar]

Think HDCP, think DRM enabled OS, DRM enabled Graphics, think TPM - you already cannot do anything with the result apart from what the owners of the content want you to do.

It's like Adam gave Eve a blackbox and scrambled piece of paper - all Eve can do is insert the scrambled piece into the blackbox and the blackbox can display what is written on the paper. If all you have is blackboxes that do not accept anything but particularly scramble piece of paper copying the displayed data and feeding it to another blackbox for viewing someplace else just became unrealistic.

That's true to the extent that the blackbox is truly black.

If somebody can build, for example, a DVD player that has all of the decryption hardware but doesn't enforce any of the content control policies, then it goes back to being a game of "hide the key/find the key".

The extent to which that is possible relies on legal intervention. It's much easier to control producers of hardware than it is to control individual consumers; so if the content lobbies can get laws passed to regulate hardware makers, then they will be able to enforce ludricous content policies.

 

[parapup]

I doubt people have loaded other OS's on it, but that's because the CPU is different from mac OR pc. There probably aren't any general purpose OS's that are compatible - it's not a DRM issue. That's like saying intel code can't run on G5, so there must be really good DRM stopping it.

That is lack of knowledge on your part - The XBox 360 has a PowerPC CPU - ton of OSes including Linux can run on that CPU. See this - and don't come back saying they do run custom code - it is limited to some buggy Xbox 360 version - Microsoft has already fixed it and you can't do nothing with the newer versions.

 

[EagerDragon]

System-level troubleshooting or profiling needs to be done across *all* processes, or you don't have a complete and accurate picture. Imagine a doctor trying to diagnose a patient with a chronic cough, but they are not allowed to listen to the lungs with a stethoscope...

I have to agree partially with you, in the event that the system you are checking performance on will be running iTunes often. However many servers have no need for it or have it installed.

I say partially because I find it hard to believe you really need to know what places in iTunes are using the most CPU or are doing the most I/O. I can see that if you were trying to make improvements to iTunes if you had the code for it, which I assume you don't.

Any user having performance problems on their work station would be smart enough to start terminating all applications they really don't need to get their job done, and iTunes is not a required item for most people no mater how much we like to listen to music while we work.

You also going to trace into windows and the virtualization server?
How do you know what a user will be running on their workstation?

I am missing something, most developers trying to improve the performance of their application, will trace their application after it is working well and is fully debugged, they don't normally trace into other peoples software in order to tune their own software.

Maybe you have different needs than most of the developers I know or me for that matter and I been developing for over 30 years.

 

[parapup]

I'm fairly certain you can rip xbox360 games. I'm also pretty sure you can put a mod chip in the 360 to play games that you downloaded and burned yourself. Of course MS can detect the chip and prevent you from playing on xbox live, but you have still circumvented their protections.

Of course it is a cat and mouse game - it is easy for the DRM overlords to deploy harder and harder mechanisms to prevent it from being broken and it is exponentially harder for any party interested in breaking it. There is no end in sight.

Leave Xbox 360 - Buggy initial iPhone versions apart but show me one person selling the latest iPhone which is hacked to run on T-Mobile. I am willing to buy some.

This is not to say people will not find a way to get to it but a long time has passed and there is nothing workable as of now. Nothing is successful in perpetuality - I think DRM is already becoming successful in what it is trying to do if you are willing to bring the "reasonable time" dimension in the discussion.

 

[quigleybc]

**Beavis and Butthead voice**



"uhhhhhh,......what?"