Discussion Over Apple's Modification Of Sun's DTrace

[parapup]

DRM is just another form of encryption, except there is no Brenda. Eve is the intended recipient and has the key, but is only expected to do some things with the result. And that's how DRM can always be broken: the key to decrypt is always there — if it weren't you couldn't do anything with the content at all — it's just "hidden." Hidden things can always be found.

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.

 

[thogs_cave]

Ask your self, why do you want to perform traces inside iTunes ? You have no business playing around in it. I can not think of a single legitimate reason you would need to do this.

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...

 

[eastcoastsurfer]

So quit itunes when you're debugging. How many apps really have compatibility issues with iTunes anyway?

Since iTunes and QT are closely related I would say quite a few, a la the recent Adobe problem

 

[guifa]

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

In the context of DRM, I'm not sure there's any useful way to use the encryption he mentioned. Basically, think of it like a Caeser cypher:

YOUCANTREADTHIS
333333333333333 <-- shift value
BRXFDQWUHDGWKLV

Instead of using using a consistent shift value, you use a random shift string

NORTHIS
1834293 <- random values
OWUXJRV

The problem, of course, is that you have to send a decrypt string just as long as the encrypted string. Since it's random, compression won't help. Since the string necessarily must be unique for each file for perfect encryption, it couldn't be stored within iTunes, it'd have to be fetched from the server. Of course, that could then be "easily" sniffed, but iTunes would have to store it somewhere unless you plan on watching the movie only once, at which point if you can only watch it once why not just have iTunes stream it? But if it's going to play it more than once, either you'd have to download the decrypt string (which would be the size of the entire movie) each time you watch it, or iTunes would store it on your computer somewhere (doubling the effective file size of the movie) and of course making it "easy" for someone to decrypt the file (I put it in quotations because the decrypt string could be crypted itself, but then it's just a question of breaking that encryption which wouldn't be perfect encryption)

 

[Domofloge]

As a mac user for the past year and a half, all I have to say is...


....Wha?

I'm just as lost as you bro. haha.

 

[eastcoastsurfer]

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.

But since you own the computer you can take apart that blackbox. DRM as it is already stops the only people it can stop - the ones who are mostly honest and just need 'gentle' reminders to stay that way. Those that really want to will always be able to crack the scheme as long as they have a device that can read the file.

 

[thogs_cave]

So quit itunes when you're debugging. How many apps really have compatibility issues with iTunes anyway?

It's not just for computability issues, tho I can imagine iTunes causing those. It's also an obstruction to the ability to analyze the system as a whole which is critical to the process.

I do this for a living, and have for many years. What bugs me is that Apple is crippling the legitimate users of a tool to protect "business interests" against the possibility of it being used against them. Never mind that the clever people who want to break DRM have other tools at their disposal.

 

[Westside guy]

So quit itunes when you're debugging. How many apps really have compatibility issues with iTunes anyway?

Well, there's a fundamental problem with your logic here. It's certainly what developers are doing NOW THAT SOMEONE HAS DISCOVERED WHAT APPLE DID - but Apple didn't bother to tell developers about it.

For most of us this is a tempest in a teapot. But it seems to me Apple, as much as they've done for the open source world, still is feeling their way around. Fortunately since dtrace is open source, people are free to "fix" it and roll their own binary - again, now that they know what Apple did.

 

[Babasyzygy]

Properly implemented DRM, like Encryption, cannot be broken.

That's exactly and completely wrong. In fact, it is impossible to make unbreakable DRM in software.

The reason for this is that the end user is intended to see the content, so the key (and ultimately the cleartext data) must be available to the user.

 

[longofest]

They may be moving towards DRM-free music, but DRM-free movies are nowhere near the horizons yet.

true

 

[ryanw]

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__ */

The confusing part for me is, can't d-trace be recompiled by anyone to NOT have problem?

 

[stokessd]

That's exactly and completely wrong. In fact, it is impossible to make unbreakable DRM in software.

The reason for this is that the end user is intended to see the content, so the key (and ultimately the cleartext data) must be available to the user.

Bingo!!! Read this carefully. Encryption is strong because even though the algorithm is known (think PGP), the keys are not. Sure you know exactly how the key will act on the data to decrypt it, and until you have the key you are stymied.

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. It’s at best a cat and mouse game, and one I find enjoyable to play (as do others). That stacks the deck against the DRM makers. There’s a little room of smart people making the obfuscation, and an entire world of smart people breaking it. The reality of the internet mean that once cracked, it’s available to all, so we each don’t have to crack it. It’s a perfect distributed computing type of analogy.


The reason you should care about this:

Apple is slowly without anyone’s knowledge poisoning the well. They are fundamentally changing the core frameworks that people rely on, and doing it in an undocumented way. They are breaking tools that people rely on. They are also breaking frameworks that their bread and butter applications require (see Adobe After Effects and QT 7.4 fiasco).

Apple has, with malice and forethought, severely weakened a very good debugging tool. And they did this to a tool that the creators gave to the community in good faith.

And lastly, it hints at where the company is going and what it thinks of it’s users. Sure, they had to do it to chase movie rentals, but the question is: “Are movie rentals worth it?” Apparently they think so, but I’m not sure I do.

Finally you should care because Apple spent time and resources on this instead of ironing out the mountain of Leopard bugs that we all suffer with.

Sheldon

 

[gnasher729]

The confusing part for me is, can't d-trace be recompiled by anyone to NOT have problem?

