a while ago, I successfully removed the drive encryption (HP-Protect Tools)form the main disk of my notebook (2 partitions) by using a BartPE SafebootWintech CD and forced decryption.
The second partition on the second drive got encrypted as well; at leastthere is a "SAFEBOOT" string in the beginning of the second sector ofthe second disk and the data on that partition is not accessible (and it lookslike having high entropy). So I presume it was encrypted using the sameencryption key as the first disk.
Since getting on the data on that disk wasn't that essential so far and themethod I used took about a week for the first drive (only about 512 KB/sdecryption speed) I postponed encryption for that drive.
Yesterday, I started a decryption attempt after discovering that Virtual Boxcan access disks directly. So I created a drive configuration for Virtual Boxthat enables it to access the encrypted drive directly from the guest VM, bootedthe BartPE Safeboot Wintech ISO in a guest VM and started to decrypt the drive.
Using the same key as for the first drive, did not work (the data still"looks" encrypted), and now I am a bit puzzled.
Here is some additional background:
The partitions of my primary disk (containing the system partition) wereencrypted again using the HP-Protect Tools. Since I noticed that I can readplain raw data from these disks using a disk editor (in Windows), I guess thedisk's raw data must be decrypted (safeboot driver) before it is passed to thedisk editor. I wonder whether this driver now interferes with the decryptionprocess in the VM.
The data from the second disk (that I am trying to decrypt in the VM) maystill be piped through the safeboot driver which maybe also "decrypts"that data (possibly even with the wrong key). Note that there are some remainsof safeboot (encryption states?) in some of the second disk's sectors.
Another fact I noticed is that a "normal" (i.e. unforced)decryption does not alter the data at all, i.e. it looks like the system thinksthey are already decrypted. Encryption (and consecutive decryption), howeverdoes alter the data.
So now I wonder whether the VM based decryption could work at all in case ofan already re-encrypted host system (as described).
firstly, this is not really the right place to be looking for help re HP's product - you need to reach out to them.
But, you are right - all bets are off within a VM - you need to actually boot off the BartPE disk for it to work properly. The encryption drivers are low enough that any VM disk access is above them.
First of all, thanks for your answer.
I know that this is actually the wrong place to ask for support, but at the same time, its the only source of information I can get in this regard as the HP-support is clearly not into this.
So, I've two (I hope) last questions and would be really glad I you could answer it.
It appears that I made a bad mistake.
Prior to trying to decrypt the 2nd hdd, I took a complete raw sector by sector backup of the disk. However, I did it in a windows environment which has been encrypted again using a different key (still safeboot). Since the sectors of this 2nd disk are still marked as being encrypted in the crypt list, I guess the low level driver (that is managing the encyption for the system on the first disk) decrypted them using the wrong key when the backup was made. At least, I was unable to pursue the procedure that worked for the first disk for the second disk again, i.e. the 2nd drive is still encrypted. Doing a force encrypt with the second key and then a forced decrypt with the first key did not help either (I hoped that could work). So now I probably have a disk that has been encrypted/decrypted using 2 different keys, but I don't know in which order decrypt/encrypt operations should be applied using the keys) As I have both of them, I could try different combinations of decrypt/encrypt operations (i.e. a short sector range for every combination). Then I could scan the sectors for low entropy (e.g. <0.9) or mabye just by viewing them to see if there is something readable in the respective sector range.
However, I need to be sure that it is at least theoretically possible to sucessfully restore the data just using the two keys (i.e. no other information that might be stored in some special sector which now might not be available any more). So the question here is: In general, are the backed-up keys sufficient for the emergency decryption process?
One more question:
If a crypt list if present on a disk and it indicates that some of the disc sectors are encrypted, will the safeboot driver automatically apply its decryption routine using its current key or is it somehow able to decide that the sector has been encrypted with a different key? I.e. will it modify read/writes to a disk that has a crypt list from a previous encryption attempt that has been done with a different key?
Thanks a lot
1. yes, all you really need are the keys.
2. Yes, the driver will automatically crypt whatever the region list tells it to - it does not support more than one key. If you did not choose to specifically re-encrypt the 2nd drive though, it should still be exactly as you left it? Your image may be messed up, but the original drive should be fine still?
OK, first to clear things up a bit (as I am confused when reading my posts myself 😞
1st HDD 2nd HDD
encrypted with 1st key encrypted with 1st key
Then things messed up (encryption bootloader overwrite or something) and I could not access my data any more.
Then I got my first drive decrypted using safeboot (which took several days as the force decrypt only crypts about 5000 sectors/s)
I was very happy that I could access the first drive again and continued working and somehow neglected the 2nd drive. In the meantime, I reinstalled the encryption on the first drive so that the state was then
1st HDD 2nd HDD
encrypted with 2nd key encrypted with 1st key
Then I had the idea to use Virtual Box to decrypt the 2nd drive while being able to use the system normally. Before attempting that though, I made a raw sector-by-sector backup of the 2nd drive (unluckily using a windows drive imagine software while running the system normally, so not using a special boot CD or Knoppix system).
> If you did not choose to specifically re-encrypt the 2nd drive though, it should still be exactly as you left it?
My fear is that the image taken of that 2nd drive got "decrypted" with the second key (which could be regarded as an inverse encryption) as the system thinks that the drive is encrypted with the 2nd key where it has actually been crypted with the first key (I try to remove the encryption with the first key).
There is, however some hash value (?) of the key with which a disk has been encrypted (called key check in safeboot). So the question is:
Did the driver recognize, that the 2nd HDD has been encrypted with another key (1st key) and did not try to decrypt it using the 2nd key while doing the backup? I think it does not check this since I made the following observation:
Modifying the crypt list of the 2nd drive (adding a specific secor) made this sector look different in a disk editor (in the windows system booted from the 1st drive with the 2nd key). It appears as the system now regards this sector as beening encrypted (with the 2nd key). Is this indeed the case (or did I not observe carefully enough)?
If that was the case, the backup data is first encrypted with the first key and then "inverse-encrypted" with the second.
> our image may be messed up, but the original drive should be fine still?
No, unfortunately I already used the backup to "restore" the 2nd HDD after some "repair" attempts...
So the question to answer this time: Does the safeboot driver "respect" a disk's encryption key hash-value (called key check in safeboot) and does not modify the bitstream from a disk if the sector is marked encrypted on the crypt list but the key hash-value does not match?
Thanks for your attention
I must admit, it's not a scenario that the EEPC software is designed to support - We catch "wrong key removable drive" problems by virtue of the fact the OS does not recognise them as formatted because the driver has no capacity to do a key check, or support multiple keys - it's designed to be as simple and fast as possible.
You bypassed this by going outside the file system and doing a backup of the sectors, so indeed if the disk region list said it was encrypted, it's quite likely the driver did what it was told to do and decrypted the stream of sectors as they were read.
BUT saying all this, you're not using the McAfee product here - you're using the HP product, so I have no real idea how different it is - it could be totally different, the algorithm could be unique - anything. It's simply not a McAfee product.
Thank you very much for clearing my remaining questions. I know have a much better understanding what may happen and what might work to restore the disk.
> BUT saying all this, you're not using the McAfee product here - you're using the HP product, so I have no real idea how different it is
Fortunately, it seems the core hasn't changed much
Hm, unfortunately, the procedure that I thought might decrypt the data was unsuccessful.
First, I completely uninstalled disk encryption from my system to prevent the driver from potentailly interferring with any operations again.
Next, de- and encryption operations were applied to the 2nd (encrpyted) drive to try to reverse the operations that lead to the so far unrecoverabley encyption:
sectors 1000 2000 3000 4000 5000
This schema has to be read top down as follows:
- means the the corresponding operations indicated on the left was applied to the blocks that are indicated on the bottom.
E.g. for sectors 1000 - 2000, first two encryption runs with key 2 were performed, followed by a decrpytion run with key 1.
My assumption was (based on the thoughts explained in the former posts) that sectors 2000-3000 would be readable again but they weren't.
One possibility that I haven't considered yet is that the driver might have used the 1st key on the 2nd HDD, albeit the system was booted with an installation that acutally uses 2nd key.
So my question this time is:
Does Safeboot (I am aware that this might have changed in the HP software) uses exactly the key that resides on the boot device (in some special safeboot sector) to crypt all drives in the system, or does it use the key that resides on the respective drive (in some special safeboot sector) which it currently operates on? In normal circumstances, the keys in those special safeboot sectors should be all the same, though.
Alignment in diagram was currupted on 05.04.11 08:21:19 CDT
on 05.04.11 08:23:49 CDTon 05.04.11 08:25:26 CDT
it uses the key you booted the system with - the key is not stored on the second physical drive.
I think you really should have tested the decryption key by using the workspace or a test sector before processing huge chunks of sectors?
it uses the key you booted the system with - the key is not stored on the second physical drive.
Well, that's good to know.
The whole drive has been backed up and has already been restored multiple times. These 1000 sectors are actually my test sectors... For some reason, the workspace simply does not work for me, i.e. it is just not displaying anything so it's completely useless. I have to admit that I use some rather old version of safeboot (20009) that I found somewhere bundled with BartPE...