CHAPTER SEVEN

Volume versus Partition

IN CHAPTER 5 WE DISCUSSED the boot-up process after touching upon important key concepts, files in Chapter 4, and in Chapters 2 and 3, HEX and binary.

We have also discussed the importance of the Master Boot Record (MBR) and its contents such as the partition table, and how the system identifies the active partition (HEX 80) and its starting sector and its size.

In order to explain how some of the data contained within the partition table is interpreted we deviated and delved into endianness. Being that the order of some of the data contained within the MBR is subjected to this endianness, it was imperative to expound upon how data is ordered and the importance of endianness, as it affects data within the MBR.

To continue on to the next step in our sequence, the process of data being assembled into human interpretable information, it is necessary for those data to be located and identified by the system.

We know already how the active partition’s starting sector and its size are derived from the partition table; however, there are several additional byte offsets within the partition table which we have not yet discussed.

These offsets, called Cylinder, Head, and Sector (CHS) or, more currently, Logical Block Address (LBA), help to quantify partition location and size.

This chapter explains how partitions are located and identified and the significant role of volumes in making these data “mountable” or accessible and readable by your system at startup.

TECH REVIEW

Prior to launching directly into our examination of volumes and partitions, it may be best to pause for a moment for a brief review of the technology that drives the hardware, where the data resides.

Hard or fixed disks store information on a revolving platter of metal or glass coated with a magnetic material. The disk typically consists of several physical platters on a common spindle.

Each disk consists of platters, rings on each side of each platter called tracks, and sections within each track called sectors. A sector is the smallest physical storage unit on a disk, almost always 512 bytes in size.

Tracks and Cylinders

On hard disks, the data are stored on the disk in thin, concentric bands called tracks. There can be more than 1,000 tracks on a 3½ inch hard disk. Tracks are a logical rather than physical structure, and are established when the disk is low-level formatted. Track numbers start at 0, and track 0 is the outermost track of the disk. The highest numbered track is next to the spindle. If the disk geometry is being translated, the highest numbered track would typically be 1,023.

See Figure 7.1 for an illustrative example of tracks on a typical hard disk.

A cylinder consists of the set of tracks that are at the same head position on the disk.1 (See Figure 7.2.)

Sectors and Clusters

Each track is divided into sections called sectors. A sector is the smallest physical storage unit on the disk. The data size of a sector is always a power of two, and is almost always 512 bytes. (See Figure 7.3.)

Each track has the same number of sectors, which means that the sectors are packed much closer together on tracks near the center of the disk. The disk controller uses the sector identification information stored in the area immediately before the data in the sector to determine where the sector itself begins.

As a file is written to the disk, the file system allocates the appropriate number of clusters to store the file’s data. For example, if each cluster is 512 bytes and the file is 800 bytes, two clusters are allocated for the file. Later, if you update the file to, for example, twice its size (1,600 bytes), another two clusters are allocated.

If contiguous clusters (clusters that are next to each other on the disk) are not available, the data are written elsewhere on the disk and the file is considered to be fragmented. Fragmentation is a problem when the file system must search several different locations to find all the pieces of the file you want to read. The search causes a delay before the file is retrieved. A larger cluster size reduces the potential for fragmentation, but increases the likelihood that clusters will have unused space.2

CYLINDER, HEAD, SECTOR, AND LOGICAL BLOCK ADDRESSING

On older x86-based systems, back when hard drives did not exceed 8 gigabytes, the starting and ending Cylinder, Head, and Sector (CHS) fields of the active partition (HEX 80) were very important during the system boot. These values, contained within the Partition Table of the MBR were used to find and load this partition. Logical Block Addressing (LBA) virtually did away with this and involves a newer way of addressing sectors using exact sector locations.

Instead of referring to a cylinder, a head, and a sector number, each sector is instead assigned a unique “sector number.” So instead of using a sort of triangulation in identifying a location on the disk, LBA simply numbers each sector with a unique number. In essence, the sectors are numbered 0, 1, 2, etc. up to (N–1), where N is the number of sectors on the disk.3

An analogy would be as follows.

Your address (assuming you live in the United States and have a typical address) is composed of a street number, street name, city name, and state name. This is similar to how conventional CHS addressing works. Instead however, let’s say that every house in the United States was given a unique identifying number. This would be more how LBA works.4

Cylinder, Head, and Sector

Table 7.1 shows the corresponding CHS tuple for a select group of LBA values, and how one would sequentially count through a number of sectors which these values represent.

TABLE 7.1 512-Byte Blocks Identified Using LBA and CHS

