SANS Digital Forensics and Incident Response Blog

SANS Digital Forensics and Incident Response Blog

Decrypting a PointSec Encrypted Drive Using Live View, VMWare, and Helix

Doing it the HARD way!

Perhaps you remember my previous blog on EnCase and PointSec, which included my plea for Guidance Software and CheckPoint to work together to create a seamless way to decrypt drives without having to go through 20 or 30 steps to get there. I even wrote, out of desperation, A Case for Decryption of the Original, because it would save time consuming steps and not change the data relevant to an investigation.

Time for an update. As noted in my last blog on decrypting the original, VMWare no longer recognizes a raw disk as a valid disk image. Images have to be converted before VMWare will recognize them.

Here is a new and "improved" method that will result in a COMPLETE decrypted image without changing the original. It is more painful because more steps are involved, but it works. (Today). That being said, I STILL want PointSec, now called "End Point Security," to work with Guidance to create a driver that could be used to directly access the disk image and decrypt it in EnCase. This can't be rocket science, right? Let me add an encrypted image to the case, key in a password, and access the data.

In the mean time, gather your tools. You will need the dcfldd for Windows, Live View application, VMWare Server, and Helix for imaging. (Twice).

  1. Use Helix or your other favorite method to acquire a raw image of the drive to be decrypted. (There is an open source version of Helix you can download for free, or you can purchase Helix Pro in order to have support, if your prefer.) [Watch for my upcoming blog on using dcfldd to acquire a raw image.]
  2. Use Live View to convert the raw image to a VMDK file. (You will have to have the correct versions of VMWare to read the VMDK. Live View will inform you what version of VMWare you should be running.)
  3. Acquire the PointSec recovery file from the administrator. (This whole process assumes that you have the administrator ID and password for an administrative install of PointSec. If you don't have that, you are reduced to a manual brute force attack. Good luck!)
  4. Using the PointSec recovery file, create Recovery Media. (Believe it or not, you need a real floppy disk to do this. Can't just create a raw floppy image. Go figure.)
  5. Create a raw image of the floppy disk in a file on the Windows hard drive using the following command:
    dcfldd if=\\.\A: of=filename.img
    (requires you have dcfldd installed — available from sourceforge.com
    If you use linux, refer to the floppy drive device (if=/dev/fd0 or as appropriate for your system) as the input file instead of the above syntax.)
  6. Copy the resulting floppy image to your VMWare server where you intend to decrypt the image.
  7. Open VMWare
  8. Select the VM created by Live View, but do NOT start the machine. (Note that you will not have to create a new virtual machine. Live View handles all that. But also note that Live View creates a snapshot and other files as well, which cannot be read directly into EnCase Forensic. That is why we must do the final acquisition with Helix in this process.)
  9. Add a floppy drive to the VM configuration and select the image created above as the floppy virtual drive. Make sure it will "Connect on Power On" so that the machine will boot to the floppy
10. Edit the CD Rom settings and set it to use an ISO image. Point to a copy of the Helix ISO image. (This is for acquiring the decrypted drive later, but will not be used for the decryption step.)

11. Start the Virtual Machine — it will boot to the floppy image.

12. Enter the requested PointSec administrator credentials and start the decrypt process. The VMDK image will be decrypted.

13. Once you have entered the credentials, the program begins decrypting the hard drive image, posting a % complete message as it goes.

14. Once decrypted, reboot the VM

15. Hit escape ONE TIME during boot to get Boot Menu. (If you hit escape too many times, VMWare will blow by the boot menu, but not to worry, because we have left the floppy image set up as the boot drive. That way the decrypted image will not boot and will, therefore, remain unchanged for maintaining Chain of Custody.)

16. Select CD-Rom from the boot menu to boot to the Helix CD-Rom.

17. Run Helix from the CD.

18. Insert a USB drive with enough spare space to receive the image from the "target" machine. You will mount it later. Helix is able to mount NTFS in read/write mode, so your portable drive can be formatted using NTFS.

19. Once Helix has booted up, use the VMWare toolbar option: VM/Removable Devices/USB Devices to select the USB drive for writing the acquired decrypted image.

20. Open a Terminal Session by clicking on the terminal icon in the Helix tool bar.

21. Execute the following command in order to get root prompt: sudo su —

22. Execute the following command in order to determine drive designations: fdisk —l [note that is dash lower case L, not I or 1]

23. Once the USB drive has been added to the VM, if it is formatted using NTFS, use the following command to mount the drive:
mount —t ntfs-3g /dev/sdx1 /media/sdx1 —o force
(substitute correct letter for x based on the results of your fdisk —l listing)

24. Create a directory on the USB drive to receive the image.

25. Change to the directory you just created.

26. Execute the following command in order to record disk parameters for the case: fdisk —l > fdisk.txt

27. Use the following command to acquire the image:
dcfldd if=/dev/sdx of=filename.img conv=noerror,sync hash=md5 hashlog=filename.img.md5

28. Once completed, for the record, do the following command to save the history of commands into file:
history > history.txt, then save the mount config in case anyone asks about that with:
mount > mount.txt

29. Now you have a raw, decrypted image that can be read into EnCase and properly acquired for analysis. Using this method, the original disk is untouched, and the only change to the disk image is that it was decrypted. This preserves proper Chain of Custody and avoids contamination of the evidence.

Whew, that was way too painful. In my next blog, I will share a method of "slaving" the target drive so that it can be acquired directly into EnCase with the hard disk left in its original state. Still not as easy as it ought to be, but much easier than the VMWare method. The only caveat is that the "Slave" method will allow us to image the decrypted partition(s), but will not allow decryption of the entire hard drive. So at some point, it may be necessary to use the method in this post, not the "Slave" method.

J. Michael Butler, GCFA Gold #00056, is an Information Security Consultant employed by a fortune 500 application service provider who processes approximately half of the $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide security incident management plan and information security policies for his corporation. He can be reached at jmbutler_1 at hotmail dot com.

20 Comments

Posted September 11, 2009 at 3:39 PM | Permalink | Reply

Matthew

You can also use FTK Imager's ability to parse vmdk files to cut this process short after step 13. Point FTK Imager at the decrypted disk's vmdk and use it to create a "dd"-style (or E01) image of the decrypted disk.

Posted September 11, 2009 at 9:04 PM | Permalink | Reply

Chad Holmes

There is a much easier way.. Using CHKP Dynamic Mount Util.

1.Attach the encrypted hard drive to the write blocker, which is connected to my lab machine over USB.
2.You may have to go into Disk Management and assign it a drive letter since it is a raw drive.
3.Open the Check Point FDE Dynamic Mount Utility.
4.Select the encrypted drive.
5.Browse to the directory where the Pointsec recovery key is stored.
6.Enter in your master password
7.Hard drive is now unlocked.

Run whatever you want...

Posted September 14, 2009 at 3:50 AM | Permalink | Reply

guodan

<a href="http://www.air-max-shoes.com/Impax_Run_2.html">Impax Run 2</a>
<a href="http://www.air-max-shoes.com/Air_Max_96.html">Air Max 96</a>

Posted September 14, 2009 at 3:36 PM | Permalink | Reply

J. Michael Butler

I appreciate all the comments. Thanks!

Please note that mounting a decrypted partition is not the same thing as decrypting the entire drive.

While this procedure is obviously very painful, there is one thing it will give you that other procedures won't - and that is the reason I have kept this procedure as an option. The above procedure allows us to acquire a COMPLETE image of the hard drive, including boot sector and other less accessible areas of the hard disk. In most cases this information may not be relevant or needed. In the case, however, of the "resourceful" malicious user who stores something (keys, data, passwords, etc.) in one of these non-partition areas, we will not be able to get to it, unless the entire drive is decrypted. If we can only get to partitions, then we cannot see the MBR or the unused sectors that are not included in any partitions.

There is another procedure that I intend to write up soon where an encrypted drive can be "slaved" to a primary and accessed using a write blocker. It is way simple compared to the above, however, it also will not allow access to any non-partitioned areas of the drive.

Again, thank you for your comments. Anything we can do to simplify life in regard to decryption is excellent for all of us.

jmb

Posted April 02, 2010 at 5:24 PM | Permalink | Reply

Ed Wilson

The instructions do not work, liveView will go as far to create some hookd a vMX and a bunk VMDK, as the DISK IS AN ENCRYPTED IMAGE....Liveview will not be able to determine OS, hive's for hooks, etc.....

I can possibly see how this procedure would work for Drives that have "PARTITIONS" encrypted, but this will not work for whole disk crypto.

To mount drive with dynamic utility it cannot be connected to firewire or USB adapter, it will not enumerate / mount "removable media devices" that has been my experience
from 6.2 all the way through R72.

Posted April 05, 2010 at 3:16 PM | Permalink | Reply

J. Michael Butler

Au contraire...

I am using this process as we speak and it works fine. Live view WILL cough and choke and spit up all kinds of error messages, but it still works. If you go through the process, set the memory size appropriately, set the OS appropriately, then tell LiveView to NOT start the virtual machine, everything works as advertised. (Of course, you have to be using a legacy version of VMWare because LiveView does not work with Server 2.x yet.)

You are absolutely correct about LiveView NOT being able to determine the OS, hives, etc. However, this process WILL work to decrypt a PointSec encrypted DRIVE - not just a partition.

Pertaining to the FDE Dynamic Mount Utility, I have also successfully used that with directly connected drives as noted and acquired the unlocked partition. This is not the same thing, however, as decrypting the drive and getting the entire hard disk as noted in my previous post.

One other side note - if you are using dd images as opposed to actual hard disks, it is possible to use the BartPE iso image with FDE Dynamic Mount Utility installed to boot the virtual machine and use FTKImager or a Windows version of dd to acquire the drive. Keep in mind, however, that this is very much like acquiring a "Live" drive, so there may be some metadata changes. (Can't hook a dd image to a physical write blocker... :) ) But if you do not have the actual hard disk, this is an option. Plus the dd image file doesn't change - only the snapshot changes - so it is possible to still keep the original drive image intact. (You can do this with FTKImager or dd.exe installed on the BartPE disk as well, or you can simply attach a second CD to the VM to get to these apps.)

Thanks for your comments and observations! Now if CheckPoint (PointSec) would just offer a "Read Only" option with their FDE Dynamic Mount Utility, we would be in much better shape for partition acquisitions...

Posted June 03, 2010 at 1:56 PM | Permalink | Reply

Amund

I tried to do it in a simpler way, after my laptop had hardware-crash:
- I put the harddisk in a usb-chassis, and connected it to my desktop pc.
- On my desktop pc, i
a virtual machine from the disk, with the command: qemu -hda /dev/sdb
- I get the login-screen for Pointsec, where i enter correct username and password.
Then this message appear on the screen:
"Pointsec ... loading operating system ...

A disk read error occured
Press Ctrl+Alt+Del to start"

Any tips on how to proceed?

Posted June 04, 2010 at 6:10 PM | Permalink | Reply

J. Michael Butler

Since you created a VMDK from hardware, my assumption is that the same hardware error that caused your laptop to fail converted failfully over to your VMDK. Otherwise your VM should have booted normally.

You may also try setting up another VM with a new primary drive. If you are using ver 6.3 or later, and if your drive is set up to be attached as a secondary drive, and if you set up your new primary drive to allow a slave drive, you can add the image you just created as a secondary drive. That way the boot error is irrelevant. (Hopefully.) Then you can read the data off of the secondary drive and write it back to the host or to a USB drive or whatever.

Another alternative would be to add your crippled drive as a secondary with no PointSec installed on the primary drive. In that case, if you can get the FDE Dynamic Mount utility, you can run that on the primary to unlock the secondary, then read the data.

Hope this is helpful.

Thx, jmb

Posted March 01, 2012 at 6:15 AM | Permalink | Reply

Ishan Agarwal

I want to decrypt my pen drive please help

Posted July 04, 2012 at 4:37 PM | Permalink | Reply

Alex Pasteur

Michael,

I need your advice or suggestions. The situation is explained below.

Last week, my USB thumb drive was in the Windows PC and the power to the PC was lost due to a power outage. The PC rebooted once the power came on. I attempted to access the USB thumb drive but I received an error message. The USB thumb drive was previously encrypted using Pointsec encryption 2 weeks ago with an older PC. The desktop team provided a new PC because of some issue with the old PC. I asked our desktop support team to help me. The technician stated that my USB thumb drive had a hardware problem. I do not believe that it is a hardware problem. I can open the drive and see the 3 files on the disk.

Is there a utility that can perform a hardware check? If I connect the USB thumb drive to the old PC assuming that there is no hardware problem with the USB thumb drive. Would I be able to decrypt the contents of the USB thumb drive?

Any feedback would be appreciated.



Alex

Posted July 04, 2012 at 7:13 PM | Permalink | Reply

J. Michael Butler

Alex,
To this point, I have never worked with a Checkpoint encrypted USB drive, so my response will have to be based on assumptions. I assume that, in your case, the USB drive may have become corrupted because of the issue you had with the computer. There may not be anything wrong with the hardware, as you say, but the data could certainly be corrupt. If you can see the files but can;t get to them, that would just confirm my suspicion that the data is corrupt. (Especially if the USB drive was working fine before you had the issue.) If there is a way to decrypt the USB drive using the recovery file for the old PC, that may be your only option. You might also try using the Dynamic Mount Utility to see if you can unlock the USB drive, but that will require that the operator knows the (enterprise?) administrative Checkpoint password. Sorry I can't be of more assistance, but decrypting USB drives using Checkpoint FDE tools is not an area of expertise for me (yet.) Thanks for your comment!

BTW, let me also respond to an old comment I read again today regarding the use of the FDE Drive Mount Utility (DMU) and forensics. It is certainly true that the DMU allows a disk to be mounted and be read or written to. Being that it can be WRITTEN TO, one must take extra care to ensure that the data is not questioned in court since it is in a read/write state at the time of acquisition. It is true that we have to get the data however we can get it, but given the choice of mounting the drive with DMU and then imaging vs using the decryption method, one must carefully consider the consequences one would expect on the stand from opposing counsel. On the other hand, either procedure is probably defensible given that it is repeatable, and given enough documentation and explanation. Any issues that arise from the use of a DMU may also depend upon the technical expertise of opposing counsel...

Posted July 25, 2012 at 11:59 AM | Permalink | Reply

Rasmus Tegtmeyer

Michael, I need your advice. Decryption a partition copy created traditionally with dd under DEFT 7.1, following your procedures otherwise to the point, I get a STOP error in the decryption startup of PointSec. I can boot from the recovery disk image, I can authenticate, not an issue. I can select the "drive" to decrypt, PointSec shows it as encrypted, no issue. But once I selected the "drive" (image) and give it a go-ahead, I get a "blue-screen"-alike error message with the code 0x5001282, and nothing else happens. VMware 6. LiveView 0.7b. Googling does not get me further. Any experience/clue?

Posted July 26, 2012 at 10:59 AM | Permalink | Reply

Rasmus Tegtmeyer

Hi Michael, I need your advice please.

Using your method by-the-book, I am facing issues when trying to run the decryption process. After selection and confirmation of the encrypted image to be decrypted, I get an error screen with the code 0x5001282, and some additional stack backtrace data. Note that I am using an image file of an encrypted partition of the evidence source. The boo mechanism might have been place on another, heading partition.

Any clue? Google did not show any results.

Posted July 28, 2012 at 3:29 PM | Permalink | Reply

Walter

. If you don't have that, you are reduced to a manual brute force attack. Good luck!)

What dies this mean? Any ideas?

Posted August 02, 2012 at 6:33 PM | Permalink | Reply

Aarstu

Hi Folks,

I need a quick info pertaining to pointsec decryption. While imaging a pointsec hard drive Encase7 is asking me pointsec password and checkpoint fde recovery file. I initially thought that for pointsec Pointsec ID and password are enough to Image the hard drive in decrypted mode. I just wanted to know:
1. What is checkpoint fde recovery file?
2. Where can I get it?
3. Is there any alternate possible to image the pointsec hard drive on Encase without pointsec?

Appriciate your help :)

Aarstu

Posted August 02, 2012 at 6:38 PM | Permalink | Reply

Aarastu

Hi Folks,
I need a quick info pertaining to pointsec decryption. While imaging a pointsec hard drive Encase7 is asking me pointsec password and checkpoint fde recovery file. I initially thought that for pointsec encrypted disk imaging Pointsec ID and password are enough to Image the hard drive in decrypted mode. I just wanted to know:
1. What is checkpoint fde recovery file?
Where can I get it?
3. Is there any alternate possible to image the pointsec hard drive on Encase without pointsec?

Appreciate your help :-)

Aarastu

Posted August 03, 2012 at 1:23 AM | Permalink | Reply

J. Michael Butler

Aarstu, This blog was written long before PointSec (now Checkpoint) and Guidance Software (EnCase) were on speaking terms. In fact, about the time I wrote this blog, I also wrote one called "EnCase and Checkpoint PointSec Im Not Feeling the Love!"

Things have gotten better in that regard. The current version of EnCase does natively recognize recent versions of Checkpoint FDE (Full Disk Encryption). However, EnCase does require you to provide the recovery file as well as credentials.

The recovery file is created by Checkpoint FDE when the disk is encrypted. In fact, the disk cannot be encrypted without producing a recovery file. The problem is where the file gets created. The only requirement is that the location of the file is writable. So it could be created virtually anywhere. In a large enterprise, one would expect all machines to be configured to write all recovery files to the same location for convenience of the desktop support folks.

In any case, the recovery file, which will have an .rec extension, is required in addition to an ID and password by EnCase in order to decrypt a Checkpoint FDE encrypted disk. That being said, you will have to determine where that file was written in order to find it. That is in the config of the hard drive. So if you can boot up a (virtual) copy of the disk, you can check the config to determine where the file was written. If you cannot find the disk, you may have to resort to some other method, such as using the Checkpoint FDE Disk Mount Utility to mount the drive, then acquire an image of it using FDK, EnCase, or some other open source tool. Hope this is helpful.

Posted September 10, 2013 at 8:42 PM | Permalink | Reply

Rafael

Hello,

I need some help pertaining Checkpoint Full Disk Encryption. I have a disk with Checkpoint Encryption R73 7.4.4 and every time I try to open it in Encase with a recovery file, username and password, it simply crashes.

Does anybody have any idea what`s up with this or if there is any other alternate solution so that I can access the content of said disk? I`m trying to recover some files that are inside this disk, but Windows is not booting and I`m running out of options.

Posted October 23, 2013 at 12:09 AM | Permalink | Reply

Raul S.

Did you manage to recover the data?
Could you share the Dynamic Mount Utility please? I have a disk in which I can't boot Windows and I need urgently to recover some data from there. If possible simply send me email to skrilax [at] hotmail [dot] com
Many thanks in advance!

Posted September 24, 2014 at 1:08 PM | Permalink | Reply

J. Michael Butler

If trying to decrypt a Checkpoint FDE encrypted drive causes a blue screen, that is probably indicative of some serious problem on the disk that could actually make the disk non-recoverable.

Other options include trying to unlock the drive using the Checkpoint DMU (Drive Mount Utility), especially if all you need to do is recover files from the disk. The DMU only requires a single ID and password and will not require the REC file. However after 3 attempts with the DMU, you are forced to reboot and start over. This would be to foil automatic brute force attacks, of course.

Another option, depending upon how Checkpoint is configured on the PC you are using, is to add the troublesome drive as a secondary drive. Then you can enter the required password during boot. Again, however, you must have Checkpoint set up to require the password at boot, and NOT set up to automatically go to the Windows Login.

The DMU is available from Checkpoint.

Thx,
jmb

Post a Comment






Captcha

* Indicates a required field.