06: Acquisition, Volumes, MBRs

Introduction

In previous lectures, we dealt with problems of parsing and carving individual files or portions of files. Now, we’ll turn our attention to one of the major tasks of digital forensics: disk drive imaging (“acquisition”) and analysis of the data so acquired.

So what does it mean to “image” a drive? It means we make a bit-for-bit copy of the raw data stored on that drive and save it as a file on another computer. This is usually referred to as a “raw image” of the drive.

We’ll restrict our attention to the use of OS-level acquisition tools, though there are (in older machines) tools that access drives through the BIOS, and there are hardware-based acquisition tools as well. Carrier provides an (older) summary in the text that we will not start to use more heavily.

Drives on computers

Depending upon your OS, you might have graphical tools and/or command-line tools built into the system to view drives on your computer. For example, on OS X I can use “Disk Utility” to examine the drives that are mountable on a system (demo w/ laptop and USB drive). The menu “Apple->About this Mac->System Report” shows a comprehensive view. Select the item “Hardware->NVMExpress” to see your internal SSD drives (on a MacBook Pro). USB-based external storage will show up on the USB item.

On a Linux system, there are various ways to see what drives are available. mount shows which drives (partitions, actually) are mounted. (OS X supports this command too.) During boot, the kernel shows a list of hardware as it’s detected. You can use dmesg to view this log after-the-fact. (Demo on virtual machine and/or elnux.)

PCs generally often have some sort of “boot menu” that lets you see what drives are attached, too, using the BIOS (or these days, UEFI running on built-in firmware that runs on the computer’s motherboard) but I can’t demo that on my Mac. We can see an example bios from vmware.

You need to hit F2 very fast to see this screen.

Given a particular drive, we can turn to The Sleuthkit (TSK)’s `mmls to interrogate it. Here’s a drive I have attached to my computer.

% mmls /dev/disk2 
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Safety Table
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  Meta      0000000001   0000000001   0000000001   GPT Header
003:  Meta      0000000002   0000000033   0000000032   Partition Table
004:  000       0000002048   0000194559   0000192512   disk image
005:  -------   0000194560   0000195352   0000000793   Unallocated

You can think of hard disk drives (old-style spinning metal or newer SSDs) as a giant array of bytes. This obviously isn’t the most useful view all the time (where did I put my program? At byte 3D7A149F?) but it is the most fundamental way to view the drive.

Unix-like OSes (including macOS) expose disk drives as a file, stored in a special location. Most devices that can be exposed as files are in the /dev directory, and disks are no exception. Be very careful messing around with things in your /dev directory. You can definitely erase all your data!

If you want to play around, create a virtual machine and mess with that. One huge hint for messing around with a VM and needing to use sleuthkit on it: when you allocate space for a virtual drive, you have to pre-allocatethe space, and make sure it’s a “flat” file and not resizable or growable. You need at least 40GB to create a windows virtual machine.

Here’s the first 512 bytes of my windows hard disk (vm). 512 is the standard sector size of a disk. (Akin to an 8x11 side of a page of paper.) I have to do this from outside windows. In this case, from my mac.

% hexdump -n 512 -Cv Virtual\ Disk-flat.vmdk
00000000  fa fc 31 c0 8e d0 8e d8  bd 00 7c 8d 66 e0 fb b8  |..1.......|.f...|
00000010  e0 1f 8e c0 89 ee 89 ef  b9 00 01 f3 a5 ea 22 7c  |.............."||
00000020  e0 1f 8e d8 8e d0 31 c0  8e c0 8d be be 01 f6 05  |......1.........|
00000030  80 75 6d 83 c7 10 81 ff  fe 7d 72 f2 e8 c4 00 6e  |.um......}r....n|
00000040  6f 20 61 63 74 69 76 65  20 70 61 72 74 69 74 69  |o active partiti|
00000050  6f 6e 20 66 6f 75 6e 64  00 eb fe e8 a5 00 72 65  |on found......re|
00000060  61 64 20 65 72 72 6f 72  20 77 68 69 6c 65 20 72  |ad error while r|
00000070  65 61 64 69 6e 67 20 64  72 69 76 65 00 eb da e8  |eading drive....|
00000080  81 00 70 61 72 74 69 74  69 6f 6e 20 73 69 67 6e  |..partition sign|
00000090  61 74 75 72 65 20 21 3d  20 35 35 41 41 00 eb b9  |ature != 55AA...|
000000a0  e8 10 00 72 b6 26 81 3e  fe 7d 55 aa 75 d1 ea 00  |...r.&.>.}U.u...|
000000b0  7c 00 00 bb aa 55 b4 41  cd 13 72 32 81 fb 55 aa  ||....U.A..r2..U.|
000000c0  75 2c f6 c1 01 74 27 eb  10 10 00 04 00 00 7c 00  |u,...t'.......|.|
000000d0  00 00 00 00 00 00 00 00  00 8b 45 08 a3 d1 7c 8b  |..........E...|.|
000000e0  45 0a a3 d3 7c b8 00 42  be c9 7c cd 13 c3 b8 04  |E...|..B..|.....|
000000f0  02 bb 00 7c 8b 4d 02 8a  75 01 cd 13 c3 31 db b4  |...|.M..u....1..|
00000100  0e cd 10 5e ac 56 3c 00  75 f3 c3 00 00 00 00 00  |...^.V<.u.......|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  02 18 ba ac 00 00 80 20  |............... |
000001c0  21 00 07 7f 39 06 00 08  00 00 00 90 01 00 00 7f  |!...9...........|
000001d0  3a 06 07 fe ff ff 00 98  01 00 00 60 fe 04 00 00  |:..........`....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

