Partition Table under the Microscope

You've seen the partition table indirectly, through the lens of somebody's utility. They read it for you, then re-depict it to you. Their way. For example, linux's fdisk utility shows you something like:

while Microsoft's presentation format (for some other partition) is a little different

and the FIPS utility shows you the stuff yet another way. Perhaps you'd like to see it directly, byte for byte, just as it actually lies on the disk.

That can be arranged. While we're at it, why not take in the entire MBR. We don't have a tool for looking straight at the MBR, but we have a tool for looking straight into a file, and another for capturing the MBR into one. (The first tool is the od  command, the second is the dd command.) So let's do it that way in 2 steps.

First we have to catpure a copy of the MBR into a file. Unix blurs the line between files and devices (or maybe other operating systems differentiate them artificially.) There is a utility called dd (device-to-device copy) whose role in life is to copy files back and forth to devices, or devices back and forth to files, or devices to devices, or files to files. Look at the following. "if" stands for "input file;" "of" stands for "output file." Look again. Analyze it.

[root@EMACH2 mydir]# echo ABC > abcfile
[root@EMACH2 mydir]# dd if=abcfile of=copyofabcfile
0+1 records in
0+1 records out
[root@EMACH2 mydir]# cat abcfile
ABC
[root@EMACH2 mydir]# cat copyofabcfile
ABC
[root@EMACH2 mydir]# ls -l
total 8
-rw-rw-r-- 1 root root 4 Mar 22 23:51 abcfile
-rw-rw-r-- 1 root root 4 Mar 22 23:51 copyofabcfile

Seems like dd can substitute for cp. But didn't somebody say something about devices? OK. You've heard of linux devices before. In particular, hard drives and their linux names. You know that the first hard disk generally is called /dev/hda. The floppy goes by /dev/fd0. They all use names like that, /dev/something. Well, dd doesn't differntiate between a device and a file. Each is a wide spot where it can lay down long strings of bytes one after the other end-to-end off into the distance over the horizon. If dd had 1440k bytes and wanted a place to put them, well a file is such a place. And a floppy disk is also such a place. From that perspective they are just the same. So you can name a device as either the "if" or the "of" as far as dd is concerned. You are not limited to files there. Like this for example:

dd if=/dev/fd0 of=floppy.img

The above command will create a file named floppy.img in your current directory (which is probably on your hard disk). Inside it will be all 1440k bytes that are inside the floppy. All the floppy. The parts of the floppy that might be considered files. And the parts of the floppy that might be considered empty or free space. Plus the parts of the floppy that might be considered its directory. Of course, you can't (normally) get at the "files" that the floppy contains as embedded inside the floppy.img file. Nor does the portion that functions within the disk as a directory do so while reposing within that file. So what good could this file be? How about inserting a fresh diskette and:

dd if=floppy.img of=/dev/fd0

Make an image of your floppy. Or, if you want to give your friend in Africa a copy of your floppy, you can email him its image file and he can manufacture the duplicate himself in Nairobi with dd. It'll take about 10 minutes altogether for both of you. This improves on the alternative, your manufacturing the duplicate and sending it physically by mail.

Now that you understand that, understand that you can read only part of the content of a file or device. You don't have to take the whole thing. You specify a block size and a count. Like:

dd if=/dev/fd0 of=halfdisk.img bs=1024 count=720

dd will read bs at a time, and repeat itself count times. So here, it will read (from /dev/fd0) and write (to halfdisk.img) 1024 bytes at a time, and do so 720 times. That'll get it half the disk (since the disk has 1440 of those 1024 byte or 1k chunks to it, and you're taking only 720 of them). What do you say we do this now:

dd if=/dev/hda of=firstsect.img bs=512 count=1

What do we get? Well here we've read chunks of 512 bytes at a time, starting from the beginning of the disk, and we did so once. So the first 512 bytes of the disk is what we have captured in the file. Wait a minute. Did somebody say "first 512 bytes of the disk?" Isn't that what the MBR is? Yes, we now have the MBR where we want it, in a file.

Let's take a photo of it now that we've got it. The "camera" is the od command. od stands for "octal dump." It can "dump," or show you, the content of a file, byte for byte, using the octal number system. But it can also show those bytes using the more familiar hexadecimal number system or even more familiar decimal system. To scrutinize the bytes in a file, and see them written in hexadecimal, use this command:

od -Ad -tx1 <filename>

To scrutinize them again, but see them written in decimal instead, use:

od -Ad -tu1 <filename>

For example, if there is a file containing the 3 bytes ABC, viewed through od it looks like:

The file /home/ftp/pub/ABC exists on the remote Unix machine and you can practice on it. (41 is the ascii code for capital A, in hexadecimal; 65 in decimal is the same as 41 in hexadecimal, so is also the ascii code for capital A). Another file to try is /home/ftp/pub/dumpme. Do the following:

Here, the -Ad option says "show numbers at left giving the bytes' ordinal postitions, and use decimal to do so." The -tx1 says the type of presentation desired is hexadecimal (x), 1 byte at a time. In -txlz, the z says "please also display the bytes as text on the right side." And the -tul says the type or presentation desired is decimal (u, or "unsigned decimal") . Try these command variants on the ABC and dumpme files to get comfortable with them. Now you will apply them to an mbr-image file that I supply you in the assignment.

When you examine the screen output of the od command applied to the mbr image file, recall the layout of the mbr and the location of the partition table within it. That will allow you to pick out the partition records from the display, in order to answer the questions. Here's the MBR's layout:

The whole thing is 512 bytes long (446 + 64 + 2). The partition table occupies by 447th through 510th bytes. Each 16 records within the table constitutes a separate individual partition record. Each record describes one of the (possible) 4 partitions that the disk could hold.

The Assignment Itself

Please find the file /home/public/mbr-assignment.img on the remote Unix machine. I created it from a hard drive using the dd command. I had first divided the hard drive into partitions for this assignment. The file contains a copy of the hard drive's MBR. The assignment consists of answering the 11 multiple-choice questions below on a Scantron #882 form. There is a 12th question. It is not multiple-choice, and is extra credit. If you do it, write the answer to it directly on the Scantron form right under the "Name/Subject/Date" box. In order to answer the 11 questions, you must dump my MBR image file and carefully analyze what you see to extract the correct responses. I anticipate you will log in to the remote Unix machine, dump the file to the screen, and answer the questions while viewing the dump(s). If you have your own Unix machine where you would like to work, you can download a copy of the mbr-assignment.img file to work with there.

The basis for doing this assignment is the class discussion of the partition table record, and the corresponding write up "Interpreting Partition Records."  Understand it before performing the assignment. Also please see the relevant resources posted on the class website about number systems if you need to review hexadecimal numbering. For this assignment, you can rely on the -tx and -tu options of the od command to give you output in either hexadecimal or decimal as you require, minimizing your need to do manual conversions between the 2 numbering systems. Let od do that work for you.