Hacking Exposed

by Aaron Philipp

  Remember that in court, questions like “Isn’t it possible that…?” are fair game. Understanding your operating system is imperative. Since the chain is never stronger than the weakest link, an unknown and undocumented process running on a system does not avail you much and weakens your case. Clearly, you must be smart about how you approach, implement, and articulate your process and methodology in conducting a forensic investigation. Reducing the number of unknowns is a smart practice and a necessary part of your job.

  It’s Still Just 1’s and 0’s

  From a technical standpoint, quite a few aspects of the Macintosh OS make it different from Windows or other operating systems. But let’s review the similarities first, and then discuss the differences. Evidence collected from a Macintosh is no different from evidence collected from a PC, a Cray Supercomputer, or any other computer. It is digital evidence and is likely to exist in the same basic format and on the same types of media as any other digital evidence. The important concepts and attributes, such as chain of custody, quantifiable assurance of integrity, and preservation of best evidence, will still apply.

  A Disk Is a Disk

  Modern Macintosh computers generally use the same type of Serial ATA hard drives that are found in comparable PCs. An emerging trend is to use flash memory in lieu of rotating magnetic media. Although Apple has historically “branded” its OEM (original equipment manufacturer) hard disk drives, branding is an issue primarily when you’re running an older Mac OS and utilities. While some versions of Apple disk utilities will work only on Apple-branded drives, for the most part, the physical devices are interchangeable; you could put a disk from a Mac into a PC and vice versa. The branding is based on the controller firmware and serves to identify Apple “authorized” hard disk drives.

  Image Is Everything

  Disk drives from an Apple computer can be removed and duplicated in any of the ways that work with disks from PCs: hardware duplication, software duplication, cloning—after all, it’s just another disk at the device layer.

  If you don’t want to disassemble a laptop and remove the hard drive (and really, who does?), you could boot the Macintosh into FireWire disk mode. Most Macs that have onboard FireWire (IEEE 1394) allow you to hold down the T key during the boot process and place the computer into FireWire disk mode. When in this mode, the computer presents the internal primary master device as a FireWire device, similar to a Maxtor or other external IEEE 1394 hard disk drive.

  You can connect the Mac to another machine via the FireWire cable and image, view, and search normally. Alternatively, you can create a bootable CD-ROM or thumb drive designed to bring up the system to a minimal state and image via the NIC card, USB, or FireWire ports. When you’re imaging with a Windows computer, it cannot understand the HFS file system and thus will not be able to modify it; just don’t initialize the disk.

  Regardless of whether you use hardware or software, you should end up with, among other things, a bit image copy—a device clone or a segmented image that resides on a file system. You can use Windows tools, Linux/BSD tools, or Macintosh tools. (The Smart Acquisition Workshop (www.asrdata.com) is a user-friendly program that runs natively on Windows, Linux, and Macintosh.) Whatever tool you decide to use, you’re ready to start looking at the data and answering some questions.

  Never boot a Macintosh that contains evidence unless you know exactly what you are doing. The “normal” boot process changes data.

  LOOKING AT A MAC DISK OR IMAGE

  As with other rotating magnetic media, Macs have a partition map that points to various partitions on the drive. Partitions are logically contiguous ranges of sectors or blocks. Sectors are currently defined as 512 bytes for most rotating magnetic disks and thumb or flash drives.

  To help you better understand the Mac partitioning scheme, let’s review a Windows Master Boot Record (MBR) and partition map, both located in logical sector 0 of the device.

  A Windows MBR contains boot code, disk geometry information, and four buckets for primary partitions. Primary partitions can point to extended partitions, which give you four more buckets. Partitions within extended partitions may be conceptualized as belonging to the parent partition, which in turn belongs to the device. The device contains everything and describes how the disk is laid out right up front. The new Apple partitioning scheme (GUID Partition Table, or GPT) is much more flexible and extensible than Windows MBR partitioning.

  When we refer to a physical device, such as the Serial ATA rotating magnetic disks like those found in Mac desktop and laptop computers, we need to define some terms and concepts. For this discussion, let’s say that a device comprises n number of blocks, and that a block is a 512-byte sector on the device. If I have a 100 Gigabyte (107,374,182,400 bytes) hard drive, I have a disk with 209,715,200 sectors or blocks. Let’s see how the blocks on disk are laid out.

  The GUID Partition Table

  The first block on an Apple-formatted GPT device is the protective MBR. According to Apple, “The protective MBR...defines a single partition entry that covers the entire area of the disk used by GPT structures and partitions. It is designed to prevent GPT-unaware programs from accidentally modifying a GPT disk. A GPT-unaware program sees the GPT disk as an MBR disk with a single, unknown partition. In a way, this is like the HFS wrapper around an HFS Plus disk.”

  The next block (LBA1) is the primary partition table header. Apple defines the partition table header as “a structure that defines various aspects of the disk, including a GUID to uniquely identify the disk, the starting block of the partition entry array, and the size of each partition entry in that array.”

  The 512-byte partition table header is laid out as follows:

  Partition Entry Array

  This brings us to the partition entry array, starting at LBA2. The partition entry array is, as you might imagine, an array or list of all the partitions described in the partition table. GPT requires that the partition entry array be at least 16 KB. For a 512-byte block size, this is 32 blocks. The size of each entry is defined in the partition table header, and at the time this chapter was written is 128 bytes. This means that using the current default values, a GPT disk can contain and describe 128 partitions.

  A typical 128-byte partition entry is laid out as shown in the following table:

  Bear in mind that block size and partition entry array size can, and probably will, change at some point in the future. Also remember that GPT is little-endian; that is, multi-byte quantities are stored with the least significant byte first.

  The most common GPT partition types are defined in the GPT specification. Apple has defined a number of GUIDs to describe Apple-specific partition types, as shown in the next table:

  Note that the first three dash-delimited fields of the GUID are written to the disk in little-endian, and the last two fields are not.

  Let’s take a look at a GPT partitioned disk. Figure 8-1 shows SMART (www.asrdata.com/SMART/) looking at a GPT-formatted MacBook internal hard drive. The hard drive is set up to triple-boot from either the Mac OS X installed in the HFS+ partition, Ubuntu Linux installed in the ext3 partition, or Windows XP installed in the NTFS partition.

  Figure 8-1 GPT-partitioned disk

  The raw data that describes this structure is shown in Figure 8-2. You can see that offset 32 for each entry specifies the starting LBA in little-endian format. This is more modern and straightforward compared with calculating and recording C:H:S values (cylinders:heads:sectors, which seem pretty silly when looking at solid state memory).

  Figure 8-2 Raw view of a GPT disk

  So now we know that the first block (LBA0) on an Apple-formatted GPT disk is the protective MBR, the second block (LBA1) contains the Primary GPT Partition table header, and that blocks 2–33 contain the partition table entry array.

  The partitions that are set by Apple disk formatting utilities follow three simple rules, depending on the size of the device being partitioned. Apple defines disks in three ways—tiny, sm