Here’s the first 512 bytes of my ubuntu hard disk. Because it’s linux, I can do this from within the vm itself.

sudo hexdump -C -n 512 /dev/sda
00000000  eb 63 90 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |.c..............|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 80 01 00 00 00  |................|
00000060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...........t...p|
00000070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |t....y|..1......|
00000080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 bb 17 04  |. ..d|<.t...R...|
00000090  f6 07 03 74 06 be 88 7d  e8 17 01 be 05 7c b4 41  |...t...}.....|.A|
000000a0  bb aa 55 cd 13 5a 52 72  3d 81 fb 55 aa 75 37 83  |..U..ZRr=..U.u7.|
000000b0  e1 01 74 32 31 c0 89 44  04 40 88 44 ff 89 44 02  |..t21..D.@.D..D.|
000000c0  c7 04 10 00 66 8b 1e 5c  7c 66 89 5c 08 66 8b 1e  |....f..\|f.\.f..|
000000d0  60 7c 66 89 5c 0c c7 44  06 00 70 b4 42 cd 13 72  |`|f.\..D..p.B..r|
000000e0  05 bb 00 70 eb 76 b4 08  cd 13 73 0d 5a 84 d2 0f  |...p.v....s.Z...|
000000f0  83 d0 00 be 93 7d e9 82  00 66 0f b6 c6 88 64 ff  |.....}...f....d.|
00000100  40 66 89 44 04 0f b6 d1  c1 e2 02 88 e8 88 f4 40  |@f.D...........@|
00000110  89 44 08 0f b6 c2 c0 e8  02 66 89 04 66 a1 60 7c  |.D.......f..f.`||
00000120  66 09 c0 75 4e 66 a1 5c  7c 66 31 d2 66 f7 34 88  |f..uNf.\|f1.f.4.|
00000130  d1 31 d2 66 f7 74 04 3b  44 08 7d 37 fe c1 88 c5  |.1.f.t.;D.}7....|
00000140  30 c0 c1 e8 02 08 c1 88  d0 5a 88 c6 bb 00 70 8e  |0........Z....p.|
00000150  c3 31 db b8 01 02 cd 13  72 1e 8c c3 60 1e b9 00  |.1......r...`...|
00000160  01 8e db 31 f6 bf 00 80  8e c6 fc f3 a5 1f 61 ff  |...1..........a.|
00000170  26 5a 7c be 8e 7d eb 03  be 9d 7d e8 34 00 be a2  |&Z|..}....}.4...|
00000180  7d e8 2e 00 cd 18 eb fe  47 52 55 42 20 00 47 65  |}.......GRUB .Ge|
00000190  6f 6d 00 48 61 72 64 20  44 69 73 6b 00 52 65 61  |om.Hard Disk.Rea|
000001a0  64 00 20 45 72 72 6f 72  0d 0a 00 bb 01 00 b4 0e  |d. Error........|
000001b0  cd 10 ac 3c 00 75 f4 c3  8a c1 63 6f 00 00 80 04  |...<.u....co....|
000001c0  01 04 0b fe c2 ff 00 08  00 00 00 00 10 00 00 fe  |................|
000001d0  c2 ff 05 fe c2 ff fe 0f  10 00 02 e8 6f 02 00 00  |............o...|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

and of a USB key:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  60 9d b9 ec 00 00 00 00  |........`.......|
000001c0  21 00 06 2a ea ca 20 00  00 00 e0 b7 3b 00 00 00  |!..*.. .....;...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

