16
Truecrypt setzt Verschlüsselung (hidden volume) auf falschem Datenträger fort - Datenverlust!!
Hallo,
ich bin nicht so ein intensiver Forum-Nutzer, hoffe aber, dass ich hier an der richtigen Stelle bin und mir jemand weiterhelfen kann. Folgendes ist mir passiert:
Ich habe mit Truecrypt über einen aktiven Hub eine Platte (= Zieldatenträger, 500GB) komplett neu verschlüsselt (inkl. verstecktem Volume), weil ich statt FAT NTFS benötigte, um auch große Dateien dort ablegen zu können. Zum Ende der Fertigstellung des äußeren Volume habe ich dann schon mal die zweite verschlüsselte Platte (= Originaldatenträger) an einen freien Port des aktiven Hubs angeschlossen. Truecrypt ließ sich dadurch im Verschlüsselungsprozess des Zieldatenträgers nicht "stören" und begann nunmehr mit dem Dialog zur Anlage des versteckten Volume. Ich gab die Daten zur Verschlüsselung ein (Größe des versteckten Volume, NTFS und gleiches Passwort) und ließ Truecrypt diesen Vorgang beenden.
Anschließend wollte ich den Ziel- und Originaldatenträger mit Truecrypt einbinden und mit dem Überspielen beginnen, musste aber Folgendes feststellen:
Auf dem Zieldatenträger existierte nur ein äußeres (logischerweise) leeres Volume. Ein inneres Volume konnte ich mit Hinweis auf "falsches Passwort oder kein Trueptcrypt-Volume" nicht öffnen (weil es - entgegen meiner Erwartung - wohl auch gar nicht vorhanden ist). Auf dem Originaldatenträger konnte ich zwar ein äußeres und verstecktes Volume öffnen, aber das versteckte enthielt - zu meiner Überraschung - keine Daten mehr.
Wie kann es sein, dass Truecrypt im Prozess der Verschlüsselung im kompletten Modus nach Fertigstellung des äußeren Volume OHNE WARNMELDUNG & HINWEIS auf einen zwischenzeitlich zusätzlich angeschlossenen Datenträger WECHSELT und DORT das Hidden-Volume anlegt (in meinem Fall besser gesagt ein bereits existentes Hidden-Volume mit Inhalt mit einem neuen Schlüssel überschreibt und somit die "alte" Datenträgerstruktur "löscht"? 1. völlig unlogisch & 2. wer weiß und rechnet denn mit sowas )-:
Meine Frage ist nunmehr: kann ich das "alte" innere Volume des Originaldatenträger so wiederherstellen, dass ich an die Verzeichnungsstruktur und den Inhalt wieder rankomme? Das Passwort für den alten Schlüssel habe ich ja, nur ein Backup von ihm leider nicht. Testcrypt hat mir nur die "aktuellen" Header der Platte (inneres und äußeres Volume) ausgespuckt. Doch wen interessieren die schon. Sind möglicherweise auf dem Originaldatenträger irgendwo auch ältere Schlüssel abgelegt, welche sich mit Bordwerkzeug von Truecrypt oder Veracrypt (dort war der Datenträger zuletzt eingebunden) oder auch mit anderer Software auslesen lassen.
Oder kann ich mit einer Datenrettungssoftware wie GetDataBack Pro von einer gemounteten augenscheinlich leeren Platte trotzdem noch Daten retten (ich gehe nämlich davon aus, dass diese Daten noch da sind und nur deswegen nicht angezeigt werden, weil der von Truecrypt neu angelegte Schlüssel, die alte Datenträgerstruktur/das Inhaltsverzeichnis überschrieben hat).
Es wäre toll, wenn es für mein Problem eine Lösung gäbe. Besinnliche Feiertage, guten Rutsch & Gruß Alex
ich bin nicht so ein intensiver Forum-Nutzer, hoffe aber, dass ich hier an der richtigen Stelle bin und mir jemand weiterhelfen kann. Folgendes ist mir passiert:
Ich habe mit Truecrypt über einen aktiven Hub eine Platte (= Zieldatenträger, 500GB) komplett neu verschlüsselt (inkl. verstecktem Volume), weil ich statt FAT NTFS benötigte, um auch große Dateien dort ablegen zu können. Zum Ende der Fertigstellung des äußeren Volume habe ich dann schon mal die zweite verschlüsselte Platte (= Originaldatenträger) an einen freien Port des aktiven Hubs angeschlossen. Truecrypt ließ sich dadurch im Verschlüsselungsprozess des Zieldatenträgers nicht "stören" und begann nunmehr mit dem Dialog zur Anlage des versteckten Volume. Ich gab die Daten zur Verschlüsselung ein (Größe des versteckten Volume, NTFS und gleiches Passwort) und ließ Truecrypt diesen Vorgang beenden.
Anschließend wollte ich den Ziel- und Originaldatenträger mit Truecrypt einbinden und mit dem Überspielen beginnen, musste aber Folgendes feststellen:
Auf dem Zieldatenträger existierte nur ein äußeres (logischerweise) leeres Volume. Ein inneres Volume konnte ich mit Hinweis auf "falsches Passwort oder kein Trueptcrypt-Volume" nicht öffnen (weil es - entgegen meiner Erwartung - wohl auch gar nicht vorhanden ist). Auf dem Originaldatenträger konnte ich zwar ein äußeres und verstecktes Volume öffnen, aber das versteckte enthielt - zu meiner Überraschung - keine Daten mehr.
Wie kann es sein, dass Truecrypt im Prozess der Verschlüsselung im kompletten Modus nach Fertigstellung des äußeren Volume OHNE WARNMELDUNG & HINWEIS auf einen zwischenzeitlich zusätzlich angeschlossenen Datenträger WECHSELT und DORT das Hidden-Volume anlegt (in meinem Fall besser gesagt ein bereits existentes Hidden-Volume mit Inhalt mit einem neuen Schlüssel überschreibt und somit die "alte" Datenträgerstruktur "löscht"? 1. völlig unlogisch & 2. wer weiß und rechnet denn mit sowas )-:
Meine Frage ist nunmehr: kann ich das "alte" innere Volume des Originaldatenträger so wiederherstellen, dass ich an die Verzeichnungsstruktur und den Inhalt wieder rankomme? Das Passwort für den alten Schlüssel habe ich ja, nur ein Backup von ihm leider nicht. Testcrypt hat mir nur die "aktuellen" Header der Platte (inneres und äußeres Volume) ausgespuckt. Doch wen interessieren die schon. Sind möglicherweise auf dem Originaldatenträger irgendwo auch ältere Schlüssel abgelegt, welche sich mit Bordwerkzeug von Truecrypt oder Veracrypt (dort war der Datenträger zuletzt eingebunden) oder auch mit anderer Software auslesen lassen.
Oder kann ich mit einer Datenrettungssoftware wie GetDataBack Pro von einer gemounteten augenscheinlich leeren Platte trotzdem noch Daten retten (ich gehe nämlich davon aus, dass diese Daten noch da sind und nur deswegen nicht angezeigt werden, weil der von Truecrypt neu angelegte Schlüssel, die alte Datenträgerstruktur/das Inhaltsverzeichnis überschrieben hat).
Es wäre toll, wenn es für mein Problem eine Lösung gäbe. Besinnliche Feiertage, guten Rutsch & Gruß Alex
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 635736
Url: https://administrator.de/contentid/635736
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
16 Kommentare
Neuester Kommentar
Hallo Alex,
du hast gleich eine Reihe von Kardinalsfehler begangen.
1. Kein Backup
2. Nicht genau gelesen, was das Tool tut
3. Änderungen am System vorgenommen, während es verschlüsselt..
Zum Fehler: Du kannst natürlich Glück haben, aber da wir bis auf das grobe Resultat kaum Infos haben, kann man das ganze als nicht mehr als einen Erfahrungsbericht einsortieren. Wenn die Daten wichtig sind, geh zum Datenretter....
Grüße
du hast gleich eine Reihe von Kardinalsfehler begangen.
1. Kein Backup
2. Nicht genau gelesen, was das Tool tut
3. Änderungen am System vorgenommen, während es verschlüsselt..
Zum Fehler: Du kannst natürlich Glück haben, aber da wir bis auf das grobe Resultat kaum Infos haben, kann man das ganze als nicht mehr als einen Erfahrungsbericht einsortieren. Wenn die Daten wichtig sind, geh zum Datenretter....
Grüße
Und warum truecrypt?
Das wird seit Jahren nicht mehr entwickelt und hat etliche Fehler.
Veracrypt hat das übernommen. Das solltest du damit machen
Das wird seit Jahren nicht mehr entwickelt und hat etliche Fehler.
Veracrypt hat das übernommen. Das solltest du damit machen
ich fürchte auch, die Daten sind futsch. Eventuell könntest noch mit einem Hex-Editor versuchen einen Schlüssel auszulesen und hoffen, dass Truecrypt nicht den alten Container überschrieben hat. Wie es passiert ist könnte ich mir nur so vorstellen, dass sich irgendwie während des Anstöpseln des 2. Laufwerkes die Buchstaben verschoben haben.
Hi Alex,
in Verbindung mit den ersten beiden Kommentaren, denen ich nur beipflichten kann:
Warum in aller Welt verwendest Du beides, TrueCrypt und VeraCrypt ?!?
VeraCrypt hat neben Korrektur von Fehlern und Sicherheitslücken auch das interne Format verändert, so dass TrueCrypt bei Zugriff auf von VeraCrypt verwaltete Container es eigentlich nur falsch machen kann.
Ergo sind Deine Chancen recht gering.
Um den nächsten Fehler zu vermeiden:
Alles was Du probierst, machst Du bitte nur auf Duplikaten Deiner Container.
=> dd und hexdump bzw wxHexEditor sind Deine Freunde (sofern Du Linux laufen hast).
=> hxd ist Dein Freund unter Windows (Daten-Imager unter Win fällt mir jetzt nicht ein)
Mit dem Container-Format von True-/VeraCrypt habe ich mich schon lange nicht mehr beschäftigt, aber ich habe im Hinterkopf, dass
1. am Anfang der asymmetrisch verschlüsselte Header ist, der den symmetrischen Schlüssel enthält.
2. Ein Backup des Headers sollte es am Ende geben.
3. Bei einem Passwortwechsel wird nur das Passwort des asymmetrischen Schlüssels getauscht. Der damit verschlüsselte symmetrische Schlüssel für die Daten ist davon nicht berührt.
=> Damit gilt:
Solltest Du Dein Passwort vergessen haben, dann könnte eine uralt-Sicherung (des gleichen Containers) durch Austausch des Headers das Passwort auf den alten Stand zurücksetzen. Das ist zwar aktuell nicht Dein Problem, aber:
Sollte die Software tatsächlich wild beide Container-Aktionen gemischt haben, so ist denkbar dass die Header vertauscht sind oder vertauschte symmetrische Schlüssel enthalten.
Mit dem Austausch der Header könntest Du den richtigen symmetrischen Schlüssel an den richtigen Container kleben und so wieder Zugriff auf Deine Daten bekommen.
Ergo:
0. Fertige eine Kopie aller Container an und arbeite darauf.
1. Bau Dir eine vollständige Liste an Möglichkeiten, wie Deine Container-Header mit Deinen Containern (extern + hidden) zueinander vertauscht sein könnten. ("kann nicht sein" gibt es nicht. nur vollständig zählt.)
2. RTFM TrueCrypt und VeraCrypt, um herauszubekommen, wie die Header zu finden und formatiert sind, denn sie enthalten sicherlich nicht nur den symetrischen Schlüssel, sondern auch die Partitions-Daten.
3. Ziehe alle Passwörter gleich, damit eine Fehlerquelle weniger besteht. Hoffentlich sind die Crypto-Verfahren identisch gewählt, so dass auch hier keine unnötigen Komplikationen auftreten.
4. Tausche die Header oder|und den symetrischen Schlüssel kontrolliert gegeneinander aus (unter Beachtung der Notwendigkeit zusätzlicher Partitions-Infos), und teste ob Du an die Daten heran kommst.
Nun kannst Du nur noch sauber arbeiten und hoffen:
Zugegeben: Das sind sehr viele Faktoren, die den Erfolg in Frage stellen und es ist viel Recherche-Aufwand notwendig.
Also stellt sich zuerst die Güterabwägung:
Gelernt, wie man es nicht macht, hast Du ja schon...
Viel Glück !
in Verbindung mit den ersten beiden Kommentaren, denen ich nur beipflichten kann:
Warum in aller Welt verwendest Du beides, TrueCrypt und VeraCrypt ?!?
VeraCrypt hat neben Korrektur von Fehlern und Sicherheitslücken auch das interne Format verändert, so dass TrueCrypt bei Zugriff auf von VeraCrypt verwaltete Container es eigentlich nur falsch machen kann.
Ergo sind Deine Chancen recht gering.
Um den nächsten Fehler zu vermeiden:
Alles was Du probierst, machst Du bitte nur auf Duplikaten Deiner Container.
=> dd und hexdump bzw wxHexEditor sind Deine Freunde (sofern Du Linux laufen hast).
=> hxd ist Dein Freund unter Windows (Daten-Imager unter Win fällt mir jetzt nicht ein)
Mit dem Container-Format von True-/VeraCrypt habe ich mich schon lange nicht mehr beschäftigt, aber ich habe im Hinterkopf, dass
1. am Anfang der asymmetrisch verschlüsselte Header ist, der den symmetrischen Schlüssel enthält.
2. Ein Backup des Headers sollte es am Ende geben.
3. Bei einem Passwortwechsel wird nur das Passwort des asymmetrischen Schlüssels getauscht. Der damit verschlüsselte symmetrische Schlüssel für die Daten ist davon nicht berührt.
=> Damit gilt:
Solltest Du Dein Passwort vergessen haben, dann könnte eine uralt-Sicherung (des gleichen Containers) durch Austausch des Headers das Passwort auf den alten Stand zurücksetzen. Das ist zwar aktuell nicht Dein Problem, aber:
Sollte die Software tatsächlich wild beide Container-Aktionen gemischt haben, so ist denkbar dass die Header vertauscht sind oder vertauschte symmetrische Schlüssel enthalten.
Mit dem Austausch der Header könntest Du den richtigen symmetrischen Schlüssel an den richtigen Container kleben und so wieder Zugriff auf Deine Daten bekommen.
Ergo:
0. Fertige eine Kopie aller Container an und arbeite darauf.
1. Bau Dir eine vollständige Liste an Möglichkeiten, wie Deine Container-Header mit Deinen Containern (extern + hidden) zueinander vertauscht sein könnten. ("kann nicht sein" gibt es nicht. nur vollständig zählt.)
2. RTFM TrueCrypt und VeraCrypt, um herauszubekommen, wie die Header zu finden und formatiert sind, denn sie enthalten sicherlich nicht nur den symetrischen Schlüssel, sondern auch die Partitions-Daten.
3. Ziehe alle Passwörter gleich, damit eine Fehlerquelle weniger besteht. Hoffentlich sind die Crypto-Verfahren identisch gewählt, so dass auch hier keine unnötigen Komplikationen auftreten.
4. Tausche die Header oder|und den symetrischen Schlüssel kontrolliert gegeneinander aus (unter Beachtung der Notwendigkeit zusätzlicher Partitions-Infos), und teste ob Du an die Daten heran kommst.
Nun kannst Du nur noch sauber arbeiten und hoffen:
- dass Deine Annahme stimmt (Daten noch da)
- auch die von mir in Betracht gezogene Annahme stimmt (Header-Infos vertauscht)
- Du den Container- und Header-Aufbau korrekt recherchiert hast
- und Du auch eine saubere Matrix an Kombinationsmöglichkeiten erstellt hast,
- die Du fehlerfrei abarbeitest.
Zugegeben: Das sind sehr viele Faktoren, die den Erfolg in Frage stellen und es ist viel Recherche-Aufwand notwendig.
Also stellt sich zuerst die Güterabwägung:
- Was sind Dir die Daten wert?
- Bist Du bereit die Kosten eines Profiunternehmens zu zahlen?
- Oder gibst Du die Daten einfach auf?
- Oder versuchst Du es und hast eine hohe Lernkurve bei sehr guter Frustrations-Toleranz?
Gelernt, wie man es nicht macht, hast Du ja schon...
Viel Glück !
Erstmal Danke für die vielen - auf jeden Fall auch - hilfreichen Antworten. Ich fasse mal kurz zusammen... zur Prophylaxe, damit mir das nicht noch mal passiert:
1) immer Header-Backup machen (klar, mache ich ab sofort)
2) nur noch mit VeraCrypt arbeiten (obwohl auch viele sagen, Version 7.1a sei trotzdem noch gut nutzbar)
3) nicht am System rumfummeln, während Testcrypt arbeitet (ok - hinterher ist man immer schlauer)
4) das mit "die Meldungen der Software beachten" ist so'ne Sache, die in diesem Moment wichtigen Fenster (sofern sie überhaupt erschienen sind) waren von den unwichtigen verdeckt. Allein das Windows nicht gefragt hat, ob er den dazugestöpselten Datenträger formatieren soll, hätte mich stutzig machen können/sollen. Wenn ich gewußt hätte, dass - wie holliknolli und Rizzo1 geschrieben haben - wahrscheinlich Laufwerkszuordnungen vertauscht werden können, wenn man Truecrypt während seiner Arbeit in die Parade fährt, hätte ich das hidden Volume natürlich erst fertiggestellt, weil - doppelt ärgerlich - dieser Vorgang ja ohnehin nur wenige Sekunden dauert.
nun gut - VIELLEICHT RELEVANT - bitte lest noch dieses:
nicht das wir uns falsch verstehen... Das ganze Unglück ist mir nur während der Nutzung von Truecrypt passiert, die Originalplatte, also jene, die dazugestöpselt wurde und dann den Schaden genommen hat, war vorher noch an einem anderen Rechner, als letzt genutzte Platte mit Veracrypt geöffnet. Deswegen hoff(t)e ich, dass evtl. Veracrypt (seitdem nicht mehr mit einer anderen Platte genutzt, allerdings natürlich zwischenzeitlich geschlossen und seitdem nicht mehr neu gestartet) den "alten" Schlüssel von diesem Datenträger irgendwo als Temp, Verlauf oder History gespeichert hat.
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Die Empfehlung von Rizzo1 werde ich auf jeden Fall ausprobieren und sehen was rauskommt.
Ich melde mich im neuen Jahr, kommt gut rüber und Grüße Alex
1) immer Header-Backup machen (klar, mache ich ab sofort)
2) nur noch mit VeraCrypt arbeiten (obwohl auch viele sagen, Version 7.1a sei trotzdem noch gut nutzbar)
3) nicht am System rumfummeln, während Testcrypt arbeitet (ok - hinterher ist man immer schlauer)
4) das mit "die Meldungen der Software beachten" ist so'ne Sache, die in diesem Moment wichtigen Fenster (sofern sie überhaupt erschienen sind) waren von den unwichtigen verdeckt. Allein das Windows nicht gefragt hat, ob er den dazugestöpselten Datenträger formatieren soll, hätte mich stutzig machen können/sollen. Wenn ich gewußt hätte, dass - wie holliknolli und Rizzo1 geschrieben haben - wahrscheinlich Laufwerkszuordnungen vertauscht werden können, wenn man Truecrypt während seiner Arbeit in die Parade fährt, hätte ich das hidden Volume natürlich erst fertiggestellt, weil - doppelt ärgerlich - dieser Vorgang ja ohnehin nur wenige Sekunden dauert.
nun gut - VIELLEICHT RELEVANT - bitte lest noch dieses:
nicht das wir uns falsch verstehen... Das ganze Unglück ist mir nur während der Nutzung von Truecrypt passiert, die Originalplatte, also jene, die dazugestöpselt wurde und dann den Schaden genommen hat, war vorher noch an einem anderen Rechner, als letzt genutzte Platte mit Veracrypt geöffnet. Deswegen hoff(t)e ich, dass evtl. Veracrypt (seitdem nicht mehr mit einer anderen Platte genutzt, allerdings natürlich zwischenzeitlich geschlossen und seitdem nicht mehr neu gestartet) den "alten" Schlüssel von diesem Datenträger irgendwo als Temp, Verlauf oder History gespeichert hat.
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Die Empfehlung von Rizzo1 werde ich auf jeden Fall ausprobieren und sehen was rauskommt.
Ich melde mich im neuen Jahr, kommt gut rüber und Grüße Alex
1. Immer voll Backup. Eine Kopf Zuweisung bringt dir nichts wenn die Daten Schrott sind.
2. Die Daten darin waren nach meiner Lesart ebenfalls überschrieben?
3. Sonst soweit im Grunde korrekt
2. Die Daten darin waren nach meiner Lesart ebenfalls überschrieben?
3. Sonst soweit im Grunde korrekt
Zitat von @Anubis8173:
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Moin,
Der Sinn und Zweck von Truecrypt, Veracrypt, Bitlicjer & Co. Ist, daß man auch mit "Datenrettungssoftware" nichts mehr "retten" kann. sonst könnte man sich den Aufwand sparen, wenn man so einfach an die Daten kommen könnte.
lks
Zitat von @Anubis8173:
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Auf die Idee, eine Kopie des eigentlichen nicht leeren Hidden Volume nach dem mounten mit einer Datenrettungssoftware anzugehen, ist keiner in seinem Beitrag eingegangen. Dem entnehme ich, dass das wohl wenig Sinn hat.
Solltest Du die Hidden Partition nach Studium der Dokumentation tatsächlich zu fassen bekommen, dann macht es natürlich Sinn, diese zu sichern. – Es verringert die Komplexität der Situation.
Gemäß meinem Verständnis (durchaus lückenhaft!) ist es wohl so, dass die Hidden Partition am Ende der äußeren Partition stehen müsste. Das blöde ist nur, dass "am Ende" nicht wirklich physisch, sondern durchaus nur "logisch" gemeint sein dürfte und dies nicht deckungsgleich ist. Wer weiß denn schon, ob die äußere und innere Parition nicht über einem Interleave-Faktor miteinander verwoben sind, um z.B. die Präsenz einer Hidden Parition auch vor Veränderungs-Analysen zu verschleiern. – Da wird wohl nur ein Blick in den QuellCode weiter helfen.
Aber das ist alles Theorie und Spekulation. — Praktisch gesehen hast Du (hoffentlich!!!) eine Sicherung des aktuellen Zustands und damit auch der Hidden Partition.
Außer es wäre wirklich trivial und sicher zu bewerkstelligen: Den Aufwand zu betreiben (und die damit möglichen Fehler zu riskieren), die Hidden Partition zu extrahieren, macht frühestens dann Sinn, wenn der erste Teil (Header/symetrische Schlüssel durchtauschen) nicht zum Erfolg geführt hat – Deine Test-Matrix sollte natürlich auch das Zusammenspiel äußere und hidden Partition berücksichtigen.
P.S.: Dass Du eine nette Backup-Software findest, die Dir geflissentlich die "Hidden Partition" sichert, das ist eher illusorisch.
Aber das ist alles Theorie und Spekulation. — Praktisch gesehen hast Du (hoffentlich!!!) eine Sicherung des aktuellen Zustands und damit auch der Hidden Partition.
So wie es praktisch aussieht, nein.
P.S.: Dass Du eine nette Backup-Software findest, die Dir geflissentlich die "Hidden Partition" sichert, das ist eher illusorisch.
Wiederrum auch hier: Kein passendes Gesamtkonzept, welches sehr böse und richtig teuer sein kann.
Weswegen wohl nur noch ein Datenretter hilft. Kostet dann aber etwas.
Wie ich schon oben sagte. Diese Art Software ist eigentlich dafür gedacht, daß auch der "Datenretter" möglichst keine "Daten retten kann.
lks
Zitat von @Lochkartenstanzer:
Wie ich schon oben sagte. Diese Art Software ist eigentlich dafür gedacht, daß auch der "Datenretter" möglichst keine "Daten retten kann.
lks
Wie ich schon oben sagte. Diese Art Software ist eigentlich dafür gedacht, daß auch der "Datenretter" möglichst keine "Daten retten kann.
lks
Bin ich ganz bei dir. Aber das trifft dann für Ihn noch umso mehr zu...Hatte da auch mal so einen Spezialisten. Irgendwann war Ihm die Anonymität seiner Daten auf seiner HW dann doch nicht mehr so wichtig.
Zitat von @certifiedit.net:
So wie es praktisch aussieht, nein.
Wiederrum auch hier: Kein passendes Gesamtkonzept, welches sehr böse und richtig teuer sein kann.
Weswegen wohl nur noch ein Datenretter hilft. Kostet dann aber etwas.
Aber das ist alles Theorie und Spekulation. — Praktisch gesehen hast Du (hoffentlich!!!) eine Sicherung des aktuellen Zustands und damit auch der Hidden Partition.
So wie es praktisch aussieht, nein.
P.S.: Dass Du eine nette Backup-Software findest, die Dir geflissentlich die "Hidden Partition" sichert, das ist eher illusorisch.
Wiederrum auch hier: Kein passendes Gesamtkonzept, welches sehr böse und richtig teuer sein kann.
Weswegen wohl nur noch ein Datenretter hilft. Kostet dann aber etwas.
Naja, da hier selbstgestrickt und ohne Backup gearbeitet wurde ist klar, Alex (Anubis8173) hat hier seine privaten Daten eingedost. Die meisten Privaten werden zur Wiederbeschaffung kein Geld in die Hand nehmen, zumindest nicht in der Größenordnung professioneller Datenretter. – Also ist es nicht hilfreich, darauf rumzureiten: "Lass es sein, gibt's den Profis."
Andererseits ist Alex an der Krypto-Technik interessiert. So ist das ein interessantes Projekt mit dickem Ansporn, denn die eigenen Daten gilt es zu retten. – Also was ist nun sinnvoller: Lieber die Playstation einschalten und einen frustriert virtuell verdreschen und lernen, dass man besser konsumiert als aktiv wird? Oder doch selbst Hand an die Rettung des Verlorenen legen? – Verloren hat er schon. Gewinnen kann er nur durch Zweiteres.
Eine Chance besteht allemal. Das Problem ist nicht, dass die Kryptografie hier quergeschossen ist, sondern die Software die Aufträge vermischt hat. – Also Datenverwaltung statt Verschlüsselung. – Kritisch ist nur, ob durch die Gleichzeitigkeit die Konsistenz der Daten zerstört wurde.
Naja, das Problem ist:
a) weisst du ob es nur private Daten sind?
b) wie wiederherstellbar sind die Ohne das? Ich hab für private Daten (Stammbaum) auch schon Gelder fließen lassen, die andere nicht in Ihre berufliche Bildung investieren.
c) Was. wenn er dadurch (noch) mehr kaputt macht? Das steht ja noch komplett offen
Grundsätzlich bin ich bei dir. Aber es kommt darauf an und es ist kein drauf herumreiten. oder sagst du das auch zu jemandem, der ohne ordentliches Auto-Schuhwerk fährt? - Nerv mich nicht mit den zu reparierenden Bremsen? ;)
a) weisst du ob es nur private Daten sind?
b) wie wiederherstellbar sind die Ohne das? Ich hab für private Daten (Stammbaum) auch schon Gelder fließen lassen, die andere nicht in Ihre berufliche Bildung investieren.
c) Was. wenn er dadurch (noch) mehr kaputt macht? Das steht ja noch komplett offen
Grundsätzlich bin ich bei dir. Aber es kommt darauf an und es ist kein drauf herumreiten. oder sagst du das auch zu jemandem, der ohne ordentliches Auto-Schuhwerk fährt? - Nerv mich nicht mit den zu reparierenden Bremsen? ;)
Zitat von @certifiedit.net:
Naja, das Problem ist:
a) weisst du ob es nur private Daten sind?
b) wie wiederherstellbar sind die Ohne das? Ich hab für private Daten (Stammbaum) auch schon Gelder fließen lassen, die andere nicht in Ihre berufliche Bildung investieren.
Naja, das Problem ist:
a) weisst du ob es nur private Daten sind?
b) wie wiederherstellbar sind die Ohne das? Ich hab für private Daten (Stammbaum) auch schon Gelder fließen lassen, die andere nicht in Ihre berufliche Bildung investieren.
Naja, das kann Alex ja selbst entscheiden, wie wichtig das ist. Ich denke, hier im Forum sollten einfach die Optionen aufgezeigt werden. Wie es wirklich bei ihm aussieht können wir nicht wissen.
c) Was. wenn er dadurch (noch) mehr kaputt macht? Das steht ja noch komplett offen
Datensicherung des aktuellen (defekten) Standes? – Dann geht nicht mehr kaputt als schon ist.
Grundsätzlich bin ich bei dir. Aber es kommt darauf an und es ist kein drauf herumreiten. oder sagst du das auch zu jemandem, der ohne ordentliches Auto-Schuhwerk fährt? - Nerv mich nicht mit den zu reparierenden Bremsen? ;)
Hmm, ich mache auch als Vergleiche, die hinken. Fahren in gefährdender Form gefährdet auch andere. Eigene Daten schrotten ist meine eigene Sache. – Wie oben schon geschrieben: Die Optionen können wir zeigen, die Auswahl trifft Alex für sich, ggf. in Absprache mit dem betroffenen Dritten. Irgendwo muss man letztlich selbst die Verantwortung übernehmen.
Naja, das kann Alex ja selbst entscheiden, wie wichtig das ist. Ich denke, hier im Forum sollten einfach die Optionen aufgezeigt werden. Wie es wirklich bei ihm aussieht können wir nicht wissen.
Wie gesagt, wenn Sie wichtig sind...
Datensicherung des aktuellen (defekten) Standes? – Dann geht nicht mehr kaputt als schon ist.
Wird bei Containern ggf. aber nicht gehen. Mehr Einblick haben wir nicht.
Hmm, ich mache auch als Vergleiche, die hinken. Fahren in gefährdender Form gefährdet auch andere. Eigene Daten schrotten ist meine eigene Sache. – Wie oben schon geschrieben: Die Optionen können wir zeigen, die Auswahl trifft Alex für sich, ggf. in Absprache mit dem betroffenen Dritten. Irgendwo muss man letztlich selbst die Verantwortung übernehmen. face-wink
face-winkKennst du die Daten? Ich nicht. Daher ist es potenziell auch ein Datum, dass für andere wichtig sein kann. Bspw Steuerdaten, Abrechnungen o.ä. Hatte auch schon Kunden, die meinten Ihre Platten von den Servern verschlüsseln zu müssen. Plan B gab es zu dem Zeitpunkt noch nicht - wäre Ihm dann später auch ziemlich hart auf die Füße gefallen, hätte es das nicht gegeben.
Ein Hallo, doch nochmal vor Jahreswechsel. Ich finde es Klasse, dass sich so viele mit meinem Problem auseinandersetzen und die Problematik etwas fachlicher durchleuchten, als ich das kann! So viel Resonanz habe ich in anderen Foren bisher noch nicht erlebt.
Also, der Verlust der Daten ist nicht so dramatisch als dass ich für einen professionellen Datenretter Geld ausgeben würde, zumal ja auch am Ende eines solchen Lösungsweges der Erfolg gar nicht gesichert ist.
Das Truecrypt eine Verschlüsselungssoftware ist, die Daten derart verschlüsselt, dass sie wenn sie verloren gehen nicht mehr gerettet werden können, ist ja Sinn der Software. Ist mir schon klar. Ich habe aber "RTFM" nicht im Detail und bis zur letzten Seite praktiziert und kenne daher viele Optionen von True- und Veracrypt nicht genau. Deswegen bemühe ich ja Euren Expertenkreis und stelle auch doofe Fragen, wie z.B. diese, ob Veracrypt den Schlüssel des zuletzt angeschlossenen Containers auch nach abstöpseln doch irgendwo abgespeichert hat und man diesen - vorausgesetzt man hat das Passwort dafür - statt aus der Kopie der beschädigten Platte viel leichter aus einem Temp-Ordner (oder was auch immer) von Veracrypt extrahieren kann. Ich hätte mir doch in meinen Allerwertesten gebissen, wenn ich 10 Jahre die defekte Platte kaputtrepariert hätte und am Ende sagt mir dann einer, "na wenn Du bei Verycrypt unter Erweiterte Optionen geschaut hättest, dann..."
Da es sich nur um eine halbvolle 500er Platte handelt und nicht um eine volle 2TB ist das ganze zwar ärgerlich aber nicht sooo dramatisch. Ich werde mir jetzt erstmal aneignen, wie man eine Kopie von einem Truecrypt-Datenträger erstellt. Das muss ich sowieso, weil ich nämlich noch einen anderen verschlüsselten Datenträger habe, der - nachdem ich Daten draufgeschoben hab - jetzt von Windows nicht mal mehr initialisiert werden kann (mich schockt schon gar nichts mehr). Auch bei diesem Problem wird empfohlen, erst einmal eine Kopie der Platte zu erstellen.
Ich habe mich nicht drum gerissen, durch Truecrypt, Windows oder - von mir aus - auch durch meine Unkenntnis und Dummheit verhunzte Datenträger mit Aussicht auf wenig Erfolg zu reparieren. Aber wenn mir Fachleute in einem Forum ausnahmslos bestätigen, dass die Datenrettung alles andere als einfach ist, dann repariere ich eben auf kompliziertem Wege. Dank Corona habe ich dafür gerade sehr viel Zeit und das dabei erlangte Wissen ist am Ende nicht ganz nutzlos ;-(
So - ich verabschiede mich in die Nacht und Grüße nochmal...
Also, der Verlust der Daten ist nicht so dramatisch als dass ich für einen professionellen Datenretter Geld ausgeben würde, zumal ja auch am Ende eines solchen Lösungsweges der Erfolg gar nicht gesichert ist.
Das Truecrypt eine Verschlüsselungssoftware ist, die Daten derart verschlüsselt, dass sie wenn sie verloren gehen nicht mehr gerettet werden können, ist ja Sinn der Software. Ist mir schon klar. Ich habe aber "RTFM" nicht im Detail und bis zur letzten Seite praktiziert und kenne daher viele Optionen von True- und Veracrypt nicht genau. Deswegen bemühe ich ja Euren Expertenkreis und stelle auch doofe Fragen, wie z.B. diese, ob Veracrypt den Schlüssel des zuletzt angeschlossenen Containers auch nach abstöpseln doch irgendwo abgespeichert hat und man diesen - vorausgesetzt man hat das Passwort dafür - statt aus der Kopie der beschädigten Platte viel leichter aus einem Temp-Ordner (oder was auch immer) von Veracrypt extrahieren kann. Ich hätte mir doch in meinen Allerwertesten gebissen, wenn ich 10 Jahre die defekte Platte kaputtrepariert hätte und am Ende sagt mir dann einer, "na wenn Du bei Verycrypt unter Erweiterte Optionen geschaut hättest, dann..."
Da es sich nur um eine halbvolle 500er Platte handelt und nicht um eine volle 2TB ist das ganze zwar ärgerlich aber nicht sooo dramatisch. Ich werde mir jetzt erstmal aneignen, wie man eine Kopie von einem Truecrypt-Datenträger erstellt. Das muss ich sowieso, weil ich nämlich noch einen anderen verschlüsselten Datenträger habe, der - nachdem ich Daten draufgeschoben hab - jetzt von Windows nicht mal mehr initialisiert werden kann (mich schockt schon gar nichts mehr). Auch bei diesem Problem wird empfohlen, erst einmal eine Kopie der Platte zu erstellen.
Ich habe mich nicht drum gerissen, durch Truecrypt, Windows oder - von mir aus - auch durch meine Unkenntnis und Dummheit verhunzte Datenträger mit Aussicht auf wenig Erfolg zu reparieren. Aber wenn mir Fachleute in einem Forum ausnahmslos bestätigen, dass die Datenrettung alles andere als einfach ist, dann repariere ich eben auf kompliziertem Wege. Dank Corona habe ich dafür gerade sehr viel Zeit und das dabei erlangte Wissen ist am Ende nicht ganz nutzlos ;-(
So - ich verabschiede mich in die Nacht und Grüße nochmal...