all, and big:

  • Tiny, less than 1GB Tiny disks are created with no reserved free space and no extra partitions; the partitions are laid out as the user specifies.

  • Small, 1-2GB Small disks are created with no extra partitions but have 128MB of free space at the end of each partition.

  • Big, larger than 2GB Big disks always have a 200MB Extensible Firmware Interface (EFI) system partition called the EFI System Partition (ESP) as the first partition on the disk, and they also have the 128MB of free space after each partition (not including the ESP partition).

  Each partition is aligned to a 4KB boundary to accommodate the limitations of the HFS+ file system implementation on Mac OS X. Free space is left at the end of each partition to make it easier for future system software to manipulate the partition map in ways that cannot be anticipated at the moment.

  The HFS File System

  Thus far, we haven’t even looked at a file system; it has all been partition information. Any discussion about HFS needs to include a discussion about B-trees (balanced or binary trees). These structures remain central to HFS and its variants.

  A quick review of File Allocation Table (FAT)–based file systems will remind you that the file system has a root from which everything on the file system can be referenced via a fully qualified path. Directories are simply file entries that have a directory attribute set. File entries contain a pointer to a starting block and a length. Directory entries point to subdirectories. The FAT is an array of pointers. The values in the FAT are either pointers to clusters, EOF markers (that say “I am the last cluster in this chain”), or perhaps BAD, as in blocks that are mapped out by diagnostic programs.

  It should be no surprise that the Macintosh file system is completely different. For one thing, no FAT is used in the HFS. The job of keeping track of the allocation blocks (clusters) allocated to a file is performed by the allocation file, a new structure introduced with HFS+ and similar to the volume bitmap in HFS: each allocation block is represented by 1 bit. A 0 (zero) means the block is free and a 1 means the block is in use. The main difference between the older HFS volume bitmap and the newer allocation file is that the allocation file is stored as a regular file; it does not occupy a special reserved space near the beginning of the volume as the older volume bitmap did. The allocation file can also change size and does not have to be stored contiguously within a volume. This more closely parallels the behavior of NTFS when it comes to file system internals.

  The tree analogy is an extension of the notion that everything grows from the “root” of a file system. Trees are made up of nodes, logical groupings of information that are internal to the file system and contain records. Records contain data or pointers to data.

  Different types of nodes appear on the tree: header nodes, index nodes, and leaf nodes. The leaf nodes give us information about files—their names, access times, and other attributes. Nodes are pointed to and/or linked together and may be conceptualized as layers. The header node is at the top, and under that are index nodes. Index nodes may point to other levels of index nodes or to leaf nodes.

  You could say that the root node is at the top of the tree, at level 0. The root node contains pointers to B-tree header nodes, which in turn point to index nodes. Index nodes can point to other index nodes or to leaf nodes. The more files, folders, and stuff you have in your file system, the more levels you will have between the root node and the leaf nodes. In general, nodes that exist on the same level point to one another. These are called FLINKS (forward links) and BLINKS (backward links), as shown in Figure 8-3.

  When we go to the offset specified as the starting logical block address of a partition that contains an HFS+ file system, we see that the first two sectors of the volume are HFS boot blocks. These are identical to the boot blocks in an HFS volume and are part of the HFS wrapper.

  Sector 2 of the partition contains the volume header. This is equivalent to the master directory block in an HFS volume. The volume header stores a wide variety of data about the volume itself, such as the size of allocation blocks, a time stamp that indicates when the volume was created, and the location of other volume structures such as the catalog file and extent overflow file. The volume header is always located in the same place.

  Figure 8-3 FLINKS and BLINKS

  The layout of the Volume header is as follows:

  HFS+ dates are 32-bit values that represent the number of seconds since midnight, January 1, 1904, GMT. Earlier implementations used local time, not GMT. The exception is the creation date stored in the volume header. This field records local time, not GMT.

  The catalog file is a branching tree data structure or (B*-tree) that contains records for all the files and directories stored in the volume. The HFS+ catalog file is similar to the HFS catalog file—the main differences being that records are larger to allow more fields and to allow for those fields to be larger (for example, to allow the longer 255-character Unicode filenames in HFS+). A record in the HFS catalog file is 512 bytes in size, and a record in the HFS+ catalog file is 4KB in Mac OS and 8KB in Mac OS X. Fields in HFS are of fixed size, and in HFS+, the size can vary depending on the actual size of the data they store.

  The extents overflow file is another B*-tree that records the allocation blocks that are allocated to each file as extents. Each file record in the catalog file is capable of recording eight extents for each fork of a file; once those are used, extents are recorded in the extents overflow file. Bad blocks are also recorded as extents in the extents overflow file. The default size of an extent record in Mac OS is 1 KB and in Mac OS X is 4 KB.

  The attributes file is a new B*-tree in HFS+ that does not have a corresponding structure in HFS. The attributes file can store three different types of 4KB records: inline data attribute records, fork data attribute records and extension attribute records. Inline data attribute records store small attributes that can fit within the record itself. Fork data attribute records contain references to a maximum of eight extents that can hold larger attributes. Extension attributes are used to extend a fork data attribute record when its eight extent records are already used.

  The startup file is designed for non-Mac OS systems that don’t have HFS or HFS+ support. It is similar to the boot blocks of an HFS volume. The second to last sector contains the alternate volume header equivalent to the alternate Master Directory Block of HFS. The last sector in the volume is reserved for use by Apple. It is used during the computer manufacturing process.

  Unique Sequential File Identifiers

  Every file system object in an HFS file system is assigned a unique, sequential file ID number when it is created. For a forensic examiner, this information is very useful, as the file with FILE ID 100 was created in the file system after the file with FILE ID 99, regardless of any date or time stamp information. The FILE ID attribute is relative to the file system you are examining. File ID numbers do not “go along with the file” when it is copied, downloaded, decompressed, and so on. The File ID number is one of the things that the HFS file system uses when organizing the B-tree.

  DELETED FILES

  On a FAT32 file system, files are “deleted” by replacing the first character of the filename with the hex byte E5. The file’s clusters are flagged as “available,” and the E5 entry in the directory still contains the (changed) name, attribute flags, date and time stamps, and logical size. On an NTFS system, the entry is “un-indexed” from the MFT. This is closer to what happens on an HFS or HFS+ volume. Let’s take a look at a catalog B-tree leaf node containing file records (the lowest level of the tree), shown in Figure 8-4.

  Figure 8-4 Tree leaf node data

  Looking at the B-tree data, you can see filenames in plaintext, as well as information that you can identify as type and creator codes:

  x00 ulong fLink Forward link to next node on this level

  x04 ulong bLink Backwards link to previous node

  x08 uchar nodeType FF=leaf node, 00=index node

  01=
