Hacker News Reader

Comment by jrockway | Hacker News Reader

I was the same way until one day, I tried to run gdb on iTunes, and gdb segfaulted. I did some research and found that Apple added extra code to the OS just to prevent someone from doing exactly that. They spent additional engineering effort just to lock me out of my own computer. (I still wonder what data collection they were trying to hide.)

Anyway, that was the day I deleted OS X and switched back to Linux forever. (I even ran Rockbox on my iPod until I replaced it with a $30 Sansa device with 10x the features.)

View on HN

Playing devil's advocate here, but what's the media store like on your typical Linux distribution? The reason Apple has to go to such draconian measures is to please their content providers. Without doing so, you wouldn't have an iTunes store with such a wide variety of content.

Apple's margins from content sales are slim; they push content to sell devices. As they've shown with music in the past, they'll get rid of DRM if the content providers allow it. So it's not entirely fair to blame Apple for that one.

> typical media store

There are several BitTorrent clients to choose from!

The content providers seem happy with iTunes running on Windows without such protection.

When Apple first signed on the labels, iTunes didn't run on Windows. Do we know when these protections first showed up? Was it Apple's way of appeasing the labels before they gained enough mass that the labels couldn't ignore them?

I don't know about the debug protections, but according to Wikipedia's timeline, it was only a matter of 6 months between iTunes Store appearing and iTunes becoming available for Windows.

The amazon store is pretty goood

7digital[1] is great for music, and they don't use any DRM.

[1] http://www.7digital.com/

You seem to be very confused. The facility that blocks gdb is part of the standard ptrace APIs. It was not extra code that Apple added.

In any case, there's also a very simple explanation that should be obvious to anyone who thinks about it as to why Apple did this: because iTunes deals with DRM. A one-line change to block debugging is something I'd absolutely expect any app that uses DRM'd content to do.

PT_DENY_ATTACH certainly isn't part of any standard. It's absolutely a Darwin-specific feature, and is thus "extra code that Apple added", and they presumably did it for exactly this application. And no, other DRM-aware apps on other OSes don't do this.

So... who's very confused?

Ubuntu also restricts use of ptrace for security reasons although it shouldn't affect gdb https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening...

Yes, but critically in Linux you can turn it off as the administrator of the system. It affects security but not inspectability. Regardless, my response was simply to the idea that Apple was "following standards" when they clearly weren't.

In Ubuntu, it's user overridable (i.e. machine owner is in control). In Darwin/OSX, it is not (i.e. machine vendor is in control).

Actually iTunes on Windows also calls IsDebuggerAttached and exits for YES. This though can be easily by passed by hooking the function call.

> I tried to run gdb on iTunes, and gdb segfaulted.

Whoo, any links please? I'd like gdb to crash on my programs as well!

For the naive: why?

To learn.

Oh, I thought you may have a specific reason for causing gdb to segfault on your app.

Call ptrace with PT_DENY_ATTACH (it's actually documented).

Besides Apple's nefarious Dr. Evil world domination uses, it can also be used to protect programs from each other. If your browser denies ptrace, it will prevent rogue programs from reading your passwords out of its memory.

Not really, since a program wanting to circumvent it can just attach before the call is made, or use other mechanisms to read process memory.

ok, true, you have get there before the bad guys.

Trivially worked around by starting the program in gdb and running these commands before you run the program:

    b ptrace
    commands
    return 0
    cont
    end

(In short, every time the app calls ptrace, return a 0 to the caller without executing any ptrace code, and automatically resume execution. Since apps almost never use ptrace for anything else, it's workable to just short-circuit every single call like this rather than trying to check for PT_DENY_ATTACH.)

Clearly, one has to agree that this is a poorly designed API feature with a huge hole that provides no real security.

Apple still, however, designed it into their product and tried to use it to prevent user inspection of system state.

I can only assume that they're following the letter of their contract with media companies to include anti-debugger measures, while not really trying very hard.

Just to be clear, I'm not trying to defend Apple here, just telling people how they can get around this if they feel like debugging iTunes or whatever.

I wonder if the above gdb script counts as circumvention of a technological measure under the DMCA.

I would guess that the gdb thing is to prevent cracking of their DRM, not to hide some PII tracking. Do you know if you can attach gdb to something like Xbox Music (Zune)?

Looks like you can attach a debugger to Zune, but if you try to play DRM'ed files when doing so, it will fail with an error.

http://blogs.technet.com/b/askperf/archive/2009/02/24/window...

Reply on news.ycombinator.com