Datenrettung Speziell für SSDs?

[P220]

Hi,

Mir ist jetzt schon öfters passiert, dass ich vergessen habe bestimmte Dateien mit zu sichern (also eben ein Backup zu machen) und die dann anschließend weg waren. Soweit mir bekannt bedeutet das bei modernen Festplatten und SSD: Weg ist weg, wenn überschrieben. Nun haben wir 2020, vielleicht hat sich da noch was getan in Sachen Datenrettung speziell für SSDs?

Könnt ihr ein Programm empfehlen dass dafür am besten geeignet wäre noch irgendwelche Reste zu finden oder ist da "vorbei"? Gerne auch im Professionellen Bereich, nur eben keine Tausend Euro Spezial-Rettungsaktion.

Danke vorab.
Gruß

 

[BFF]

Bei SSD meist noch schneller wech.
Spaetestens wenn TRIM gelaufen ist, und das macht das OS automatisch, ist Schicht im Schacht.

-> https://www.caine-live.net/

Das nehme ich.
Natuerlich auch TestDisk/Photorec. Fuer Scheiben und bockige HDD manchmal den UnstoppableCopier oder das gaengige DDrescue.

BFF

 

[rocketworm]

Bei HDD's wird beim löschen einer Datei nur der Vermerk gelöscht wo die Datei gelegen hat. Die Datei ist Prinzipiell solange noch da und wiederherstellbar bis der Bereich oder ein teil davon mit neuen Daten überschrieben wurde.

Bei SSD's ist das anders. Auch hier werden erstmal nur die Positionen gelöscht wo die Daten gelegen haben. Aber SSD's verlieren an Geschwindigkeit durch die gelöschten Dateien. Daher führen SSD's Regelmäßig Trim und Garbage Collection durch. Dabei werden die Bereiche wo die gelöschten Dateien liegen vollständig wieder gelöscht/freigegeben. Mit Wiederherstellungs Software hat man also nur Chancen wenn man schnell dabei geht.

 

[Sephe]

Das ist vorbei.
Bei der Festplatten wurden Daten in der korrekten Reihenfolge, passend zur Partitionstabelle geschrieben.

Beispiel:
500 GB Partition 1
100 GB Partition 2

Somit weiß man, wo die Daten auf der Platte liegen.

Bei SSDs wird zur Erweiterung der Lebenszeit auf Wear-Levelling gesetzt. D.h. wenn du Daten öfters liest und schreibst, wird nicht mehr gleiche Sektor neu geschrieben, sondern ein anderer irgendwo im Flash benutzt, damit im Idealfall alle gleichmäßig "abnutzen".
(Somit können Dateien, die das Betriebssystem logisch in Partition 1 ablegt, nun physisch im Bereich der Partition 2 liegen. )

Viele SSDs arbeiten mittlerweile zudem mit - für das Betriebssystem - transparente Verschlüsselung.
Dabei werden die Daten zwischen SSD-Controller und SATA-Controller im Klartext übertragen, aber vom SSD-Controller ver/entschlüsselt. (Dabei gibt es einen Key im Controller)
Um SSDs sicher zu löschen einfach dieser Key überschrieben, damit sind die Daten auf dem Flash nicht wiederherstellbar. (secure erase)

Somit: Backups, Backups, Backups....

 

[rocketworm]

Somit: Backups, Backups, Backups....

👍

 

[TorenAltair]

Gerade bei modernen SSDs sind Datenrettungsfirmen oft chancenlos, weil diese SSDs eine eingebaute Hardwareverschlüsselung haben.

 

[c0m4]

Ich empfehle Recovery-Spray von Flash-Wonder - speziell die Version von 2020...einfach großzügig auftragen. :-D

Im Ernst - bei plötzlichen Hardware-Defekten hat der Pro vielleicht noch eine Chance - aber Nachlässigkeit in Sachen Backups wird bei SSDs aufs schärfste bestraft. Da hilft keine Software.

 

[fritz3]

Im Ernst - bei plötzlichen Hardware-Defekten hat der Pro vielleicht noch eine Chance - aber Nachlässigkeit in Sachen Backups wird bei SSDs aufs schärfste bestraft. Da hilft keine Software.

Wohl wahr, aber manchmal ist man noch nicht dazu gekommen ein Backup zu machen. Selber mache ich es nur alle 6 Monate.

