Most of the operating systems that are somehow related to UNIX are offering a possibility to read the kernel memory by using the /dev/mem or /dev/kmem interfaces. Thanks to this, the administrator can inspect memory in much greater details than (s)he normally would.

Unfortunately, from some reason, default installation of OS X has this mechanism disabled. I was quite glad when I've found out that it was actually a matter of enabling the feature, without the need of implementing my own device driver.

Depending on whether you're running OS X on a virtual machine, or natively, this can be done in different ways.

Native installation or VMware Fusion

In native/Fusion installation, enabling /dev/mem is a matter of invoking the nvram command with some arguments that define the command line for the kernel that is being used during system startup. You have to append the kmem=1 option to this command line. Before you modify it, make sure you don't overwrite anything. You can check what is the current command line by issuing this command:

$ nvram -p | grep boot-args

If the command won't display anything, it means that your command line is empty. That's normal, and you can just set your command line like this:

$ sudo nvram boot-args="kmem=1"

In case you'd already have something in your command line, you should copy everything as it were before, adding kmem=1 on the beginning or the end of the command line.

In case your machine won't boot, it may be possible to reset the NVRAM. Consider reading this apple KB article in advance to know how to cope with this situation.

VirtualBox

If you're using OS X on VirtualBox, the approach taken above won't work, because VirtualBox simply overwrites the boot-args variable. To fix this, you have to read the current boot-args variable the same way as above, and use VBoxManage to save it with kmem=1 directive.

Obtaining current command line is done from the guest:

$ nvram -p | grep boot-args

VirtualBox forced my command line to look like this: keepsyms=1 -v -serial=0x1. Let's get back to our host, and issue this command:

$ VBoxManage setextradata <vm_name> "VBoxInternal2/EfiBootArgs" "kmem=1 keepsyms=1 -v -serial=0x1"

You need to shut down your guest VM entirely, and start it again (please note that simply restarting the guest system won't suffice).

After restarting, you can verify that both /dev/mem and /dev/kmem now exist.

I've tested this on MacOS X Mavericks. It should also work on previous versions of the system, though there's no guarantee that it will work in the future.