BSD Partitions

It is becoming more common for computer investigations to encounter BSD UNIX servers, such as FreeBSD (http://www.freebsd.org), OpenBSD (http://www.openbsd.org), and NetBSD (http://www.netbsd.org). These systems use their own partitioning system, and this section will show the details of its structures. It is more common to encounter a Linux system during an investigation, but Linux uses only the DOS-based partitions and does not have any special data structures.

Many BSD systems use IA32-based hardware (i.e., x86/i386), and they have been designed such that they can exist on the same disk as Microsoft products. Therefore, they build on the DOS partitions described in the previous chapter. A BSD system that runs on non-IA32 hardware likely does not use the DOS partitions, and they are not covered in this book.

An important concept to understand before we begin is that when an operating system is running, it can choose to what partitions it will give the user access. As will be shown, the FreeBSD operating system uses both the DOS and BSD partition systems, yet OpenBSD and NetBSD use only the BSD partition system. A basic understanding of DOS partitions is needed for this section.

General Overview

The BSD partition system is simpler than the DOS partitions but more limited than the Apple partition map. There is only one sector that contains the needed data, and it is located inside a DOS partition, as shown in Figure 6.1. It is inside a DOS partition so that the system can also have Windows on the same disk and give the user a choice of which operating system to load. The DOS partition table will have an entry for a partition with a FreeBSD, OpenBSD, or NetBSD type0xa5, 0xa6, and 0xa9, respectively. The BSD partition will be one of the primary DOS partitions.

Figure 6.1. A disk with two DOS partitions and three BSD partitions inside the FreeBSD-type DOS partition.

If we wanted to be very strict with our terminology, we would say that the BSD partitions are located inside a volume created by a DOS partition. As discussed in Chapter 4, "Volume Analysis," this is an example where we are partitioning a volume that was created from a partition.

The central data structure is the disk label. It is at least 276 bytes in size and is located in the second sector of the BSD partition. For some non-IA32 systems, it may be in the first sector and have an offset. FreeBSD, OpenBSD, and NetBSD use the same structure, but the implementation is slightly different. Therefore, the general theory will be described here, and specific details are given in later sections.

The disk label structure contains hardware specifications of the disk and a partition table for eight or sixteen BSD partitions. Unlike Apple partitions, the partition table is a fixed size, and unlike DOS partitions, there is only one partition table. Each entry in the BSD partition table has the following fields:

• Starting sector of the BSD partition
• Size of the BSD partition
• Partition type
• Size of the UFS file system fragment
• Number of UFS file system fragments per block
• Number of cylinders per UFS Cylinder group

The starting sector address is given relative to the start of the disk, not the disk label or DOS partition. The partition type field identifies the file system type that should be in the BSD partition, such as UFS, swap space, FAT, and unused. The last three values are used only when the partition contains a UFS file system. The UFS file system is described in Chapter 16, "UFS1 and UFS2 Concepts and Analysis," and Chapter 17, "UFS1 and UFS2 Data Structures."

The basic theory of BSD partitions is simple. The one structure is read, and the list of partitions can be easily processed. The challenge to an investigator, though, is to know to what partitions the user had access. For example, if it was a dual boot system, the investigator must know if the user had access to the Windows partition as well as the BSD partitions. FreeBSD handles this differently from OpenBSD and NetBSD. I will discuss how each OS uses the data in the disk label, even though this may be considered application-level analysis.

FreeBSD Overview

FreeBSD gives the user access to all DOS and BSD partitions on the disk. FreeBSD uses the term "slice"' to refer to each DOS partition and uses the term "partition" to refer to the BSD partitions. Therefore, if a system has both Windows and FreeBSD installed on it, the user would have access to the Windows slices when running FreeBSD.

The disk label structure in FreeBSD is used to organize the sectors in only the FreeBSD DOS partition. This may sound obvious, but it is one of the ways in which the OpenBSD implementation is different from the FreeBSD implementation. If we refer to Figure 6.2, the disk label describes three partitions inside the FreeBSD type DOS partition but it does not need to describe the NTFS type partition.

Figure 6.2. FreeBSD Disk with device names added.

FreeBSD, like other UNIX flavors, assigns a special device file to each partition and slice. The file is named according to its DOS partition number and its BSD partition number. The base name for the primary ATA disk is /dev/ad0. Each slice, also called a DOS partition, adds the letter 's' and the slice number to the base name. For example, the first slice is /dev/ad0s1 and the second slice is /dev/ad0s2. Any slice that has a FreeBSD partition type is processed for the disk label structure. The partitions in the slice are given letters based on their entries in the disk label partition table. For example, if the second DOS partition was FreeBSD, the first BSD partition would be /dev/ad0s2a, and the second BSD partition would be /dev/ad0s2b. A second set of devices that does not include the slice number may also be made for the BSD partitions. For example, /dev/ad0a would be a shortcut to the /dev/ad0s2a partition if the FreeBSD partition was DOS partition 2.

Some of the BSD partitions have special meaning. The 'a' partition is usually for the root partition, which is where the boot code is located. The 'b' partition is usually for the swap space of the system, the 'c' partition is usually for the entire slice, and the partitions starting at 'd' can be anything. The term 'usually' is used because that is how many of the BSD partitioning tools will create the partitions, but any user can edit the disk label partition table with a hex editor and modify the entries.

In summary, a FreeBSD system provides access to all DOS partitions and BSD partitions. An investigator must analyze each of the DOS partitions and BSD partitions in the disk label to fully analyze the system.

NetBSD and OpenBSD Overview

OpenBSD and NetBSD give a user access to only the entries in the BSD disk label structure. Unlike the FreeBSD disk label, the OpenBSD and NetBSD disk label structure can describe partitions anywhere on the disk. In other words, the disk label can describe partitions that are outside the bounds of the DOS partition in which it is located. For the rest of this chapter, I will refer to OpenBSD only, but I really mean both OpenBSD and NetBSD. The OpenBSD code split from the NetBSD code years ago.

After the OpenBSD kernel is loaded, the DOS partitions are ignored. The DOS partitions are only used to locate the start of the OpenBSD partition. Therefore, if a system has both Windows and OpenBSD on it and users had access to a FAT partition from OpenBSD, the FAT partition would be in both the DOS partition table and the BSD disk label. We can see this in Figure 6.3 where we have the same DOS partitions as in Figure 6.2. In this case, though, we need to have an additional entry in the disk label so that we can access the NTFS type DOS partition.

Figure 6.3. A disk with two DOS partitions and an OpenBSD disk label that describes three partitions inside the OpenBSD type DOS partition and the entire NTFS partition.

OpenBSD uses file names that are similar to the ones that FreeBSD uses for partition devices. The base name for the primary ATA device is /dev/wd0. There is no notion of slices, and the BSD partitions are named with letters. Therefore, the first BSD partition is /dev/wd0a and the second is /dev/wd0b. Like FreeBSD, the first partition is usually for the root partition and the second partition is for swap space. The third partition, /dev/wd0c in our example, is the device for the entire disk. Recall that the third partition for FreeBSD was for only the slice, or DOS partition.

In summary, an OpenBSD system provides access to only the partitions described in the OpenBSD disk label. An analysis of an OpenBSD system should focus on the partitions that are listed in the disk label.

Boot Code

The boot code for a BSD system surrounds the disk label structure, which is located in sector 1 of the volume. Sector 0 of the volume contains boot code, and it is executed when the boot code in the MBR finds the bootable BSD-type partition. Not all the boot code can fit in sector 0, so it jumps to sector 2, and boot code can exist until the file system data starts, which is typically in sector 16.

Data Structures

This section will describe the BSD disk label data structure and parse example disk images from FreeBSD and OpenBSD systems. The output from running analysis tools on the example disk images is also given.

Disk Label Data Structure

We will now look at the details of the disk label data structure. If you are not interested in this, you can skip ahead and look at the tool output when we list the contents of our example disk images. I will first describe the BSD disk label structure and then examine the FreeBSD and OpenBSD implementation details. The disk label has the layout given in Table 6.1. Note that the data marked as non-essential could be essential for other disk operations, but are not essential for determining the layout of the disk.

The 16-byte BSD partition table entries have the layout given in Table 6.2.

The file system type field identifies the type of file system that could be located in the BSD partition. The type values shown in Table 6.3 are defined.

The most common file system for FreeBSD and OpenBSD is the 4.2BSD fast file system (FFS). The system will also have at least one swap partition. An NTFS partition will typically have an 'in use, but unknown' type.

We can now look at an example system that has both FreeBSD and OpenBSD on it. The DOS partition table has the following contents:

# mmls t dos bsd-disk.dd Units are in 512-byte sectors Slot Start End Length Description 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000001 0000000062 0000000062 Unallocated 02: 00:00 0000000063 0002056319 0002056257 Win95 FAT32 (0x0B) 03: 00:01 0002056320 0008209214 0006152895 OpenBSD (0xA6) 04: 00:02 0008209215 0019999727 0011790513 FreeBSD (0xA5)

We can see that the disk has a 1GB FAT partition, a 3GB OpenBSD partition, and a 6GB FreeBSD partition. Inside each of the OpenBSD and FreeBSD partitions are disk label structures that describe additional partitions. The next two sections will look at the two BSD partitions.

OpenBSD Example Image

We will first extract and parse the OpenBSD disk label. The partition starts in sector 2,056,320, and the disk label is located in the second sector.

# dd if=bsd-disk.dd skip=2056321 bs=512 count=1 | xxd 0000000: 5745 5682 0500 0000 4553 4449 2f49 4445 WEV.....ESDI/IDE 0000016: 2064 6973 6b00 0000 4d61 7874 6f72 2039 disk...Maxtor 9 0000032: 3130 3234 4434 2020 0002 0000 3f00 0000 1024D4 ....?... 0000048: 1000 0000 ff3f 0000 f003 0000 f02b 3101 .....?.......+1. 0000064: 0000 0000 0000 0000 100e 0100 0000 0000 ................ [REMOVED - ZEROS] 0000128: 0000 0000 5745 5682 b65e 1000 0020 0000 ....WEV..^... .. 0000144: 0000 0100 501f 0300 8060 1f00 0004 0000 ....P....`...... 0000160: 0708 1000 e061 0900 d07f 2200 0004 0000 .....a...."..... 0000176: 0108 1000 f02b 3101 0000 0000 0000 0000 .....+1......... 0000192: 0000 0000 501f 0300 b0e1 2b00 0004 0000 ....P.....+..... 0000208: 0708 1000 8056 0200 0001 2f00 0004 0000 .....V..../..... 0000224: 0708 1000 0000 0000 0000 0000 0000 0000 ................ 0000240: 0000 0000 3f4b 3c00 00f8 4000 0004 0000 ....?K<...@..... 0000256: 0708 1000 80a0 0f00 8057 3100 0004 0000 .........W1..... 0000272: 0708 1000 4160 1f00 3f00 0000 0000 0000 ....A`..?....... 0000288: 0800 0000 9dae b300 3f43 7d00 0000 0000 ........?C}..... 0000304: 0a00 0000 0000 0000 0000 0000 0000 0000 ................ 0000320: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000336: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000352: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000368: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000384: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000400: 0000 0000 0000 0000 0000 0000 0000 0000 ................ [REMOVED]

We can see the two signature values, 0x82564557, at bytes 0 to 3 and 132 to 135. After the second signature value, bytes 138 to 139 show that there are 16 (0x0010) partition table entries. The partition table starts on the next line in byte 148 and continues for 16 16-byte structures to end at 403. Entries 11 to 16 are not used and contain 0s. The remainder of the sector is not used by the disk label structure.

The sixteen partition table entries can be parsed into the data shown in Table 6.4, where the decimal value is given in parentheses.

Before we look at this in detail, we will review the special BSD partitions. The first partition is for the root partition, and it contains the boot code. The second partition is for the swap space, the third partition is for the entire disk, and partitions four and up are for any BSD partition.

Our example image follows these guidelines, and the first partition begins at the start of the DOS partition, which is sector 2,056,320. The second partition has a type value of 1, which translates to swap space. The third partition begins in sector 0 and has the size of the entire disk. Partitions 4, 5, 7 and 8 have a 4.2BSD FFS type and the starting sector of the partitions increase until partition 9. Partition 9 has a starting sector of 63, and its type is for a FAT file system. This partition is the BSD disk label entry for the FAT partition that is described in the first entry of the DOS partition table. Partition 10 has an unknown type value and is the BSD disk label entry for the FreeBSD partition that is the third entry in the DOS partition table that we previously saw. Because partition 9 is labeled as 'i,' the user could access the FAT partition with device /dev/wd0i. Remember that OpenBSD ignores the DOS partition table contents after it is loaded.

Table 6.5 shows to which partitions the user would have access from within this OpenBSD system.

Note that the FreeBSD partition cannot be mounted because its disk label must be first read to identify the file system locations. We can see the same data from the disk label using the mmls tool and supplying the bsd type. The offset of the BSD partition must be given using the -o flag because we have a disk image.

# mmls t bsd o 20563210 bsd-disk.dd BSD Disk Label Units are in 512-byte sectors Slot Start End Length Description 00: 02 0000000000 0019999727 0019999728 Unused (0x00) 01: 08 0000000063 0002056319 0002056257 MSDOS (0x08) 02: 00 0002056320 0002260943 0000204624 4.2BSD (0x07) 03: 01 0002260944 0002875823 0000614880 Swap (0x01) 04: 03 0002875824 0003080447 0000204624 4.2BSD (0x07) 05: 04 0003080448 0003233663 0000153216 4.2BSD (0x07) 06: 07 0003233664 0004257791 0001024128 4.2BSD (0x07) 07: 06 0004257792 0008209214 0003951423 4.2BSD (0x07) 08: 09 0008209215 0019984859 0011775645 Unknown (0x0A)

Remember that mmls will sort the output based on the starting sector of the partition, so the FAT partition is located at the beginning of the output even though it was the eighth entry in the partition table. The 'slot' column shows where the partition was actually described.

FreeBSD Example Image

Now let's look at the FreeBSD partition in our example image. The partition starts in sector 8,209,215, and the disk label is in the second sector.

# dd if=bsd-disk.dd skip=8209216 bs=512 count=1 | xxd 0000000: 5745 5682 0500 0000 6164 3073 3300 0000 WEV.....ad0s3... 0000016: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000032: 0000 0000 0000 0000 0002 0000 3f00 0000 ............?... 0000048: 1000 0000 814d 0000 f003 0000 f02b 3101 .....M.......+1. 0000064: 0000 0000 0000 0000 100e 0100 0000 0000 ................ [REMOVED - ZEROS] 0000128: 0000 0000 5745 5682 b9ab 0800 0020 0000 ....WEV...... .. 0000144: 0000 0000 0000 0800 3f43 7d00 0008 0000 ........?C}..... 0000160: 0708 0880 a073 1700 3f43 8500 0000 0000 .....s..?C...... 0000176: 0100 0000 b1e8 b300 3f43 7d00 0000 0000 ........?C}..... 0000192: 0000 0000 0000 0800 dfb6 9c00 0008 0000 ................ 0000208: 0708 0880 0000 0800 dfb6 a400 0008 0000 ................ 0000224: 0708 0880 1175 8400 dfb6 ac00 0008 0000 .....u.......... 0000240: 0708 886f 0000 0000 0000 0000 0000 0000 ...o............ 0000256: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000272: 0000 0000 eb0e 4254 5801 0180 f60f 8007 ......BTX....... 0000288: 0020 0000 fa31 c08e d0bc 0018 8ec0 8ed8 . ...1.......... 0000304: 666a 0266 9dbf 001e b900 3957 f3ab 5fbe fj.f......9W.._. 0000320: e296 ac98 91e3 1dac 92ad 93ad b608 d1eb ................ 0000336: 730b 8905 8875 0288 5505 83c0 048d 7d08 s....u..U.....}. 0000352: e2ec ebde c645 0518 c645 0810 c645 0d1e .....E...E...E.. 0000368: c645 6668 bb20 28e8 bb00 0f01 1ed6 960f .Efh. (......... 0000384: 0116 d096 0f20 c066 83c8 010f 22c0 ea7f ..... .f...."... 0000400: 9008 0031 c9b1 108e d1b1 380f 00d9 ba00 ...1......8..... 0000416: a000 0036 0fb7 0513 0400 00c1 e00a 2d00 ...6..........-. 0000432: 1000 0029 d0b1 3351 5068 0202 0000 6a2b ...)..3QPh....j+ 0000448: ff35 0c90 0000 5151 5151 52b1 076a 00e2 .5....QQQQR..j.. 0000464: fc61 071f 0fa1 0fa9 cffa bc00 1800 000f .a.............. 0000480: 20c0 25ff ffff 7f0f 22c0 31c9 0f22 d90f .%.....".1..".. 0000496: 0115 d096 0000 66ea e890 1800 b120 8ed1 ......f...... ..

We can see from the value in bytes 138 to 139 that there are eight partitions. The eight partition table entries are in bytes 148 to 275 and can be parsed into the fields shown in Table 6.6, where the decimal values are given in parentheses.

We see that the first BSD partition has the same starting sector as the DOS partition in which the disk label is located, and it has a 4.2BSD FFS type. The second entry is for swap space, and the third entry is for only the sectors in the DOS partition. Entries 4, 5, and 6 are FFS file system partitions. To summarize, the device name and location of each partition that a FreeBSD user would have access to is given in Table 6.7.

The mmls tool from The Sleuth Kit can be used to list the disk label contents. The output for our example image is as follows:

# mmls t bsd o 82092165 bsd-disk.dd BSD Disk Label Units are in 512-byte sectors Slot Start End Length Description 00: ----- 0000000000 0008209214 0008209215 Unallocated 01: 00 0008209215 0008733502 0000524288 4.2BSD (0x07) 02: 02 0008209215 0019999727 0011790513 Unused (0x00) 03: 01 0008733503 0010270430 0001536928 Swap (0x01) 04: 03 0010270431 0010794718 0000524288 4.2BSD (0x07) 05: 04 0010794719 0011319006 0000524288 4.2BSD (0x07) 06: 05 0011319007 0019999727 0008680721 4.2BSD (0x07)

Note that the space allocated to the FAT and OpenBSD partition is marked as 'Unallocated' because there are disk label entries for that space. The DOS partition table is needed to carve that data into partitions.

Analysis Considerations

Each BSD partition in the disk label structure has a type field, but it is not enforced. It is actually enforced less with the BSD systems than with Microsoft Windows because Windows uses the type field to determine if the partition should get a drive letter or not. With a BSD system, a device is created for every disk label entry, so the partitions can be mounted as any type. Therefore, verify that the partition doesn't have a known file system even when the type identifies it as an old UNIX format because it could actually be a common file system, such as FAT.

The disk label structure is, at most, 404 bytes. For disk labels with only eight entries in them, the disk label structure is only 276 bytes. Therefore, the rest of the 512-byte sector can be used to hide data, although not a lot of it. If the DOS partition table is corrupt and the location of the BSD-type partition cannot be determined, a search for the 0x82564557 signature value can be performed. The signature value should exist at byte 0 and byte 132 of the disk label structure.

With a FreeBSD system, remember that the user had access to both the DOS partitions and the BSD partitions. Therefore, the investigation must include the analysis of all DOS partitions and the BSD partitions. Note that the system may not have support for NTFS, so the user would not have been able to mount an NTFS partition if one exists.

With an OpenBSD system, remember that the user had access to only the partitions in the disk label. Because OpenBSD ignores the DOS partition table when it starts, it can be useful to compare the contents of the DOS partition table with the BSD disk label. Look for BSD and DOS partitions that overlap and where gaps may exist. Figure 6.4 shows two interesting examples of BSD partitions. One of the BSD partitions is contained inside the NTFS-type DOS partition. If the NTFS partition has an NTFS file system inside it, this is an unlikely scenario and should be investigated. The figure also shows a BSD partition that exists in space that is unallocated to a DOS partition. This is not a good practice from a systems administration point of view because another program may allocate the space to a DOS partition and overwrite the BSD data, but it is possible.

Figure 6.4. A disk with two BSD partitions inside the OpenBSD type DOS partition, a BSD partition inside the NTFS-type DOS partition, and a BSD partition that is not part of a DOS partition.

Summary

BSD partitions are described in a simple disk label structure. A difficulty for an investigator is to identify all the data that the user had access to on the suspect system. BSD systems are frequently used as servers and are involved with criminal and corporate investigations. A thorough understanding of BSD partitions will provide more comprehensive investigations.