4 Replies Latest reply on May 18, 2011 2:57 AM by Odgeuk

    Fixing a Partially Decrypted SB disk

      This refers to a SB v4.2.15 installation

       

      Just had a case (and not the first one either) where a machine OS is blue-screening so Desktop engineer has kicked off a SafeTech Removal so that the customer data can be removed from the drive. In this case, authentication was performed using the local SBFS file system (Values from Disk) rather than SDB file. Decryption began, but at 2% was saying that decryption was going to take 100's of hours to complete. Suspecting the recovery was not working as expected, the engineer cancelled the decryption at 2%.

       

      Now of course the engineer wants to try a removal using SDB file authentication but I have voiced my concerns that if the disk is now partially decrypted, running a decrypt over those sectors with the SDb file is simply going to scramble those decrypted sectors and he is very unlikley to be able to read the file system if the SDB authenticated decryption completes. Is this correct? If so....then are there any tools available which would allow us to work out from which sector we need to continue decryption?

       

      I get a few of these and they are very frustrating. The usual outcome is that the machine is either rebuilt and the customer loses their data, or the disk is sent to a specialist recovery company and the customer is billed a lot of money (and we never find out the outcome of these 3rd party attempts so I do not know if even they have the tools or utilitites to repair a disk which has had sectors which have effectively been decrypted twice.

        • 1. Re: Fixing a Partially Decrypted SB disk

          you could in theory grab the EPT's with SBFS.exe, and that will give you within 90 sectors the current crypt point of the drive? Of course, SafeTech using VFD will know where things left off, and will continue from that point.

           

          V5 of course it's much easier - the exact regions which are encrypted are displayed in the disk information. 4.x unfortunately is thebest part of 10 years old now and does not have such sophistication.

          • 2. Re: Fixing a Partially Decrypted SB disk

            This sounds interesting. I am thinking that by repeating a decrypt using VFD, it may continue from where it left off (assuming that it was cancelled cleanly and there isn't a second problem here which was causing the exceptionally long estimated decrypt progress time on the first attempt).

             

            I'm interested in the effect a few encrypted sectors has on a disk. Is it sometimes possible that, even with a few hundred encrypted sectors, it may be possible to slave a drive and read and move files from the file system, or does every sector has to have it's integrity before you stand any chance of viewing the Windows File system?

            • 3. Re: Fixing a Partially Decrypted SB disk

              it's certainly possible - if you have bad sectors on a disk, the disk just stalls for a bit while it tries to read them - the OS etc does not know (or care) about such things, it's entirely up to the disk itself.

               

              Depending on what's good and bad, you may loose a file, or the whole file system might be corrupt - there are plenty of tools though to help rescue files from a failing drive.

              • 4. Re: Fixing a Partially Decrypted SB disk

                Thank you.

                 

                In an earlier thread I just read, where a SafeTech decryption was interrupted by a power fail but the user repeated the decryption process (thus double decrypting some sectors) you recommended re-encrypting the drive using the SDB file and to work out how far the first decryption got to by a "binary-chop inspection". What is this?