LBA Value	CHS Tuple
0	0, 0, 1
1	0, 0, 2
2	0, 0, 3
62	0, 0, 63
63	0, 1, 1
64	0, 1, 2
65	0, 1, 3
125	0, 1, 63
126	0, 2, 1
127	0, 2, 2
188	0, 2, 63
189	0, 3, 1
190	0, 3, 2
16,063	0, 254, 62
16,064	0, 254, 63
16,065	1, 0, 1
16,606	1, 0, 2
16,127	1, 0, 63
16,128	1, 1, 1
16,450,497	1,023, 254, 1
16,450,558	1,023, 254, 62
16,450,559	1,023, 254, 63

The data listed in Table 7.1 will only be valid for hard disks having 63 sectors per track and 255 heads per cylinder.

Entries of the First Partition Table Entry

Let’s again examine the partition table contained within the MBR (see Figure 7.4) and review those values, which we have already covered (see Table 7.2).

TABLE 7.2 Byte Entries of the First Partition Table Entry

Remaining Byte Entries of the First Partition Table Entry

The remaining HEX values are those for starting and ending CHS values. We did not cover these previously because the concepts of CHS and LBA had not yet been introduced. Let’s review these now!

Starting CHS Value

Byte offset 01 through 03 of the partition table—01 01 00 (see Figure 7.5). First byte is reserved for the Head value—01, the remaining HEX values are 01 00. The next byte is assigned the Sector value and the third byte is assigned the Cylinder Value.

Thus the CHS value 00:01:01 (0, 1, 1) (see Table 7.1):

• Head Value = 01
• Sector Value = 01
• Cylinder Value = 00

This may seem backwards, but remember, so is little endian. Why does the Sector value byte come before the Cylinder value byte? It’s all in the code. Why assign the value of HEX 80 to the active partition? This all has to do with coding. You can view this as a little endian reordering of the last two bytes.

Ending CHS Value

Byte offset 05 through 07 of the partition table—FE FF FF (see Figure 7.6).

First value is reserved for the Head value (H = FE); when HEX FE is converted to decimal, the resulting value is equal to 254.

The remaining calculation gets a little tricky. The values are not reversed (little endian), but they are regrouped. Remember, HEX is our representation of binary. Also, remember that code can be written to perform any mathematical function on any binary values.

As stated, the first byte, in this case FE, is reserved for the HEAD value, so we remove that value. We are left with HEX FF FF.

This next step is where we regroup, but in order to do so we must convert our HEX values to their binary equivalents, which results in:

We put these binary values together—11111111 11111111, and we regroup those values, the first 6 bits, and the next 10 bits.

Why this regrouping?

It all has to do with how the code handles the binary. It is important to remember that binary is, at its base, simply 0s and 1s. It is code that combines them into bytes just as it is code that regroups and splits them. Ultimately, if we were to look at the numerical data representation embedded within the disk’s surface (i.e., platter) all we would see would be a long string of consecutively joined 0s and 1s.

What defines the partition table? What defines sectors? What defines bytes? Why words and Dwords? Why endianness? Why this regrouping of byte offset 05 through 07 of the partition table?

It’s all in the code (e.g., firmware, ROM, boot code, OS code, programmers and developers, etc.—it depends on “how” the code has been written). The code is telling the system “how” to handle “which” binary bits and how to arrange these bits within the grouping for interpretation.

This gives us a binary number grouping as such:

Now converting 111111 binary into its decimal equivalent, gives us a value of 63 (the sector address). Converting 1111111111 binary into its decimal equivalent gives us a value of 1,023 (the cylinder address).

The sector is assigned the first grouping and the cylinder is assigned the second grouping:

The final CHS tuple is 1023:254:63.

Using the legacy CHS system, the starting point for the partition is 0:1:1, and the end point is 1023:254:63.

This is a long explanation for extracting CHS values from a partition table, but for what reason is this information valuable or even necessary?

The more meaningful information follows the CHS addressing, which is the starting sector (in the relative column) and the size in sectors. The size of the partition is 496,729,737 sectors, relative to sector 63.

Thus, this implies that the starting point if utilizing CHS reference is 0:1:1, whereas if using LBA reference, it would be 63. Therefore, the location of the starting sector for the partition in CHS is 0:1:1 and in LBA, 63.

Why Is This Important?

As a cyber forensic investigator it is important to understand where data and how data are located on the hard drive. Nowadays forensic tools do this behind the scenes. Cyber forensic investigators may not necessarily need to concern themselves with this information in order to perform a forensic examination. But, it is imperative to understand how and why this occurs. If called to the witness stand and the defense attorney asks, “Can you please tell the court exactly where on the hard drive did you find the evidence and how you made that determination?” you will need to understand these basic concepts.

CHS Summary

This is a legacy system, CHS, that in its day was helpful in identifying size in smaller drives. It is constrained by the amount of bits available in the partition table, which are used to represent these values.

