Apple cripples debugging tool to keep iTunes DRM safe

Discuss

33 Responses to “Apple cripples debugging tool to keep iTunes DRM safe”

  1. w000t says:

    Anyone know how this affects Leopard’s Unix certification?

    From (http://www.apple.com/macosx/technology/unix.html):

    Unix Certification
    Leopard is an Open Brand UNIX 03 Registered Product, conforming to the SUSv3 and POSIX 1003.1 specifications for the C API, Shell Utilities, and Threads. Since Leopard can compile and run all your existing UNIX code, you can deploy it in environments that demand full conformance — complete with hooks to maintain compatibility with existing software.

  2. Skep says:

    OT:

    Otherwise it’s like suing McDonald’s for coffee being too hot.

    Sorry, bub, but that was a meritorious suit. McDonald’s was serving coffee in flimsy paper cups at an undrinkable and undeniably instantly scalding 180 degrees–and handing these cups of instant scalding liquid to people through their drivers windows.

    It was not only completely foreseeable that people would get burned by this practice but it had already happened a number o times. McDonalds elected to continue this practice in spite of the known danger.

    A the victim in the case you allude to was burned to the bone and had to have skin grafts to treat her 3d degree burns. She didn’t set out to sue them, initially she just asked McDonalds to reimburse her for her direct medical costs. It was only after they told her to stuff it that she was forced to sue for medical costs. The jury decided to fine McDondalds’ 3 days of coffee profits as punitive damages since a small fine would mean nothing to the behemoth. The damages were later, unjustly IMO, reduced on appeal. However, the verdict stands.

  3. Rob says:

    @JPlotz:

    Well, since you can’t find the right line, the code for protecting an app is ptrace(PT_DENY_ATTACH, 0, 0, 0);, right in the comments.

    The company I work with will not abandon Mac, but anything I was going to do on my own will not occur. I was also going to be the project manager for one of the products, a promotion I will decline.

    So, what else does Apple do in the name of DRM? Does tcpdump not report phone home packets? Is ps or Activity Monitor skipping manager processes?

  4. meadhbh says:

    Degrading debugging tools to prevent developers from hacking DRM systems is considered harmful.

    Sadly, Apple is not the only company to do this. If you use the WinCE / WinMobile platform, you need to get all your platform and BSP debugging done _before_ you add DRM to the mix. Several years ago I worked for a company that was developing a custom device that (among other things) allowed you to download music and play it on the device. We did all the proper things with respect to licensing, including promising to take reasonable steps to protect the intellectual property rights of our partners. To be sure, there were a number of “typical” snags. But the most irritating bit was when, after signing deals with the big 5 (there used to be 5 major labels), signing a deal with Microsoft for the WinCE DRM bits, jumping through Verisign’s bizarre hoops to identify ourselves, we discovered that kernel debugging on WinCE is (or was) _completely_ disabled after you add DRM to the platform.

    I don’t know if any of you out there have developed a BSP (Board Support Package) for WinCE (or any other embedded OS), but it’s not always a straight-forward process. Documentation from chip vendors is not always completely accurate and timing tolerances seem to vary with the quality of some parts. Debugging custom drivers is often required to discover the cause of vexing low-level problems in a reasonable time frame.

    In our case, we had to maintain multiple build environments: one for our BSP & Apps without DRM, and one with DRM. We also had to get quite “creative” in the way we debugged problems and even had to spend time developing custom tools.

    The long and the short of it was that the removal of debugging capabilities from the development process added at least 3 man-months to our development project, but what’s worse… it seemed to add (at least) 3 months to our release calendar.

    Bringing this back to a discussion about DTrace… removing capabilities from a development tool is unlikely to be a good idea. Especially with tools like DTrace, where enterprising developers can figure how to remove the Apple “improvements” while maintaining full functionality. I suspect that if Apple doesn’t do it themselves, someone out there will fork the code and distribute a “unimproved” version of DTrace for MacOSX 10.5. Or… they’ll just give the patches to the proper maintainer and enterprising developers will be able to compile the “unimproved” version from sources (though admittedly, this is always slightly less easy than I might have made it sound.)

    “Improving” DTrace will require Apple developers to get an “unimproved” version if they feel the “improved” version is not working properly (and believe me, programmers rarely think of _themselves_ being the problem before they think of their _tools_ as having issues.)

    Sure… I can understand Apple having to “play nice” with the big 4, but it’s time we move past the model of “system developer as adversary.”

  5. zuzu says:

    Afterall, as has been posted several times, if you’re not buying anything from iTunes, then the Apple DRM restrictions doesn’t affect you. It’s wrong, sure, but that’s why I don’t buy anything from iTunes in the first place.

    Generally I agree, but iTunes is Apple’s most troublesome piece of software, primarily because of DRM or DRM-like issues. Corrupting DTrace for iTunes is one example. Limiting DAAP music shares to 10 people per day is another. Precluding users from copying MP3s from their iPods back onto their computers is yet another. Disabling manual music management for the iPhone and Shuffle is another.

    Also, I just dislike that Apple never implemented hybrid CD burning where the MP3s are stored on Track 0 and the CDDA on Tracks 1-n. But that’s arguably just an unimplemented feature.

  6. meadhbh says:

    Kerckhoff’s principle applied to developing DRMish systems…

    Continuing my comments… One of the reasons we have “improved” versions of debugging tools is that there is a pervasive fear among technologists and record company executives that general knowledge of the implementation of a DRM system will more rapidly to successful exploits.

    In the commercial crypto developers community (of which I was a part for a while) there were several discussions in the 80′s and 90′s about similar concepts. (If you’re really interested, google “A secret that cannot be readily changed should be regarded as a vulnerability”)

    In the crypto world, we have this thing called “Kerckhoff’s Principle” which can be described as: “A system should be secure, even if an adversary has complete knowledge of the system, save a secure key.” This has gotten us out of trouble several times. It allows us, as algorithm developers and implementors to openly discuss our concepts and have them be debated in public. There is general agreement amongst really smart people that this is “a good thing.”

    With respect to DRM systems, consider a DRM system that could be implemented in such a way that while it’s under development, a blessed “developer key” could be used to allow the developer to peek into every nook and cranny of the system under development. When it came time to ship the device, a new key… a production key… preferably related to a key not under control of the development organization is installed into the device.

    You could take this one step forward and release such a system under an open source license (and yes… I can hear Cory going apoplectic over the concept of “open source DRM”.) Actually… several years ago, Sun proposed such a system. A system called DReaM. And it was released to near universal, deadening silence, a total “cricket moment.”

    But hope springs eternal… the best solution to the DRM problem? Get rid of it. It complicates development at best, and at worst it allows people to complain about “anti-competitive” behavior on the big 4′s part. The argument being that since a professional copyright infringer could either buy CDs or DVDs to copy directly, and the ease with which DRM regimes seem to be defeated, the _only_ reason the labels could be supporting DRM is as an indirect path to control the distribution not only of their content, but to control the companies that build devices to distribute their content.

    That being said… I suspect we’ll continue to see DRM used for the foreseeable future, despite the success of DRM-free projects. But… for the love of everything that’s holy, can we please stop considering developers as “the enemy”? It isn’t helping.

  7. abb3w says:

    adrian: Perhaps I´m misunderstanding something here (I´ve just pulled an all-nighter so that may very well be the case) but since the iTunes store has already sold a gazillion DRMed tunes, are they not obliged to prevent these tracks from being unlocked? I understand that crippled debugging tools must be a pain for programmers, but providing the tools to crack files that were purchased would certanly put Apple in very legal hot water with the record companies yes/no? How could they possibly justify it?

    IAmNotALawyer, but I believe “no”, “no”, and “via Sony v. Universal (aka the Betamax case) and MGM v. Grokster”. DTrace is capable of substantial non-infringing uses as per Betamax; ergo, unless Apple can be shown as distributing it “with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, going beyond mere distribution with knowledge of third-party action”, they’re clear… at least via case law.

    However, Apple may have signed contracts which create a larger obligation in order to get the distribution rights from the various parts of the M(afi)AA. If the contract really requires buggering up a debugger tool, it’s a stupid one, and sloppily done.

    A more clever way would be an implementation that merely notes the presence of the “DRM-flag” on a scanned process, and throws up a pop-up message that trying to circumvent DRM to commit copyright piracy is a violation of the US code title and chapter yada yada, punishable by yadayadayda, and keeps it open while the scan runs. However, I don’t run Apple…. so blame Steve.

    Hopefully, someone will re-port the application without Apple’s little DRM-protecting/malware-facilitating addition.

  8. tim says:

    “eg. IBM invented concept of RISC processors and then sat on the idea because they realized it would cannibalize their existing, quite profitable systems, and it took ARM to come along and actually commercialize RISC technology successfully.”

    Nonsense. It just happens that I was involved in both in their early days.

    IBM developed the 801 which became the powerPC and successors. You might remember a range or two of machines based on that cpu. IBM still sells rather a lot. They licensed the design to a number of companies and they continue sell quite a few. I had an 801 machine for a while when I was an IBM Research Fellow.

    Acorn invented the ARM because nobody there liked the 68000 or x86 or NS32000 for their plans to move beyond the 8bit BBC Micro. I still have an original handbuilt prototype machine that was provided to do the Smalltalk-80 for the commercial version.

    SUN of course had the Sparc. I used to have one of them too but never really liked the architecture.

    All three ‘successfully commercialised’ RISC cpus before ARM (the company) was founded. Apple dropped the dreadful ‘hobbit’ and moved to ARM for the Newton, and wanted a slightly more arms length relationship between the cpu and Acorn, so Acorn, Apple, VTi and … somebody else… formed a separate company and the Acorn Risc Machine became the Advance Risc Machine and took over the world of non-desktops.

  9. kstevens says:

    To learn more about Digital Restrictions Management and to help in the fight to eliminate it, visit http://defectivebydesign.org/

  10. Skep says:

    As pointed out on other threads on this issue, Apple didn’t just hide iTunes from DTrace, they crudely hacked it so that DTrace doesn’t record when specially tagged programs like iTunes are cycling. This means that DTrace will give false results about other processes because it is so busy turing a blind eye. Oh, and malware could use the same Hide From DTrace tag to make detection more difficult.

  11. Antonio Silva says:

    I agree with Cory’s points on DRM most of the times, but I’m still trying to figure out how could Apple deliver digital video rentals without it. At first, it seems to be the only acceptable use of DRM and one that I would actually think would be counterproductive to hack. I accept that I may be wrong, though.

  12. adrian says:

    Perhaps I´m misunderstanding something here (I´ve just pulled an all-nighter so that may very well be the case) but since the iTunes store has already sold a gazillion DRMed tunes, are they not obliged to prevent these tracks from being unlocked? I understand that crippled debugging tools must be a pain for programmers, but providing the tools to crack files that were purchased would certanly put Apple in very legal hot water with
    the record companies yes/no? How could they possibly justify it?

    Is this really an example of draconian DRM evilness Cory, or are they just (rightfully so) guarding their legal asses?

  13. Eduardo Padoan says:

    Make me remember this SciFi from Richard Stallman, “The Right to Read”:
    http://www.gnu.org/philosophy/right-to-read.html

  14. Cory Doctorow says:

    Antonio — that’s the point. Once Apple decided to get into the “digital movie rental” business (which could also be called the “your computer will attempt to prevent you from using it in certain ways” business), they set themselves on a course to create an ever-tightening set of strictures in their OS, devtools, and apps.

    No one held a gun to Apple’s head and said, “You must rent.” No one promised the entertainment industry that “rental” and “digital” would be compatible — indeed, they aren’t, since “rental” requires the entirely implausible proposition that personal computers won’t be used in ways that invalidate the security on which the model depends.

    I’m not talking about the morals or ethics of rental here. Perhaps it’s possible that, say, Warner Brothers and I could come to a fair agreement that I will only hold the file on my hard drive for a certain number of days.

    The problem is that once Warner sets out to strike “deals” like this with everyone, they end up requiring that hardware vendors and software vendors take a series of steps that inflict harm on innocent parties, and that will have to escalate and escalate and escalate.

    Apple did make this bed, and now they have to lie in it. It’s not going to get anymore comfortable, either.

    Once you accept the premise that Apple should get into rentals, no matter what the cost, then sure, all they’re doing in “covering their legal asses.”

    But why should we accept the premise? Say that Ford decided to make cars whose price was subsidized by Nokia, and in return, Ford promised Nokia that they would police all Ford automobiles to make sure that only Nokia chargers were being fitted to the car.

    Now, Ford would have to do some pretty crazy things to make this work: they’d have to rip out your Motorola charger when you brought the car in for service; they’d have to redesign the lighter-socket to prevent you from easily fitting a Sony-Ericsson charger; they’d have to set the terms of the warranty such that they revoked your warranty if you were caught “hacking” into your car to do anything that might undermine the “security” of the Nokia deal.

    At that point, Ford would just be doing what they needed to do to hold up their end of the Nokia deal.

    But so what? If making that deal work requires that Ford screw us and screw us and screw us, should we just shrug and say, hey, they’re just trying to earn a buck?

    I say no. I say if Apple starts down the DRM path and then has to take a series of ever-worsening step to “protect itself,” that we should note this, and stop using their products until they improve.

  15. danegeld says:

    Apple has an interest in the film business through Steve Jobs being on the board of Pixar. Apple isn’t about to make piracy easier than necessary and eat into its own profit margins.

    The MacBook Air $99 external DVD drive is cheaper than the $200 external drive to the MacBook Pro, though both pieces of equipment provide the same functionality. Hence, the $99 drive is locked by design to the MacBook Air, to prevent Apple cannibalizing its own sales.

    eg. IBM invented concept of RISC processors and then sat on the idea because they realized it would cannibalize their existing, quite profitable systems, and it took ARM to come along and actually commercialize RISC technology successfully.

    I expect DTrace can be unhacked by people with the inclination to do so.

  16. Frank Drebin says:

    I’m really not trying to be a troll, but I like the disparity between the headline “Apple *cripples debugging tool to keep iTunes DRM safe”

    and this line from the quote :”To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist..”

  17. Antonio Silva says:

    Cory – I think where we disagree is that I don’t have an intrinsic problem with DRM, just a pragmatic one. I agree that in most occasions is crippling for the consumer and counter productive for the industry. As well, in most cases there’s viable alternatives to the industry to make money without DRM. However, in the case of movie rentals I struggle to find one, and many of the problems with DRM such as playforsure/mlb/etc fiascos do not apply to rental.

    What would be the exact terms of the fair agreement with Warner that you mentioned as an example? How would it be enforced? In the end there needs to be a technological differentiation between rental and buying and DRM seems to be the only one available. If the movie didn’t stop playing after a day it wouldn’t be renting, it would but buying.

    It’s a question of trade offs, I let Apple control my computer in order for me to rent a film. Yes, I could buy the film and own it but I don’t want to, nor I can be bothered to go to the shop to get it.
    I feel in similar ways to Gmail. I give them access to my email, I get a great email service in exchange. My privacy becomes a currency I can use to acquire a service. When buying music and films I find the use of DRM a bad trade off, in the case of rental I think it’s fair.

  18. cbernard says:

    In regards to not using Apple’s products until they stop inflicting DRM, etc, this is impossible for some of us. I do not own an Apple for iTunes, I own it for many other reasons–reasons that in my situation, Apple simply excels at compared to alternatives.

    I have never heard of Dtrace before, and all my iTunes purchases are backed up to CD.

    I rarely read anything negative about those who are duping these movies that cause this DRM to fire up in the first place. “personal use” my ass. Go to any asian video rental store anywhere in the world and look at how many “personal use” copies they have.

  19. Rob says:

    @#8:

    I will never rent a movie. Yet my Mac has the same DRM that is affecting the OS. Please explain how this is fair to me.

    @#5: “Apple did make this bed, and now they have to lie in it. It’s not going to get anymore comfortable, either.”

    Nope, and it looks like my next computer will not be a Mac. Certainly won’t be Windows (hasn’t been for years), and it’s looking much less likely now.

  20. jplotz says:

    Dtrace wasn’t available at all on OS X until Leopard, so the fact that you can’t use it on iTunes doesn’t count as “crippling” it in my book. Leopard offers new functionality over Tiger, without taking any functionality away – so how exactly is that “crippling”? If you mean it is crippled compared to the Sun version of Dtrace, you aren’t comparing apples to apples, since Sun’s OS has different features and capabilities anyway (for example, there’s no iTunes for Sun OS).

  21. Rob says:

    @JPlotz:

    Read the original article. Because it doesn’t work on iTunes, it throws it completely out of whack, proper scripts do not return the proper results. EVEN ONES THAT AREN’T TARGETING ITUNES

    They would’ve been better off not shipping it.

  22. Rob says:

    @JPlotz:

    There is one other thing you are missing as well, as is everyone else that supports this.

    This same mechanism can be used to help hide malware.

  23. jplotz says:

    1. Rob: The malware issue is entirely separate from DRM. If Apple is introducing security flaws, then yes, that is a problem. Can you point to an exploit that could use this flaw?

    2. If Sun were in the media business like Apple is, I can guarantee you they’d do exactly the same thing. The media content providers are scared to death of digital media and don’t trust their own customers. Apple clearly does this sort of thing only because they are legally bound to (for example, Leopard has no copy protection or activation codes at all, the user is trusted to do the right thing).

    3. If system-wide Dtrace capability is that important to you, don’t use OS X. I’d guess that will affect about 0.001% of the existing OS X base.

  24. Bloo says:

    Perhaps I’m oversimplifying this in my mind, but, since DTrace runs on x86 hardware, and since DTrace is available for *nix variants on x86 hardware, and since OS X is a *nix variant, wouldn’t it be fairly easy for someone else to port a different DTRace to OS X and defeat this?

  25. Antonio Silva says:

    @#9:
    “I will never rent a movie. Yet my Mac has the same DRM that is affecting the OS. Please explain how this is fair to me.”

    Crippling DTrace is a bad move, I guess I was going slightly off topic and talking about DRM in general. But if you choose to not buy DRMed products how is your computer affected by it? In Vista that might be the case, but in my Mac I’ve never had any problems.

  26. Rob says:

    @JPlotz:

    RTFA. The code needed is right there, so any malware that wants it can use it.

    As for 3, it affects more than 0.001%, by far. It may DIRECTLY affect that many, but those are the people that write software (which includes me, I have commercial Mac stuff out there). If they stop writing the software, it’s a global effect, not a local one.

  27. Rob says:

    @Antonio:

    Read my comment about malware. My system is vulnerable to malware that has another mechanism to hide, all in the name of DRM. Any dtrace scripts that use timing are also thrown off.

  28. Moon says:

    As long as we have iTunes geeks on here, can anyone tell me why it takes sooooooo long to upload MP3s from a hard drive?

    I have a 30GB Dell DJ and it takes about 2 hours to upload 30GB. On my iPod, I’m lucky to get 3GB uploaded in 2 hours. It took me 2 whole days to upload 75GB. (24 HOUR days – I let it run!)

  29. Rob says:

    @Moon: What are you using? My wife uploaded 40GB to her iPod, it took longer than I thought it would, but it certainly wasn’t a full day. This was a PowerBook, the iTunes library was on an external USB drive as well, so not the fastest way to do it, yet it was still far faster.

  30. jplotz says:

    So Rob, let me get this straight: your entire software development business is dependent on accurate Dtrace timings on OS X (said timings not even existing until Leopard), and as a result you are going to abandon OS X? If that is true it would be a pretty foolish business decision.

    I don’t see any Malware code in the original article. I see Apple source code which prevents gdb or dtrace from attaching to specially-tagged processes. ‘top’ or ‘ps’ would still show the process though. Of course, a hacker could replace top and ps, but then again they could replace dtrace too.

  31. zuzu says:

    I agree with Cory’s points on DRM most of the times, but I’m still trying to figure out how could Apple deliver digital video rentals without it. At first, it seems to be the only acceptable use of DRM and one that I would actually think would be counterproductive to hack.

    The fundamental problem here is applying the “rental” paradigm to digital media. “Rent” only applies to physical objects such as an apartment, a car, or a cassette. For digital media, where copying is easy, the problems customers are willing to pay for solutions to are quality assurance and availability (two aspects that P2P struggles with). Not everyone wants to buy 10TB of storage space, no matter how cheap, and then administer a personal collection of videos. Some people want to pay (a monthly flat fee, like Netflix) to be able to use the iTunes store to download any movie whenever they feel like watching it, and then delete it to make room whenever they tire of it — knowing they could always download it again later. There’s no need for DRM at all, except by dinosaurs trying to put a square peg in a round conceptual hole.

    Personally I blame Bill Gates for back in the day pitching the idea of “software as product” to industrial economy of scale minded suits who didn’t understand selling anything that you couldn’t put in a box. Again, software (i.e. information) has fundamentally different qualities and constraints than physical artifacts; to wit Stewart Brand later, “information wants to be free”.

  32. GoAway says:

    The point is that your choice to use Apple products, proprietary Apple software, and in many cases proprietary Apple hardware locks you into a non-stop battle with Apple over how you want to use your computer. Apple isn’t interested in your freedom they only care about theirs. They only side with Open things when it immediately benefits them. Sure they have some OSS projects but that’s often because the used and OSS to get there!

    You of all people should know that you give up your freedom to use your software and hardware as you wish when you use proprietary software. Apple’s continuous attempts to stop people from changing software on their home computers is a good example of how they feel about freedom. They only side with freedom when it is immediately beneficial.

    It is very simple: Freedom is a feature, buy and use products which have this feature. Stop whining about “features” you’ll never get. Switch.

  33. serotonin says:

    I think someone giving up on Macs over this is a little harsh. If you’re at all tech-savvy and bought any DRM-ridden tracks/videos from iTunes then you get what you deserve.

    Otherwise it’s like suing McDonald’s for coffee being too hot.

    Afterall, as has been posted several times, if you’re not buying anything from iTunes, then the Apple DRM restrictions doesn’t affect you. It’s wrong, sure, but that’s why I don’t buy anything from iTunes in the first place.

Leave a Reply