1

An interesting feature in the new iTunes is it's inability to accept debugger processes that are attached to it (crippling tools like F-Script) Not only would this involve a detection method, but it would require some kind of process that was either checking for the debugger attaching itself mid-run, or an entry-point method that the debugger would emit when it attempts to attach itself. In addition, it would need a way to tell the debugger to go away (as it were) without terminating the process. The question is: How? Clearly, polling for a debugger every X number of seconds is inefficient, and not allowing it to attach to a given process (sans override like ptrace()) seems intensely private.

CodaFi
  • 43,043
  • 8
  • 107
  • 153
  • This isn't a new feature at all; it's been true for iTunes since Apple brought out the store (good lord, almost a decade ago now). The usual supposition is that it's required by Apple's contracts with music publishers as a hurdle to reverse engineering the DRM. The authors of dtrace were pissed when they learned about it: https://blogs.oracle.com/ahl/entry/mac_os_x_and_the – jscs Jan 25 '13 at 06:21

1 Answers1

4

iTunes is calling ptrace(PT_DENY_ATTACH) which sets the P_LNOATTACH flag which stops debuggers (and other processes, e.g. F-Script and DTrace) from attaching to the process.

See Is it possible to conceal a OS X app from DTrace? for more information.

I wouldn't be surprised if iTunes is also actively using detection methods to identify debuggers. Apple have gone to great lengths to try to protect the DRM in iTunes.

There are a number of books that have methods of securing Cocoa applications, including detecting debuggers. Some potential titles that spring to mind (I haven't double checked the contents of these so don't assume they have detection methods): "Mac Hacker's Handbook", "Hacking and Securing iOS Applications", "Professional Cocoa Application Security" and "Secure Programming Cookbook for C & C++".

"Mac OS X Internals" and "Mac OS X and iOS Internals" might have something on PT_DENY_ATTACH.

Community
  • 1
  • 1
mttrb
  • 8,297
  • 3
  • 35
  • 57
  • +1 Thanks, I didn't see that. It's rather the other methods that you mention that I'm interested in. Seems they would know about a thing as simple as breaking ptrace. – CodaFi Jan 25 '13 at 04:07
  • I've added some potential books that talk about detection methods. – mttrb Jan 25 '13 at 04:15
  • Answering this question led me to investigate the kernel module that disables the `P_LNOATTACH` process flag. I attempted to update the module to Mountain Lion which ultimately failed due to write protected memory but I did work around the issues created by Kernel Address Space Layout Randomisation. A blog post on the details can be found at: http://www.blendedcocoa.com/blog/2013/02/16/failing-to-update-the-pt_deny_attach-kernel-module-for-mountain-lion/ – mttrb Feb 16 '13 at 06:08