Before you direct me to HP support (who has already offered me Disktech), please hear me out. I have what I think is a potentially unique situation.
My HP 2560p has a 160G SSD drive, currently with 3 partitions: a boot partition (unencrypted), a Windows 7 partition (encrypted), and an HP_TOOLS partition (also unencrypted). A few days ago I accidentally pulled the battery (it's actually easier than you think) while Windows was shutting down (during updates).
Before I go further, I should say that I do not have the original recovery encryption key. But I think I do have a glimmer of a chance.
When I power on, I get a quick peek at the McAfee Endpoint Encryption 6.1 identifier in the upper left corner, and then a login screen with Drive Encryption for HP ProtectTools. Here is the thing: I can still get past this screen using my password or fingerprint.
I am now presented with the bootloader screen with a Windows 7 entry. I can select advanced boot options from here, such as safe mode. In Safe Mode I can see a bunch of drivers getting loaded until I get to CLASSPNP.SYS, at which point I get a BSOD.
My primary question is this: are those drivers being loaded from the encrypted partition? It seems that they must because they don't exist on the boot partition. If they are coming from the encrypted partition, does it mean they are being decrypted on the fly, and if so, what's doing the decryption, some kind of early boot kernel driver?
Finally, if my previous statements are correct, am I totally grasping at straws if I believe there must be some way to interrupt the boot process (perhaps via kernel debugging) and obtain access to the Windows partition? I realize that this is what we're trying to prevent, but it seems like it should be possible if I were to e.g., duplicate my environment in a VM and utilize privileged code in the hypervisor to dip into the VM's memory.
Everybody has their nightmare stories here, and I know I'm asking a lot, but I wouldn't have asked if I didn't have some really important stuff on that hard drive (such as all my tax prep for 2012, some scans of recently discovered 120-yr old family photos, etc).
Thanks in advance to all of you.
2. Yes, a real-mode disk hook
3. Not kernel debugging as the code isnt in the kernel, but by some out of band inspection, possibly yes (though it does not exist).
AFAIK HP don't offer any support for this scenario, though it's trivial to solve if you had a McAfee version of the product. It's a guess, but given a working copy of EETech (McAfee's diagnostic and recovery toolkit for EEPC) you might be able to decrypt the drive - I don't know whether EETech has the capacity to understand HP's login credentials or not though.
Thanks a bunch for that info!
I know you may not be able to answer this in a public forum, but I have to ask anyway:
Does the disk hook patch the boot manager such that after I select Win7 from the menu, all further reads from the encrypted partition are decrypted?
Does the decryption mechanism require further support from the OS?
I installed Plop (http://www.plop.at/en/home.html) as a second menu entry in the BCD, which allows me to boot from USBs, ISOs or other partitions, but trying that with a Win7 x64 Recovery ISO (on my HP_TOOLS) still sees the encrypted partition only. What makes the Win7 entry different if it's just running winload.exe? Does winload.exe get patched also/instead?
1. No, it does not patch the boot manager. The boot manager is stored on the encrypted drive, so the decryption needs to be much lower still.
2. When you're in protected mode, yes - you need a protected mode filter driver. Real mode is handled without the OS though.
3. Your Windows OS has protected mode drivers for the encrypted disk - that's how it's able to read it. Your recovery CD does not have the protected mode driver, so it can not.