Recall from Chapter 1 we discussed the possible outcomes or combinations around a Base two encoding scheme; with one (1) bit we only had two outcomes—on or off, and with two (2) bits we had four (4) outcomes or combinations. As we just discussed, one full byte is used to compute the Head value. If one byte contains eight (8) bits, how many possible outcomes can we have in a Base two encoding scheme with eight (8) bits? 256! So, we can only have 256 values for the Head variable.

Note: there are really only 255 possible values for Head due to a Microsoft bug. For details see http://thestarman.pcministry.com/asm/mbr/DiskTerms.htm#HDcnt.

Since Head value starts count at zero (0), then the greatest possible value for Head is 254. Also recall that in order to compute the sector value, we removed the leading two bits of the second (or middle) byte and slid them over to the Cylinder value, thus leaving six bits for the sector value.

Therefore, the largest value you can have for a Sector is [11 1111] (six bits), or 63, and likewise the largest value that can be obtained for a Cylinder is [11 1111 1111] or 1,023.

So the largest size for a drive using the constraining CHS labeling method is determined by multiplying the cylinder, head, and sector values (C * H * S) thus, 1,023 * 254 * 63, which equals 16,370,046 sectors. Multiplying the number of sectors by the number of bytes per sector (512), (16,370,046 * 512), results in a total number of bytes for the drive of 8,381,463,552 bytes, or roughly an 8 GB drive. The CHS parameter ceases to be much of an ending sector identifier once a drive exceeds 8 GB.

VOLUMES AND PARTITIONS

In the greater world of information technology, volumes and partitions are often times used by practitioners as referring to the same thing; however, there are subtle differences between the two and sometimes the lines between the two can get fuzzy. In short, volumes exist at the logical OS level, and partitions exist at the physical, media specific level. Sometimes there is a one-to-one correspondence, but it is not guaranteed to be true.

A partition is a collection of (physically) consecutive sectors (see Figure 7.7), where a volume is a collection of (logically) addressable sectors (see Figure 7.8). Herein lies the difference; the data contained within a volume may appear consecutive, but only logically.

A partition, as explained in previous chapters, is an area of the hard disk drive that is defined by an entry in the partition table of the MBR, and is recognized system wide. The partition is interpreted by code contained within that same sector, the MBR, and a partition is usually a subdivision. As the name implies, it is the process of splitting something larger into smaller pieces.

A volume is an area defined or interpreted by an operating system. A volume is recognized by the operating system and will have a drive letter associated with it. It is often used synonymously with the term drive or disk. (See Table 7.3.)

TABLE 7.3 Volumes and Partitions

In this example:

Perhaps most importantly, a volume contains the file system, which is unique to the operating system and only understood by the specific operating system. File systems will be addressed in depth in Chapter 8.

The physical verses logical nature of the partition and volume however are not necessarily always mutually exclusive. The difference or similarities sometimes get fuzzy as they were not created with the idea of the other in mind. In fact, many times they are the same thing.

For example, if a system contains one hard disk drive then it will contain one volume, such that if a hard disk were to be divided into partitions (as set forth by the partition table in the MBR), then each partition would become a volume. In this case, the partition is also a volume and they are essentially the same, although their definitions remain unique.

So a volume can be a whole hard disk or a partition. A volume can be a partition, a flash drive like an iPod, a floppy disk, mounted from a network server, or even a RAID array.

Reasons Why We Have Partitions and Volumes

Partitioning a drive may help to increase HDD efficiency by making cluster size smaller. Volumes, on the other hand, create logically intuitive storage areas (e.g., “Save it to the K drive”).

Volumes are identified by file systems, and file Systems are the way in which files are accessed and stored by an operating system. So, one may have two separate volumes in order to have two separate operating systems running on the same machine. Volumes provide enhanced recovery, data availability, performance, and storage configuration options. (See Figure 7.9.)

Extended Partitions

We already know that a single hard drive can have up to four partitions. The reason being is that there are only enough bytes available in the partition table of the MBR to accommodate four entries. We are also aware that typically when a partition is created on a single hard drive, it automatically becomes a volume and is assigned a drive letter (e.g., C:, D:, etc.). A volume and a partition are the same at this point, albeit with varying definitions.

As with everything else there are always exceptions. One of the four partitions defined by the partition table of a hard drive may be subdivided into multiple logical partitions (volumes), therefore allowing two or more volumes to exist within one partition. This subdivided partition is referred to as an extended partition. (See Figure 7.10.)

The extended partition was created to allow for additional logical partitions or volumes. Since a partition essentially becomes a volume upon creation, then a hard disk was limited to four volumes. In order to overcome this shortcoming the extended partition is created. It allows for itself to be further subdivided into logical volumes. Mind you, the partition table contained within the MBR still only defines four partitions and as far as it is concerned only four partitions exists.