gruss.fritz

 

[P220]

Oh je. Okay, dann kommt demnächst immer der ganze AppData mit. Just in Case.

(Somit können Dateien, die das Betriebssystem logisch in Partition 1 ablegt, nun physisch im Bereich der Partition 2 liegen. )

Auch bei primären Partitionen?

 

[Sephe]

Ja. Dem SSD-Controller sind Partitionen vollkommen egal und kennt sie nicht mal. Dort sind nur die Sektoren wichtig.

 

[P220]

Ohha. Das muss man erstmal wissen. 😶 Danke!

 

[Holt]

(Somit können Dateien, die das Betriebssystem logisch in Partition 1 ablegt, nun physisch im Bereich der Partition 2 liegen. )

Das stimmt doch gar nicht, die Partitionen beschreiben bestimmte Bereich von LBAs und dienen zur logische Unterteilung des Adressraums der SSD. Intern stehen die Daten alle irgendwo im NAND, gewissermaßen durcheinander und nicht wie bei HDDs schön geordnet, aber was unter einem LBA geschrieben wurde der zur Partition 1 gehört, kann auch nur unter genau diesem LBA wieder ausgelesen werden, aber nie unter einem LBA der zur Partition 2 gehört.

 

[Sephe]

Doch eben schon bei SSDs weil hier das wear levelling zusammen mit Trim greift. Das ganze erscheint auf der logischen Seite (Betriebssystem) zwar transparent und geschieht zwischen SSD-Controller und Flash, Fakt ist aber, das man den Flash nicht auf eine andere Controller Platine löten kann, und einfach wieder an seine Daten kommt. (wie es z.B. bei plattertausch bei Festplatten funktionieren kann. )

Ändert auch nichts daran, das Backups bei SSDs deutlich wichtiger sind als bei Festplatten.

 

[P220]

Fakt ist aber, das man den Flash nicht auf eine andere Controller Platine löten kann

Da habe ich auch mal überlegt. Könnte man nicht theoreitsch an der Platine herum doktoren und die Leiter zu einem anderen Controller verbinden? Mit einen präparierten Gerät und entsprechender Software wäre auch auf diesem Weg ein Secure Erase nicht mehr - Secure. Einzig ein vollständiges überschreiben.

 

[Holt]

Mit einen präparierten Gerät und entsprechender Software wäre auch auf diesem Weg ein Secure Erase nicht mehr - Secure. Einzig ein vollständiges überschreiben

Was soll man denn Auslesen können, nachdem ein NAND Block gelöscht wurde? Da ist nichts mehr auszulesen. Auch beim Überschreiben werden die alten Daten früher oder später gelöscht, denn erstens werden sie dadurch ungültig, also sehr wahrscheinlich bei der nächsten Idle-GC abgeräumt und zweitens braucht der Controller beim vollständigen Überschrieben, außer er hat eine Datenkompression und es wird mit extrem komprimierbaren Daten überschrieben, den Platz für die nächsten Daten und muss sehr bald anfangen schon während des Überschreibens die Blöcke mit den vorher durch Überschreiben ungültig gewordenen Daten, sowieso löschen. Am Ende bleiben dann nur Fragmente von der Größe der Free Area der SSD, die dann bei der nächsten Idle-GC gelöscht werden. Aber schon vorher kann man sie nicht mehr normal auslesen, weil die LBAs in de Mappingtabelle ja alle auf die Adressen mit den neuen Daten zeigen und kein LBA mehr mit den alten Daten verknüpft ist.

Diese Aufhebung der Verknüpfung in der Mappingtabelle und die Markierung der Daten als ungültig, erfolgt auch bei TRIM, das wirklich Löschen der NAND Blöcke in denen die Daten stehen, passiert dann erst später bei der nächsten Idle-GC. Wo die Daten jeweils intern in NAND stehen, spielt dabei überhaupt keine Rolle, außer das es eben die Rettung von Daten durch Auslesen von der abgelöteten NANDs deutlich erschwert, weil man die eben erst noch zusammensetzen muss, da sie wegen der Performance über die NAND Dies verteilt geschrieben werden.

 

[P220]

Das meinte ich ja, einzig ein vollständigen überschreiben bleibt sicher (dass die Daten weg) sind. Wenn die Platte komplett voll mit neuen Daten ist, bleibt physikalisch kein Platz mehr für die alten. - Im Gegensatz zum vermeintlichen "ATA Secure Erase" (sicherem Löschen), wo man nach meiner Überlegung, eventuell immer noch dran käme, mit hohen Aufwand und sofortigen Zugriff.

 