Apparently (from reports on Slashdot) that is not quite easy, because finding all the sources needed seems difficult. It would of course be easy for Apple.

However, if you look at this code, the compiler will translate this to something that checks a bit somewhere, and then there is a conditional jump (if ... continue) if that bit is set. It wouldn't be very difficult to find exactly that conditional jump in the compiled code, and modify just that instruction. No compiler needed.

Moreover, some people have noticed that any malware could hide itself from DTrace using the same mechanism, but when you modify DTrace this way you could easily create a version that _only_ traces applications that try to hide and nothing else (these applications wouldn't be exactly hidden, it's more like having a sign "don't look at me").

But the point is that Apple advertises DTrace as a valuable tool for developers (in places that developers care about), but ships it in a way that is broken.

 

[stokessd]

The confusing part for me is, can't d-trace be recompiled by anyone to NOT have problem?

Not confusing, that's exactly the solution if you care about dtrace. That's the power of open source and the GNU license. If apple had developed dtrace themselves chances are there wouldn’t be any source available for people to look at. Because the GNU license requires that apple provide source, they did, and the problem is a non-problem in terms of getting proper dtrace functionality.


Sheldon

 

[EagerDragon]

Everyone here has missed the point. Likely because they do not understand what Dtrace is or how it works.

The problem is not that we can't trace inside iTunes. Who really cares about that except for developers working at Apple on iTunes development? The problem is that if iTunes is running you cannot trace ANYTHING. Data collection is disabled SYSTEM WIDE.

Read the code excerpt that was posted to this thread.

So you can't collect performance data on a Mac this is runing iTunes. That's bad. It means you can't tune a system for best performance, you can't make your product play nicely with iTunes

Should end users care? No 99.999% do not even know what Dtrace does and would never use it.

Im sorry, but how do you go about getting good performance numbers and tune a system when you are running iTunes and it trows your numbers off?

Yes it is stupid that you can not run iTunes and do debuging, but not stupid if you are doing performance measurements as the numbers will vary depending on the music file or video you are playing at the same time.

I like to debug and listen to music at the same time, so I see the point, but it is not criminal, it is just a bug..

 

[gnasher729]

Apple has, with malice and forethought, severely weakened a very good debugging tool. And they did this to a tool that the creators gave to the community in good faith.

I doubt the "malice" and I really doubt the "forethought". And remember that Apple had to do some work to get DTrace working on Leopard. So it is not as if Apple had taken anything away - they ported a valuable tool that otherwise wouldn't have been available on the Mac, and then through some stupid blunder messed it up. If Apple had done _nothing_, then DTrace wouldn't be available at all on the Mac.

Apple should have modified DTrace so that when it starts it checks if there are any applications that want to hide, and in that case tells the user what happened and quits. Doing nothing and telling the user would have been much better than going ahead and producing wrong results. So the developer would have just said "damned, I cannot listen to music while I am trying to fix this problem", but that wouldn't be a big deal.

 

[Compile 'em all]

DTrace is a system-level diagnostic tool. Hiding programs from being traced defeats the whole purpose of having DTrace in the first place. Not only this, but it means I can also code my own program (read: rootkit), set the LNOATTACH flag, and I am good to go.

 

[diamond.g]

DTrace is a system-level diagnostic tool. Hiding programs from being traced defeats the whole purpose of having DTrace in the first place. Not only this, but it means I can also code my own program (read: rootkit), set the LNOATTACH flag, and I am good to go.

Finally... It isn't just iTunes that could make this happen. It is any program that uses the LNOATTACH flag.

 

[milo]

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.

Are you sure about that? If it isn't hacked, where are the 1080p movie rips coming from?

Since iTunes and QT are closely related I would say quite a few, a la the recent Adobe problem

Adobe apps have problems with iTunes? Link please?

 

[stokessd]

The real irony is that all this mess is over protecting movies that lately have been so crappy that they aren't worth the effort to steal.

Sheldon

 

[stokessd]

Adobe apps have problems with iTunes? Link please?

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

Apple has been taking down discussion topics at the apple forums, but they are all over the adobe forum too. Here's a link, there are a ton of them:

http://discussions.apple.com/thread.jspa?messageID=6365013&#6365013

 

[diamond.g]

Are you sure about that? If it isn't hacked, where are the 1080p movie rips coming from?



Adobe apps have problems with iTunes? Link please?

video-pros-dont-install-that-quicktime-7-4-update-yet

EDIT: beated...

 

[SthrnCmfrtr]

Ha ha...the only DRM that can't be broken is a DRM that does NOT play audio or video in ANY WAY. In other words, you zip it up but can never open it and view it.

Otherwise you get this:
http://en.wikipedia.org/wiki/Analog_hole

LOL @ "a. hole"

Adobe apps have problems with iTunes? Link please?

Quicktime, to be specific. http://www.tuaw.com/2008/01/23/after-effects-7-users-quicktime-7-4-update-a-nono/

 

[parapup]

Are you sure about that? If it isn't hacked, where are the 1080p movie rips coming from?

Lack of uniformly available fool proof DRM - that's where they are coming from, now. 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. Watermarking, Trusted Devices to prevent the Analog hole, the insanity does not stop there.

 

[Virgil-TB2]

Well, there's a fundamental problem with your logic here. It's certainly what developers are doing NOW THAT SOMEONE HAS DISCOVERED WHAT APPLE DID - but Apple didn't bother to tell developers about it. ...

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.