Daten-SSD mit Bitlocker verschlüsselt, wie entschlüsseln?

PC295 schrieb:
Bitlocker legt auch ohne Account los
Hatte ich so noch nie. Auch nicht mit Home-Editionen. 🤷‍♂️

Muss ich mal neu nach stellen der Tage.
Installiere ja nix mit Rufus/Ventoy. Nur noch mit XML.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: nutrix
Die Funktion ist ja auch erst seit der 24H2 aktiv. Davor gab es das nur bei OEM-Vorinstallationen. Und ja, Bitlocker verschlüsselt natürlich immer, nur liegt der Schlüssel halt im Klartext auf dem Datenträger vor, solange keine geeigneten Key-Protectoren konfiguriert sind.
Das ist wie eine abgeschlossene Haustür, wo der Schlüssel unter der Fußmatte liegt.
 
  • Gefällt mir
Reaktionen: OdlG, nutrix und PC295
mchawk777 schrieb:
Selbst wenn du versuchen würdest einfach nur alle Zellen überschreiben zu wollen - wirst Du nie alle erwischen.
(Mal abgesehen davon, dass dies eine blödsinnige Aktion in Bezug auf SSD-Verschleiß darstellt.)


Hmm allerdings wenn ich auf einer z.B. 512 Gbyte grossen SSD eine random Datei erzeuge die auch 512 Gbyte gross ist dann erwischt man doch alle Zellen?

Ansonsten würde die SSD doch geschriebene Daten einfach wegwerfen?
 
  • Gefällt mir
Reaktionen: OdlG
Du meinst die SSD wirft dann einfach Daten weg aus der Datei damit die manche Zellen doppelt berschrieben kann? Over Provisioning ist doch nur für defekte Zellen? ausser man stellt das manuell ein?

Wenn ich auf dien Datenträger der z.B. 100 Bytes Kapazität hat eine Datei mit 100 Bytes schreibe wie soll der denn dann nicht alle Zellen nutzen - ausser dass er dann die Datei beschädigt schreibt? (also abzüglich FS)

Ich schreibe da z.B. die Zahlen 1 bis 100 rein - welche Zahlen fehlen dann wenn ich 100 geschrieben haben, wenn die SSD nicht alle Zellen nutzt? das wäre doch mehr so ein 16 TB SSD aus China für 40 Euro - die machen das glaub so :D
 
Zuletzt bearbeitet:
Der Controller mappt doch nicht intern so um dass er falsch z.B. "alte" Daten zurückliefert also statt der 10 2x die 5 liefert wiel die in einer regemappten Zelle steht oder so.

Die hier als Beispiel 100 Bytes Gesamtkapzität müssen beim Auslesen IMMER die 100 Bytes enthalten die ich vorher reingeschrieben habe - egal was der Controller macht. Und auf mehr als die 100 Bytes Daten kann ich niemals zugreifen von aussen - die einzige Möglichkeit wäre durch Auslöten der Speicherchips und manuelles auslesen indem man den Controller simuliert.

Hehe aber wenn das jemand macht wird der sicher lieber einen Folterknecht anheuern der holt die Daten für einen Bruchteil der Kosten raus. Was kosten 2 Zangen und 1 Feuerzeug? :D

Wie der intern arbeitet ist doch egal - dass ein SSD Controller geschriebene Daten nicht beim Auslesen verfälschen darf ist hier doch entscheidend.
 
Zuletzt bearbeitet:
Eigentlich seid ihr etwas weit weg vom Thema.
 
  • Gefällt mir
Reaktionen: nutrix, mchawk777 und Evil E-Lex
Kleiner Exkurs. Versuche aber den Bogen zu spanne. 😉
Uzer1510 schrieb:
Hmm allerdings wenn ich auf einer z.B. 512 Gbyte grossen SSD eine random Datei erzeuge die auch 512 Gbyte gross ist dann erwischt man doch alle Zellen?
Nur theoretisch. Du erreichst nur die meisten Zellen eines Volumes - aber nicht alle Zellen.
...und selbst die nicht vollständig, da SSDs für die Verschleißregulierung meist noch eine Reihe Ersatzzellen haben.
...und wie gesagt: Es wäre einfach ein unverhältnismäßiger Verschleiß der SSD. Wenn das egal ist und sie im Zweifel sogar "schrotten soll", dann wäre das natürlich kein großes Ding.

