Apple updates DTrace... again

Back in January, I ranted about Apple's ham-handed breakage in their DTrace port. After some injured feelings and teary embraces, Apple cleaned things up a bit, but some nagging issues remained as I wrote:

For the Apple folks: I'd argue that revealing the name of otherwise untraceable processes is no more transparent than what Activity Monitor provides — could I have that please?

It would be very un-Apple to — you know — communicate future development plans, but in 10.5.5, DTrace has seen another improvement. Previously when using DTrace to observe the system at large, iTunes and other paranoid apps would be hidden; now they're showing up on the radar:

# dtrace -n 'profile-1999{ @[execname] = count(); }'
dtrace: description 'profile-1999' matched 1 probe

  loginwindow                                                       2
  fseventsd                                                         3
  kdcmond                                                           5
  socketfilterfw                                                    5
  distnoted                                                         7
  mds                                                               8
  dtrace                                                           12
  punchin-helper                                                   12
  Dock                                                             20
  Mail                                                             25
  Terminal                                                         26
  SystemUIServer                                                   28
  Finder                                                           42
  Activity Monito                                                  49
  pmTool                                                           67
  WindowServer                                                    184
  iTunes                                                         1482
  kernel_task                                                    4030

And of course, you can use generally available probes to observe only those touchy apps with a predicate:

# dtrace -n 'syscall:::entry/execname == "iTunes"/{ @[probefunc] = count(); }'
dtrace: description 'syscall:::entry' matched 427 probes

  pwrite                                                           13
  read                                                             13
  stat64                                                           13
  open_nocancel                                                    14
  getuid                                                           22
  getdirentries                                                    26
  pread                                                            29
  stat                                                             32
  gettimeofday                                                     34
  open                                                             36
  close                                                            37
  geteuid                                                          65
  getattrlist                                                     199
  munmap                                                          328
  mmap                                                            338

Predictably, the details of iTunes are still obscured:

# dtrace -n pid42896:::entry
dtrace: error on enabled probe ID 225607 (ID 69364: pid42896:libSystem.B.dylib:pthread_mutex_unlock:entry):
  invalid user access in action #1
dtrace: error on enabled probe ID 225546 (ID 69425: pid42896:libSystem.B.dylib:spin_lock:entry):
  invalid user access in action #1
dtrace: 1005103 drops on CPU 1

... which is fine by me; I've got code of my own I should be investigating. While I'm loath to point it out, an astute reader and savvy DTrace user will note that Apple may have left the door open an inch wider than they had anticipated. Anyone care to post some D code that makes use of that inch? I'll post an update as a comment in a week or two if no one sees it.

Update: There were some good ideas in the comments. Here's the start of a script that can let you follow the flow of control of a thread in an "untraceable" process:

#!/usr/sbin/dtrace -s

#pragma D option quiet

	trace("this program is already traceable\\n");

/self->level < 0 || self->level > 40/
	self->level = 0;

	this->p = ((dtrace_state_t \*)arg0)->dts_ecbs[arg1 - 1]->dte_probe;
	this->mod = this->p->dtpr_mod;
	this->func = this->p->dtpr_func;
	this->entry = ("entry" == stringof(this->p->dtpr_name));

	printf("%\*s-> %s:%s\\n", self->level \* 2, "",
	    stringof(this->mod), stringof(this->func));

	printf("%\*s<- %s:%s\\n", self->level \* 2, "",
	    stringof(this->mod), stringof(this->func));

Well, well... pthread_mutex_unlock:entry, and spin_lock:entry, is it?

\*SIGH\* buying an Apple product was one of the biggest computing mistakes I ever made... And even if does happen again, the first thing I will be doing is wiping Apple Computer OS X and installing Solaris on there.

Oh, and if you changed all the blue in Aqua to Pink, you could see that the fascist OS X is really a Barbie toy, but not much more than that.

Posted by UX-admin on October 04, 2008 at 07:49 AM PDT #

@UX-admin That last bit of output was a bit misleading: I elided thousands of lines of similar text. I'm not sure I agree with your conclusions about Apple, but I certainly understand where you're coming from.

Posted by Adam Leventhal on October 04, 2008 at 08:06 AM PDT #


Great blog !
They just need to make ZFS damm usable, It can't be _that_ hard to port ZFS to be workable by now considering there resources. FreeBSD is almost there and just needs to make things a little more stable for production use.

Best Regards,
Edward O'Callaghan.

Posted by EdwardOCallaghan on October 04, 2008 at 08:36 AM PDT #

Hmm. If syscall::: is kosher, I imagine you can intercept communication with the sound server. On linux you'd be looking for the payload of writes to /dev/dsp; maybe for mac is it's some mach'ed out port rpc thingy, but the principle is the same.

Posted by kma on October 04, 2008 at 04:19 PM PDT #

AHL you don't necessarily have to agree with me (;-)

I simply found out, the hard way, that the stuff \*I\* needed for my day-to-day computing activities was NOT in OS X, but instead in something called "OS X server", at which point it's way cheaper and simper for me to go back to, and stick with Solaris. (Surprise!, surprise!)

But be that as it may, if I were cracking this thing, I would hook myself on to "libSystem.B.dylib", as that seems to me the place to start digging.

(I thought we lived in a world where cracking software was obsolete. Thanks a whole bunch uncle Steve for proving me wrong!)

Posted by UX-admin on October 05, 2008 at 01:31 AM PDT #

@kma Unsurprisingly, you're thinking too hard. It appears that an error is generated every time a pid provider probe is hit, but this doesn't make processes as untraceable as I think was intended.

Posted by Adam Leventhal on October 05, 2008 at 03:18 AM PDT #

What about those 'Probe ID' values?

"The probe ID is the system-wide unique identifier for the probe as listed in the output of dtrace -l." I would guess that may be a bit of an open door?

Posted by Nigel Smith on October 06, 2008 at 02:23 AM PDT #

Hmm, since the pid provider mostly just lets you know when a subroutine is entered and exited, and the errors being spewed by the pid provider above give you the same info...

Seems like a little scripting could reduce the error messages into working information about the what routines are being called. Probably harder or impossible to get useful info like how much time was spent in each routine, but still could be some good stuff.

Posted by Peter Galvin on October 06, 2008 at 03:38 AM PDT #

@Nigel, Peter You're both spot on. In fact it should be quite possible to determine how much time was spent in various functions. Anyone care to distill that idea to D? It's a bit tricky.

Posted by Adam Leventhal on October 06, 2008 at 04:11 AM PDT #

For those of you still paying attention: I updated this post to include the details of how to extract data from an obfuscated process.

Posted by Adam Leventhal on October 13, 2008 at 04:53 PM PDT #

Post a Comment:
Comments are closed for this entry.

Adam Leventhal, Fishworks engineer


« June 2016