There are some similarities with the two OS images. And notice that all three with the values 55 aa. Not a coincidence!

Imaging a drive

I kinda already let the horse outta the barn, above: you can directly read these “files” and you’ll get the bytes from the disk. Of course, we don’t usually do it with hexdump. Instead, there are various utilities that can do it for you. The simplest such is dd, which just copies bytes block-by-block (default: 512 bytes at a time) from an input (default: standard in) to an output (default: standard out).

The basic invocation looks like this:

dd if=/dev/sda of=/Users/brian/disk-image.dd bs=512

If you were to switch the two of= and if= arguments, you would make your drive inaccessible and possibly overwrite the whole thing! (I’ve done this by accident, it ruins your month.) Also speak aloud what you have written as the arguments to dd as a safety check (or get a write blocker, or do this with a vm).

ALSO, what I wrote won’t work! I can’t image an entire drive into a file inside a filesystem on the drive I’m imaging, for obvious (I hope) reasons. Usually, you need another drive to capture the data to. For demonstration purposes, I’ll limit the count of blocks here so that (a) data fits and (b) it doesn’t take all day.

$ sudo dd if=/dev/sda of=/home/brian/disk-image.dd bs=512 count=10
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.00045468 s, 11.3 MB/s

I can also compute a hash of the file and/or the drive:

shasum /dev/sda   # note that this will take a looong time

Again, I can read just some of the drive for demonstration purposes:

brian@ubuntu:~$ sudo dd if=/dev/sda bs=512 count=10 | sha1sum 
10+0 records in
10+0 records out
5120 bytes (5.1 kB, 5.0 KiB) copied, 0.000128855 s, 39.7 MB/s
cf85a82e24fd5d6ed5ff7a418835bd781b55969a  -

And check the bytes I saved:

brian@ubuntu:~$ sha1sum disk-image.dd 
cf85a82e24fd5d6ed5ff7a418835bd781b55969a  disk-image.dd

There are a couple other details to consider. First, what if the drive has errors? The simplest thing to do is replace the sectors you cannot read with just 0s in the image. You must pass two options to the conv argument of dd to make this happen:

dd if=/dev/rdisk0 of=/Users/liberato/disk-image.dd bs=512 count=10 conv=noerror,sync

noerror means to not stop on error, and sync pads erroneous read with NUL (zero) bytes. See man dd for more details. Carrier has a discussion as well.

(Data recovery of corrupted hardware is beyond the scope of this course.)

Finally, a note expounded upon more in the text. In this day and age, forensic exams that are conducted on-site are conducted according to a protocol, written down ahead of time.

Machines that are off are brought back to a lab, and the drive is imaged. But notably, we don’t (usually) boot the OS on the machine; instead we boot from a known-good OS (like, say a Linux LiveCD) and use it to run the imaging operation. We might also interpose a hardware and/or software “write blocker” to prevent making changes to the drive being imaged. This overall process is called a “dead acquisition.”

In contrast, a “live acquisition” is performed on a running machine. Usually, we might dump memory of an active machine or do other memory forensics (a topic we don’t cover), then decide whether to attempt a live acquisition or to shut the machine down to prevent further changes. Lots of factors to consider here, including:

technical sophistication of the user
presence of disk encryption
rootkits
etc.

that go beyond the scope of this lecture. (If you are interested in memory forensics, check out a system called Volatility.)

Interpreting the data: Disk volumes

