I am working on a DBT framework that has some user space support. I do my main development in OS X and Linux, and so I have done some testing of it on OS X.
The main focus of the DBT tool is Linux kernel modules, but let me know the kinds of stuff you need it for and I can a) figure out if my tool is applicable, and b) perhaps share the code.
I need to know everything about that binary. How it works, what ports(unix domain & network sockets), files it opens on the harddrive, libraries it's linked to, how it decides what to do. Anything & Everything there is to know about it. ^_^
There are plenty of built-in performance/introspection tools in OS X that you can try first before resorting to a third-party solution:
1) What ports it opens:
- netstat shows you what ports a program has running
- DTrace shows you all syscalls a process makes (among other things). dtruss is a convenient wrapper script included in OS X which shows you all the syscalls a process makes (including opening sockets.
2) What files it opens
- Again, DTrace's syscall provider lets you introspect all syscalls, including open(). There's even a handy wrapper script included with OS X called opensnoop.
- Alternately, you can use the fs_usage command line tool to tap into the xnu kernel's trace mechanism. This shows all sorts of filesystem events, including what files are opened.
3) What libraries a binary is linked to
OS X binaries use the Mach-O format, not ELF like most other Unixes. So you have to use OS X's binary introspection tools to understand that format rather than the standard GNU binutils. What you're looking for here is otool, which lets you introspect Mach-O binaries. Specifically, "otool -L /Applications/Mail.app/Mail" for instance shows you which libraries Mail links to. Run this recursively to get the transitive closure of all dependencies a binary links against. Another way to do this is to run "vmmap -v <pid>" to show you the vm layout of a process, which includes the __TEXT/__DATA segments of all libraries the process links against.
And of course, gdb/lldb is included with the developer tools, you can just attach to whatever process you care about and set breakpoints, type "info sharedlib" to see what libraries are in the address space, etc. Also, for better or worse, Objective-C is an extremely dynamic language, so you can even do things like write a shared library with code you want to inject into a process (potentially monkey-patching existing methods using ObjC categories) and dlopen it from gdb to insert it into the target process's address space.
So, this might be naive, but for static information like the shared libs it's using, you might want to check out otool, and then pick up a good disassembler (I'm a fan of hopper, which is relatively cheap). For dynamic analysis you might want to check out the standard osx tools like netstat, and instrumentation tools like valgrind or gdb. gdb + breakpoints on choice system calls works pretty well on non-obfuscated binaries!
I'll have to try that out. So far I've tried iosnoop, lsof and dtrace to get an idea of what the program is up to. I did get a bit of info from those tools.
The main focus of the DBT tool is Linux kernel modules, but let me know the kinds of stuff you need it for and I can a) figure out if my tool is applicable, and b) perhaps share the code.