Duplicating forensic images by splitting a RAID1

It is considered very good practice to make two copies of any image collected, particularly in the field. On one very long collection trip we did this by collecting to one set of drives during the day and running Robocopy over night to duplicate the image set. FTK allows writing to two destinations, and the various versions of dd have always allowed this via one means or another. But these all require either time or precious IO bandwidth.

So, I thought, is there any way to create two images in real time without pushing the data down the pipe twice? Isn’t that what RAID1 is supposed to provide? But, are two drives in a hardware RAID 1 *really* identical? Turns out, that at least in my test case, they are.

I bought a  vAGE220-SAU two drive, USB 2.0/eSATA, RAID0/1 external enclosure. ($275 @ Amazon.)  It’s fairly well constructed, compact, and easy to use. The instructions weren’t clearly translated but were sufficient unto the task. Once I flipped the dip switches correctly and waited a few hours for it to do the initial mirroring, I was good to go.

I hooked my source drive up to one port on my field laptop’s eSATA card and the RAID enclosure up to the other one. Fired off FTK (but dd, or EnCase, or whatever would have done just as well.) Imaged the drive and it ran at near expected speeds. The process finished and the image was verified.

Now the test. I pulled both drives and hashed them via a writeblocker. The hashes matched. I had two identical, forensically sound, images of my source drive. This required less time that imaging to two destinations using the hardware available on my field laptop, and a lot less time than running a copy overnight.

I need to try this a few more times and do some more performance measurements, but I’m pretty happy with the outcome. I wish there was a drop in drive dock with RAID1 capability. That would eliminate the need to open the enclosure up when changing disks.

Advertisement

analyzeMFT – a Python tool to deconstruct the Windows NTFS $MFT file

Three elements combined last week to inspire me to write a tool to deconstruct the Windows NTFS $MFT file:

1. I’ve been wanting to learn Python for quite awhile. (I found a “Learning Python” book on my shelf published in 1999.
2. Mark Menz’s MFT Ripper started me wondering about the significance of the MFT sequence number.
3. I’d been trying to get through the SANS 508.1 book but couldn’t bear to read about NTFS structures yet again.
4. I wanted to start building a framework for doing more detailed timeline analysis.

So, last week I sat down and wrote analyzeMFT.py.  Please keep in mind that this is a novice Python programmer’s code and is definitely a work in progress. A simple project page and a link to the source can be found here.

If you have any comments, suggestions, or improvements, please do let me know. I’d like to keep building on this and making it as useful as possible.

Using Python to parse and present Windows 64 bit timestamps

I’m working on learning Python since Perl, even after 20 years, still doesn’t stick in my head. The phrase “like a duck to water” doesn’t quite apply to my experience with Python, but I’m certainly swimming along nicely.

Since I learn languages and tools more effectively when I have a real problem to work on, I set out to parse the NTFS MFT record using Python. This was going swimmingly until I hit the file MAC times. According to Microsoft:

“A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).”

So, two problems: 1) It is a 64 bit value and python only has 32 bit longs and b) it doesn’t use the Unix definition of epoch.

After a lot of false starts, I learned the power of dictionaries and classes and came up with the following:

from datetime import date, datetime

class WindowsTime:
    def __init__(self, low, high):
        self.low = long(low)
        self.high = long(high)

        self.unixtime = self.GetUnixTime()
        self.utc = datetime.utcfromtimestamp(self.unixtime)
        self.utcstr = self.utc.strftime("%Y/%m/%d %H:%M:%S.%f")

# Windows NT time is specified as the number of 100 nanosecond intervals since January 1, 1601. 
# UNIX time is specified as the number of seconds since January 1, 1970. 
# There are 134,774 days (or 11,644,473,600 seconds) between these dates.
    def GetUnixTime(self):
        t=float(self.high)*2**32 + self.low
        return (t*1e-7 - 11644473600)

I have a module that defines a dictionary and parses chunks of data read from the MFT:

# Decodes the Standard Information attribute in a MFT record
def decodeSIrecord(s):

 d = {}
 d['crtime'] = WindowsTime(struct.unpack("<L",s[:4])[0],
                           struct.unpack("<L",s[4:8])[0])
 ...

Then just do:

SIobject = decodeSIrecord(data)

And you can print the times out directly from the dictionary:

print "CRTime: %s" % (SIobject['crtime'].utcstr)

This isn’t rocket science, and there’s probabaly a better way to do it, but if you’re trying to use Python to work with Windows filesystems and metadata, this could come in handy.

CRU DataPort (Wiebetech) USB Writeblocker Quick Review

I bought this months ago as it seemed like something that would be really useful to own. Then I got busy and it sat until someone asked me about doing a review. I pulled the unit out and immediately attached it to a WD 320GB Passport. No go, not enough power. Wiebetech very promptly sent me a very well constructed dual USB cable to provide power and connectivity. Good to go, or so I thought.

I really want this thing to work, and it just doesn’t.

1. It doesn’t work at all with OS X. (Correction: It works once, but subsequent drives are not recognized.)
2. The drivers failed to install on Windows 7. It looks like this can be addressed with a certain amount of “reset and reboot”. (Rebooting and reinstalling cleared the problem. It works with Windows 7 32bit and 64bit.)
3. It requires a lot of “fiddling” to get it working on XP. Sometimes you need to hit the reset button, sometimes the order that you plug things in matters, and all too often you need to reboot your system.
4. It doesn’t work with EnCase at all. EnCase locks up trying to read the first two sectors of the device. If you hit the reset button, EnCase returns an error and drops back to the GUI so it isn’t completely locked up, but you cannot add any evidence attached to the write blocker. X-Ways, FTK Imager, and FTK all work, taking the “fiddling” into account. (This is an EnCase v6.15 problem. If you turn off “Detect FastBloc”, EnCase v6.14 and .15 recognize the device.)

I tried it with FAT and NTFS formatted thumb drives as well as the WD 320GB Passport – same results.

The packaging is great and the concept is good but it simply doesn’t work consistently enough or with enough operating systems to make it worth adding to my kit.

Since posting this, I’ve spoken with several other users. Some have experiences very similar to mine, some haven’t had any issues at all. I’m also talking with CRU-DataPort and they’re actively working through identifying and fixing the problems. I’ll hang on to my unit and hope they get these problems sorted out soon.

Updates:

1. The USBWB apparently works with versions of EnCase prior to V6.14.
2. Disabling “Detect FastBloc” in the later versions of EnCase allows. EnCase to successfully recognize the USBWB attached drive.
3. USBWB doesn’t work on OS X 10.4, does work on 10.5, and hasn’t been tested on 10.6. It seems to work once on 10.6 but not with subsequent drives, at least not without a reboot.
4. USBWB works on Windows 7 64bit after a reboot. Drivers fail to install, reboot, drivers install.