Macintosh Forensic Acquisition

Recently the Mac OS X Forensics site has been amassing a wealth of information on acquiring and analysing Macintosh OS X computers. Additionally, the “Inside the Core” podcast has made a strong start at presenting similar and related content as a podcast. Both teams deserve congratulations and encouragement for their contributions.

One problem that I have observed with acquiring Macs is a particular problem with some Apple keyboards that have a brushed aluminium appearance. They will not reliably allow one to boot to CD or target mode using option keys, due to (purportedly) a firmware bug. The result of this can be an unplanned booting of the hard disk in the computer, and resulting modification of the state of the disk.

I haven’t observed this problem with any other Apple keyboards. Forensic practitioners may want to consider making it a part of your practice to ensure that you are booting with a non aluminium keyboard.


Paper on new evidence container format accepted for presentation at DFRWS2009

Michael Cohen, Simson Garfinkel and I have been collaborating recently on the development of a new digital evidence storage container format. Today we have had notification that a paper detailing the research behind this development has been accepted at the 2009 Digital Forensics Research Workshop, to be held in Montreal Canada. The title of the paper is “Extending the Advanced Forensic Format to accommodate Multiple Data Sources, Logical Evidence, Arbitrary Information and Forensic
Workflow”.

A new evidence container is sorely needed by the computer forensics community, due to the large amount of manual work currently required in managing evidence and the closed nature of the current generation of forensic containers and tools. With this new forensic container, we provide an open and extensible container standard which promotes forensic tool interoperability and simplifies evidence sharing and management.

Technically, this new container achieves these things by enabling:

  • efficient random access storage of multiple streams of digital evidence within a single container;
  • storage of arbitrary information such as case relevant information or tool derived analysis results;
  • composition of evidence containers into a larger corpus of related evidence through an inter container referencing scheme;
  • decomposition of evidence containers into sets of smaller containers to support filesystem limitations;
  • definition of virtual evidence streams as maps of existing evidence streams.

The new format is slated to replace the current generation of Simson’s Advanced Forensic Format (AFF) and will be known as AFF4. Michael has been providing some documentation on the format over at the forensicswiki, and he has a beta quality implementation in the C language. Plans are in place for a JAVA based parallel implementation.

The abstract follows:

Forensic analysis requires the acquisition and management of many different types of evidence, including individual disk drives, RAID sets, network packets, memory images, and extracted files. Often the same evidence is reviewed by several different tools or examiners in different locations. We propose a backwards-compatible evolutionary redesign of the Advanced Forensic Format—an open, extensible file format for storing and sharing of evidence, arbitrary case related information and analysis results among different tools. The new specification was designed to be simple to implement, allowing the use of the well
supported Zip File format specifications for bit level file access.

UPDATE: The paper is now published on the DFRWS 2009 website.


dd2vmdk relocated into the cloud

A while ago I wrote a tool to convert flat disk images (which we commonly call dd images) to VMWare .vmdk disk images (the original blog post on the tool, called dd2vmdk is posted here). I have in the mean time ceased development of it, but despite its relatively archaic nature, some still find it of use.

Today I relocated hosting of it to Google’s new cloud web application service, Google App Engine. My motivations to do this were to reduce adminitrative burden, to eliminate server costs, and to increase long term availability (the Java App Engine is Beta, so there might be some short term availability issues).

The relocation took roughly one hour of my time, was dead simple, and required no code modification, just the simple addition of a new text configuration file.

dd2vmdk is still available via my personal website.


New tool – CERT/CMU Live View

I am in Lafayette, Indiana this week at DFRWS2006. A gent from CERT was present and demonstrating an excellet tool called “Live View” which, from first impressions to be a p2v GUI that automates running dd images in vmware. It appears that the features of it are far beyond what dd2vmdk does in some respects: you appear to point it at an image upon which it:
* generates a vmware vmdk
* generates a corresponding virtual machine definition
* fixes up the driver boot problem
* optionally lets one set the time to a different value.
* automatically boots up the image in vmware

On the downside, it doesnt appear to handle disk images, just partition images. This introduces further complications such as having to specify the OS used, and remapping of drive letters, which they do however handle. I am not convinced that their insistence of replacing the MBR is necessary either.

When I get back from DFRWS I will be testing if it does handle disk images, and if it does, how it copes with geometry problems and LDM.