[Holt]

Ein Secure Erase sollte genauso sicher sein, wenn es in der FW korrekt implementiert ist und die NAND Blöcke wirklich gelöscht werden. Wenn der Controller die Daten auf den NANDs verschlüsselt, dann gibt es auch die Option das er einfach den Schlüssel wechselt. Wenn dann wegen eines FW Bugs der alte Schlüssel doch auslesbar ist oder wenn doch nicht alle NAND Blöcke gelöscht wurden, ist das Secure Erase doch nicht sicher. Es hängt also davon ab, wie gut dies in der FW implementiert ist und dies weiß man im Zweifel nie. Außerdem muss für ein Secure Erase ein Passwort verwendet werden, i.d.R. wird von den Tools ein User Passwort gesetzt und dies wird beim Secure Erase wieder entfernt, aber wenn etwas schief geht und man dieses Passwort und auch das Master Passwort nicht kennt, hat man einen Briefbeschwerer. Außerdem ist das Secure Erase ein Teil der ATA Security Feature und diese werden bei Aktivierung von OPAL2 deaktiviert, dann muss man statt des Secure Erase einen PSID Reset ausführen und auch NVMe hat ein eigenen Secure Erase Befehl, nicht jedes Tool kann damit umgehen. Auch hier hängt die Sicherheit von der korrekten Implementierung in der FW ab.

Deshalb finde ich das vollständige Überschreiben die einfachere und sicherer Möglichkeit, es funktioniert auch über USB und Überschreiben ist eine alltägliche Funktion die in jeder SSD FW korrekt implementiert sein muss, damit man sie überhaupt gebrauchen kann. Klar dauert es länger und kostet einen P/E Zyklus, aber wer es nicht täglich machen muss, dürfte so viel Zeit haben und wer schafft es schon die NANDs seiner SSD kaputtzuschreiben?

Aber eigentlich geht es ja hier um Datenrettung und da ist es bei SSD wegen TRIM schwerer versehentlich gelöschte Dateien wiederherzustellen, denn TRIM bewirkt meist innerhalb von Sekunden, dass die getrimmten LBAs nicht mehr mit den Daten verknüpft sind. Mit dem Tool TrimCheck kann man prüfen ob TRIM funktioniert und schauen wie schnell dies passiert, denn man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Sind die LBAs noch mit den Daten verknüpft, so wird beim nächsten mal erneut geprüft, bis andere Daten bzw. meist 00 ausgelesen wird.

 

[P220]

So sehe ich es auch. Ich überschreibe lieber komplett als irgendwelche "Tricks" anzuwenden. Notfalls baut man das Teil aus, schließt es extern an, 3 Minuten Arbeit, Rest geht zeitgleich. Aber bei meiner "Produktiv"-SSD scheint TRIM wohl nicht länger als 5 Sekunden zu brauchen.

Weißt du zufällig wie es mit der Firmware älterer (sehr alter) Crucial Modelle steht? Ich habe da eine Vermutung eines anderen Problems. Eine von Bekannten ist kaputt. Mein Verdacht, da wurde gemurkst.

 

[Holt]

Welche alte Crucial? Die m4 hatte in den ersten FW Versionen (0002 und 0009) den 5184 Stunden Bug, die FW sollte mindestens die 0309 oder höher sein, wobei das hintere Byte (also 09) das wichtigere bei der Versionsnummer ist. Außerdem ziehen sich Probleme mit LPM wie ein roter Faden durch die Changelogs der FW Update der meisten Crucial SSDs.

 

[Sephe]

Da habe ich auch mal überlegt. Könnte man nicht theoreitsch an der Platine herum doktoren und die Leiter zu einem anderen Controller verbinden? Mit einen präparierten Gerät und entsprechender Software wäre auch auf diesem Weg ein Secure Erase nicht mehr - Secure. Einzig ein vollständiges überschreiben.

Geht nicht. Der Key für die Verschlüsselung wird nicht im Flash gespeichert. Wenn du also den flash an einen Fremden Controller hängst, kommt dabei nur Datensalat raus, falls der Controller sich nicht komplett weigert weil er den Schlüssel nicht hat