Hi friends, I really need help with this situation:
Background: Laptop froze so I tried to reboot. On startup, I got past the McAfee login/password screen for Safeboot (EndPoint Security) but Windows went into an endless loop of startup repair. So I did "restore MBR" from the command line (very bad idea since the drive was encrypted, I know now). Booted from the WinTech CD but it could see the HDD but couldn't do much there. Before trying anything else, tried to do a sector by sector image of the HDD. The imaging process was taking a long time so stopped it gracefully.
After that, the drive couldn't even be recognized by the Windows machine during startup. Sent the drive to a reputed data recovery company. They diagnosed and said that the heads are torn and there is some surface damage but they are confident that they can do partial recovery with files less then 200 MB being recoverable. They said they can leave the McAfee encryption as is, recover the data on another drive (sector by sector image) and send that to me. But they said they can't guarantee that I will be able to decrypt unless I somehow have them decrypt the data as part of the recovery services (they said they won't charge anything extra for decryption), which I definitely don't want to do and won't do. The original drive was a laptop drive of 320 GB capacity and they said they would do a sector by sector copy of the damaged 320 GB drive to another drive of 1 TB capacity and the drive manufacturer would be a different one from the original damaged drive.
My questions (please, please help me here):
1. If I have the code of the day and the SDB file, would I be able to decrypt the data on the new drive and access it on my end using the WinTech CD ? I am asking because the drive I will receive with the image would be from a different manufacturer and with a different (much higher) capacity. I read somewhere on the forum that the image should be on the same exact same drive (same manufacturer and same capacity).
2. Would force decrypt work ? I am assuming force decrypt doesn't care about lost EEPC MBR (lost because I did a restore MBR at Windows command line) or start sector etc. and just starts decrypting.
3. When the data recovery company does a sector by sector copy, wouldn't they carry over the bad or damaged sectors on the new drive with the image ? If so, I am afraid force decrypt would stall once it hits bad/damaged sectors.
4. Since they said only partial recovery is possible with files less than 200 MB being recoverable, I am assuming some files will not be recoverable. So how is decryption possible at all on the new disk with the sector by sector image? Does it skip the "unrecoverable" files on the new disk with the image and continue with the rest ?
Simon, please help. I know you are busy (not just saying it) but I desperately need your advice. I just need to know that given the background of the issue as explained above, is the data recoverable and can be decrypted at my end.
Friends: anyone else has run into such a scenario ?
Hi, thanks a lot ! I would appreciate if you could answer the following 3 quesitons whenever you have a chance:
Sorry, had one more question:
Will this impact the chances of successful decryption ? Or is it that the sector numbers are not important as long as the order or the sequence is maintained ?
true, but most hard disk copy tools have the ability to expand partitions, and most only work at the partition level, not the disk level - with EEPC, capturing sector 0 is usually important, and in older versions, also capturing the partition gap is required.
Yes, it's possible - but if the full partition is encrypted, makes no difference (other than confirming the correct key). The EEPC MBR is vital if encryption is in progress but if the whole partition is encrypted, it adds nothing.
Yes, the MBR is not required (except for the case of encryption in progress)
When the sector is read, the drive will try a few times, click a bit etc, and then return zeros as you say - the only way to tell if a sector is bad is to write something, then see if what you read is the same - there's really little intelligence there.
So usually bad sectors still return data (eventually). You won't end up with out of sequence data - each read/write is for a particular range of sectors. There's no "skipping" to speak of.