When an extended partition is created, an extended partition table is also created. In essence, the extended partition is akin to a disk drive in its own right—it has its own partition table that points to one or more partitions (now called logical partitions, as opposed to the four primary partitions) contained entirely within the extended partition itself.5

There is no limit on the number of logical volumes other than the fact that there are only 26 letters in the alphabet and A, B, and C have been taken.

Figure 7.10 shows the existence of five volumes. In order for there to be five volumes on a single disk an extended partition would need to be created. As we can see, these exist as logical partitions and are all part of an extended partition.

SUMMARY

We conclude this chapter with a discussion of extended partitions to demonstrate the existence of partition defining data contained within an area of the hard drive other than the partition table, contained within the MBR.

The extended partition contains its own “sub” or extended partition boot record to identify its subdivisions. This concept of further identifying and defining parameters continues within volumes as well. Volumes also contain boot sectors that identify the file system contained within and its parameters, just as the MBR contains data that identifies itself so to do volumes.

Why are the review and discussion of volumes and partitions so important to the cyber forensic examiner? Partitions in some form or another were covered in the past three chapters; why spend so much time covering, reviewing, and discussing partitions?

Partitions are extremely important as they identify the layout of the hard drive. As a cyber forensic examiner it is extremely important to understand where data resides and how it resides there.

The forensic tools available to investigators today automatically perform much of the function of identifying partitions, and examiners don’t have to go through the painstaking steps of identifying where partitions start and end. Investigators have grown to develop a certain level of dependency on these tools.

However, remove those tools and how are you able to identify the partition type and size? How would you make sense of all the 0s and 1s without the knowledge of knowing where data starts and where it stops? Before you can properly investigate you must properly “enumerate.” What if you are called to the witness stand and then asked to explain such concepts? Stating, “the tool did it for me” won’t be enough, especially not enough to prove your expertise or knowledge of “how” the data were identified, found, and examined.

The importance of identifying or enumerating data can be seen in the ongoing case of Ronelle Sawyer, who is investigating whether Jose McCarthy has potentially engaged in the unlawful distribution of his organization’s intellectual property to a competitor, Janice Witcome, managing director of the XYZ Company.

Jose McCarthy, in an effort to conceal his actions, created two partitions on his 80 GB hard drive; one in which he used for day-to-day activity and a second he used to store his malicious activity. When confronted with the possibility of criminal prosecution he quickly deleted the second partition, therefore making it “invisible” to the operating system.

Ronelle would be able to clearly see that the hard drive is 80 GB, but how would she be able to identify the size of the partition? How would she be able to account for all 80 GB of data?

If the second partition is not identified she may miss a lot of evidence; in this case, all the “essential criminal evidence.”

As a cyber forensic investigator, Ronelle would, by protocol, examine the partition table and see only one partition of 60 GB, and the starting and ending points of that single partition could quickly be determined. Without the use of forensic tools, if Ronelle did not have working knowledge of the specifics and functioning of the partition table, how would our investigator be able to explain the missing 20 GB?

Sure, there are other ways to identify the missing space but the validity of understanding the functioning and role of the partition table remains.

Keep in mind that when deleting a partition only the partition table entry is deleted. All the data contained within the partition remains until they are overwritten. Being that the partition is no longer used and inactive the data contained within will not be overwritten. So it is likely that these data will remain intact and retrievable as part of an investigation.

Identifying the end of the first partition will be helpful to Ronelle in locating the starting point of the deleted partition. Finally, the deleted partition can be recovered and all those data associated with the second partition retrieved, accessed, and analyzed. Recovering a partition, and its critical data information, may be difficult without a firm grasp of the functioning of partitions.

Chapter 8 continues with the natural progression of how the computer “mounts” data and goes into greater detail on the important topics of volumes and file systems, and their relationship to the overall cyber forensic investigation.

NOTES

1. “Chapter 17—Disk and File System Basics,” TechNet, 2010 Microsoft Corporation, retrieved June 2010, http://technet.microsoft.com/en-us/library/cc750198.aspx.

2. Ibid.

3. C. Kozierok, C., “Logical Block Addressing (LBA),” The PC Guide, Site Version: 2.2.0—Version Date: April 17, 2001, retrieved June 2010, www.pcguide.com/ref/hdd/bios/modesLBA-c.html.

4. Ibid.

5. “Appendix C. An Introduction to Disk Partitions,” Red Hat Enterprise Linux 4: Installation Guide for the IBM® POWER Architecture, retrieved June 2010, http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-ig-ppc-multi-en-4/ap-partitions.html.