Discussion Over Apple's Modification Of Sun's DTrace

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

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.

 

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

 

[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

 

[min_t]

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

 

[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

 

[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 her has missed the point.

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

That's better.

 

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

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

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.