Samsung T7 SSD lässt sich nicht entschlüsseln

[James Atlick]

Und? Platte gelöscht und mit magician ausgelesen?

 

[chuck01]

Wollte ein kurzes Update geben:

Hab die Platte natürlich nicht gelöscht, da ich sie sowieso nicht für andere Zwecke benötige und die Daten ja grundsätzlich da waren. Hatte gehofft, dass es mit einem Update irgendwann wieder klappen würde. Habs so zweimonatlich probiert, aber weder Magician noch FileVault konnten drauf zugreifen.
Bin heute zufällig auf den "UFSExplorer" gestoßen, Probeversion runtergeladen (Dateien bis 768 kb lädt er in der freien Version auch herunter) und siehe da, hat nach dem Passwort für die Entschlüsselung gefragt, habs eingegeben und alle Fotos und Dateien, die kleiner waren als die maximale Größe für die Testversion, innerhalb kürzester Zeit runtergeladen. Hab die knapp 70 EUR für die Vollversion (also Standard) bezahlt und nun lädt er alle Videos, Fotos und sonstigen Dokumenten bislang (bin bei so ca. 30%) ohne Probleme runter.

Muss dazusagen, dass ich vorab dieses Video entdeckt hab:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

und nach Befolgen aller Schritte wurde die Platte zumindest von Magician zum ersten Mal erkannt, dennoch hatte ich keinen Zugriff auf die Dateien. Zumindest konnte ich aber eine neue Firmware downloaden, vielleicht lags schlussendlich ja auch daran

Also falls sich hier mal wer herverirrt und vor dem Problem steht: siehe oben.

 

[James Atlick]

Verstehe ich nicht ganz.

Du hast also mit endlich mal den vorgeschlagenen Schritt von uns gemacht um die Festplatte zu erkennen?
Aber statt dafür Samsung SSD magician zu verwenden, hast du Samsung Portable SSD verwendet wie im Video?
Und als dass dann geklappt hat, hast du die Daten mit UFSExplorer "undeleted".

Hoffe du nutzt die Platte aber nicht weiter, ich würde der ja nicht mehr trauen.
Irgendwie haben wir ja nicht geklärt, wie es so weit kommen konnte? Oder habe ich das verpasst?

 

[chuck01]

Magician hat die Platte erkannt, ich konnte sie aber trotzdem nicht entschlüsseln. Was wäre denn dein nächster Vorschlag gewesen wenn MacOS die Platte nicht aktivieren/entschlüsseln kann?

 

[James Atlick]

Zuerst mal eine Kopie mit dd oder clonezilla erstellen.
Das ist immer der erste Schritt bei data recovery.

Danach hätte ich vermutlich wie du eine Software ähnlich UFSExplorer verwendet. Testdisk (welches ich sonst gerne verwende) unterstützt kein AFPS.

Musstest du bei UFSExplorer ein Passwort eingeben?
Weil wenn nicht, war die Platte nie verschlüsselt.

Hoffe du nutzt die Platte aber nicht weiter, ich würde der ja nicht mehr trauen.
Irgendwie haben wir ja nicht geklärt, wie es so weit kommen konnte? Oder habe ich das verpasst?

 

[chuck01]

ja, musste bei UFSExplorer das Passwort eingeben. Das war ja laut dem Support der anderen Software das Problem - darum hab ich sie auch nie formatiert. Die Dateien waren ja grundsätzlich da, nur konnte sie nicht entschlüsselt werden - habs ja mit 2 anderen Programmen probiert.

Was meinst du? Die SSD ist mir nie runtergefallen, hat kein Wasser abbekommen oder sonstiges. Eines Tages ließ sie sich einfach nicht mehr entschlüsseln. Gab keinen Vorfall.

 

[James Atlick]

ja, musste bei UFSExplorer das Passwort eingeben.

Dann war sie also tatsächlich verschlüsselt. Spannend.

Was meinst du? Die SSD ist mir nie runtergefallen, hat kein Wasser abbekommen oder sonstiges. Eines Tages ließ sie sich einfach nicht mehr entschlüsseln. Gab keinen Vorfall.

Ja eben. Warum zeigt dir macOS die Platte plötzlich als unverschlüsselt an?
Ist da etwas bei der UUID schief gelaufen? Und wenn ja, vielleicht weil die Platte einen defekten Sektor hat?
Auch Flash ist nicht perfekt. Mit runterfallen oder Wasser hat dies nix zu tun.

