Pointsec for PC: Master Boot Record Analysis

Occasionally when people are thinking about dual booting computers with Pointsec I get asked about what changes Pointsec makes to the Master Boot Record. The short answer is, none. Pointsec installs its boot code to the Volume Boot Sector. At least that is the stock answer from Checkpoint. Last night I decided to check it out for myself. The following is a harrowing tale of forensics and Pointsecery, but if you don't feel like reading it all, then you can take my word for it. Pointsec doesn't make any changes to the Master Boot Record when it is installed.

So the first step is to establish my hypothesis. Here they are:
H1: Installation of Pointsec does not result in changes to the Master Boot Record.
H2: Installation of Pointsec does result in changes to the Volume Boot Sector.
To test my hypothesis, I created a virtual machine using VirtualBox and loaded Windows XP onto the machine. Then I booted to a Helix disk which allows me to do forensic analysis of the disk.

Once inside helix, I opened up a command prompt so that I could gather the Master Boot Record of my Windows machine. For those of you that are not familiar with File System Forensics, the MBR consists of the first 512 bytes on the hard drive for DOS based systems. I wanted to capture the MBR from this virtual machine on my Mac, so I also opened a command prompt on my Macbook and set up a netcat listener with this command: nc -l 8000 > mbr1.txt. Back in the virtual machine I used dd to gather the MBR and copy it over the network to my Mac: dd if=/dev/hda bs=512 count=1 | nc ip_address_of_mac 8000. To sum up, on the Mac, netcat set up a listener on port 8000 and any data sent to that listener was copied to a file called mbr1.txt. On the Virtual machine dd will copy from the hard drive (/dev/hda). The block size is 512 and we are going to copy one block. The output of dd will be piped into netcat which will set up a connection and transmit the data.

Now that I have my MBR copied, I want to create an MD5 hash of it so that I can quickly detect any changes. On the Mac I typed md5 mbr1.txt and got b8ce0ea32fdf9706ff7b17eac93d7ea4.

Now let's take a look at that Master Boot Record. I opened up the MBR with a hex editor, in this case xxd, xxd mbr1.txt | less. There are two important things to look at in the MBR, the boot code and the partition table. The boot code consists of the first 446 bytes of the MBR. After that you've got the partition table. Here is a photo of the one I copied from the virtual machine. Notice that at the very end you'll find the hex 55aa, which is the signature for the end of the MBR on little-endian systems like mine. The line labelled 00001b0: is the line where the partition table begins and the last set of four is the specifc place where it starts. It begins with the code 80 which means that this partition is bootable. On the next line, in the second grouping of four we see the code 07, which means that this is an NTFS partition. This partition entry ends where all the zeros begin which tells us that there is only one partition on this system.

The next thing I wanted to do was get a copy of the Volume Boot Sector, which is also known as the Partition Boot Record. (PBR). So from my virtual machine that had been booted into Helix, I opened a command prompt. I typed the command fdisk -lu /dev/hda to get a list of partitions, and as expected it came back with one. The partition starts at sector 63, and since my sectors are 512 bytes in size, that means that it begins 32256 bytes into the drive. So I set up my netcat listener again and used the following command on Helix to copy the PBR: dd if=/dev/hda bs=1 count=512 skip 32256 | nc ip_address_of_mac 8000. Once the PBR was copied, I ran an md5 hash of it and got 46223945ddf87f223fc8850483b99cf0. The picture on the left is the Volume Boot Sector from my virtual machine. Notice the first three bytes, 0xEB5290. This is a jump instruction that tells the computer where to go for its next instruction.

Alright, so we've established our baselines. The next step in my experiment was to install Pointsec on my virtual machine. I went through the installation, rebooted, logged in and waited for the disk to start encrypting. Then I shutdown and booted back into Helix.

So I basically repeated the same process as above. I opened a command prompt and copied the Master Boot Record to my Macbook. Then I ran the md5 hash on the second MBR and found that the hashes are the same. Pointsec made no changes to the Master Boot Record on the virtual machine. However, when I checked out the Volume Boot Sector the hashes did not match, which is what I expected. Further inspection of the Volume Boot Sector showed that the jump instruction at the begining had changed to something else. This supports my previous knowledge on the subject of how Pointsec boots. The computer boots the MBR and the MBR sends the computer to the active partition where the Volume Boot Sector contains additional code. Pointsec changes the jump instruction so that instead of running the Windows code, the Pointsec code is run first.

So let's follow up on my hypothesis:
H1: Proven true in this case by the MD5 hashes. No changes to the MBR.
H2: Proven true in this case by the MD5 hashes. Changes to the jump instructions and possibly other changes.