tool – pasco2

I am off to the DFRWS 2006 conference in a week or so to present my paper “A correlation method for establishing provenance of timestamps in digital evidence”. In this paper I describe some research I have performed in characterising where the behaviour of computer clocks differs from the ideal.

A second theme of the paper is the identification of methods of correlating commonly found evidence to establish provenance of timestamps. In this case, I have been correlating Internet Explorer Cache and History files with Squid cache logs.

As a part of my work I reimplemented and extended a parsing tool for the IE cache and history index.dat files. This was due to finding bugs in the initial pasco tool (which was missing some error conditions from the read() system call). That and I am more productive using java.

The tool, which I have named pasco2 in honour of Keith Jones’ earlier IE parser, pasco , can be found here: pasco2.


dd2vmdk – dd Image to VMWare Virtual Disk converter

While performing the last set of investigations, I have produced a simple web based application for automating the conversion of dd images into VMWare Virtual Disks. I have called this tool dd2vmdk – it is accessable at http://www.bschatz.org/2006/p2v/index.html

Currently the tool carves up the image into a virtual disk composed of a number of files, where partitions are contained individual files. The next version of the tool will support directly modifying the partition table and NTFS boot record in-situ within the image file.


P2V – Will the 2K MBR boot up a non cylinder aligned partition?

I left my last post unsure whether of not a PC can boot into a partition that is not aligned with the beginning of a cylinder boundary. I devised a quick test, employing the same image that I have been using for the last two posts.

In this case, I left the partition table unmodified, but went into the NTFS boot record and adjusted its conception of the hard drive to reflect the Virtual Drive’s geometry. I got this:

Error Loading Opertating System.

If the bootable partition was the first on the hard drive, there may have been a chance for it to work, but since it is 73440 sectors in, the CHS values will be all wrong.

Recalling the original partition table as taken from fdisk is:

Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics
/dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS
/dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS
/dev/ida/c0d0p4 0 – 0 0 Empty

We regenerate the new partition table with sfdisk, setting the correct CHS values for the new virtual disk. (sfdisk recalculates the right CHS values for the start and end of the partitions based on geometry specified on the command line, and the sector offsets and sizes):

sfdisk -uS -C 4436 -H 255 -S 63 -f c0d0.dd << EOF
32,73408,12
73440,20481600,42,*
20555040,50526720,42
EOF

The image now boots correctly.

So, to answer my initial question. Yes, the MBR boot code WILL boot up a non cylinder aligned partition. Inside the OS the dynamic disk shows up as healthy and exactly as it was in the original physical machine.


P2V – hard drive geometry problems

I have been trying to convert a physical Windows 2000 server running on SCSI RAID to run inside a virtual machine. Given my interest in digital evidence, I was interested in achieving the conversion (which is popuarly referred to as Physical To Virtual or P2V conversion) from first principles.

A while ago I came across the Windows Dynamic Disk partitioning scheme (also called Dynamic Disk or LDM). It’s support under linux is slowly gaining momentum, but still remains a bugbear for manipulating disks. So just to complicate things, I decided to convert the physical host’s drive to using Dynamic Disks.

My proposed methodology was as follows:
1. Use a live CD (helix) to acquire the source drive to a external SATA drive. This included recording the partition and disk geometry using the sfdisk program, recording the LDM partition information using the ldminfo tool from the Linux NTFS project, and imaging the drive using dcfldd.
2. Load the image onto the Linux host running VMWare Server.
3. Generate a VMWare Virtual Disk file which works with the image.
4. Create and configure a VM using the new virtual disk.
5. Fixup the drivers inside the VM using the Ultimate P2V method.

In practise this didn’t work as planned. What I was presented with was the following:

A blank screen with a non flashing cursor on boot.

Looking into the problem in more detail it appeared that the boot problem was due to a difference in disk geometry between the SMART2 RAID controller present in the the physical host and VMWare’s emulated SCSI hard drives. As it turns out VMWARE will only emulate a disk with 63 sectors per track, and 255 heads (the number of cylinders from this perspective is irrelevant). My RAID controller however presented a disk with 32 sectors per track, and the 255 heads. Fdisk showed me this:

Disk /dev/ida/c0d0: 8711 cylinders, 255 heads, 32 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/ida/c0d0p1 32 73439 73408 12 Compaq diagnostics
/dev/ida/c0d0p2 * 73440 20555039 20481600 42 SFS
/dev/ida/c0d0p3 20555040 71081759 50526720 42 SFS
/dev/ida/c0d0p4 0 – 0 0 Empty

Running sfdisk inside the virtual machine with this image resulted with a number of warnings about partitions not being aligned on cylinder boundaries.

It appeared that this problem was related to the differences in geometry between the two drives. On boot, the boot code in the MBR of the hard drive is looking inside the image at the wrong point. It appears that the Boot code can only boot partitions that are aligned on cylinder boundaries, ie. the start address of partitions must be fully divisible by heads*sectors. The differences between these means that the boot code is looking in the wrong place inside my image.

[Update: I am not sure about this after researching this some more... it appears that some old versions of DOS required that partitions be cylinder aligned, but the MBR boot code appears like it is independent of cylinder alignment.]


MACtimes oddness on CDROM filesystems

I have been looking at the MACtimes of files stored on CDROM’s recently. One thing that particulary struck me was the access time (the A in MAC) of files on a cdrom…

F:burntest>dir /ta *
Volume in drive F is My Disc
Volume Serial Number is 8181-A540

Directory of F:burntest

01/01/1601 10:00 AM <DIR> .
01/01/1601 10:00 AM <DIR&gt’ ..
01/01/1601 10:00 AM 34,304 LDM.doc
01/01/1601 10:00 AM 1,267 mailheaders.txt
2 File(s) 35,571 bytes
2 Dir(s) 0 bytes free

Did I reset the access time when I burned it?

No. From the quick skim of the ISOFS documentation, it appears that ISOFS contains no field to save the access time of a file in, which i expect makes sense if you are thinking of a filesystem as a read only medium.

I imagine that the windows CDFS implementation is simply returning the number 0 (64bit) to the upper level filesystem layers here for the accessed time. And what you see here, is 12 Midnight, 1/1/1601 (plus 10 hours as I am in Brisbane, GMT+10), which is the starting point of the windows clock.

Too bad if you are wanting it as a backup of a regular filesystem. From a forensic standpoint, you have lost all of those useful accessed times (not to mention the usual suspects like slack space, deleted files…)

Which brings me to validating some CD writing software, in this case, Nero 6. For my experiment, I will compare the mactimes of some files on a NTFS filesystem which have been burned to a ISOFS CDROM with Nero 6.

The creation times on the NTFS FS on C: and the ISOFS on F:

C:burntest>dir /tc *
Volume in drive C has no label.
Volume Serial Number is 8C26-C144

Directory of C:burntest

15/09/2005 07:44 PM <DIR> .
15/09/2005 07:44 PM <DIR> ..
14/08/2005 05:53 PM 34,304 LDM.doc
23/07/2005 08:54 PM 1,267 mailheaders.txt
2 File(s) 35,571 bytes
2 Dir(s) 9,896,013,824 bytes free

F:burntest>dir /tc *
Volume in drive F is My Disc
Volume Serial Number is 8181-A540

Directory of F:burntest

15/09/2005 07:44 PM <DIR> .
15/09/2005 07:52 PM <DIR> ..
14/08/2005 06:16 PM 34,304 LDM.doc
23/07/2005 08:55 PM 1,267 mailheaders.txt
2 File(s) 35,571 bytes
2 Dir(s) 0 bytes free

Huh?

C:burntest>dir /tw *
Volume in drive C has no label.
Volume Serial Number is 8C26-C144

Directory of C:burntest

15/09/2005 07:44 PM <DIR> .
15/09/2005 07:44 PM <DIR> ..
14/08/2005 06:16 PM 34,304 LDM.doc
23/07/2005 08:55 PM 1,267 mailheaders.txt
2 File(s) 35,571 bytes
2 Dir(s) 9,896,013,824 bytes free
F:burntest>dir /tw *
Volume in drive F is My Disc
Volume Serial Number is 8181-A540

Directory of F:burntest

15/09/2005 07:44 PM <DIR> .
15/09/2005 07:52 PM <DIR> ..
14/08/2005 06:16 PM 34,304 LDM.doc
23/07/2005 08:55 PM 1,267 mailheaders.txt
2 File(s) 35,571 bytes
2 Dir(s) 0 bytes free

It looks like Nero 6 likes to throw away the creation time, and replace it with the last modified time. Yet more data lost.