Würde ich persönlich mal mit Linux und badblocks testen. Oder halt nicht weiter für wichtige Daten verwenden.

 

[dadudeness]

Würde ich persönlich mal mit Linux und badblocks testen

Das bringt nix. SSDs schreiben nicht der Reihe nach wie auf einer HDD, sondern wild durcheinander. Außerdem haben SSD mit einer ausgewiesenen Größe meist weiteren Speicher, der über die ausgewiesene Größe hinaus, um Defekte ausgleichen zu können. Der Bereich wird für gleichmäßige Abnutzung mit benutzt. Daher funktioniert auch ein Löschen durch Überschreiben bei SSDs nicht.
An derlei Infos kommst bei SSDs praktisch nur noch mit SMART oder Hersteller-Diagnose ran.

Hier sieht alles nach Firmware-Theater aus. Ein Kabel kann man vorab tauschen, aber es ist nicht so, dass es jetzt irgendein fancy 3.1gen2 Kabel sein muss. Auch "Lade"-Kabel haben fast immer verbundene USB2 Datenleitungen, so dass das Gerät funktionieren muss — nur eben langsamer.

 

[James Atlick]

Klar, das kann keine vergangenen schlechten Blöcke erkennen, wenn der Kontroller diese bereits behoben/verschoben hat.
Dennoch bring es natürlich was.
Das testet jeden einzelnen Block. Wenn du am Ende schlechte Blocks entdeckst weisst du, da stimmt was nicht. Ganz egal ob dies nun durch einen neuen schlechten Block, ein Hardware Fehler oder ein Kabelfehler entstanden ist.
Könntest auch die gesamt Platte mit 1 beschreiben, auf write errors achten und am Ende versuchen alle einsen wieder auszulesen. Badblocks ist halt komfortabler

 

[Wuchtbrumme]

Könntest auch die gesamt Platte mit 1 beschreiben, auf write errors achten und am Ende versuchen alle einsen wieder auszulesen.

Du hast den zutreffenden Einwand des Vorposters und das technische Prinzip nicht verstanden: in SSDs ist der Controller dafür zuständig, die Daten zu speichern. Die tatsächliche Speicherzelle vs. gemeldetes LBA für den Enduser (und badblocks) ist abstrahiert, nur gemappt. Anders ausgedrückt, was Du der SSD sagst, wohin gespeichert werden soll und wo die SSD tatsächlich hinspeichert, ist vom Controller gesteuert, also nicht von Dir.

Dein Beispiel z.B. könnte ein SSD-Speicherkontroller mit

dd if=</dev/"1"> of=/dev/ssd bs=4TB count=1
4TB written in 0.01ms

beantworten, weil bei dem Prozess auch Optmierungen wie z.B. Kompression, Erkennung wiederkehrender Zeichenfolgen (wie 0), ... stattfinden könnte. (Niemand wird das Schreiben von 4TB in weniger als einer Sekunde erwarten, also ist vermutlich nur eine Zelle geschrieben worden und der Inhalt könnte auf alle LBA gemappt worden sein). Also alles eine Frage, was der Speicherkontroller macht, was du aber nicht siehst. Wenn überhaupt, dann eine nicht optimierbare Zeichenfolge wie /dev/random benutzen. Das ist aber weder schnell, noch effizient und eher eine Bestrafung für die Hardware (Schreiben ist schlecht für Flash).

SSDs haben einen definierten Weg, die Speicherzellen zurückzusetzen und das ist ein Secure_Erase (bei SATA) oder ein nvme_format (durch das Löschen der Mappingtable und das Instruieren des Controllers, alle Speicherzellen als leer/neu anzusehen). Es gibt dazu auch verschiedene Modi: ganz oft wird nur die Table gelöscht und der Schlüssel zur ohnehin stattfindenden internen Verschlüsselung verworfen, man kann aber auch etwas initiieren, was am ehesten einem vielleicht noch bekannten "Low Level Format" gleicht, was Du wahrscheinlich meinst (nvme sanitize).

Erschwerend: in dem Fall hier wird SATA oder NVMe gar nicht wirklich vom Host genutzt, sondern steckt ein USB dazwischen. Das tunnelt diese Kommandos gar nicht notwendigerweise, wenn nicht die Herstellersoftware diese Option anbietet.

 

[James Atlick]

Du hast den zutreffenden Einwand des Vorposters und das technische Prinzip nicht verstanden

Doch, genau darum mein Ausführungen.

Dein Beispiel z.B. könnte ein SSD-Speicherkontroller mit beantworten,

