I'd appreciate any help with this time-sensitive question.
Background: The boot hard drive from my laptop was encrypted with Safeboot Device Encryption version 5.2.4, managed with EEM. In the process of upgrading to a new boot hard drive, I tried to image the encrypted boot drive with Acronis (bad idea), and the MBR became corrupt, resulting in the error messages "MBR error 1" and "MBR error 3" on reboot. Not realizing the problem I rebooted with a standard windows 7 recovery DVD and restored the MBR with the standard, unencrypted windows 7 MBR, which erased the safeboot encryption information. Another bad idea. When I tried to reboot after that, I got nothing but a blank black screen with an underscore in the upper left "_"
Solution steps so far: I installed the hard drive in a different machine, obtained my machine's SDB file from my organization's EEM database, obtained the code of the day from McAfee, booted with with a BartPE CD and launched WinSafeTech v 22.214.171.124 (which I am told is the appropriate version for all of our organization's hard drives). I authorized with code of day, then authenticated from database with my machine's SDB file on a USB flash drive. Wintech confirmed successful authorization and authentication. I opened a workspace, and then decrypted some sectors and found lots of good readable stuff on decryption, so it seems the key is correct. However, because the MBR was corrupted, the "Remove EEPC" option failed. On reading advice in this forum, I determined that my next recommended step was to look in the disk information for partition information, and if a main partition was found, to attempt a forcible decryption of that partition. Disk info showed a partition starting at sector 2048 (as expected for a windows 7 system, which this was), and extending to sector 627535711 (partition size: 627533664 sectors). So far so good.
#1) My next step was to go into the "Force crypt" dialog. Here was where I made my first mistake, which I'm hoping doesn't matter: I was using an overly senstive touchpad and as my mouse cursor moved over the "decrypt" button in the dialog box it clicked the button, and proceeded to forcibly decrypt disk 0, which was not the hard drive I was trying to decrypt, but instead was the USB THUMB DRIVE ON WHICH I HAD STORED THE SDB FILE. Doh. I'm hoping this is not a big deal, since I had already authenticated. Hopefully (please please please let this be right) WinTech only checks the USB drive once for the SDB file, when you ask it to " authenticate from database" and point to the SDB file (which I had already done, before I accidentally nuked the thumb drive). There's no chance it would still be periodically checking the now-scrambled thumb drive for SDB file, is there? and reading a scrambled key? Becuase that would be terrible, given that I am now in the middle of a forced decrypt of the hard drive (what I originally intended). Which brings me to potential problem #2.
#2) After accidentally scrambling the USB drive, I re-opened the Force crypt dialog and properly selected logical disk 1, which was the hard drive I wanted to decrypt. In entered 2048 as the starting sector, which is correct. But then I misinterpreted the next dialog box, and entered the ENDING SECTOR of the partition instead of the NUMBER OF SECTORS in the partition. In other words I entered 627535711 for the number of sectors in the partition, when in fact the partition has only 627533664 sectors. I pressed decrypt before I realized my mistake. So noe the decryption is happily humming along, and will take about 6 days at the current pace. However, I am terrified of what will happen on day 6, at the very end of the decryption process, when it attempts to decrypt 2048 sectors past the end of the drive. Is this going to cause a crash or any serious problem? I am hoping it just decrypt up to sector 627535711, and then throw an error on attempting to read sector 627535712 (the first sector past the end of the drive), and exit gracefully without crashing WinTech or undoing the 6 days worth of decryption of all 627,533,664 sectors that it processed correctly before reading past the end of the drive. Dare I hope for this latter outcome, or should I be prepared for disaster when it tries to read past the end of the drive? If disaster, is there any way I can avert it/recover from it?
Thanks for any help you can provide, especially if you can provide an answer before next Wednesday 9/18/2013. At the current rate the decrypt process will reach the end of the drive and possibly trigger the error sometime later on Weds 9/18 or early on Thurs 9/19.