B-tree Header node, 02=2nd VBM

  x09 char level level of this node (1=leaf)

  x0A uint numRecs Number of records in this node

  So looking at the first 12 bytes in Figure 8-4, you see the following:

  • The forward link is 00 00 04 60 (Node 1120).

  • The backward link is 00 00 04 5c (Node 1116).

  • The node type is FF for a leaf node.

  • The leaf node is at level 01 of the tree.

  • Three records are contained in this node.

  The three records in the example are leaf node entries for these files:

  • Windows 98.img

  • Wipe Info

  • wrap.gif

  So what happens if you delete the file Wipe Info? What changes would you observe in the node you are looking at? For one thing, offset x0A (the number of records) would be decreased to 2. Slightly less obvious, the file records are arranged alphabetically within the node. Therefore, if you deleted the second file, Wipe Info in this example, the third entry would pop up in the stack of records tracked by the node. Think of it as the stack of plates at your favorite all-you-can-eat place. If you take the top plate off the stack, the second plate now becomes the first plate, and every plate underneath it shifts up the queue by one.

  If you take the second plate off the stack, the first plate is still the first plate, but the second plate used to be the third plate. What this means to you is that the second entry (Wipe Info) is overwritten by the third entry (now the second entry). You would see that only two records were indexed in the node, Windows 98.img and wrap.gif, and you would see the original third entry as well as the “new” second entry. It might look like Figure 8-5.