Document Mac OS X Setup about cuckoo-osx-analyzer

[phretor]

I've been using unmodified hackintosh ISOs, which boot and install nicely on both modified KVM/QEMU (http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/) and unmodified VirtualBox.

The only additions I used were:

1. analyzer/darwin/bin/fslogger
2. analyzer/darwin/kext/pt_deny_attach/

tar jxf pt_deny_attach.tbz
sudo mv pt_deny_attach.kext /System/Library/Extensions/pt_deny_attach.kext
cd /System/Library/Extensions/
sudo chmod -R 755 pt_deny_attach.kext
sudo chown -R root:wheel pt_deny_attach.kext
sudo echo "kextload -v 0 /System/Library/Extensions/pt_deny_attach.kext" >> /etc/rc.local
chmod a+x /etc/rc.local

[rodionovd]

@phretor yeah, pt_deny_attach-disabler kext is useful if we need to attach a debugger to a target.

---

Regarding dtrace

Since dtrace requires root's privileges to run, we also want to enable the default user to run it (as well as some dtrace wrappers like dtruss or iosnoop) without prompting for a root password. I guess this could be done by editing the local sudoers file (replace username with actual user name):

--- a/etc/sudoers
+++ b/etc/sudoers
@@ -43,3 +43,5 @@ root  ALL=(ALL) ALL
 # Samples
 # %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
 # %users  localhost=/sbin/shutdown -h now
+
+ username   ALL=(root) NOPASSWD: /usr/sbin/dtrace
+ username   ALL=(root) NOPASSWD: /usr/bin/dtruss
+ username   ALL=(root) NOPASSWD: /usr/bin/iosnoop

[phretor]

Good point about /etc/sudoers, @rodionovd.

Regarding pt_deny_attach, AFAIR, it is a good idea to have to avoid anti-dtrace binaries as well. Moreover, it would be a good way to see if a sample is evading analysis (e.g., run dtrace w/ and w/o the kext and check the differences).

Also, are we assuming that we want to start the sample via dtrace fork? What I see is:

1. sudo dtrace [options] /path/to/sample:
   • CONS: implies that sample will run with high privileges
   • PROS: we don't miss anything
2. sudo /path/to/sample, take PID, attach dtrace to it + /path/to/sample, take PID, attach dtrace to it
   • CONS: we may miss the first syscalls (taking the PID and attaching dtrace takes some time)
   • PROS: we can compare sudo-launched vs non-sudo-launched sample

Since OS X has sandboxed processes, the sudo vs non-sudo perspective is interesting. However, I expect that most of the sample won't work without sudo. Just brainstorming.

[rodionovd]

@phretor

Moreover, it would be a good way to see if a sample is evading analysis (e.g., run dtrace w/ and w/o the kext and check the differences)

Ah, good point!

Also, are we assuming that we want to start the sample via dtrace fork?

Hmm, yeah I see. So when we run $ sudo dtrace -s foo.d ./sample our target is going to be launched as root…

Well, what about a wrapper around dtrace (or some sort of .d script) that would follow children processes of the target? So we can do something like this:

$ sudo dtruss -f sudo -u `whoami` ./sample

(dtruss already has an option for this: -f : follow children as they are forked)

I've just tried this approach and it kinda worked: it yields some garbage output from sudo -u itself. I guess there's a way to mute it, though.

[phretor]

@rodionovd - makes sense.

About using DTruss directly vs. launching DTrace supplying a D script that we ship with the analyzer: the first option is readily available, the second option gives us more customization power in the future. Which one do you think we should follow?

[rodionovd]

@phretor well, dtruss is actually just a script too, so we can always replace it with our own implementation. Also, it handles lots of edge-cases, so at least we should copy-paste it into our own script in the future :-)

[rodionovd]

See also my bootstrap_guest.sh and bootstrap_host.sh setup scripts.

[rodionovd]

So I close this issue now, feel free to re-open it if you still have any questions.