Deshalb: Mit Volumen-Verschlüsselung - egal, ob jetzt BitLocker oder Veracrypt - umgeht man das Ganze sehr elegant. (Wobei Veracrypt deutlich gnadenloser ist, wenn es da Probleme gibt. Für BitLocker gibt es Datenrettungssoftware, wenn der Notfallschlüssel bekannt ist!)

Die Frage im Kontext des Threads ist hier eher: Wie die BitLocker-Verschlüsselung zustande kam.
Denn automatisiert im Hintergrund und ganz ohne Hinweisfenster kenne ich es halt nicht.
 
  • Gefällt mir
Reaktionen: OdlG
Abgesehen von Auslöten oder eine eigene SSD Controller Firmware entwickeln auf Basis der aktuellen etc nicht nur theoretisch denn ich erreiche ALLE Zellen die nach aussen ansprechbar sind - das ist ja dass Black Box Prinzip der Sparezellen.

Wie gesagt auch Ausweichzellen können nichts anders zurückliefen als das was ich in die Originalzelle reingeschieben habe sonst würde die SSD die Daten korrumpieren ode rmeioonst du einen Ausweichzelle in der z.b. "20" aus alten Daten steht die rsetzet halt dann ein Zelle in die "12" reingeschieben wurde - damit muss der Nutzer dann halt leben :D

Man kommt nur dann an alte Daten aus Ausgleichszellen von aussen, wenn die die neuen korrumpieren würden.

So gross ist der Verschliess nun auch nicht wenn ich eine SSD komplett vollschriebe mit einer Datei wird jede Zelle nur 1x angesprochen - denn es werden - hoffentlich :D , sonst taugt die SSD ja eh nichts und ist Schrott - nicht bereits geschriebenen Daten mehrfach überschrieben - DIe Schreibwerte gelten doch pro Zelle und sind damit relativ unkritisch.


-------------------

Doch das hatte ich auch schon wenn glaub alle Vorausstzungen gegeben sind verschlüsseln manche Win 11 (Prof?) Versionen ohne Rückfrage.

https://www.reddit.com/r/Windows11/...ows_11_24h2_has_automatic_encryption_enabled/

Ich musste das bei meinem Notebook auch per Hand rückgängig machen - Win 11 wurde von mir da neu installiert, das war also nicht vom Kauf aus verschlüsselt. Wo ich auch dachte wow was für ein extremer Scheiss dass da nicht wenigstens eine Rückfrage kommt damit man sich das Recovery Konzept anschauen kann.

Ich nutze auch "viel" crypt aber immer dann von mir aus angeworfen, so dass ich auch weiss dass ich an die Daten trotzdem noch rankommen kann.

Das was MS da eingeführt hat ich finde das schon krass.
 
Zuletzt bearbeitet:
Uzer1510 schrieb:
denn ich erreiche ALLE Zellen die nach aussen ansprechbar sind
Ja, nach außen. Das ist genau das Problem. Durch Over-Provisioning passiert folgendes: Deine SSD wird mit 512 GB angezeigt, tatsächlich hat sie aber z.B. 515 oder 520 GB. Diese werden im Rahmen des Wear-Leveling ganz normal genutzt, nur siehst du davon nichts und kannst es auch nicht beeinflussen. An diese "überschüssigen" GB kommst du nicht ran, wenn du 512 GB Daten auf die SSD schreibst. In den restlichen Zellen können somit immer noch verwertbare alte Daten stehen, die man auslesen kann, wenn man die Flash-Bausteine auslötet und dann ausliest.
 
  • Gefällt mir
Reaktionen: cartridge_case und OdlG
Ich finde den Exkurs ganz interessant. Genau dieselbe Frage habe ich mir auch schon gestellt, ob man nicht einfach 500GB Datei auf eine 500 GB SSD schreiben kann und fertig.

