Truecrypt - A newer version is required...

[Harti2011]

Hallo liebe Community,

vor einiger Zeit hatte ich hier schonmal einen Thread zum Thema Truecrypt eröffnet.

https://www.computerbase.de/forum/threads/truecrypt-container-aus-dummheit-geloescht.931208/page-2

Damals hatte ich versehentlich die falschen Truecrypt Container gelöscht. Mit der Hilfe von Simpson474 habe ich es dann wieder zum größten Teil hinbekommen (vielen Dank hierfür)!!

Nun habe ich auf der Suche nach dem Rest der Daten einen neuen Teil entdeckt. Allerdings sagt mir Truecrypt beim mounten des Containers "A newer version of truecrypt is required to mount the volume"

Allerdings benutze ich schon die neueste Version (7.1a) und der Container wurde mit Version (6.x) erstellt. Kennt jemand diesees Phänomen?? Kann es sein, dass der Container damals nicht vollständig erstellt wurde und es nur ein Containerrest ist??

Vielen Dank im Voraus,
Harti2011

 

[wertzuiop123]

Auf der Suche nach der Frage findet man nur auch nur Fragen und keine Antworten :/
Einzige Möglichkeit wäre mal ältere Versionen installieren und testen ob man's zum Laufen bringt

Kenne dies nur von Web Anwendungen, die die neueste Version noch nicht kennen. z.B. trotz neuesten Firefox wurde gesagt (Adwords Kundencenter), dass man einen aktuellen Browser nehmen soll.

 

[Harti2011]

Vielen Dank für die Antwort. Habe schon eine 5er und eine 6er Version getestet. Werde aber wohl mal noch ein paar weitere Builds probieren und hoffen!
Dachte, dass es vielleicht mal eine Version mit einem Bug oder ähnlichem in diese Richtung gab. Wenn nichts klappt, teste ich die Sektoren mal mit TestCrypt - vielleicht schafft es dieses Programm ja den Container zu mounten...

Ergänzung (23. April 2013)

Habe es nun nochmal mit Truecrypt 5.3 (glaube ich), 6.3a und 7.0 probiert. Bei Version 6 und 7 kommt immernoch die Meldung "A newer version of truecrypt is required..." - interessanterweise sagt die 5er Version gleich, dass es das falsche Kennwort oder keine Truecrypt Datei ist.
Beim Scan der Sektoren mit TestCrypt findet er auch keinen Startheader. TCBrute (habe dort einfach mal das Kennwort in eine Textdatei geschrieben) allerdings findet das Kennwort für diesen Container.

Hat noch jemand eine Idee oder kennt diesen Fehler??

 

[Simpson474]

// Try to decrypt header 
DecryptBuffer (header + HEADER_ENCRYPTED_DATA_OFFSET, HEADER_ENCRYPTED_DATA_SIZE, cryptoInfo);

// Magic 'TRUE'
if (GetHeaderField32 (header, TC_HEADER_OFFSET_MAGIC) != 0x54525545)
	continue;

// Header version
headerVersion = GetHeaderField16 (header, TC_HEADER_OFFSET_VERSION);
if (headerVersion > VOLUME_HEADER_VERSION)
{
	status = ERR_NEW_VERSION_REQUIRED;
	goto err;
}

Auch wenn es unwahrscheinlich ist, dass 4 aufeinanderfolgende Bytes nach der Entschlüsselung zufällig den String "TRUE" ergeben - unmöglich ist es auch nicht. Da TrueCrypt in den ursprünglichen Versionen keinen CRC-Schutz im Header besitzt, ist der nächste Check nach der Prüfung auf "TRUE" bereits der Check auf die Header-Version - war das "TRUE" ein reiner Zufallstreffer, so kann in der Header-Version alles mögliche stehen.

Mittlerweile hat es im Bereich Datenrettung bei fragmentierten Dateicontainern doch einige Fortschritte gegeben - es ist mittlerweile einmal gelungen, 3 Fragmente mit nur einem einzigen Header quasi ohne Datenverlust zusammenzusetzen. Damit dieser Ansatz funktioniert, benötigst du ein paar (möglichst kleine) Dateien mit definierten Dateiheader (z.B. JPEG, MP3, DOC, etc.), welche beim Einbinden des ersten Fragmentes nicht geöffnet werden können.

 

[Harti2011]

Hallo Simpson474,