Machs mal
Spoiler: wird er nicht.
Aber ja, kannst auch random nehmen.

Das ist aber weder schnell, noch effizient und eher eine Bestrafung für die Hardware (Schreiben ist schlecht für Flash).

Völlig egal. Es gibt eine TBW. Die TBW ist ein vielfaches von der Kapazität der SSD. Einmal 100% beschreiben ist darum nicht relevant.

Sollte etwa so aussehen (ohne Gewähr, nicht getestet)

badblocks -wsv -t random -p 1 /dev/disk4

 

[Marcel Bresink]

Das testet jeden einzelnen Block.

Nein, das tut es nicht. Weder badblocks, noch irgendein anderes Programm, das auf dem steuernden Computer läuft, hat eine Chance, herauszufinden, wie viele Blöcke es in der SSD wirklich gibt, geschweige denn, auf alle zuzugreifen oder deren physische Größe zu ermitteln. Das kann nur die Firmware des SSD-Controllers selbst.

badblocks wurde ursprünglich für Disketten entwickelt und stammt aus einer Zeit, lange bevor es SSDs gab.

 

[James Atlick]

Nein, das tut es nicht.

Doch, mit random tut es das.

 

[Marcel Bresink]

Nein, das beeinflusst nur, welche Bytes zum Testen geschrieben werden.

 

[AndaleR]

<OT>Sorry

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

 

[James Atlick]

Nein, das beeinflusst nur, welche Bytes zum Testen geschrieben werden.

Ja eben.
Ein Kompression (wie von dir erträumt) kann dann nicht stattfinden.
Der vom Kontroller dir zur Verfügung gestellter Platz wird beschrieben.

Hast du ein USB Problem -> wird erkannt
Hast du ein Kontroller Problem -> wird erkannt
Hast du ein neues NAND Problem -> wird erkannt

Genau das was es tun soll, erkennen ob die Disk noch was taugt, tut es also. Der Rest ist Haarspalterei.

 

[Marcel Bresink]

Ein Kompression (wie von dir erträumt) kann dann nicht stattfinden.

Es findet an dieser Stelle niemals eine Kompression statt. Und Du solltest nicht so arrogant daherkommen, wenn hier jedem klar wird, dass Du keine Ahnung hast, wie eine SSD funktioniert.

Der vom Kontroller dir zur Verfügung gestellter Platz wird beschrieben.

Ja, aber das ist eben nicht der gesamte Speicherplatz der SSD, wie es dir @dadudeness und @Wuchtbrumme bereits erklärt haben.

 

[James Atlick]

Es findet an dieser Stelle niemals eine Kompression statt.

Doch, wenn du zum Beispiel ZFS verwendest

Und Du solltest nicht so arrogant daherkommen

Ich sehe hier nur eine Person, die versucht der anderen Person die Kompetenz abzusprechen.

Ja, aber das ist eben nicht der gesamte Speicherplatz der SSD

Ja, das ist aber irrelevant. Haarespalten eben. Wenn die SSD 901GB hat und dir 900GB anzeigt weil sie 1GB als badblocks reserve hat, ist das für den Test irrelevant.

 

[Marcel Bresink]

Doch, wenn du zum Beispiel ZFS verwendest

Nein, sowohl der badblocks-Befehl als auch der dd-Befehl, über den hier diskutiert wurde, arbeiten blockorientiert auf dem Gerät, so dass das Dateisystem keine Rolle spielt und überschrieben wird.

Wenn die SSD 901GB hat und dir 900GB anzeigt weil sie 1GB als badblocks reserve hat,

Wir sprechen hier nicht über "badblocks-Reserven". So gut wie alle SSDs verwenden Überprovisionierung, die bei jedem Schreibzugriff eine Rolle spielt.

ist das für den Test irrelevant.

Für so einen einfachen Test würde es auch reichen, eine Datei von macOS aus auf die SSD zu schreiben. Da braucht man kein Linux-System mit einem Diagnoseprogramm für Disketten.

 

[James Atlick]

Wir sprechen hier nicht über "badblocks-Reserven". So gut wie alle SSDs verwenden Überprovisionierung, die bei jedem Schreibzugriff eine Rolle spielt.

Was ist für dich der Unterschied? Ernstgemeinte Frage, beides sind keine definierten Wörter der IT. Für mich sind sie das Selbe.

Für so einen einfachen Test würde es auch reichen, eine Datei von macOS aus auf die SSD zu schreiben.

Bekommst du einen write error so mit?