Testcrypt failure(32)?

[hierunda]

Versuche grade Daten von einer Samsung F4 (2TB) zu retten die beim in-place verschlüsseln mit Fehler abgebrochen hat.
Sind zwar keine Lebenswichtigen, aber unwiederbringliche persönliche Daten drauf, daher versuche ich es immer wieder :/
Nachdem ich nun endlich einen alten Rechner wiederbelebt habe und damit Testcrypt laufen lassen konnte, hat dieser auch eine verschlüsselte Partition gefunden, bricht aber beim mounten des Backupheader mit dieser Meldung ab:

Unable to mount the volume: "DeviceIoControl" API using I/O-Controll "TC_IOCTL_MOUNT_VOLUME" failed(32)

Kann mir jemand sagen was diese Meldung bedeutet und wie ich am besten weiter vorgehe?
Habe auch gehört das der(einer der?) Testcrypt-Entwickler hier unterwegs ist.

Über google und die Forensuche habe ich herausgefunden, das es womöglich mit den größeren Sektoren der F4 zusammenhängt, dass Testcrypt diese nicht mounten kann?

Wie bei anderen großen Festplatten mit 2 TByte und mehr verwendet Samsung eine neue Technik, die mit größeren Sektoren arbeitet. Anstatt der üblichen 512 Byte besitzen jetzt die Sektoren eine Größe von 4096 Byte im so genannten „Advanced Format“. Dadurch lassen sich mehr Daten auf einer vergleichbaren Fläche mit 512 Byte-Sektoren speichern.

//Edit:
Ich habe die in-place Verschlüssung damals per USB-SATA-Adapter gemacht, die HDD hängt jetzt intern an einem SATA2 Port. Evtl. ist dies noch wichtig?

 

[Simpson474]

Habe auch gehört das der(einer der?) Testcrypt-Entwickler hier unterwegs ist.

Bisher ist das ganze eine One-Man-Show

Der TestCrypt-Treiber ist bis auf kleine Erweiterungen der Original TrueCrypt-Treiber - dieser lehnt unvollständig verschlüsselte Volumes ebenfalls ab (Fehlercode 32 bedeutet beim TrueCrypt-Treiber ERR_NONSYS_INPLACE_ENC_INCOMPLETE). Ich hab mir bei ähnlichen Problemen die In-Place Verschlüsselung von TrueCrypt schon mal angesehen und eigentlich wäre es möglich, den Treiber mit kleinen Erweiterungen dazu zu bringen, unvollständig verschlüsselte Volumes zu mounten - ich müsste dazu den Kernel-Debugger noch einmal ausgraben, denn meine testweise Anpassung des Treibers funktionierte nur manchmal. Die einfachste Lösung in diesem Fall ist häufig das Fertigstellen der In-Place Verschlüsselung: bleibt TrueCrypt beim Verschlüsseln scheinbar stehen, so liegt es meist an fehlerhaften Sektoren der HDD (Screenshot von CDI wäre interessant). Wenn du die HDD in diesem Fall mit dd_rescue unter Linux klonst (gibt wohl keine bessere Alternative bei fehlerhaften Sektoren), so lässt sich die Verschlüsselung anschließend meist fertigstellen.

 

[hierunda]

Also für ne one-man show ist das ein super Programm.
Schade, dass das mit dem mounten von unfertigen In-Place-Verschlüsselungen nicht klappt, hatte auf sowas gehofft, da das bei DiskCryptor ohne Probleme möglich ist :/
Hab nur 2 HDDs mit TrueCrypt verschlüsselt und den Rest mit DC, und ausgerechnet eine von denen geht kaputt

Du hast recht, dass Truecrypt wegen fehlerhaften Sektoren stehen bleibt. Es fragt dann nach ob es diese mit Nullen überschreiben soll, oder so und dann hängt sich nach einem CRC Fehler (vorhin zumindest hab ich es nochmal versucht) das ganze System auf.

Die Platte ist allerdings schon zu 83% verschlüsselt laut Fortschrittsanzeige, und es waren nur so um die 300-400gb drauf, vllt hab ich ja glück.