vielen Dank erstmal für die viele Unterstützung, die du mir schon geleistet hast - da war jetzt mal eine kleine Spende fällig!

Ich denke nicht, dass der Header ein Zufallsfund war, da er genau auf ein mir bekanntes Passwort hört. Du meinest ja, dass es evtl. nur ein Zufall war, oder??

Ausgangssituation:
2 Container auf einer Platte (1 x ca 20 GB / 1x ca. 80) - war aber zusammen nur ein Teil der Platte.
Habe dann den größeren Container gelöscht (war unwichtig) und einen neuen kleineren angelegt und wollte die Daten (von dem noch bestehenden) hineinkopiert. Allerdings hat der Platz nicht ausgereicht und ich habe ihn wieder gelöscht.
Anschließend habe wollte ich nochmal einen kleinen Container anlegen. Als ich gemerkt habe, dass ich versehentlich den originalen Container und den neu angelegten gelöscht hatte, brach ich die Erstellung ab.

Das heißt, ich hatte dann keinen Container mehr auf der Platte. Mit deiner Hilfe habe ich es dann aber geschafft 3 Containerfragmente des Originalcontainers (20GB) aneinanderzureihen. Allerdings fehlen in der Mitte gute 5 GB. Ich habe nun also Fragment 2 (1 und 3 sind in Ordnung) mit TCBrute auf alle möglichen Kennwörter geprüft und fand den neuen Header (der die neuere Verision will). Sprich, das muss der Container sein, dessen Erstellung ich abgebrochen habe. Zugleich hat mir diese Erstellung wohl die Daten überschrieben.
Im Umkehrschluss heißt dies für mich allerdings auch, dass der Container, in den ich meine Daten kopieren habe, aber zu klein war ja noch vorhanden sein muss.
Ich habe auch das Anfangsfragment des 80 GB Containers gefunden - allerdings lässt der sich zwar mounten, aber selbst mit file recovery nichts finden. Meine Vermutung ist nun, dass in diesem Fragment der Container liegt, der mir zu klein wurde und dann von mir gelöscht wurde. Allerdings kann ich den Header optisch nicht erkennen, da er zwischen den "Zufallszahlen" des ursprünglichen 80 GB Containers liegt.

Momentaner Zustand:
Container 1:
Fragment 1 - ok
Fragment 2 - ab circa 5 GB ok - davor ist der abgebrochene Container
Fragment 3 - ok

Container 2:
Fragment des 80 GB Containers mit 15 GB - Mountbar aber nur Datenmüll - dazwischen muss sich wohl der Container verstecken den ich suche (Vermutung, da ich wenn ich das Fragment mounte nur "Müll" sehe)

Kann ich bei Container 2 prüfen, ab welcher Stelle er inkonsistent wird??

Ich hoffe dass man einigermaßen versteht was ich meine (ganz ehrlich - ich versuche selbst immernoch nachzuvollziehen was mir da wie passiert ist )

Vielen Dank nochmal,
Harti2011

 

[hoermann]

@Harti2011,

bei mir hat es Dank Simpson474 Hilfe geklappt einen Container bestehend aus drei Fragmenten wieder so zusammenzusetzen das wirklich alle Dateien wieder lesbar waren. Simpson474 konnte ein paar Bugs in seinen Tools entfernen und so kann man die Containerfragmente besser lokalisieren (bei Dir muss man dann noch raus bekommen welches Fragment zu welchem Container gehört).
Es gibt auch ein neues Tool von Simpson474 mit dem man eine bestimmte Datei in den Fragmenten orten kann. (Am besten geht das wenn man noch eine original Datei besitzt von der man weiß das Sie im Container liegt.) Dadurch ist es mir gelungen die Fragmente aneinander zufügen mal mit Lücke und mal überlappend. Ich verlinke bewusst nicht auf die Tools das überlasse ich Simpson474.

Gruß hoermann

 

[Harti2011]

Hallo Hoerman,

