Well it’s been a while since I’ve posted and I apologize for that. I do have some ideas for posts “in the hopper” but I haven’t had a chance to sit down and really work on them. I’m hoping with some “life changes” coming up this year I’ll have the opportunity to write more. But we’ll see.
Anyway, I was looking for an easy way to mount VMDK files on my Linux box so I could do forensic analysis on the images. Similar to how I’ve done things in the past with E01 files. I didn’t really want to image the VM and then analyze it, since most of the time I’m using VM’s for testing.
So this will be short and sweet, but first a couple of caveats:
1) I have not tested this against split VMDK files yet, but I’m thinking it should work.
2) I haven’t even considered testing this against VM snapshot images, but I’m guessing that will not work.
3) You need to have AFFLIB installed and working
That being said, this post was inspired by Sketchymoose’s post…
She talks about downloading the Virtual Disk Development kit, but one item in the post caught my eye:
“I first discovered I had to add the ‘-i aff’ parameter to get mmls to determine the disk structure of the vmdk file.”
I thought hey, there’s affuse!
affuse <vmdk file> /mount/point
ex: affuse windows7.vmdk /mnt/aff
mmls -t dos <mount point>/<vmdk file name>.raw
ex: mmls -t dos /mnt/aff/windows7.vmdk.raw
mount -o ro,loop,show_sys_files,streams_interface=windows,offset=<offset> <mount point>/<vmdk file>.raw /mount/point
ex: mount -o ro,loop,show_sys_files,streams_interface=windows,offset=1048576 /mnt/aff/windows7.vmdk.raw /mnt/windows
And voila! /mnt/windows now contains the file structure of the VMDK image!
I’m sure someone else figured this out, but a google search didn’t come up with anything when I added AFF to the search query (for me at least). So I thought I would share…
Also, keep in mind you can still use the -i AFF with TSK and VMDK images if you don’t need to mount it…
Filed under: Uncategorized | 12 Comments
Well I’m back once again….
I’m trying to plan out posting entries every month or two (probably closer to every two as some people will tell you :p). But I wanted to at least get an update out from my last/first post.
First off, Rob Lee was kind enough to point out that one of the steps in my process:
losetup –o32256 –r /dev/loop0 /mnt/ewf/foobar_image
isn’t really needed. You can skip this step and just use the mount command with the bytes offset option instead:
mount /mnt/ewf/foobar_image /mnt/windows_mount –o loop,ro,show_sys_files,offset=32256
I’m not sure why I used the losetup the first time I ever did this (aside from reading it originally on Stephen Venter’s Blog post), but I have removed that part from my process since then and it works fine. Thanks for that info Rob!
Now, there was one part of Rob’s SuperTimeline process that I was never able to figure out how to do with an e01 image. Specifically using fls on it. What I would do in the past is takethe e01 image and load it into FTK imager and create a DD image from it. Then I would run fls against the DD image. But that’s a lot more time then I want to spend for only one part of my timeline creation process, AND it means I now have one more copy of my image. So I did a bit more reading on the man page for fls and discovered the -i option:
-i imgtype -> Identify the type of image file, such as raw or split. Use ’-i list’ to list the supported types. If not given, autodetection methods are used.
So of course I did a fls -i list and discovered there is a ewf option you can pass to the -i switch!
Which lead me to this:
fls -r -i ewf -o (offset to start of partition, ex 63) -m c: /path/to/e01/segments.e* >> /export/path/to/bodyfile
and voila! I get fls output against my e01 image. Note that you have to point this command to the e01 segment files, NOT the image that you mounted.
And now, I can do Rob Lee’s SuperTimeline the E01 way! If anyone is interested in a post about all the steps I go through with an E01 image to create my timelines, leave a comment below. I’ll be happy to make a post on that as well (but I’ll warn you it pretty much steps through Rob’s method).
Filed under: Digital Forensics | 4 Comments
(ok not really, but that stuck with me for a title)
So I’ve finally gotten around to starting up a blog again. I decided (with some pushing from my friend Dave Kovar – who makes a very nice python script called analyzeMFT, you should check it out) to do my first post on using E01 images in the SANS SIFT Workstation VM.
This came about primarily because most of the documentation for SIFT talks about using DD images. Which is fine, I don’t mind DD images at all, however my current “place of employment” requires that I use E01 images in my casework. So I had to do some digging in order to create timelines using SIFT. I prefer creating timelines using the SuperTimeline method because it’s what I’m used to, and for me it’s easier to read.
So here’s my setup, I have all my evidence for my case on a TrueCrypt’d eSATA Desktop Drive, attached to my forensic workstation with an eSATA dock. All the Evidence images are in a folder called Evidence, and any data I’m going to export out of SIFT I’ll put in my Export folder.
So I start up VMware Workstation and fire up SIFT. Once I log in and get to the desktop the first thing I’m going to do is go to VM->Settings (Ctrl-D)->Options and then Shared Folders. I always set this to “Enabled until next power off or Suspend” just so I force myself to “enable” the connection to my eSATA disk. And if I move on to another case/project I can start fresh again. Next I’ll add my Evidence and Export directories as separate folders. The Evidence folder I’ll check the read-only attribute, because there’s really no reason for me to write to that folder.
Once that’s done I can confirm the folders are there by clicking on the VMware-Shared-Drive icon. One note is that the VMware-Shared-Drive shortcut is a soft link to the /mnt/hgfs directory.
For the purposes of this post, we’ll call my image that I’m mounting “foobar_image.E01”….
Ok, first we’re going to start off with the mount_ewf.py script to mount the image on the system. We’re dealing with an image that is split, so the command we’ll use is:
mount_ewf.py /mnt/hgfs/evidence/foobar_image.E* /mnt/ewf
Now there’s already some mount points set up in SIFT, and since we’re only working with one image there’s no need to create additional subdirectories in the /mnt directory.
Next we need to look at the image partition layout to determine where the volume on the disk starts.
fdisk –lu /mnt/ewf/foobar_image
and you’ll get an output that looks something like:
Device Boot Start End Blocks Id System
/mnt/ewf/foobar_imagep1 * 63 68281919 34140928+ 7 HPFS/NTFS
Partition 1 has different physical/logical endings:
phys=(1023, 239, 63) logical=(4515, 239, 63)
/mnt/ewf/foobar_imagep2 68281920 78140159 4929120 12 Compaq diagnostics
Partition 2 has different physical/logical beginnings (non-Linux?):
phys=(1023, 0, 1) logical=(4516, 0, 1)
Partition 2 has different physical/logical endings:
phys=(1023, 239, 63) logical=(5167, 239, 63)
Ok, so based on this output we have two partitions in this image. One is a diagnostic partition the other is a HPFS/NTFS file system. So foobar_imagep1 is the one we are interested in. What we now need to calculate is the offset in bytes to where that partition starts. To find that we take the “Start” value of foobar_imagep1 and multiply it by 512 (for 512 bytes per sector). Keep in mind that newer drives are starting to use a larger bytes per sector value (3TB and some 2TB drives that I’ve seen).
Ok, so next is to mount the image to a loopback device so we can then mount the partition and work with it:
losetup –o32256 –r /dev/loop0 /mnt/ewf/foobar_image
The –o switch is for the byte offset, and the –r switch is to mount it read only.
Once this part is done, we can go ahead and mount the partition. Keep in mind that we want to mount it so we can see the “hidden” system files associated with the file system ($MFT, etc).
mount /dev/loop0 /mnt/windows_mount –o loop,ro,show_sys_files
Now do an “ls –l” on /mnt/windows_mount and you should see the volume file system (and the hidden system files as well).
Finally, once we’re done using this image, what is the proper way to unmount it all? Well, it’s actually a three step process.
First we unmount the volume from the /mnt/windows_mount point.
Next, we remove the link between the loopback device and the image.
losetup –d /dev/loop0
Finally we unmount the E01 image.
And we’re done.
Please note you may have to do some tweaking with some of these steps. Most of the time the steps have worked for me, but there will be instances where the offset for the volume is different (for example). Remember that the “man” pages are available for most of the commands used here if you need to fine tune any parts of this process. You can also mount multiple images all at the same time, you just need to change/increment the /dev/loop values (/dev/loop1, /dev/loop2, etc) and add additional directories to mount the images to.
If any of you have suggestions on how to improve this process I’d love to hear about it.
Again I’d like to thank the following for making this blog post possible:
Filed under: Digital Forensics, VMware | 8 Comments