So now that we’ve already covered the basics and you now you grasp the fundamental concepts of hexadecimal and how it represents data, it’s time to actually apply what you have learned so far toward real world situations. After all, what would be the point of knowing how to read hex if there was no relevant use for it in data recovery and forensics?

First lets take a look at the MBR (Master boot record) for an NTFS file system.

NTFS MBR

As you look over the provided MBR screenshot (Screenshots compliments of Winhex), you will notice I have also provided a legend and have highlighted the appropriate data using various colors.
The two items you should be particularly concerned about are:
BPB (Bios parameter block). This is going to tell you how the sectors are laid out. In most cases (I’m talking well over 90% of cases) the drive will use 512 byte blocks. In some cases (for server applications, etc) the user may use larger blocks (1024 byte for example). This will all be outlined here in the BPB.
The other highly important item is the “End of sector marker” (also called the signature). This should ALWAYS be 55AA. If the signature of the boot sector is not 55AA, then either the file system is damaged or it is not a windows file system. Different file systems use different signatures; NTFS always uses 55AA.
Partition tables are the next stop. The relevance of the partition table is pretty obvious. First of all, it will tell you where each partition begins and ends and how many sectors are in each partition. It will also contain a status byte, which indicates whether the partition is bootable. The boot indicator field is either going to be 80 or 00. 80 means that the partition is a bootable one, and 00 meaning that it is not a bootable partition. Finally, the partition table will include a system ID field which is is going to tell you what kind of file system the partition is for.
The partition table is located in the last 64bytes of the MBR. There can be a maximum of 4 primary partitions, and an unlimited amount of extended partitions. In data recovery you will likely only run into primary partitions on Windows systems as 99% of Windows users only use one or two primary partitions.
The predetermined locations for the partition tables are:
  • Partition 1 0×01BE (446)
  • Partition 2 0×01CE (462)
  • Partition 3 0×01DE (478)
  • Partition 4 0×01EE (494)

80 01                ..
000001C0:01 00 06 0F 7F 96 3F 00 -00 00 51 42 06 00 00 00  …..?…QB….
000001D0:41 97 07 0F FF 2C 90 42 -06 00 A0 3E 06 00 00 00 A….,.B…>….
000001E0:C1 2D 05 0F FF 92 30 81 -0C 00 A0 91 01 00 00 00 .-….0………
000001F0:C1 93 01 0F FF A6 D0 12 -0E 00 C0 4E 00 00 55 AA ………..N..U.

Above is the end of a MBR created using Windows. When reading hex you will notice that the beginning of each line actually starts on the line above it. You can see very easily that the boot indicator for the first partition is 80, follow by 01 which is telling which is the starting head. Future partitions will not list a starting head, but rather simply the starting sector.

At 0×1C2 you will find the value 06. This is the system ID field. This tells you what file system formatted the partition. 06 is a FAT indicator. 07 is NTFS. 05 is an extended partition, and 01is a FAT12 partition. There are many more system ID fields, but these are the ones present in the example above.

The last thing I wanted to talk about is file signatures. Every type of file has a signature, even photos taken with a digital camera have a special signature that can actually tell you what kind of camera took the picture and when. This is the type of thing that you need to really learn for forensics, and can prove to be a very helpful skill for data recovery if you are going to attempt to repair files. There just isn’t enough time and space for me to go into the various types of signatures here, but here is a link to a list of signatures that is constantly being updated:

http://www.garykessler.net/library/file_sigs.html - File signatures

You now have the basic understanding of hexadecimal and the part that it plays in data recovery and forensics. From here you should refine your ability to recognize patterns in the code so that you know when something has been changed or is damaged. Practice is the key here. You should constantly be looking at files in hex so that you can see what a working file should look like. Then, as a learning tool, you can damage that file and take note of the differences that occurred when you damaged it. Look for signatures in all kinds of files and become familiar with their location.

Next week I am going to be returning to the topic of hard drive anatomy, continuing with headstacks and then moving into the details of Servo technology.

HDD Doctor

Bookmark