Was für mich bis heute nicht ganz klar ist, wie und wann es zur Verschlüsselung der Nicht-System-SSD kam. Wie gesagt, am Ende ging ja alles gut, aber die Kommunikation war da einfach nicht optimal...
 
  • Gefällt mir
Reaktionen: mchawk777
Ja wie gesasgt wnen man die RAM Bausteine auslötet und den Controller simuliert mit einem Ergebnis das man VIELLEICHT mit einer Wahrscheinlichkeit von 0,0....01% irgendwas zusammenhängendes drin findet.

Denn Overprovisoning Zellen werden garantiert selten als Block genutzt da sind dann ein paar Bytes drin von irgndwas das 2 Jahre alt ist ein paar Bytes von irgendwas das 2 Monate alt ist und ein paar Bytes von einem Youtube Video das man vor 9 Monaten gespeichert hat. etc - und keienr weiss welche Bytes in welche Reihenfolge gehören weil das Filesystem längst längst weg ist.

Man hat dnan wenn man das ausliest halt am Ende was weiss ich 9000x die 01 ..... 10000x10 5000x30 .... 7600 die 255 und kann dann sich jede beliebige Kombinationen daraus zusammenbasteln - vom lustigen katzenvideo bis zu den Geheimplänen für ein Militär U-Boot - daraus kann man ALLES konstruieren.

Die Wahrscheinlichkeit dass sich da eine sinnvolle Datei drinnen befindet ist selbst wenn man massigst Geld für das manuelle Auslesen durch auslöten und Controller Simulation investiert halt 0.

Sobald die Reihenfolge (und auch der Bezug zum Filesystem) verloren geht und die Speicherzellen selber nicht streng geordnet sind ist das eben nur noch Müll den man zu was Beliebigen zusammenbauen kann.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: OdlG
OdlG schrieb:
Was für mich bis heute nicht ganz klar ist, wie und wann es zur Verschlüsselung der Nicht-System-SSD kam. Wie gesagt, am Ende ging ja alles gut, aber die Kommunikation war da einfach nicht optimal...
Dann empfehle ich mal die Folge 270 vom Chaos-Radio (CCC): "Daten archivieren, wiederherstellen und löschen" - die gehen da auch was mehr ins Detail ein.
 
  • Gefällt mir
Reaktionen: OdlG
Uzer1510 schrieb:
Sobald die Reihenfolge (und auch der Bezug zum Filesystem) verloren geht und die Speicherzellen selber nicht streng geordnet sind ist das eben nur noch Müll den man zu was Beliebigen zusammenbauen kann.
Dann fände ich es sinnvoller, dass man Hersteller verpflichtet, dass Controller Dateien mehr oder weniger zufällig verstreuen müssen anstatt dass man durch Verschlüsselung einen möglichen (wenn auch seltenen) Datenverlust riskiert. Oder übersehe ich hier etwas?
mchawk777 schrieb:
Dann empfehle ich mal die Folge 270 vom Chaos-Radio (CCC): "Daten archivieren, wiederherstellen und löschen" - die gehen da auch was mehr ins Detail ein.
Die Folge hattest du glaube vorher schon erwähnt. Wenn Familie und Arbeit mir mal die Zeit lassen, höre ich da rein. Auch wegen meiner Pläne zur Datensicherung :)
 
Das wird doch bei SSDs eh gemacht dass die Speicherzellen nicht nacheinander sondern komplett verstreut genutzt werden wegen z.B. wear levelling - und es für die Schreib und leserate komplett egal ist ob man nacheinander schreibt oder wild verstreut.

Man schriebt idealerweise immer das nächste "Byte" in die Zelle die bisher am wenigsten oft für das Schreiben genutzt wurde und frei ist komplett egal welche "Nummer" die physikalisch hat und mit dme nächsten "Byte" macht man das wieder so auch das landet irgendwo. (phsikalisch)

Logisch natürlich nicht - deshalb kann man eine SSD schon in der logischen Reihenfolge "auslesen" also auf der Nutzer Seite des Controllers - aber auf der physischen macht das halt eher wenig Sinn.
 