danke für die Antwort. Die 3 Fragmente des 20 GB Containers konnte ich auch schon zusammen schustern. Fragment 2 ist ca 7 GB groß und ab circa 5 GB sind die Daten auch OK. Nur ist am Anfang des Fragments ein Container, den ich erstellen wollte und mir somit meine Daten überschrieben habe.
Das heißt der Originalcontainer ist soweit wie möglich auch schon wiederhergestellt (Daten hab ich schon gesichert). Aber das was mir noch fehlt ist genau das was schon in den Container kopiert war, der mir dann zu klein wurde. Den hab ich dann gelöscht - blöderweise auch den Originalcontainer. Danach wollte ich einen größeren erstellen (hab aber abgebrochen als ich das Unglück bemerkt habe) - den hab ich nun am Anfang von Fragment 2 gefunden. Somit muss der, der mir zu klein wurde, aber die noch fehlenden Daten beinhaltet noch da sein. Blöderweise liegt er aber wohl genau zwischen anderen "Zufallsdaten" der schon gelöschten Container

Inzwischen ist es einfach schon das Interesse, das mich dazu treibt daran zu glauben, dass dort noch etwas machbar sein muss. Bin schon weiter gekommen als ich erwartet hatte.

@Simpson474
Wenn du noch mehr geniale Tools (wie von hoermann beschrieben) in deinem Repertoire hast spiele ich natürlich gerne Versuchskaninchen

 

[hoermann]

@Harti2011

Das einfache an einander reihen der Fragmente bringt gar nix da diese so nicht passen bei mir war zwischen dem 1 und 2 Fragment ein leerer Zwischenraum und das 2 und 3 haben sich überlappt. Wichtig ist alle Fragmente nochmal genau zu lakalisieren und dort die Header zu suchen. Das Fragment mit den Header am Anfang ist Fragment 1 wenn man dieses dann mountet und darüber mit GetdataBack Dateien sucht kann man sich die Position der Datei anzeigen lassen und weiss welches das richtige nächste Fragment ist.

 

[Simpson474]

Ich denke nicht, dass der Header ein Zufallsfund war, da er genau auf ein mir bekanntes Passwort hört. Du meinest ja, dass es evtl. nur ein Zufall war, oder??

Ich würde zu 99% davon ausgehen, dass es sich um einen Zufallstreffer handelt: bei 2 Byte hat man alle paar MB einen Zufallstreffer, bei 3 Byte wird es bereits deutlich weniger, aber auch eine Kombination von 4 Bytes kann man noch durch Zufall finden. Da TrueCrypt hier wirklich nur auf den String "TRUE" prüft und anschließend sofort versucht, die Version zu interpretieren ist sowas durchaus möglich: wäre noch eine CRC-Prüfung vorhanden, so gäbe es mit extrem hoher Wahrscheinlichkeit nie einen Zufallstreffer (diese ist in TrueCrypt zwar vorhanden, wurde aber erst mit einer späteren Header-Version eingebaut und daher muss vor der CRC-Prüfung die Header-Version geprüft werden).

Die restliche Beschreibung muss ich mir morgen mal genauer durchlesen und überlegen, wie man hier am besten vorgehen könnte.

 

[Harti2011]

Hallo Simpson,

dann kann das ganze natürlich durchaus ein Zufallsfund sein. Ich dachte nur, weil ich mit TC-Bute knappe 10000 Passwortkombinationen probiert habe und genau das, das ich kenne als richtig angezeigt wurde, ich einen Header entdeckt habe. Aber mich hat es dann auch stutzig gemacht, dass dein TestCrypt keinen Header gefunden hat.

Ich liefere natürlich auch gerne nochmal eine Erklärung nach, falls aus meinen obigen Beiträgen nicht genau herausgelesen werden kann was ich meine
Aber generell hört sich die Methode, die hoerman beschrieben hat, mit vorhandenen Dateien nach Fragmenten zu suchen recht interessant an. Wie muss ich mir das vorstellen?? Falls ich nämlich in Fragment 2 doch keinen Header gefunden habe, dessen Daten mir meinen Originalcontainer überschrieben haben, könnte es sein, dass es noch ein weiteres Fragment gibt, das dazwischen gehört. Sprich ich habe 3 Fragmente erfolgreich aneinander gesetzt. Bin aber davon ausgegangen, das der Container (den ich dachte jetzt gefunden zu haben) mir einen Großteil von Fragment 2 überschrieben hat.

Vielen Dank schonmal,
Harti

 

[Simpson474]

Um welche Dateitypen handelt es sich bei den fehlenden Daten? Wichtig wäre auch der Offset im Dateisystem von ein paar defekten Dateien - diesen solltest du mit der Demoversion von GetDataBack auslesen können.

 

[Harti2011]

So, habe mal versucht die Offsets zu finden. Leider sehe ich weder in WinHex noch in GetDataBack eine Offset Angabe.

