Corsair CSSD-R60GB2 SAW AS RAW

[grillsar]

Hello everybody,

I have a SSD Corsair CSSD-R60GB2 which was initially formated as NTFS from windows comander program afterwards whole disk encrypted with bestcrypt. It is connected at my laptop PC through a e-sata cable with an additional usb power cable supply, and mounted in windows as a removable device.

Normally when the computer is shutting down the SSD is automatically dismounted and I usually manually disconnect the usb cable by myself from the laptop. However one day I forgot to do this, and when I powered on the laptop the SSD wasn't recognized by the windows 7 and saw it as RAW.

I managed to decrypted it with the help of the rescue files from bestcrypt, but windows did't recognized the decrypted disk with a valid filesystem partition.

First I used teskdisk to reconstruct the MBR and restore the MFT from it's backup. I found a valid NTFS partion there and I wrote it on the disk but the error is still there. I am attaching a lot of log files from different programs I used to gather more details about my problem.

If you have any ideas about a possible solution please give me an advice.

Thanks and I appreciate your help.

Grillsar

Corsair CSSD-R60GB2.rar

[jaclaz]

Not really.

There is nothing like a $MFT backup, there is a $MFT mirror, which actually holds just first four records of the $MFT.

What you report makes little sense (the manually disconnection of the cable(s) being related), if the disk was encrypted, unecrypting it in case of corruption should not have been possible, which means that there was a corruption of the filesystem while it was mounted (and the corruption itself was encrypted by Bestcrypt).

The TESTDISK log shows how the $MFT is corrupted.

The MBR and PBR seem apparently fine (though the MBR code looks like corrupted, but it has no relevance if not for booting.

BUT, the MBR has LBA start 2048 and Num Sectors 117960704, i.e. 2048+117960704=117962752 total sectors, the PBR has 2048+117960703(+1)=117962752, while the image taken with datarescuedd has 60390005760/512=117949230 sectors.

Source: F:

Source size: 60 GB

Source sectors: 117949230

Source bytes: 60390005760

Destination: K:\image[0-60390005760].dd

Read direction: ->

Last read sector: 117949229

Last read offset: 60390005248

The image *somehow* misses seemingly 117962752-117949230=13522 sectors

This seems like indirectly confirmed by the TESTDISK log (though it provides another difference):

disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(/dev/sdb)=60398080512

60398080512-60390005760=8074752, -8074752/512=15771

Try opening the K:\image[0-60390005760].dd with dmde:

http://softdm.com/

it may be able to parse the corrupted $MFT and allow at least the recovery of some files.

jaclaz

[grillsar]

Hello again,

It does not work either. When I am trying to recover some of my files it shows me nothing. Actually I only had one bestcrypt volume inside the partition, one big block, 55 Giga I guess, so if I cannot recover it intact it wouldn't be any help because it must be mounted it as a drive with a password to show me the information.

I suppose it was to much paranoia on my part having the ssd whole disk encrypted and all the information being contented inside a volume drive on that disk. So when the error occurred any information on the ssd was mixed up all together.

Thank you anyway jaclaz for your time and professionalism. I read most of your post on this forum and I thing you are doing a great job.

Edited November 7, 2012 by grillsar

[jaclaz]

It does not work either. When I am trying to recover some of my files it shows me nothing. Actually I only had one bestcrypt volume inside the partition, one big block, 55 Giga I guess, so if I cannot recover it intact it wouldn't be any help because it must be mounted it as a drive with a password to show me the information.

Chances are pretty much low (if none at all) .

But I wouldn't be (yet) so pessimist.

The good thing (it depends on a number of factors) of having an encryption through a "mountable volume" could be that the volume (container) is created in a whole chunk (i.e. it is not fragmented).

If this is the case (and unless there is a logical/physical defect in the actual SSD, such as an internal corrupted table of remapped sectors of wear leveling mechanism), it should be possible to recover the RAW data (PHOTOREC or similar file-based recovery).

A single 55 Gb sized file/volume is however biggish (and thus increases the chances of some sectors having being corrupted for *any* reason).

I would anyway try another attempt at it, you never know.

I suppose it was to much paranoia on my part having the ssd whole disk encrypted and all the information being contented inside a volume drive on that disk. So when the error occurred any information on the ssd was mixed up all together.

Yes, more generally, encrypting *anything* is in "normal" use, not only of no actual practical advantage, but as you have unfortunately experimented directly, a big obstacle to anything related to recovery if an issue arises.

In Italy we have a saying "mettere il dito sulla piaga" which equates to "to touch a sore point" (only somehow more crude/descriptive) and believe me, I am sorry for the loss of your data, but I have to :

http://reboot.pro/9297/#entry80938

On the other hand the good outcome of this misadventure of yours could be that you have learned (the hard way) something about the futility of encryption in general and of large encryption containers more specifically.

If you look at it in another way, you have forked from a noticeable amount of bucks to buy a SSD drive for what? Speed, good, pure, raw speed .

And what is your next step?

Adding a layer of computing power need/slowness through encryption.....

Thank you anyway jaclaz for your time and professionalism. I read most of your post on this forum and I thing you are doing a great job.

I doubt about the professionaliism , but you are welcome.

jaclaz