TrueCrypt Festplatte retten: schnellformatiert unter Win7

1PunchMickey

Newbie
Registriert
Okt. 2011
Beiträge
4
Hallo,

Ich benötige eure Hilfe:
Ich habe versehentlich meine mit TrueCrypt komplett verschlüsselte externe 1TB-Festplatte unter Windows 7 schnellformatiert. Jetzt kann nicht mehr mit TrueCrypt darauf zugreifen.

Unter der Datenträgerverwaltung von Windows 7 wollte ich eigentlich meine interne 1TB-Festplatte schnellformatieren und habe aus Versehen die falsche Festplatte erwischt.
Das ganze ist passiert, weil ich von Windows 7, sofort als ich die Datenträgerverwaltung geöffnet hatte, auf ein Problem bezüglich meiner Festplatte hingewiesen wurde. Ich habe vergessen, dass ich die externe Festplatte schon über TrueCrypt eingebunden hatte und dachte, dass sich die Meldung von Windows auf die interne Festplatte bezieht, die ich ja gerade formatieren wollte.
Ich kann mich leider nicht mehr ganz erinnern, was Win7 genau in dieser Meldung von mir wollte (es ging um irgendeine Aktion, die Win7 vornehmen muss, damit ich auf den Datenträger, der als "nicht zugeordnet" angezeigt wurde, zugreifen kann; es gab eine Auswahl zwischen 2 Punkten; das Wort Partitionierung war auch irgendwie aufgeführt).
Da habe ich leider auf "Okay" geklickt, wobei die Festplatte danach immer noch "nicht zugeordnet" war; allerdings ist dadurch in der Datenträgerverwaltung ein kleines rundes Icon direkt neben der entsprechenden Festplatte verschwunden, was davor noch angezeigt wurde. Das Icon befand sich in dem Bereich, den ich in dem Screenshot im Anhang mit einem roten Kasten markiert habe.
Nach dieser Aktion wurde nach der Formatierung gefragt, bei der ich dann eine Schnellformatierung durchgeführt habe.