Hab mal einen Screenshot gemacht. Was es gibt sind die Cluster.


Die Dateitypen die noch fehlen sind hauptsächlich Bilder, also jpg und eventuell auch ein paar avi bzw. mpg Dateien...
Alles andere ist soweit ich mich noch erinnere wieder da. Ein paar Ordner werden mir in Winhex angezeigt, aber ohne Inhalt. In GetDataBack gibt es Ordner deren Namen er nicht wiederherstellen konnte. Mit Inhalt aber der ist defekt. Von einem dieser defekten Bilder habe ich den Screenshot erstellt...

 

[Simpson474]

Hast du FAT32 als Dateisystem? Am ehesten denke ich dürfte der Wert bei "Ben. Sektoren" hingehen: kannst du die Infos mal von einer funktionierenden JPEG-Datei anzeigen und anschließend das eingebundene TrueCrypt-Volume in HxD öffnen und einen Screenshot vom entsprechenden Sektor machen.

 

[Harti2011]

Ja, das Dataisystem ist Fat32... Hab den Screenshot der Sektoren mit WinHex gemacht - falls das etwas ausmacht!?

Funktionierende Datei mit GetDataBack:


Sektor in WinHex:

 

[Simpson474]

Der Inhalt des Sektors wäre interessant, dieser müsste bei einer JPEG-Datei mit FF D8 beginnen, falls der von GetDataBack angezeigte Sektor korrekt ist.

 

[Harti2011]

...

Ergänzung (27. April 2013)

Guten Morgen,

so, der Scan ist durchgelaufen, hat aber keine Ergebnisse geliefert. Was mir aber auffiel ist, dass bei ein paar vergleichen von funktionierenden Dateien nur die ersten 4 Byte gleich waren. Könnte auch an unterschiedlichen Kameras bei der Aufnahme liegen, oder??

Ich würde sonst mal die ersten 4 Byte einer avi angeben, da weiß ich dass es die selbe Kamera war. Oder meinst du bei nur 4 Byte könnten wieder Zufallstreffer entstehen??

 

[Simpson474]

Selbst bei 4 Byte kann man sich bei JPEG nicht ganz sicher sein, da nur die ersten zwei Byte wirklich definiert sind und anschließend bereits Unterschiede je nach Kamera/Programm auftreten können. Bei AVI sollten die ersten 4 Byte definiert sein und falls du Zufallstreffer bekommst, so könnte man versuchen, mit einer zweiten Datei die Zufallstreffer zu filtern. Wichtig bei größeren Dateien (z.B. AVI) ist jedoch, dass bereits der erste Cluster beschädigt ist - du solltest daher zunächst mit WinHex nachsehen, ob die ersten 4 Byte der Datei wirklich fehlerhaft sind. Ansonsten kannst du auch einen Test machen, ob die Angaben soweit passen, indem du die ersten z.B. 16 Byte einer funktionierenden Datei als Referenz verwendest und prüfst, ob das Tool den richtigen Sektor ausspuckt.

 

[Harti2011]

So, hab jetzt gestern mal auf avi geprüft - leider auch ohne Erfolg - allerdings bekomm ich auch bei einer bestehenden Datei kein Ergebnis. Ich denke, dass da noch der Offset falsch ist. Beim Randomblocklocator, musste ich bei jedem gefundenen Block
67 Sektoren zurück gehen, dann hatte ich den Anfang. Meinst du das könnte hier auch so etwas sein? Mein Header hat 128 KB - somit hab ich 131072 dazu addiert....

 

[Simpson474]

Ich bin zur Zeit beruflich ziemlich eingespannt, von daher bin ich erst jetzt zum Antworten gekommen. Ich hab das Tool noch einmal aktualisiert, so dass es jetzt zusätzliche Informationen beim Öffnen des TrueCrypt-Headers ausgibt. Lade diese Version noch einmal herunter und poste die angezeigten Werte.

 

[Harti2011]

Garkein Problem - find es ja schon super dass du mir überhaupt hilfst! Hab jetz grad mal den Screenshot gemacht. Aber der Offset scheint gestimmt zu haben. Ich glaub ich lass über Nacht nochmal auf eine exisitierende Datei prüfen - nicht dass ich mich irgendwo verrechnet hab... Ich hoff, dass der ausgegebene Sektor in WinHex und GetDataBack der richtige ist. Meinst du ich sollte vielleicht mal ein anderes Programm probieren??