Ich verwende ein Win10-Notebook und habe das folgende Problem:
Ich habe einen Ordner inklusive aller Unterordner mit der integrierten Verschlüsselungsfunktion verschlüsselt, die Sie erhalten, wenn Sie mit der rechten Maustaste auf einen Ordner klicken > Eigenschaften > Erweitert.
Ich habe einen Unterordner dieses Ordners, der einige .cpp-Dateien enthielt, auf ein USB-Laufwerk (FAT32) und von dort auf eine Linux-Festplatte (EXT3/EXT4) verschoben, ohne zu bemerken, dass es immer noch verschlüsselt war.
Auf meinem Linux-PC konnte ich die Dateien offensichtlich nicht öffnen, da sie die Endung .pfile hatten und verschlüsselt waren. Also habe ich sie wieder auf den USB-Stick verschoben und von dort wieder auf das Notebook.
Auf dem Notebook kann ich sie jetzt allerdings auch nicht mehr öffnen. Scheinbar merkt Win10 gar nicht, dass sie noch verschlüsselt sind, denn der Haken in den Eigenschaften ist nicht mehr gesetzt.
Ich habe die Installation mit Azure Information Protection-Viewer durchgeführt, erhalte aber nur die Fehlermeldung, dass der Dateityp (.cpp) nicht geöffnet werden kann. (Ich kenne die genaue Fehlermeldung auf Englisch nicht, da ich keine englische Installation verwende.)
Antwort1
Es scheint, dass Microsoft bisher ungenutzte Felder in FAT32-Verzeichniseinträgen und möglicherweise auch versteckte Verzeichniseinträge und Tricks mit langen und kurzen Dateinamen verwendet, um EFS-Metadaten auf FAT32 zu speichern:
Verschlüsselte Dateien haben die Erweiterung „.PFILE“ und ihre 8.3-Verzeichniseinträge speichern zusätzliche Metadaten. In der aktuellen Implementierung passen diese Metadaten in 6 Bits: Zwei Bits werden als Flags verwendet und vier Bits werden zum Speichern der Füllgröße verwendet.
Die zusätzlichen Metadaten werden im NTByte-Feld gespeichert, das sich am 12-Byte-Offset innerhalb des 8.3-Verzeichniseintrags befindet. Bisher wurde dieses Feld nur verwendet, um zwei Flags zu speichern, die den kurzen Basisnamen oder die Erweiterung als Kleinbuchstaben markierten (Bits Nr. 3 und Nr. 4).
Nun werden auch die restlichen Bits verwendet. Bit Nr. 0 wird gesetzt, wenn die Datei verschlüsselt ist (es wird auch für ein Verzeichnis gesetzt, wenn dessen neu erstellte Dateien standardmäßig verschlüsselt werden sollen), Bit Nr. 1 wird gesetzt, wenn die Datei mit einem großen EFS-Header beginnt (ansonsten ist es ein Standard-EFS-Header). Andere Bits (Bits Nr. 2, Nr. 5, Nr. 6 und Nr. 7) werden verwendet, um die Füllgröße zu speichern (die höchstens 15 Byte groß ist, also reichen 4 Bits aus) – sein Bit Nr. 0 (LSB) geht an Bit Nr. 2 des NTByte-Felds, Bit Nr. 1 an Bit Nr. 5, Bit Nr. 2 an Bit Nr. 6, Bit Nr. 3 an Bit Nr. 7.
(Quelle, siehe auch die zitierteUS-Patent US10726147B2)
Indem Sie die Dateien wegschieben und anschließend wieder zurückspeichern, haben Sie die speziellen Metadaten zerstört, da Linux nichts davon weiß.
Es tut mir leid, das sagen zu müssen, aber Ihre Dateien sind mit ziemlicher Sicherheit nicht mehr wiederherstellbar. Sie könnten trotzdem versuchen, die versteckten Metadaten zu erraten, schließlich gibt es nur 64 mögliche Werte. Dazu wäre allerdings ein Raw-Disk-Hex-Editor oder ein benutzerdefinierter Dateisystemtreiber erforderlich.
Antwort2
Nach tagelanger Suche fand ich die Lösung,
Das Problem ist, wenn Sie Dateien nach Linux kopieren und sie zurückkopieren, werden die Metadaten für Dateien zerstört. Ich löse dies mit dem Disk Editor. Ich habe eine Datei mit der gleichen Größe erstellt, sie verschlüsselt und auf das FAT32-Laufwerk kopiert und die Metadaten für die Datei kopiert, nachdem ich sie gelöscht und durch die zerstörte ".PFILE" ersetzt habe und die Metadaten ersetzt habe.
Vielen Dank "Daniel B" Ihre Antwort hat mir wirklich geholfen