Ist es möglich wieder auf meine Daten zugreifen zu können? [Ohne, dass ich eine Zeitmaschine bauen muss, um eine Stunde zurück in die Vergangenheit zu reisen um dann nicht die Schnellformatierung an der falschen Festplatte durchzuführen... :-(]

Die Daten waren sehr wichtig. Es wäre sehr nett, wenn mir jemand helfen kann.

Grüße,
Philipp
 

Anhänge

  • Unbenannt.jpg
    Unbenannt.jpg
    10,6 KB · Aufrufe: 138
Die Aktion, die du wohl durchgeführt hast war das Initialisieren der HDD (du hattest wohl eine vollständig verschlüsselte HDD ohne jegliche Partitionen) - dabei wird nur ein MBR auf die HDD geschrieben. Eigentlich solltest du die HDD weiterhin unter TrueCrypt einbinden können, wenn du die Option aktivierst, dass der integrierte Backup-Header verwendet werden soll. Funktioniert das nicht, so kannst du mit TestCrypt mal das Ende der HDD analysieren lassen ("Automatic" bei "End of Volume" sollte reichen). Wird auch dort nichts gefunden, so sieht es düster aus - wurde z.B. eine TrueCrypt Version älter 6.0 verwendet, so hast du ohne einen manuell gesicherten TrueCrypt-Header keine Chance.
 
Ich kann die Festplatte nicht mehr unter TrueCrypt einbinden. Liegt wahrscheinlich daran, dass ich sie schnellformatiert habe, oder? Das wurde von Windows direkt nach dem Initialisieren angefragt.
Unter Testcrypt kann kein Header gefunden werden. Gibt es noch irgendwelche Möglichkeiten?
 
Eher nein. Kann es sein, dass die HDD noch mit TrueCrypt 5 oder älter verschlüsselt wurde? Dort gibt es am Ende der HDD keinen integrierten Backup-Header und es hilft nur noch eine zuvor erstellte Sicherung des TrueCrypt-Headers. Hast du in TestCrypt auch sicher die richtige HDD ausgewählt und die Option "Automatic" bei "End of Volume" gesetzt?
 
Ich habe die Festplatte erst seit ca. 5 Monaten und habe damals mit der neusten TrueCrypt-Version verschlüsselt. Nehme an, dass die Version neuer als 5 war.
Ich habe ganz sicher die richtige Festplatte ausgewählt. Allerdings meckert TestCrypt auch rum, sobald ich es starte http://imageshack.us/photo/my-images/41/unbenanntshj.jpg/
Ich bekomme die Fehlermeldung leider nicht weg. Trotzdem kann ich die Festplatte überprüfen. Ich weiß jetzt nur nicht, ob das Überprüfen mit der Fehlermeldung so viel Sinn macht.
 
Zuletzt bearbeitet:
Überprüfen funktioniert auch ohne den Treiber. Ich versteh jedoch nicht, wieso nichts gefunden wird. Noch einmal um sicher zu gehen, die Option "Automatic" hast du aber schon auf der dritten Seite von TestCrypt gewählt, oder?
 
Ja, habe ganz sicher "Automatic" bei "End of Volume" gewählt. Testcrypt findet leider nichts. Gibt es da noch irgendwelche Wege meine Daten retten zu können?
 
Hallo!

ich habe ein ähnliches Problem! Aus Versehen habe ich eine externe Festplatte mit win 7 initialisiert d.h. es wurde eine mbr-table/partition am anfang der festplatte gesetzt, welche ich mit gparted bereits gelöscht habe. (Mit einem Klick wars dann schon wieder so weit und die Mbr verschwand und der Speicherplatz gesellte sich zur zweiten "unknown" Parition hinzu) Die Festplatte wurde ehemals verschlüsselt mit gparted - glaube ich - ist schon 1-2 Jahre her. Ich benutze Linux und das System hat vorher die Festplatte automatisch erkannt. Gparted sagt die, nun einzige Partition auf der externen sei "healthy", aber eben auch "unknown".

ist hier noch irgendwas zu machen? oder sind die daten alle unwiederruflich verloren?

Viele Grüße!

Madeleine
 
Ich hab noch was gefunden - vielleich hilft das weiter? :

"To repair a filesystem not listed by TestDisk, run testdisk device, i.e.

testdisk
/dev/mapper/truecrypt0 or testdisk /dev/loop0 to repair the NTFS or
FAT32 boot sector files from a TrueCrypt partition. The same method
works with a filesystem encrypted with cryptsetup/dm-crypt/LUKS.
testdisk /dev/md0 to repair a filesystem on top of a Linux RAID device."

siehe:
http://sohonetwork.blogspot.com/2011/04/testdisk-step-by-step-video-tutorial.html
http://www.cgsecurity.org/wiki/Schritt_für_Schritt_Wiederherstellungsbeispiel

meine
festplatte wurde mit cryptsetup verschlüsselt. ich verstehe den befehl nicht wirklich - muss da nicht irgendwo noch das device spezifizieren?
 
Versuch die Partition mal manuell mit folgendem Befehl einzubinden (x durch entsprechende Buchstaben und zahlen ersetzen):
Code:
cryptsetup luksOpen /dev/sdxx testdisk
Bekommst du hier keinen Fehler so kannst du TestDisk mal mit folgendem Befehl starten:
Code:
testdisk /dev/mapper/testdisk
 
funktioniert leider beides nicht:

Device /dev/sdb is not a valid LUKS device.
Device /dev/sdb2 is not a valid LUKS device.

Unable to open file or device /dev/mapper/testdisk

und das noch gefunden:


http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery :

"How do I recover the master key from a mapped LUKS container?

This is typically only needed if you managed to damage your LUKS header, but the container is still mapped, i.e. "luksOpen"ed.

WARNING: This exposes the master key of the LUKS container. Note that both ways to recreate a LUKS header with the old master key described below will write the master key to disk. Unless you are sure you have securely erased it afterwards, e.g. by writing it to an encrypted partition, RAM disk or by erasing the filesystem you wrote it to by a complete overwrite, you should change the master key afterwards. Changing the master key requires a full data backup, luksFormat and then restore of the backup.

First, there is a script by Milan that tries to automatize the whole process, including generating a new LUKS header with the old master key:

http://code.google.com/p/cryptsetup/source/browse/trunk/misc/luks-header-from-active

You can also do this manually. Here is how:

- Get the master key from the device mapper. This is done by the following command. Substitute c5 for whatever you mapped to:

# dmsetup table --target crypt --showkey /dev/mapper/c5

Result:
0 200704 crypt aes-cbc-essiv:sha256
a1704d9715f73a1bb4db581dcacadaf405e700d591e93e2eaade13ba653d0d09
0 7:0 4096

The result is actually one line, wrapped here for clarity. The long hex string is the master key.

- Convert the master key to a binary file representation. You can do this manually, e.g. with hexedit. You can also use the tool "xxd" from vim like this:

echo "a1704d9....53d0d09" | xxd -r -p > master_key

- Do a luksFormat to create a new LUKS header. Unmapthe device before you do that (luksClose). Replace \dev\dsa10 with the device the LUKS container is on:

cryptsetup luksFormat --master-key-file=master_key \dev\sda10

Note that if the container was created with other than the default settings of the cryptsetup version you are using, you need to give additional parameters specifying the deviations. If in doubt, just do the first step, keep the whole result safe and try with the script by Milan. It does recover the other parameters as well.

Side note: This is the way the decrypt_derived script gets at the master key. It just omits the conversion and hashes the master key string. "

----
ich würd das gern ausrprobieren, aber wie kann ich die festplatte spezifizieren? gibt ja auch die verschlüsselte am rechner, an dem die betroffene angeschlössen ist... ist c5 der wert in den ich festplatte einsetze?

Schönen Tag!
 
Zuletzt bearbeitet:
Die Anleitung wird dir nichts bringen, da diese nur bei einem noch eingebundenen Volume funktionieren wird - hast du den Rechner seit dem Formatieren bereits neu gestartet, so ist es vorbei. Allerdings ist die verlinkte Seite interessant, da dort auch mal beschrieben wird, wie es bezüglich LUKS mit Backup-Header aussieht: Fazit - es gibt keinen. Daher treffen für dich wohl leider folgende zwei Punkte aus der verlinkten Seite zu:
What happens if I (quick) format a LUKS partition?

I have not tried the different ways to do this, but very likely you will have written a new boot-sector, which in turn overwrites the LUKS header, including the salts, making your data permanently irretrivable, unless you have a LUKS header backup. You may also damage the key-slots in part or in full. See also last item.
What happens if I overwrite the start of a LUKS partition or damage the LUKS header or key-slots?

There are two critical components for decryption: The salt values in the header itself and the key-slots. If the salt values are overwritten or changed, nothing (in the cryptographically strong sense) can be done to access the data, unless there is a backup of the LUKS header.
 
Gutja, ich habs aufgegeben und die Festplatte überschrieben. Die Daten waren größtenteils doppelt gesichert - hoffe es fehlt nichts wichtiges.

Danke für Eure Antworten!
 
Zurück
Oben