Discussion Over Apple's Modification Of Sun's DTrace

[MacRumors]

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com)

One of the most anticipated features of Mac OS X Leopard amongst the technical community was the port (http://www.apple.com/macosx/technology/unix.html) of Sun's DTrace (http://opensolaris.org/os/community/dtrace/) utility for application and system profiling. DTrace is a powerful, low-level dynamic tracing framework that allows system administrators and developers to trace applications for tuning or troubleshooting purposes.

Recently, Adam Leventhal, one of DTrace's initial developers, discovered that Apple's implementation creates a way for a program to exclude itself from being traced (http://blogs.sun.com/ahl/entry/mac_os_x_and_the). Namely, he was unsuccessful at tracing iTunes, and found that Apple had added a method of disabling probing on certain applications defined with the directive P_LNOATTACH.

Wow. So Apple is explicitly preventing DTrace from examining or recording data for processes which don't permit tracing. This is antithetical to the notion of systemic tracing, antithetical to the goals of DTrace, and antithetical to the spirit of open source. I'm sure this was inserted under pressure from ISVs, but that makes the pill no easier to swallow.

Since the initial publication of the blog entry last week, the story has begun to pop up (http://arstechnica.com/journals/apple.ars/2008/01/21/apple-may-be-crippling-dtrace-to-protect-its-drm) around (http://www.theregister.co.uk/2008/01/22/sun_apple_dtrace/) the mac web (http://www.boingboing.net/2008/01/22/apple-cripples-debug.html).

The practice is not entirely new to Apple. A commenter on Adam Leventhal's blog (http://blogs.sun.com/ahl/entry/mac_os_x_and_the#comment-1200781574000) noted that Apple used the same directive to prevent GDB tracing on iTunes. Additionally, the implementation of this directive appears to be limited to iTunes (for the moment?), so many are speculating that the move is to protect Apple's FairPlay DRM.

To present an alternate view, Apple has extended Java, Ruby, Python, and Perl to include DTrace support, and Apple has built a GUI front-end called Instruments. Also the issue may eventually become moot with Apple's stated desire to move towards DRM-free music (http://www.macrumors.com/2007/02/06/steve-jobs-thoughts-on-music/).

Article Link (http://www.macrumors.com/2008/01/24/discussion-over-apples-modification-of-suns-dtrace/)

[longofest]

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

[parapup]

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

On top of that, noted developer Landon Fuller posted a fairly quick and tiny Kext with source that will disallow applications from doing the NOATTACH trick so iTunes can be traced anyways.

:confused:

[daveschroeder]

And the reason it's so easy to see what's going on?

Because the source code for things like dtrace (http://www.opensource.apple.com/darwinsource/10.5/dtrace-48/) is readily available on Apple's site.

And since the source is available, it's easy to fix for things like gdb (http://landonf.bikemonkey.org/code/macosx/ptrace_deny_attach.20041010201303.11809.mojo.html) and dtrace (http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html).

Making good-faith attempts to protect things like iTunes is a necessary evil for Apple to play in things like the video rental realm. Some people might not like it, but for the current iTunes ecosystem to exist, it's simply necessary to take steps to make the DRM environment more difficult to defeat.

But since Jobs himself has stated in no uncertain terms that DRM will always be broken - both literally and figuratively - this simply represents a necessary intermediate step to a world where digital content isn't encumbered with DRM. And it's only Apple who is going to be able to move the industry in that direction the fastest, because they have the most influence. In the meantime, Apple needs to do what needs to be done.

If FairPlay was trivial (anymore trivial than it already has been, anyway) to break, do you think Apple would have been able to get ALL the studios on board for movie rentals?

That means Apple takes actions which can be construed to ISVs as good-faith attempts to protect FairPlay.

[messedkid]

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


....Wha? :confused:

[em500]

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

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

[irmongoose]

Music might be on its way to no-DRM, but FairPlay is also used for movies, so I don't see how the issue will be obviated - especially with the new movie rentals which need DRM by nature.


irmongoose

[madrag]

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

[JoeG4]

Apple only brought out their desire to sell DRM-free music after the music studios decided that was the way to go.

Steve Jobs happily changes his mind however it benefits him.

[tk421]

Why should an average user even care about this?

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

[daveschroeder]

Apple only brought out their desire to sell DRM-free music after the music studios decided that was the way to go.

Steve Jobs happily changes his mind however it benefits him.

You are completely wrong, and that is revisionist history.

No one is staying Steve Jobs is God, but the DRM statement was the single biggest shot across the bow with respect to DRM that the music industry has EVER had from anyone close to that stature, and it was only AFTER that statement that the vast, vast, overwhelming majority of no-DRM music sales activity has gone on.

Was it due exclusively and only to Jobs? No.

Did it have a lot to do with that? Absolutely. Both from the standpoint of the statement, and from the standpoint of content owners trying to figure out how to still make content available to the widest range of customers without being beholden to iTunes.

[parapup]

But since Jobs himself has stated in no uncertain terms that DRM will always be broken - both literally and figuratively

Properly implemented DRM, like Encryption, cannot be broken. But I agree with your point that they have to take some steps to convince the music and video companies and this poorly implemented DRM is a good faith attempt. The "poorly implemented" part may have its roots in practical limitations - they don't have the Vista style hardware and OS assisted DRM yet in OSX to be able to thwart breaking attempts.

[Iroganai]

that's why I don't use iTunes.
Sad.
No, it's not just the fault of iTunes, it's the combination of iTunes and the
OS X kernel. So, if this is why you don't use iTunes, you shouldn't use OS X itself :rolleyes:

Anyways, it shows the good thing about the open-sourced Darwin project,
in that people can easily find what's `crippled' in the DTrace implementation on Leopard by looking at the code. You can't do that for a truly closed-source kernel. You can also re-compile the kernel with the offending code removed if you'd like, although it's not particularly easy.

[notjustjay]

Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

I agree with this statement.

[QuarterSwede]

Properly implemented DRM, like Encryption, cannot be broken.
That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

[madmax_2069]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

well can 3rd party's use it to point out a bug that Apple didn't see

[diamond.g]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

The problem, reading slashdots comments on the issue, is that if iTunes is open it screws up the trace log. So you could have iTunes (or any program that uses the flag) open and your trace log would basically be empty or corrupted. I am guessing that Apple didn't tell anyone that they were doing that, it took someone doing some snooping to figure out what was going on. It isn't that big of a deal as you can just compile that flag right out of the program, but it is annoying if one doesn't realize that is happening.

[kainjow]

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


....Wha? :confused:

Basically, Apple is preventing open-sourced debugging tools (software that helps a developer troubleshoot their programs) from working on iTunes :)

[milo]

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

What's why? Because you can't run dtrace on it? Um...what?

[QuarterSwede]

The problem, reading slashdots comments on the issue, is that if iTunes is open it screws up the trace log. So you could have iTunes (or any program that uses the flag) open and your trace log would basically be empty or corrupted. I am guessing that Apple didn't tell anyone that they were doing that, it took someone doing some snooping to figure out what was going on. It isn't that big of a deal as you can just compile that flag right out of the program, but it is annoying if one doesn't realize that is happening.
Ahhh I see. Thanks for clarifying. Yeah, that would've pissed me off too. :D

[milo]

Basically, Apple is preventing open-sourced debugging tools (software that helps a developer troubleshoot their programs) from working on iTunes :)

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

Quit iTunes. Debug your program.

[iSee]

Why should an average user even care about this?

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

You're not a jerk: this doesn't really even affect software developers.

Well, actually it is a positive thing for software developers because we can use the same mechanism to make our apps opaque to DTrace, too, if we choose to.

It's kind of a negative for hackers (who else wants to debug someone else's apps?). But not really, because they can work around it. Actually, hackers enjoy working around things like this, so it's actually a positive for them, too. :D

In practical terms, this doesn't really mean anything to anyone. If you are the type of person who wants everything to be "open," the idea of this will annoy you. I assume that's why such an esoteric thing is posted on as a main story. :rolleyes:

[kainjow]

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

Quit iTunes. Debug your program.

What if your program is in iTunes? Visualizers?

[gnasher729]

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

If you are not a software developer, it doesn't affect you at all.

There are two things worth discussing here: The first thing is that Apple tries (moderately successful) to keep people from looking at what iTunes is doing, which I think is their right to do. It's trivial (well, for a developer with a bit of hacker blood in him) to get around this. It is actually trivial to change DTrace so that it will _only_ work with applications that don't want it to look.

The second thing, which is not nice, is that DTrace doesn't work properly when iTunes is running. The problem isn't that DTrace cannot look what iTunes does, the problem is that DTrace cannot look what _my own code_ does while iTunes is running. That is a problem. The whole purpose why DTrace is there (and it has been proudly announced by Apple, is a major feature of Leopard as far as developers are concerned, and was reportedly very valuable for developers working at Apple) is to look at _my_ code, and it doesn't work properly. So whoever added those few lines of code should have done a better job and changed DTrace so that it doesn't look at iTunes, but continues working when iTunes is running.

The real problem is that DTrace can give completely wrong results without any warning. So a developer who listens to iTunes while he works might spend hours and hours looking for problems that don't exist - because DTrace gives the wrong results. Or he might not be able to find the cause of a real problem because DTrace gives the wrong results.

[diamond.g]

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

Quit iTunes. Debug your program.

It may not be only iTunes using that flag. It could be any program. Apple not telling anyone was the issue.

[EagerDragon]

Sounds foolish to me as it provides a false sense of security.

There are other debuggers available while not as convenient, they still can use them.

However we are talking about protecting Apple Intellectual Property (IS), no company wants their reserch and effort being used in unauthorised ways or modified in any way.

Mac OSX is not open source, some pieces are, but not all.

If it makes Apple feel better, thats fine so long as they understand that this won't stop a lot of code crackers.

[chuckiej]

DRM for TV Shows, movies etc will keep going especially with rentals coming. This is likely to continue then...

[twoodcc]

seems like Apple is slowing allowing this "tracing"

[eastcoastsurfer]

If it makes Apple feel better, thats fine so long as they understand that this won't stop a lot of code crackers.

Bad Apple! A change like this won't stop anyone who has the talent or the will to hack iTunes. All it does is make it harder to develop for the mac, since the change doesn't look like it was well thought out and hoses up any tracing while iTunes is running. Apples quality sure has taken a nose dive the past year or two.

[ChrisA]

That's not true either. Any encryption can be broken.

What? I can think of one technique that can be done by hand without using a computer that is mathematically proven to be unbreakable.

Hint: in involves a single use key that is as long as the message text. Key distribution is a practical issue with this method but it has been used for military and diplomatic messages for decades

[hexor]

This was openly stated at WWDC 2007 about this "feature". A developer had asked if there was some way to prevent a user from using DTrace on their program to work around registration, security, whatever, and it was stated you can set a flag to prevent DTrace from examining your app.

[akadmon]

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


....Wha? :confused:

I hear you. looks like another slow day on MR. Why the hell is this page 1 material? Why do I, Joe Regular, need to know/care about this stuff?

[lazyrighteye]

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

Creepy.

Tho I can understand why they would want to protect certain areas of certain applications. But still, creepy.

[QuarterSwede]

What? I can think of one technique that can be done by hand without using a computer that is mathematically proven to be unbreakable.

Hint: in involves a single use key that is as long as the message text. Key distribution is a practical issue with this method but it has been used for military and diplomatic messages for decades
Sounds like it involves quantum physics. I'm interested in knowing more.

[VaDor]

If you are not a software developer, it doesn't affect you at all.

There are two things worth discussing here: The first thing is that Apple tries (moderately successful) to keep people from looking at what iTunes is doing, which I think is their right to do. It's trivial (well, for a developer with a bit of hacker blood in him) to get around this. It is actually trivial to change DTrace so that it will _only_ work with applications that don't want it to look.

The second thing, which is not nice, is that DTrace doesn't work properly when iTunes is running. The problem isn't that DTrace cannot look what iTunes does, the problem is that DTrace cannot look what _my own code_ does while iTunes is running. That is a problem. The whole purpose why DTrace is there (and it has been proudly announced by Apple, is a major feature of Leopard as far as developers are concerned, and was reportedly very valuable for developers working at Apple) is to look at _my_ code, and it doesn't work properly. So whoever added those few lines of code should have done a better job and changed DTrace so that it doesn't look at iTunes, but continues working when iTunes is running.

The real problem is that DTrace can give completely wrong results without any warning. So a developer who listens to iTunes while he works might spend hours and hours looking for problems that don't exist - because DTrace gives the wrong results. Or he might not be able to find the cause of a real problem because DTrace gives the wrong results.

Very true!

I think Apple has to take some actions and maybe in a future update, change the way that Dtrace works... that can be very annoying for a developer...

I am imagining a C-objective book in the debug chapter saying this:
"First of all, you have to close iTunes to properly listen your process with Dtrace.."

Lolol :P

[Small White Car]

Properly implemented DRM, like Encryption, cannot be broken.

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

So tell me, how useful is DRM that doesn't allow anyone to view the content? Because outside of that, all DRM can be beaten using this method. No exceptions.

[min_t]

I guess it's better than another story on some lawyer's suit against Apple for patent violations.:rolleyes:

[parapup]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.


Let's put it this way - For all practical purposes and by all available means it is not possible to break properly designed encryption scheme in reasonable amount of time. Sure if you have a gazillion dollars and most of world's computing power you might make a dent but someone could just double the number of bits and make you look weak :D

[QuarterSwede]

This was openly stated at WWDC 2007 about this "feature". A developer had asked if there was some way to prevent a user from using DTrace on their program to work around registration, security, whatever, and it was stated you can set a flag to prevent DTrace from examining your app.
The problem is that if that's all they meant to do they seriously screwed up because right now, just having iTunes open is preventing DTrace from working properly.

[ChrisA]

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.

[QuarterSwede]

Let's put it this way - For all practical purposes and by all available means it is not possible to break properly designed encryption scheme in reasonable amount of time. Sure if you have a gazillion dollars and most of world's computing power you might make a dent but someone could just double the number of bits and make you look weak :D
That's better. :D

[parapup]

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.


Well then again it is not properly designed - If you have Vista, DRM enabled ATI graphics, a HDCP compliant monitor tell me how you could break the DRMed Videos you are watching.

Means exist to make it unbreakable - it's just a matter of time before they become common and DRM will then be properly designed and unbreakable.

[numbsafari]

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

On top of that, noted developer Landon Fuller posted a fairly quick and tiny Kext with source that will disallow applications from doing the NOATTACH trick so iTunes can be traced anyways.

:confused:

Most likely Apple's agreements with the record labels and movie companies include clauses that state Apple will make an effort to ensure that it's DRM is protected and not circumvented. Obviously, apple cannot do anything about hacking software except, perhaps, sue the people who are distributing it (if they have grounds to do so).

No one would trust Apple's DRM if it was easily circumvented by common users.

What's funny is that Apple's DRM CAN be circumvented by power users and so it is the common user who is restricted and constrained, and not those likely to be attempting massive pirating schemes... the exact people the music industry claims to be fighting.

It's really all a joke and you should vote with your dollars: buy music on CD and then rip it to MP3. Don't give apple money for DRM music. Don't buy CDs you think are overpriced. Don't play their game.

[grumpy]

I hear you. looks like another slow day on MR. Why the hell is this page 1 material? Why do I, Joe Regular, need to know/care about this stuff?

Lots of dev types among the rest of us Joe Regulars. :)

[eastcoastsurfer]

Let's put it this way - For all practical purposes and by all available means it is not possible to break properly designed encryption scheme in reasonable amount of time. Sure if you have a gazillion dollars and most of world's computing power you might make a dent but someone could just double the number of bits and make you look weak :D

Or actually implement a quantum computer which has been proven to be able to solve those pesky NP problems quite effectively. But, if someone does manage to do that, breaking DRM is the least of our worries (think no more SSL).

[bubba451]

Properly implemented DRM, like Encryption, cannot be broken.

Encryption is typically used when Adam wants to deliver a message to Eve without it being read by Brenda. That can only happen when Eve has something (a key) that Brenda does not.

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.

[parapup]

Or actually implement a quantum computer which has been proven to be able to solve those pesky NP problems quite effectively. But, if someone does manage to do that, breaking DRM is the least of our worries (think no more SSL).

Yep - we will be in a world of pain if that happens - but I am sure some bright mind will make use of the same Quantum tech to build an encryption scheme that can't be cracked until Octum computers are invented :)

[/dev/toaster]

So, what's the problem ? I don't see anything wrong with them trying to protect their DRM. They are under contracts with the music and movie industry to take every step possible to prevent the DRM from being compromised.

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.

[thogs_cave]

Why should an average user even care about this?

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

You've asked a very valid question. On the surface, I believe it probably doesn't affect the "average" user. However, it's more disturbing on a couple of different levels:

1) For those of us who troubleshoot computers for a living, or those who develop software, the idea of a system-level debugging tool with "blind spots" is scary. And that affects "average users" when we cannot do our jobs fully, either troubleshooting problems or ensuring quality software.