Zuletzt bearbeitet:
Uzer1510 schrieb:
denn Overprovisoning Zellen werden garantiert selten als Block genutzt
Garantiert? Von wem? Von dir? Darauf würde ich mich nicht verlassen. Es ist eher zu erwarten, dass alle vorhanden Flashzellen gleichmäßig beschrieben werden.
Uzer1510 schrieb:
da sind dann ein paar Bytes drin von irgndwas das 2 Jahre alt ist ein paar Bytes von irgendwas das 2 Monate alt ist und ein paar Bytes von einem Youtube Video das man vor 9 Monaten gespeichert hat.
Und dann waren doch wichtige Daten drin. Es benutzt nicht jeder den PC nur zum Surfen.
Uzer1510 schrieb:
etc - und keienr weiss welche Bytes in welche Reihenfolge gehören weil das Filesystem längst längst weg ist.
Aha. Wenn das OS Windows war, ist das verwendete FS zu 99% NTFS. Vielleicht exFAT oder FAT32. Ganz wilde benutzen ReFS. Die Strukturen, wie dort Daten abgelegt werden sind bekannt. Man weiß also, wie und wo man schauen muss.

Wie wäre es, wenn du einfach akzeptieren würdest, dass deine Aussage aus Beitrag 43 schlicht falsch ist?
 
Es gibt kien 1,2,3,4,5,6 logisch=phyiskalsich wie aus der Zeit aus der offensichtlich dein Wissen stammt der magnetischen Datenträger es gibt ein 1,2,3,4,5 logisch das aber physikalisch z.B. 94845843839,37,473532,6343,5238883635 ist diese Info ist nur im FTL und wir nur bestimmt durch z.B. wear level

Die Vorstellung Daten würden in SSDs physikalisch mit n,n+1 ist halt Unsinn.


Und die logische Info ist nur im FS <> egalö welche S´eite es ist keione Rekonstruktion mehr sinnvopll möglich durch auslesen der Chips.

Dein Wissen über magnetische Datenspeicher bei denen das anders war ist halt jetzt einfach veraltet. der FTL ist der Gamechanger der nur noch logisches Auslesen zur Rekonstruktion ermöglicht aber kein physikalisches mehr. Ohne FTL ist auch der OOB nutzlos.
 
Zuletzt bearbeitet:
Ich weiß nicht, wo du das rausliest, aber das habe ich mit keinem Wort geschrieben und auch nicht gemeint.

Einzig die filesystembezogene Stelle könnte man so interpretieren, aber mit dem Unsinn hast du angefangen.

Du musst verstehen, dass es Firmen und Institutionen gibt, die Kenntnis darüber haben, wie die Firmware von SSDs arbeiteten und damit ziemlich gut vorhersagen können, wie die Daten physisch abgespeichert sind.
 
  • Gefällt mir
Reaktionen: nutrix
Diese Information ist nicht statisch sondern dynamisch. Selbst wenn man den Rechenweg hat der bringt nichts

Man muss dann bis auf die Millisekunde nachstellen was der Nutzer mit der SSD jemals gemacht hat seit er die hat.

Den daraus berechnret sich über den wear table was der nächste Speicherort ist. da gibt es keine Tabellen von Werrk aus das ist zu 100% von der Nutzung abhängig.

Bei jedem einzelnen Nutzer ist der Rechenweg der gleiche aber der Wert der Variablen ist von seiner bisherigen Nutzung abhängig - sonst würde wear levelling auch gar nicht funktionieren das ist ein komplett individueller Wert und der wichtigste welcher Speicherbaustein als nächstes genutzt wird.

Wie soll denn Deiner Meinung nach wear levelling = also das Aussuchen des am wenigsten bisher beschriebenen freien Speicherorts für die nächste Schreib-Speicheradresse für alle funktionieren mit vom Werk vorgegebenen Daten? Jeder nutzt seine SSD anders - das sind dynamische Werte.

Deshalb ist es auch nicht möglich einen defekten ftl durch einen identischen zu ersetzen unter Beibehaltung der Daten weil die mapping tables (wie auf Basis von wear leveling) dynamisch erzeugt wurden. Der beste Fall ist da eine leere nutzbare SSD
 
Zuletzt bearbeitet:
Zurück
Oben