Wednesday, May 12, 2010

OSX RAM Acquisition


Acquisition of OS X RAM is a bit of a holy grail of memory analysis, quite simply because no-one has done it, or has admitted to it. It is always good form to realize that whatever we think of as secure has probably been undermined by Dark Forces working from bunkers under grassy fields, or desert, or tundra depending on your Government Agency of choice.

In Leopard there were some significant weaknesses in OS X RAM, well researched and documented by Dai Zovi (We're not worthy!) who demonstrated in 2009 a number of different attacks on the OS through the poorly implemented memory stack which enabled heap allocated memory to be executable, unlike Vista/7 etc - Windows more secure - who knew!!

Snow Leopard with its 64bit architecture has gone a long way to solve that. But with the incredible amount of information available from a Windows RAM dump it would be great to achieve the same from a Mac. Work has been done with DMA (Direct Memory Access) via Firewire which can theoretically work and some researchers had some success with Leopard but its all gone quiet with Snow Leopard. So where does that leave us?

Well, unless you are prepared to freeze the chips you need to acquire the RAM whilst the machine is live. On a Linux machine you can simply dd /dev/mem and /dev/kmem but no such luck with OS X.

For the time being our best bet is the OS X counterpart of hiberfil.sys. In Windows hiberfil is a file generated in the root of C when the PC is put into hibernate state. The resulting file can be converted into a raw RAM dump using either tools from Matthieu Suiche with the Sandman project or the version produced for Volatility. OS X has a similar file called sleepimage. You can see if your Mac has one at the moment by doing the following:-

Open terminal
Type - cd /var/vm
Type - ls

If your machine has been hibernated you should see a sleepimage file with a file size that is the same as your RAM.

If you come up against a running Mac and will be seizing it then it is possible to force the machine to create the sleepimage file.

Suggested 'Forensic' methodology:-

Open Terminal
Type - sudo pmset –a hibernatemode 1

When you shut the lid it now creates a hibernate file and shuts machine down rather than putting it into sleep mode. The problem is that it will likely ask for the admin password. You could run MacLockpick which will extract the Keychain and possibly give you the password you need.

Next, you need to set it back - sudo pmset –a hibernatemode 3

Shut the lid, take the machine.

Now simply image the drive as normal and extract the sleepimage file and analyze.

If you were doing a live data acquisition or search of the machine it is simply the case of plugging in a USB drive and typing:-

sudo cp /var/vm/sleepimage /Volumes/USBkey (Where USBKey is the name of your drive.)

Now the problems:-

Changing the hibernatemode makes a technical change to the machine.
The technique forces you to shut the machine down which is no good if you want the RAM live whilst leaving the machine running.
There are currently no tools available for the analysis of the sleepimage. The tools we use for Windows RAM analysis such as Volatility, Foremost, Memoryze etc do not work. Get coding!

This post is not desperately useful as it just explains how to get a pseudo-Ram dump out, what you then do with it is up to you. If you figure anything out I'd love to hear about it!

12 comments:

Unknown said...

Nick, I think the sleepimage is encrypted by default on Snow Leopard, might be worth checking system preferences before making the copy of the sleepimage file on Snow Leopard to confirm.

johnmccash said...

It's worth mentioning that Matthieu Suiche (blog at http://www.msuiche.net/) did a presentation on advanced MacOS X physical memory analysis at BlackHat DC 2010. Slides are available at http://www.msuiche.net/con/BHDC2010_MacOSX_PhysicalMemory.pdf
John McCash

Nick Furneaux said...

Dougee, johnmcash - thanks for your comments. Re RAM being encrypted I've not spent much time on it, however I have been able to recover some plist information on printer drivers in plain text suggesting that the sleepimage isnt encrypted, or at least fully encrypted.

Thanks for the Matthieu Suiche slides link, I put the link in to his new site but not to the BH slides. Either of you going to BH or Defcon this year?

Unknown said...
This comment has been removed by the author.
Unknown said...

Hi Nick,

I think we might both be right according to this Apple security document "Encrypted virtual memory is enabled by default for all current portable systems running Mac OS X".

I checked on my iMac and the default was off and my MacBook Pro was on, interesting stuff.

http://images.apple.com/macosx/security/docs/MacOSX_Security_TB.pdf

Sadly not going to either, are you? If so what about a stop over in Vancouver for a beer :)