2) Sun provided DTrace as open source on good faith. When a company uses software like that but changes it in ways that are inimical to its core functionality, then they have acted in bad faith. Much like Microsoft modifying Java so it could run "Windows-only" versions of Java software.

Crippled tools are troublesome. I've spent hundreds of hours using DTrace under Solaris (Sun's Unix), and it has indeed helped me trace down issues that were affecting system performance and stability. Having "blind spots" scares me.

[milo]

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.

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

Well then again it is not properly designed - If you have Vista, DRM enabled ATI graphics, a HDCP compliant monitor tell me how you could break the DRMed Videos you are watching.

Assuming it hasn't been cracked already, it's just a matter of time. The hi-def disc formats were supposed to be uncrackable, but they were cracked pretty quickly.

Sure, an encryption method can be created that would take enormous time and resources to crack. But it probably wouldn't make a practical consumer format either.

[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? :confused:

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

[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 (http://arstechnica.com/journals/apple.ars/2008/01/23/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 (http://en.wikipedia.org/wiki/Digital_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. :confused:

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.

[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 (http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html) 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 (http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html) 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 (http://www.curtpalme.com/forum/viewtopic.php?t=5282&postdays=0&postorder=asc&&start=140). 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 (http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html) 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]

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

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 (http://en.wikipedia.org/wiki/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. :confused:

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 (http://www.free60.org) - 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?"

[milo]

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 (http://www.free60.org) - 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.

That link says you CAN run linux on xbox 360, at least on models with older firmware. Seriously, this is supposed to be the example of Impossible To Hack?

[Babasyzygy]

Take the case of Xbox 360

It's somewhat disingenuous to compare a box deployed as a sealed system (essentially a hardware solution even with magnetic media inside) with a multipurpose platform's OS designed to allow the user to load his or her own software with privileged access.

This is something that's not going to change with Mac OS X - Apple can not "seal" it so that users can't load their own programs with root access, too many ISVs depend upon this.

[ahl]

You're not a jerk: this doesn't really even affect software developers.

Well, actually it is a positive thing for software developers because we can use the same mechanism to make our apps opaque to DTrace, too, if we choose to.

This statement couldn't be more wrong. DTrace is a good thing for all users and developers. For users, you're empowered to understand the applications you use every day. For developers, you've empowered your users to collaborate with you to improve your program. We've seen countless examples of exactly this interaction for Solaris from the day in 2003 when we first made DTrace available to users. We were finally able to diagnose problems in situ rather than trying to replicate them back in our labs. And customers are able to gather their own data which is invaluable in understanding and fixing their problems.

[morespce54]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

Well, that's not really the point here. You see, they claim that they proudly port a good (and GPL) inspection tool that truly help in debugging softwares when in fact, they broke it (or adapt it to fit their needs). Now, to take any tool (GLP or not) and adapt it is not the real problem but render it partially useless (by changing bits and that to fit their needs), that's a different business from my point of view...

Anyway, the problem is not about iTunes or DMR or DTrace itself but it's more about making a tool available which, in it's present form, can't do its job properly.

It's a little bit like saying: Now with OS X, whenever an application crash, you can just look at the logs and see what happened and by looking at the log you can only see "Error -64" or even worst, you can't see any error being reported at all! :confused:

No big deal (for non-developers) but no medal awarded either...

[raimue]

The bad thing about dtrace is that it can't be run as a non-root user. Or is it possible?

PS: I also asked this question over at discussions.apple.com (http://discussions.apple.com/thread.jspa?threadID=1347396), but got no fulfilling answer yet.

[EagerDragon]

This statement couldn't be more wrong. DTrace is a good thing for all users and developers. For users, you're empowered to understand the applications you use every day. For developers, you've empowered your users to collaborate with you to improve your program. We've seen countless examples of exactly this interaction for Solaris from the day in 2003 when we first made DTrace available to users. We were finally able to diagnose problems in situ rather than trying to replicate them back in our labs. And customers are able to gather their own data which is invaluable in understanding and fixing their problems.

I don't supposed you are running iTunes in Solaris, so I assume you were looking for file lock contention or issues between two applications that talk to each other over shared memory. Unless it is a single application or a set of applications that work together to solve a problem, or that share specific resources like a block of memory, a lock, or a file, I do not see why one would care what another application is doing. The os is a multitasking multi user system, most programs run as separate processes and have little to no interaction with each other other than compete for cpu, disk space and virtual memory space. So I dont see why most people would care.

Most people have no need to know what iTunes is doing or how efficiently it does its job.

Most user are that .... USERS. They could care less how something works as long as they can get their job done.

While it is useful to have the user do things for you while reconstructing an issue that QA missed, most users are not technical enough to be helpful. If you are dealing with programmers and system admins, they can be very useful, but they are the minority of the USER community, unless your application is for one of those the average user can do little to help. Better to remote connect and do it your self with the user on the phone.

I like to see a show of hands of how many non-developers in this forum have used Dtrace with an Apple developer to solve an application or OS issue.

[ahl]

I like to see a show of hands of how many non-developers in this forum have used Dtrace with Apple to solve an application or OS issue.

Fair enough. Now everyone do this in the Terminal application:

sudo dtrace -c date -n 'pid$target:::entry{ @[probefunc] = count(); }'

Congratulations, you've now all used DTrace. If this had been a real bug, you would have been able to gather information for a developer working on your problem.

Now: a show of hands of how many non-developers in this forum who have hit a bug in some application and been unable to get a developer of that application to help solve the problem.

[thogs_cave]

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.

Actually, I'm not a developer, I'm a Systems Admin and Analyst. (For only 20 years or so.) While we've been focusing on iTunes, it's actually the modification of an important diagnostic tool that has me concerned - other apps can be set the same way, and that just adds to the issue.

I used to be a senior engineer at Sun, and the introduction of DTrace was a real thrill for me. I'm used to working on a system from a holistic approach, and missing parts of the picture make it difficult to do what I do best.

[EagerDragon]

Actually, I'm not a developer, I'm a Systems Admin and Analyst. (For only 20 years or so.) While we've been focusing on iTunes, it's actually the modification of an important diagnostic tool that has me concerned - other apps can be set the same way, and that just adds to the issue.

I used to be a senior engineer at Sun, and the introduction of DTrace was a real thrill for me. I'm used to working on a system from a holistic approach, and missing parts of the picture make it difficult to do what I do best.

Let me clarify, I never said it was not useful to a developer to have someone technical run commands like dtrace when the developer receives a call about a possible bug.

I said that most users would have no clue what to do and no clue as to the meaning of the output, also most software development companies with the exception of very small ones allow a customer to talk to their development / support staff directly. Most times you have to write to them and hope the developer calls you back. So it would be unlikely that a user would know how to use dtrace and is unlikely a user would know which application to look at and which data being displayed is significant, as such the email to the company will have little of value as the user did not run dtrace or the debuger to look at the registers. Which means that until the developer calls back and ask for specific things the user is completely clueless other than the symptoms he/she sees. Not only that, but the user may not even be able to use sudo or become root to run some of these commands, the user maybe a regular user at a corporation with few rights if any.

The average Grama and secretary does not know how to use dtrace, how to spell it, what it means, and what is significant from its output. Not every user is a sysadmin or a programmer, as a matter of fact few are unless you make software targeted at them.

[tyr2]

The bad thing about dtrace is that it can't be run as a non-root user. Or is it possible?

PS: I also asked this question over at discussions.apple.com (http://discussions.apple.com/thread.jspa?threadID=1347396), but got no fulfilling answer yet.

The reason for this is the level of access to raw data that you get with DTrace. For example you can see all data that is being read/written to disk or the network. You could, if you wanted, re-implement something like tcpdump with DTrace. If non-privileged users were allowed this access then that would break the entire security model of OS X, any user could see what any other user was doing and intercept their data. As noted in the discussions article you've linked it appears to be possible to give users the rights to run d scripts without having to give them whole root access if that is what is desired.

For example there's a Brendan Gregg d script called 'shellsnoop' here (http://www.brendangregg.com/DTrace/shellsnoop.d) that will display keystokes and command outputs from a users shell. (btw I've no idea if this would work without modification on OS X it's designed for Solaris, but the concepts are the same).

Edit: In further response to your question on apple discussions


Yes, that's what I want to know, too!
The main reason I have asked this question was a application crashing as non-root, but running fine as root. So I am unable to debug this know, as I don't know why it is crashing...
This is really bad.


DTrace works perfectly well against applications running as unprivileged users, it's just the DTrace script itself that must run as root.

BTW your crashing problem is almost certainly down to a permissions issue.

[thogs_cave]

The average Grama and secretary does not know how to use dtrace, how to spell it, what it means, and what is significant from its output. Not every user is a sysadmin or a programmer, as a matter of fact few are unless you make software targeted at them.

Oh, no doubt and I don't think we're actually in disagreement. I'm really not trying to nitpick a certain case or users, but rather express my distress at the concept that it's kosher to modify a diagnostic tool of this nature.

I'm not calling Apple evil, and I'm not going to toss my MacBook in the trash. Having worked for software, hardware, and just about every other industry, I can say that all companies do questionable things from time to time. But, if we don't air our dissatisfaction, then the people involved, then we're not being honest with ourselves. Even if Apple ignores me, it's worth it to say, "This is wrong."

[jpine]

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

All those who have no clue what this thread is about please raise your hand and say, Aye. Good. Now I don't feel so stupid. :D I do think I learned a little something though, which is a nice thing about this forum. There are some very bright people here.

[EagerDragon]

Oh, no doubt and I don't think we're actually in disagreement. I'm really not trying to nitpick a certain case or users, but rather express my distress at the concept that it's kosher to modify a diagnostic tool of this nature.

I'm not calling Apple evil, and I'm not going to toss my MacBook in the trash. Having worked for software, hardware, and just about every other industry, I can say that all companies do questionable things from time to time. But, if we don't air our dissatisfaction, then the people involved, then we're not being honest with ourselves. Even if Apple ignores me, it's worth it to say, "This is wrong."

almost one 100% with you on this, just one nick pick...... The place to complain about apple stupid practices is the support section of their site.

This is a good place to state the problem one sees, explain it why it is a problem and ask everyone to go complain at the Apple support site. Sort of rally the troops. Unless enough people complain rarely things change.

[WolfJLupus]

Properly implemented DRM, like Encryption, cannot be broken.

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.

Back peddling I see?

---

As long as the users have access to the hardware that decrypts the DRM media and plays it, it can be broken.

Even without physical access to the hardware they still have other means to record said media to something else. Like those bootleggers with video cameras at movie theaters.

[mdriftmeyer]

Let's put it another way.

If SUN Microsystems owned iTunes you would see a dtrace that had this and more disabled.

[eastcoastsurfer]

almost one 100% with you on this, just one nick pick...... The place to complain about apple stupid practices is the support section of their site.


I would agree with you if Apple didn't delete posts like they are the thought police out of 1984...

[savar]

As long as the users have access to the hardware that decrypts the DRM media and plays it, it can be broken.

Even without physical access to the hardware they still have other means to record said media to something else. Like those bootleggers with video cameras at movie theaters.

The difference between hardware and software is that, given enough time, a hobbyist hacker can debug enough code to recover a key or reverse-engineer a protection scheme, because all the tools that one needs are right there in front of you.

Imagine trying to reverse engineer a TPM chip. It's probably printed at 90nm resolution onto a silicon substrate, and then sealed in plastic. Much harder to study and thus much harder to reverse engineer.

To the extent that content owners can force these closed-source hardware solutions on customers, they will be able to dominate content in a brand new way.

[iSee]

This statement couldn't be more wrong. DTrace is a good thing for all users and developers. For users, you're empowered to understand the applications you use every day. For developers, you've empowered your users to collaborate with you to improve your program. We've seen countless examples of exactly this interaction for Solaris from the day in 2003 when we first made DTrace available to users. We were finally able to diagnose problems in situ rather than trying to replicate them back in our labs. And customers are able to gather their own data which is invaluable in understanding and fixing their problems.

I'll have to take your word for it regarding Solaris users. But you are seriously mistaken if you think asking OS X users to kick off DTrace sessions is part of an effective support strategy.

I do need to come clean on this though: There's no reason for a developer to try to take advantage of this by setting the LNOATTACH flag; it won't protect your app from hackers and will only annoy system administrators (apparently there are a very large number of them).

[123]

I'll have to take your word for it regarding Solaris users. But you are seriously mistaken if you think asking OS X users to kick off DTrace sessions is part of an effective support strategy.


Why not? Doesn't need to be a CLI.

[123]

As long as the users have access to the hardware that decrypts the DRM media and plays it, it can be broken.

As long as... that's the idea, you won't have any longer.

Even without physical access to the hardware they still have other means to record said media to something else. Like those bootleggers with video cameras at movie theaters.
Look up watermarking.

[iSee]

Why not? Doesn't need to be a CLI.

How is that tech call going to go?

[WolfJLupus]

The difference between hardware and software is that, given enough time, a hobbyist hacker can debug enough code to recover a key or reverse-engineer a protection scheme, because all the tools that one needs are right there in front of you.

Imagine trying to reverse engineer a TPM chip. It's probably printed at 90nm resolution onto a silicon substrate, and then sealed in plastic. Much harder to study and thus much harder to reverse engineer.

To the extent that content owners can force these closed-source hardware solutions on customers, they will be able to dominate content in a brand new way.

You still can hack the hardware though and even more simply you bypass it. As long as you have access to the hardware you can do that and consumers aren't going to be too keen on having hardware they can't access at all.

It's just like if/when they make HDMI use DRM/protection schemes to ensure you're connected to "proper equipment", you get a box to bypass that which will say "I'm a good piece of equipment"... Simple enough...

DRM schemes would work better with software vs media because software provides complex functions (but still can be hacked) where as media is viewable to the end user otherwise it's worthless... You have the analog hole which just simply is not going to be plugged unless something radical happens and even then it's likely to have work around.

The main point being, it is not impossible to hack DRM, no matter how great it is, the same with encryption...

[TPALTony]

Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

Here here. Apple is incredibly open source friendly. That they should choose to protect certain parts of their software (the bit that is attached to the iPod, their big cash cow) is entirely understandable, and reasonable.

When will people stop getting on their high horse over things like this and recognize the good that people do.

[bigwig]

Encryption (which is a form of DRM), is really designed to stop casual piracy.
So they say. The problem is, it isn't true. I never have to break the DRM scheme to copy data to my own discs and start selling bootlegs that will play just like legitimate copies. I think that's why HD drives are still hard to get, they want to prevent copying in hardware but that has a substantial risk of detecting false positives without a software workaround if that happens. It also means you can't yet build HD media servers, not that the studios care how consumer-friendly their product is. The studios should have learned from software companies, who attempted to enforce use restrictions with dongles and other hardware in the 1980s and were eventually forced to abandon such schemes due to intense customer dissatisfaction.

[savar]

You still can hack the hardware though and even more simply you bypass it. As long as you have access to the hardware you can do that and consumers aren't going to be too keen on having hardware they can't access at all.

It's just like if/when they make HDMI use DRM/protection schemes to ensure you're connected to "proper equipment", you get a box to bypass that which will say "I'm a good piece of equipment"... Simple enough...

DRM schemes would work better with software vs media because software provides complex functions (but still can be hacked) where as media is viewable to the end user otherwise it's worthless... You have the analog hole which just simply is not going to be plugged unless something radical happens and even then it's likely to have work around.

The main point being, it is not impossible to hack DRM, no matter how great it is, the same with encryption...

I guess by "the analog hole", you mean displaying the image on a screen (or playing the sound through a speaker). You're right, given our current understanding of physics, it is impossible to share information with somebody without them being able to capture that information in some form. I don't think anybody disputes that.

But given that the media is digitally encoded and has an all digital path from decoder to display, I still don't think your viewpoint on "bypassing" hardware makes any sense. The "trusted" devices can recognize each other using public key encryption. Sure, the private key is present, but if it's hardcoded on a piece of silicon, how are you going to recover it?

Nothing is literally impossible, but recovering a 1024 bit private key with brute force would take more years than there are particles in the universe.

There is a fundamental difference between hardware and software, and its mostly economic. Basement hackers don't have access to the tools required to reverse engineer a computer chip. Sure you can see what signals go in and out, and you can attempt to bypass, but there are elementary encryptions systems that would make it impossible to "bypass" a chip unless you knew the private key.