Hello everybody , I am new to this forum, have read many threads regarding ways to recover data, especially Dantz’s method . But I am having difficulties to apply some of the steps needed to recover data, and would be very glad to have some guidance by some of you. The goal is to know if I can and how to recover important work data, from the current situation : It concerns a whole disk (SSD) with 2 partitions: Partition 1 : 499Mb (Microsoft reserved partition), encrypted with TC 7.1 Partition 2 : 120Gb Win 7 partition (120Gb) which was encrypted with TC 7.1 Encryption method is unknown, Partition password is known for sure There is no rescue disk nor header/mbr backup Data which needs to be recovered is on the 120Gb partition, is about 20Gb mainly located in "My Documents" Windows 7 folder - What happened with details: TC Bootloader has been overwritten by the following commands : bootrec /fixmbr then bootrec /fixboot (After bootrec /fixmbr, Missing OS was being displayed) (The purpose of it was to remove the TC layer and then to use bitlocker instead, this process went well on another same model PC) -After the boot update, the whole disk (both partition)) has been backed up straight away with Norton Ghost (there should be no fragmentation since it’s SSD), Ghost explorer sees 2 NTFS / HPFS partition which could not extract files due to TC Encryption. Diskpart shows both partition as being RAW Partition Since data to recover is on Partition 2, I focus on this partition. So far, this is what I’ve tried : - TC feature “use backup header embedded in volume if available without success” -I’ve created test file of 2Mb and tried to mount it without success “Incorrect password or not a TrueCrypt volume” , and I am sure 100% password is correct. So it means, I am not in the correct location for the starting point of the header. -I’ve tried : TC feature “ Restore the volume header from the backup embedded in the volume” but without success : “Incorrect password or not a TrueCrypt volume” Also,before offset 1048576, there is a bunch of Zeroes then From 1048576 to 1052711 = Scrambled Data From 1052712 to 1056767 = Zeroes From 1056768 to …XXX = Scrambled Data From XXX to YYYY = Zeroes From YYY to XXXX = Scrambled data …..then it alternates many times from Zeroes to Scrambled data From XXXX to final Offset 128035675495 = Zeroes ~ Content Removed As Requested ~ Thanks Regards, Fred
The backup header is usually at the end of a volume, but System partitions doesn't contain an embedded backup header: You have to mount a System partition with the option: "Mount without Pre-Boot Authentication..." Did you try this?
Whenever I use Windows, I use VeraCrypt, which is basically TrueCrypt on steroids, so there's not much difference there. What I do is I create two partitions: one for the OS (and this has to be big enough so I can install lots of things, which equals to around 430 GB), and another for data and backups, in the same disk of course (501 GB in size). There's a separate HD that I use for backups too. So if anything goes bad with the OS partition, I still have the data/backup partition encrypted and I know I can retrieve data from there. Remember: always do backups, you simply cannot trust anything related to computing, be it hardware or software, they will fail at some point. If you have backups, chances are one piece of the puzzle will fail before the other, so you still have your data somewhere safe. Now, regarding your issue. I'm no encryption Guru, but I have no idea why you would change from TrueCrypt to BitLocker using that method you described. I've never seen that, and just by looking at the commands used I would know the method is prone to fail. What I would personally do, to go on the safe route, is to fully de-crypt the OS using TrueCrypt and then encrypt using BitLocker. If the data is important, it doesn't make sense not to do it this way. I don't think you can retrieve your data.
mood : Thanks for your input Yes, I've already tried to mount a system partition, but I unfortunately always get the message "Incorrect password or not a Truecrypt volume". amarildojr: I also totally share your point of view regarding backups, they are simply essential. Unfortunately, there is no rescue disk in the current situation I don't have the full background about why it was done that way, but now my main goal is to help to recover those data. Since the whole disk has been backed up straight away after having hd boot updated, I think there must be some possibilities to recover the data.
I'm sure the commands you've entered lead to a damage of critical data, which is needed for decrypting/mounting your system partition. And because there is no backup header available for system partitions you can't simply search for a backup header and restore it. For "normal partitions" you have the option to Backup or Restore the Volume header, or to mount it with the backup header embedded in the volume. For system partitions you "only" have the option to create a Rescue Disk, so all important things are done with the Rescue Disk itself. Basically the Rescue Disk is the backup of the header for your system partition. And with it you can restore the master key, restore the boot loader, or you can even decrypt the system partition. All critical data is stored on it. If important data/the header was overwritten and you can't mount it, i don't think it's possible to recover your data without a Rescue Disk.
Thanks for your explanation about the difference with normal & system partitions regarding backup header. Like I said in my previous post, I don't have the full background about why it was done that way (tc bootloader overwritten), and of course situation could have been another story if there was a rescue disk, but this is unfortunately not the ase From what I know, only the boot has been overwritten (therefore, important data must still be there but encrypted), and then the whole hard disk has been backed up using Norton Ghost (byte for byte), so maybe there is still some ways (even if it's not easy) to recover the data ? Regards, Fred
This should be a simple, although time required, solution based upon your last post in this thread. If you in fact have a forensic (byte specific) image of the drive simply restore that and all will be intact (assuming there is no physical drive failure here). Its been several years since I used Ghost since I now use Macrium, but Ghost has a good reputation among its loyal users. Ghost may be able to restore the MBR alone which was made during the creation of the forensic image. There is some chance that restoration of the partition table resident in the MBR might provide what is needed to mount the drive. Also, resident in the MBR backup would be the TC bootloader which is contained in the first 446 bytes on the drive space. So try restoring those 512 bytes and you may just get lucky. If that doesn't pan out and you actually have overwritten the header you can actually pull it directly out of the image file and use it. I am going to hold off on the specifics/mechanics since again its been awhile since I used Ghost. At a post count of 3 here I would rather recommend that you simply image the entire 120 Gig since that is a small amount nowadays. If you have usb3 hardware its well under an hour, and if not maybe a few hours or less on usb2. That is much safer and less prone to errors. Very very simple stuff IF you have the image you stated above this post.
Thanks for your message Palancar. Unfortunately, this image of the drive has been created after overwriting of TC bootloader , so I guess restoring those 512 bytes will be useless in this case ? When you said "If that doesn't pan out and you actually have overwritten the header you can actually pull it directly out of the image file and use it." Could you please give me more details in order to pull the header directly out of the image file and use it ? Thanks Regards, Fred
In your case it won't matter since your backup image is "hosed" already. Why restore known bad digits? However; as a simple learning exercise. When I make a forensic quality backup that means that if I restore ALL bytes will be returned to their exact location. This is critical because TC looks in an exact location "canonically" to locate the encrypted header data. The little manual snapshot table below depicts where TC examines as a password (salt and all factors considered) is attempting to establish a TRUE against the needed hash resolution. So if I were to open my good and working backup I could pull that EXACT region of digits and write the same back to the exact location where they came from. This would indeed restore the needed headers, but its beyond reach for most of our users' experience level. Its sounds tough but when you get good with editors its a walk in the park to do. This in essence is exactly what the TC code and the rescue disk was setup to do. By examining the table below you can visualize that a forensic quality backup would contain what is needed and if you place the digits back in the exact location, of course it would work as if nothing ever changed. See? Overview from the encryption scheme section of VeraCrypt. You can see the same scheme in the TC manual as well. Just look under encryption scheme. Encryption Scheme When mounting a VeraCrypt volume (assume there are no cached passwords/keyfiles) or when performing pre-boot authentication, the following steps are performed: 1. The first 512 bytes of the volume (i.e., the standard volume header) are read into RAM, out of which the first 64 bytes are the salt (see VeraCrypt Volume Format Specification). For system encryption (see the chapter System Encryption), the last 512 bytes of the first logical drive track are read into RAM (the VeraCrypt Boot Loader is stored in the first track of the system drive and/or on the VeraCrypt Rescue Disk). 2. Bytes 65536–66047 of the volume are read into RAM (see the section VeraCrypt Volume Format Specification). For system encryption, bytes 65536–66047 of the first partition located behind the active partition are read (see the section Hidden Operating System). If there is a hidden volume within this volume (or within the partition behind the boot partition), we have read its header at this point; otherwise, we have just read random data (whether or not there is a hidden volume within it has to be determined by attempting to decrypt this data; for more information see the section Hidden Volume). 3. Now VeraCrypt attempts to decrypt the standard volume header read in (1). All data used and generated in the course of the process of decryption are kept in RAM (VeraCrypt never saves them to disk). The following parameters are unknown and have to be determined through the process of trial and error (i.e., by testing all possible combinations of the following):
Thanks Palancar for those detailed information regarding forensinc quality backup and TC encryption scheme, it's quite interesting to see how it works From what you've said, since the backup was made after TC boot was overwritten. Encrypted header data should still be in the exact same place , right ? Since TC password is known for sure, do you think there is still some chance to decrypt data with full version of Winhex , and also with the following offset context I've described in my 1st post : "Before offset 1048576, there is a bunch of Zeroes then From 1048576 to 1052711 = Scrambled Data From 1052712 to 1056767 = Zeroes From 1056768 to …XXX = Scrambled Data From XXX to YYYY = Zeroes From YYY to XXXX = Scrambled data …..then it alternates many times from Zeroes to Scrambled data From XXXX to final Offset 128035675495 = Zeroes ~ Content Removed As Requested ~ Regards, Fred
Hello everybody Dantz, if saw on another thread that you were on a trip, if you are back from your trip and have little time, I would be glad if you could give me your insight regarding my 1st post. According to your knowledge and experience, I would like to know if you also think only the rescue disk is the only solution (which unfortunately is not available...) or if there is another way with WinHex or else (I have access to a friend's full version). Thanks Regards, Fred
Fred if you don't think the data you are trying to retrieve is encrypted or even if it is , you could create a bootable linux distro on a CD or USB stick and still view it. very easy to do.
Hi boredog, I've tried linux mint distro but without success, I could only see raw partition. Feel free to suggest another linux distro and the steps to view the data if it's possible Thanks Regards, Fred
