Monday, January 5, 2009

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 t
o start encrypting. Then I shutdown and booted back into Helix.

So I ba
sically 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.

6 comments:

Anonymous said...

Hello,

I'm seeking a way to build a WinPE2.0 ISO which can boot a computer has pointsec6.3.1 installed. After that I can access the files on C: or D: (I know how to build a WIM by using WAIK and installed the WIM file on HDD to dual boot computer.)

I found a tool called PSWinRE.exe under pointsec\1_Pointsec for PC\Tools\MS Windows RE folder and configured the PSWinRE.ini according to the sample. However, after running the tool, it seems the prot_2k.sys has not been added to the WIM file and it cannot access C: D: says the volume is unrecognized format.

Do you know how to make a WinPE2.0 CD which include pointsec6.3.1 driver so that I can access the local C: D: ? .

Thanks very much.

Anonymous said...

Hello,

I'm seeking a way to build a WinPE2.0 ISO which can boot a computer has pointsec6.3.1 installed. After that I can access the files on C: or D: (I know how to build a WIM by using WAIK and installed the WIM file on HDD to dual boot computer.)

I found a tool called PSWinRE.exe under pointsec\1_Pointsec for PC\Tools\MS Windows RE folder and configured the PSWinRE.ini according to the sample. However, after running the tool, it seems the prot_2k.sys has not been added to the WIM file and it cannot access C: D: says the volume is unrecognized format.

Do you know how to make a WinPE2.0 CD which include pointsec6.3.1 driver so that I can access the local C: D: ? .
I'll be very appreciated if you could share me the method.

Thanks very much.

Anonymous said...

Good article but it is a pitty you did not go further. Suggestions: It is true standard MBR is 512bytes, but there existis extended MBR which can take Nx512bytes - so these should be checked as well. Is Pointsec located really in MBR of the partition or is it in main extended MBR? What will happen if you change one insignificant byte in MBR with Pointsec - will it refuse to boot? If not we have a good start to sort the problem with dual boot and MBR...

Marek said...

Hi,

I have currently reviewed a couple of FDE solutions from Check Point and from Guardian Edge, CP make a big point of the fact that their solution does not encrypt MBR, GEdge however make an equally big point of the fact that their product encrypts the whole HDD including the MBR.

Could you please briefly summarise the pros and cons of both angles (encrypted/not encrypted MBR)?

Thanks!

Black Fist said...

@Marek
It's a trade-off between operability and security. Since Checkpoint doesn't encrypt the MBR, you are able to dual boot your machine with other operating systems (mine is running Ubuntu and Vista). You also don't have to worry about something getting screwed up when some piece of software wants to write to the MBR for some reason. I seem to remember that TrueCrypt had a problem with some Adobe products that were writing to the MBR for anti-theft reasons. You get increased useability, but then of course your MBR is not encrypted. Still I don't know of anyone that even accidentally keeps sensitive company data in their MBR. I'm curious how they are able to encrypt the MBR though. I mean, unless you have a tricked out BIOS that can read the encrypted data some part of the hard drive has to be unencrypted for the boot process to work.

Marek said...

Thanks for immediate response which, incidently, sums up all I wanted to know so thanks again for your effort.

As it turns out GEdge FDE doesn't acutally encrypt MBR, what they do is copy the original MBR to another part of the disk, encrypt it and use it for SSO apparently, this is all I could find out from their pre sales TAM and sadly he was not able to elaborate on details.