So now we know how to get some or all of the raw data from a disk. What does it mean?

To answer this question, we’re going to first introduce some terminology and sketch some abstract examples of how disks are organized. Then we’ll dive into some specifics.

“Volumes” are organized by “volume systems”, assembled from one or more disks, usually but not always 1:1. A volume is a collection of addressable “sectors” (sometimes also: “blocks”) which are the smallest unit of addressing that most disk controllers support (older disks: 512 bytes; newer disks can be larger (4KB or Advanced Format) but have backward-compatibility translation layers(!!)) that appear continuous to the OS.

Volumes are usually divided into one or more “partitions”. A partition names a particular collection of consecutive sectors in a volume. For example, a Mac’s HD has two user-visible partitions (show in Disk Utility), as well as two that are not visible through the GUI show in System Report (note this is a mac from 2018, the latest macOS does things differently):

EFI:
  Capacity: 209.7 MB (209,715,200 bytes)
  BSD Name: disk0s1
  Content:  EFI
  Volume UUID:  BDC1974F-6B8C-3DAE-9DB2-3AA3C17BF506
disk0s2:
  Capacity: 299.42 GB (299,418,038,272 bytes)
  BSD Name: disk0s2
  Content:  Apple_CoreStorage
Recovery HD:
  Capacity: 650 MB (650,002,432 bytes)
  BSD Name: disk0s3
  Content:  Apple_Boot
  Volume UUID:  42320CA6-833A-3699-AAC3-64080DD45FF8
Cobalt:
  Capacity: 199.86 GB (199,864,942,592 bytes)
  Available:    198.94 GB (198,938,521,600 bytes)
  Writable: Yes
  File System:  Journaled HFS+
  BSD Name: disk0s4
  Mount Point:  /Volumes/Cobalt
  Content:  Apple_HFS
  Volume UUID:  42E09BD5-9547-36E4-9879-4BB9C01484EB

And here’s a partition on the USB storage key fob thing:

USB:
  Capacity: 2 GB (2,003,812,352 bytes)
  Available:    2 GB (2,001,010,688 bytes)
  Writable: Yes
  File System:  MS-DOS FAT16
  BSD Name: disk2s1
  Mount Point:  /Volumes/USBkey
  Content:  DOS_FAT_16
  Volume UUID:  8117D4F3-4CD8-38D5-8B94-75D720C736A5

Different operating systems and devices use different methods of partitioning drives and labeling them, though most modern consumer PC hardware and OSes (Windows, Mac, Linux) these days are converging on two standards: the newer Unified Extensible Firmware Interface’s GUID Partition Table (GPT) format, and legacy support for the Master Boot Record (MBR) format (notably, on basically every USB thumb drive and SD storage card in existence, as well as older PCs). There are other formats, but understanding these two will give you the basis to understand others if you need to. (Btw, GUID stands for Globally Unique IDentifiers – each partition is given a GUID. Some people refer to GPT as GUID.)

If you want to carve out individual partitions, you can use mmls to find their offsets, then dd to read/write them (note you can pass a skip or iseek parameter to dd). But usually you would just operate on the entire image; most tool sets (TSK included) have other, volume-aware tools to deal with individual partitions, as we showed in our demo in Lecture 2.

The Master Boot Record

The older master boot record (MBR) style of partitioning (sometimes called “DOS” style, as that is the operating system that popularized this format) has no formal standard, though it’s well documented in many places since it’s so ubiquitous.

In its simplest form, a MBR contains three things:

bootcode (literally: its executable code that the BIOS will load then execute)
a partition table
a signature

Note that modern MBRs on HDDs and SSDs don’t contain bootcode – the firmware handles this now, and the bootcode area is used for other information instead. We’ll talk more about this when we get to UEFI. (See https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout.) And MBRs on USBs don’t usually contain bootcode either. (In the long long ago, PCs could boot from a floppy disk. The code to boot the computer appeared in the MBR. A lot of malware was propagated this way.)

The signature value we’ve seen already: The last two bytes of a sector containing a MBR are 55 AA; this is another “magic number” not unlike the SOI/EOI tags in a JPEG file (i.e., FFD8/FFD9). Seeing this signature it is not a guarantee of a valid MBR, but not seeing it means it’s definitely not an MBR.