dougee

Nick Furneaux said...

Thanks dougee, good find in the PDF, it seems that virtual memory can be encrypted on either, but as you rightly said the Apple powers that be seen to think that only portable OS's need it turned on by default - umm. Interesting area I think!

Planning to be at Defcon this year. Would love to catch a coffee in Vancouver, if I'm ever in town I'll drop you a line. I've got an old buddy there actually, Andy Joyce, do you know him? Good investigator.

Nick Furneaux said...

Thanks dougee, good find in the PDF, it seems that virtual memory can be encrypted on either, but as you rightly said the Apple powers that be seen to think that only portable OS's need it turned on by default - umm. Interesting area I think!

Planning to be at Defcon this year. Would love to catch a coffee in Vancouver, if I'm ever in town I'll drop you a line. I've got an old buddy there actually, Andy Joyce, do you know him? Good investigator.

thinkinginforensics said...

I've Snow Leopard v.10.6.4, and there's a problem: md5 code don't change, is it normal?


MacBook-di-peppespe:vm giuseppespecchio$ sudo pmset hibernatemode 1
MacBook-di-peppespe:vm giuseppespecchio$ ls -l
total 4325376
-rw------T 1 root wheel 2147483648 5 Ott 11:38 sleepimage
-rw------- 1 root wheel 67108864 6 Ott 07:55 swapfile0
MacBook-di-peppespe:vm giuseppespecchio$ sudo md5 sleepimage
MD5 (sleepimage) = 2ece03222977a07b115583191967f887
MacBook-di-peppespe:vm giuseppespecchio$ sudo pmset hibernatemode 3
MacBook-di-peppespe:vm giuseppespecchio$ sudo md5 sleepimage
MD5 (sleepimage) = 2ece03222977a07b115583191967f887
MacBook-di-peppespe:vm giuseppespecchio$ sudo pmset hibernatemode 1
MacBook-di-peppespe:vm giuseppespecchio$ sudo md5 sleepimage
MD5 (sleepimage) = 2ece03222977a07b115583191967f887

Nick Furneaux said...

Hi E io Pago

What you are seeing is correct. The hibernatemode command is changing the way OSX deals with the sleepimage it doesnt write to the sleepimage file itself, hence not changing the MD5.

Hope that helps

Nick

thinkinginforensics said...

I've tried your method, but I've again some uncertain.

1. I've applied your method:

$ pwd
/var/vm
$ sudo pmset -a hibernatemode 1
$ sudo pmset -a hibernatemode 3
$ ls -l
total 4325376
-rw------T 1 root wheel 2147483648 12 Ott 14:31 sleepimage
-rw------- 1 root wheel 67108864 13 Ott 08:28 swapfile0
$ sudo cp sleepimage /Users/giuseppespecchio/sleepimage

2: Through an hexadecimal editor (Hex Fiend) I've analyzed the content of sleepimage file, but I haven't found the content of a temporary file, where content was: "This is a not salved file, if I switch off the computer, I will lose the data."

Sorry for my broken english ;-)

Nick Furneaux said...

Peppespe

That is a good test. I am also struggling to recover text strings from the sleepimage. I've managed to get some plists and things but not content like I am used to in a Windows RAM image.

There is however a new possibility on the horizon to carry out a clean RAM dump, watch this space.

Nick

Unknown said...

Your post really cool and interesting. Thanks very much.

Acer - Aspire V5 Series 11.6" Laptop - 4GB Memory - 320GB Hard Drive - Black

Acer - Aspire 15.6" Touch-Screen Laptop - 8GB Memory - 500GB Hard Drive