Hab mir nun erst mal eine neue HDD besorgt um das mit dd auszuprobieren.
Genauer gesagt diese: http://www.kmcomputer.de/item/699/684/0/114829/3.5zoll-wd-3000gb-caviar-green-wd30ezrx-6gbs.html
Ich nehme mal an, dass diese auch 4096er Sektoren hat um die 3TB handlen zu können?

Bin mir nicht sicher ob dd das stört, hab das bis jetzt erst einmal von einer 500er Seagate auf eine 500er Seagate gebraucht, die waren baugleich^^

 

[Simpson474]

Intern haben beide HDDs 4096 Bytes pro Sektor - nach außen melden beide jedoch 512 Bytes pro Sektor. Bisher gibt es so viel ich weiß keine HDD, welche dem Betriebssystem eine Sektorgröße von 4096 Bytes vorgibt - es gibt jedoch ein paar USB/SATA-Brückenchips in externen Festplattengehäusen mit 4096 Bytes pro Sektor um den MBR über 2 TB aufblasen zu können. Bezüglich Klonen macht das nicht viel aus, selbst wenn du mit falschem Alignment auf die neue HDD klonst, so funktioniert trotzdem alles nur beim Schreiben hast du Geschwindigkeitseinbrüche.

Das normale "dd" eignet sich nur bei wenigen fehlerhaften Sektoren (und auch nur mit spezieller Option, ansonsten bricht "dd" beim ersten fehlerhaften Sektor ab) - sind größere Blöcke an fehlerhaften Sektoren vorhanden, so ist "dd_rescue" die bessere Wahl, da dort bei einem fehlerhaften Sektor größere Blöcke übersprungen werden, welche anschließend nach der ersten Sicherung in einem zweiten Durchgang noch verkleinert werden können.

 

[hierunda]

hm ich glaube ich kann mich von der Platte verabschieden, nach knapp 361MB die er in das image gerettet hat sagt er jetzt ErrSize: 2000GB und fängt an die Errorsektoren zu splitten...

Schätze mal die Platte ist verloren, was?

//Edit:
durch die Moderation scheinen die Beiträge durcheinander zu kommen, dieser Beitrag hier ist eigentlich der letzte.

//Edit2:
oder die Moderation hat den anderen Beitrag gefressen, kann auch sein
Ich schrieb, dass das direkte 1:1 kopieren von Platte zu Plate nicht funktioniert hat, durch zu viele Fehler, und dich daher diesen Weg mit einem Image probiert habe:
hxxp : / / www_mrmuh_com/2011/02/raw-image-von-truecrypt-partition-erstellen/
Sah zunächst gut aus, aber scheinbar sind nicht mehr als 361MB zu retten.

 

[Simpson474]

Bricht das Programm ab oder läuft es weiter? Wenn es nicht abbricht, so würde ich den Klonvorgang einfach mal durchlaufen lassen (Logfile am besten anlegen) - besser wird die HDD sicher nicht mehr. Das Programm kann auch automatisch von hinten beginnen die Daten zu kopieren - möglicherweise kommen daher die angegebenen 2TB an Fehlern.

 

[hierunda]

meinst du das direkte klonen von HDD auf HDD oder das mit dem .img File?
Bei dem Image ist nach den 361MB ein scheinbar endloses splitten der Error am laufen ohne ETA.
Bei der 1:1 Kopie auf die andere HDD hab ich wenn die Error losgehen eine ETA von 500-800 Stunden :/

//Edit:
Achja, den Schalter, -r, hab ich probiert, legt leider direkt mit Error los.

 

[Simpson474]

Ich würde die 1:1 Kopie machen - wie lange hast du das Programm nach dem ersten Fehler laufen lassen? Die Restzeit geht natürlich extrem hoch, wenn bereits nach ein paar hundert MB eine große Anzahl an fehlerhaften Sektoren kommen. Anschließend sollte die Zeit jedoch wieder runtergehen, wenn keine weiteren Blöcke mit fehlerhaften Sektoren mehr vorhanden sind.

EDIT: Von ddrescue gibt es zwei Versionen, das "-r" für Rückwärts ist so viel ich weiß nur bei der alten Version vorhanden. Probier mal nach dieser Anleitung, am besten unter Ubuntu (der apt-get Befehl funktioniert normal erst nachdem du die Universe-Paketquelle hinzugefügt hast, geht irgendwo unter Unity und Paketquellen auswählen).