A disk with three partitions has an MBR with three partitions, and the MBR has entries for each of the three partitions. These entries are stored in the partition table. At most four entries can appear in the MBR in the first section; a drive that is partitioned into more than 4 partitions uses another sector to list them for the OS.

Each of the (at most four) entries contains the following (https://en.wikipedia.org/wiki/Master_boot_record#PTE):

status/flags (1 byte).
starting CHS address (3 distinct bytes, but ignore)
type (1 byte)
ending CHS address (3 distinct bytes, but ignore)
starting LBA sector (4 bytes)
number of sectors (4 byte s)

Status indicates if a partition can be used to boot into an operating system. 0x80 indicates it is bootable; 0x0 otherwise.

CHS is a legacy system (when disk locations where referred to by Cylinder / Head / Sector, see https://en.wikipedia.org/wiki/Cylinder-head-sector if you’re curious) and basically irrelevant these days. These values are often hardcoded to various marker values that indicate that Logical Block Addressing (LBA) address should be used instead, e.g., (1023, 254, 63) or (1023, 255, 63).

The type is a value you look up in a table (e.g., https://en.wikipedia.org/wiki/Partition_type) though different OSes and tools might name different types slightly differently due to the lack of a standard here.

The LBA sector is an offset from the start of the disk, in terms of 512-byte sectors, to the start of the partition, and the number of sectors tells you how bit that partition is. Easy-peasy.

Or is it? What if you want more than four partitions on a disk?

MBR and extended partitions

If you want more than four partitions on a disk, instead of a nice neat MBR table, you end up with a hybrid. (Up to) the first three partitions are treated as normal and given entries in the MBR. The last partition in the MBR is turned into a “Primary Extended Partition,” which is further subdivided into what looks like a linked-list of “Secondary Extended Partitions.”

Each of these extended partitions starts with an “Extended Boot Record” which is just a simplified version of the MBR, containing two entries:

The first entry is the data partition as you’d expect: it points to the data partition (offset from this EBR) and contains the length of this partition, in sectors.
The second entry is the address of the next EBR relative to the start of the primary extended partition; it’s length includes all sectors in that span up to the end of that partition, not just filled ones (as some sectors can be unallocated for various reasons).

Extended partitions are a PITA but are becoming more rare as GPTs are becoming standard. (And MBRs on USB keys and the like typically have just a single partition, so generally no extended partition nonsense occurs there.)

Let’s pull up the MBR documentation on Wikipedia https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout (see also Carrier for a good alternative presentation) and the MBR of my USB key, and see what we can see:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  60 9d b9 ec 00 00 00 00  |........`.......|
000001c0  21 00 06 2a ea ca 20 00  00 00 e0 b7 3b 00 00 00  |!..*.. .....;...|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200

Very important: All multi-byte fields are little endian in the MBR!

Let’s look at just the partition table, starting at 0x1BE:

00 00 21 00 06 2a ea ca 20 00 00 00 e0 b7 3b 00

And now let’s parse it:

https://en.wikipedia.org/wiki/Master_boot_record#PTE

00: status (not bootable)
00 21 00: CHS start (ignore)
06: type 0x06 is FAT-16 https://en.wikipedia.org/wiki/Partition_type
2a ea ca: CHS end (ignore)
20 00 00 00: LBA start, in this case 32 sectors from the start of the disk
e0 b7 3b 00: number of sectors in partition (not its LBA end!)

To convert in Python (don’t forget the “little” argument!):

>>>int.from_bytes(bytes.fromhex('e0 b7 3b 00'),"little")
3913696

Does this match mmls?

mmls /dev/rdisk2
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000000031   0000000032   Unallocated
002:  000:000   0000000032   0003913727   0003913696   DOS FAT16 (0x06)

Look at that! We can parse MBRs! In fact that’s your job for the next assignment.

To build your own parser, you need to examine Tables 5.1, 5.2, and 5.3 in Carrier.

A note about partitions and slack

There’s nothing in the MBR that implies all sectors will be part of a partition. Space that’s not allocated is not accessible under OSes. One could imagine deleting a partition entry in an MBR to “hide” it from examination, and putting it back in when you wanted to access the data.