6
EFS verschlüsselte Dateien nach convert unrettbar? (.PFILE)
Hi,
hier ist mal eine richtig harte Nuss zu knacken
Ich habe regelmäßig unverschlüsselte Dateien von USB Stick in einen verschlüsselten NTFS Ordner auf dem PC kopiert. Die Dateien wurde auf grund des Ordner Attributes "E" (wie encrypted) von Windows automatisch verschlüsselt (Ordner > Eigenschaften -> Inhalt verschlüsseln).
Wenn sich genügend angesammelt hatte, habe ich diese Dateien auf ein Veracrypt FAT32 Laufwerk verschoben. Auf dem VC FAT32 Laufwerk, wo sie 1:1 abgelegt wurden, waren sie weiterhin verschlüsselt und ihr Inhalt lesbar.
So weit, so gut.
Irgendwann wurde im VC der Platz knapp und ich musste das VC Laufwerk mittels VC Tool (Volume Expander) vergößern. Das geht aber nur mit NTFS. Deshalb habe ich mit dem Windows Befehl "convert Z: /FS:NTFS /NoRestrictions" das FAT32 umgewandelt (habe ich schon öfter gemacht, um zB MBR zu GPT zu konvertieren). Hat auch wie immer prima geklappt, mit einem klitzekleinen Fehlerchen, wovor convert mich leider nicht gewarnt hat: Von den verschlüsselten Dateien wurde das Attribut "E" entfernt und jede Datei erhielt die Endung .PFILE (Test.txt.PFILE).
Nun komme ich nicht mehr an den Dateiinhalt ran!
Ein Blick mit Hex Editor in den Datei Header zeigt, dass sie weiterhin verschlüsselt vorhanden ist. Windows müßte sie also problemlos entschlüsseln können, tut das aber nicht, weil das "E" fehlt. Beim Setzen des "E" Attributes wird sie natürlich neu verschlüsselt, was ergo keinen Sinn macht.
Der Windows Befehl "cipher" tut es auch nicht. Im Gegenteil: Ohne "E" erkennt er nicht mal die Verschlüsselung.
Ich habe bisher keinen Weg gefunden, am Windows NTFS Treiber vorbei das "E" zu setzen (Linux/Samba kann es auch nicht), sonst könnte man die Dateien ja einfach zur NTFS Quelle zurück kopieren.
Wie kriege ich die *.PFILE Dateien entschlüsselt???
Es muss einen Weg geben, denn sonst macht es keinen Sinn, diese Dateien nach *.PFILE umzubenennen. Dann hätte "convert" sie auch gleich löschen können.^^
Normaler Win 10 PC ohne Domäne, Original PC und Platte + EFS Zertifikat usw. ist alles vorhanden. Es MUSS gehen.
Falls hier also jemand eine Idee hat... bitte her damit
hier ist mal eine richtig harte Nuss zu knacken
Ich habe regelmäßig unverschlüsselte Dateien von USB Stick in einen verschlüsselten NTFS Ordner auf dem PC kopiert. Die Dateien wurde auf grund des Ordner Attributes "E" (wie encrypted) von Windows automatisch verschlüsselt (Ordner > Eigenschaften -> Inhalt verschlüsseln).
Wenn sich genügend angesammelt hatte, habe ich diese Dateien auf ein Veracrypt FAT32 Laufwerk verschoben. Auf dem VC FAT32 Laufwerk, wo sie 1:1 abgelegt wurden, waren sie weiterhin verschlüsselt und ihr Inhalt lesbar.
So weit, so gut.
Irgendwann wurde im VC der Platz knapp und ich musste das VC Laufwerk mittels VC Tool (Volume Expander) vergößern. Das geht aber nur mit NTFS. Deshalb habe ich mit dem Windows Befehl "convert Z: /FS:NTFS /NoRestrictions" das FAT32 umgewandelt (habe ich schon öfter gemacht, um zB MBR zu GPT zu konvertieren). Hat auch wie immer prima geklappt, mit einem klitzekleinen Fehlerchen, wovor convert mich leider nicht gewarnt hat: Von den verschlüsselten Dateien wurde das Attribut "E" entfernt und jede Datei erhielt die Endung .PFILE (Test.txt.PFILE).
Nun komme ich nicht mehr an den Dateiinhalt ran!
Ein Blick mit Hex Editor in den Datei Header zeigt, dass sie weiterhin verschlüsselt vorhanden ist. Windows müßte sie also problemlos entschlüsseln können, tut das aber nicht, weil das "E" fehlt. Beim Setzen des "E" Attributes wird sie natürlich neu verschlüsselt, was ergo keinen Sinn macht.
Der Windows Befehl "cipher" tut es auch nicht. Im Gegenteil: Ohne "E" erkennt er nicht mal die Verschlüsselung.
Ich habe bisher keinen Weg gefunden, am Windows NTFS Treiber vorbei das "E" zu setzen (Linux/Samba kann es auch nicht), sonst könnte man die Dateien ja einfach zur NTFS Quelle zurück kopieren.
Wie kriege ich die *.PFILE Dateien entschlüsselt???
Es muss einen Weg geben, denn sonst macht es keinen Sinn, diese Dateien nach *.PFILE umzubenennen. Dann hätte "convert" sie auch gleich löschen können.^^
Normaler Win 10 PC ohne Domäne, Original PC und Platte + EFS Zertifikat usw. ist alles vorhanden. Es MUSS gehen.
Falls hier also jemand eine Idee hat... bitte her damit
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: 1172868622
Url: https://administrator.de/forum/efs-verschluesselte-dateien-nach-convert-unrettbar-pfile-1172868622.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
6 Kommentare
Neuester Kommentar
Aus Backup wiederherstellen.
lks
PS. zum Datenretter gehen oder selbst mit einem Hex-HDD-Editor im Filesystem die e-Flags setzen.
Hi,
das bist du der Fat32-"Kompatibilität" von EFS unter Windows 10 auf den Leim gegangen.
Ich habe mich mit der nicht beschäftigt, aber hast du mal den naiven Ansatz versucht, die Dateien auf ein Fat32-Medium zu kopieren und von dort zu öffnen?
In der Theorie müsste der Key-ADS von NTFS bereits beim Verschieben auf Fat32 mit der Datei verkettet worden sein zur pfile (was angesichts des Zwecks der pfile als Austauschformat plausibel wäre). Ggf. schauen pfiles aus EFS unter Windows 10 noch aus wie EFS, das weiß ich nicht. Aber den ADS haben sie jedenfalls schon beim Verschieben verloren.
Grüße
Richard
das bist du der Fat32-"Kompatibilität" von EFS unter Windows 10 auf den Leim gegangen.
Ich habe mich mit der nicht beschäftigt, aber hast du mal den naiven Ansatz versucht, die Dateien auf ein Fat32-Medium zu kopieren und von dort zu öffnen?
In der Theorie müsste der Key-ADS von NTFS bereits beim Verschieben auf Fat32 mit der Datei verkettet worden sein zur pfile (was angesichts des Zwecks der pfile als Austauschformat plausibel wäre). Ggf. schauen pfiles aus EFS unter Windows 10 noch aus wie EFS, das weiß ich nicht. Aber den ADS haben sie jedenfalls schon beim Verschieben verloren.
Grüße
Richard
Hallo Richard,
danke für die Anteilnahme
Das bringt ja nichts. Die Dateien haben das "E" Flag verloren und werden deshalb beim Öffnen nicht "on the fly" entschlüsselt.
Was ist Key-ADS? (Active Directory Service? Ich schrieb ja, dass kein AD vorhanden ist)
Auf dem Zieldatenträger hat "convert" in einigen Ordnern zu den PFILES noch im Ordner eine kleine Datei namens "$EFS" mit Hex-Salat erzeugt.
Linux hat sich auch ziemlich zickig und erkennt NTFS Ordner mit "E": Man kann da nicht mal eine x-beliebige Datei reinkopieren. Die Idee war, dass sich Windows damit austricksen lässt und das "E" Attribut sich zB mit chkdsk "reparieren" lässt bzw. durch die Vererbung auf dem Ordner selbst heilt.
danke für die Anteilnahme
hast du mal den naiven Ansatz versucht, die Dateien auf ein Fat32-Medium zu kopieren und von dort zu öffnen?
Das bringt ja nichts. Die Dateien haben das "E" Flag verloren und werden deshalb beim Öffnen nicht "on the fly" entschlüsselt.
... in der Theorie müsste der Key-ADS von NTFS ...
Was ist Key-ADS? (Active Directory Service? Ich schrieb ja, dass kein AD vorhanden ist)
Auf dem Zieldatenträger hat "convert" in einigen Ordnern zu den PFILES noch im Ordner eine kleine Datei namens "$EFS" mit Hex-Salat erzeugt.
Linux hat sich auch ziemlich zickig und erkennt NTFS Ordner mit "E": Man kann da nicht mal eine x-beliebige Datei reinkopieren. Die Idee war, dass sich Windows damit austricksen lässt und das "E" Attribut sich zB mit chkdsk "reparieren" lässt bzw. durch die Vererbung auf dem Ordner selbst heilt.
Zitat von @lexa-lexa:
Das bringt ja nichts. Die Dateien haben das "E" Flag verloren und werden deshalb beim Öffnen nicht "on the fly" entschlüsselt.
Das bringt ja nichts. Die Dateien haben das "E" Flag verloren und werden deshalb beim Öffnen nicht "on the fly" entschlüsselt.
Ich würde es zumindest mal ausprobieren, und zwar mit dem gesamten Dateibaum, einschließlich der $EFS-Dateien. Umgekehrt einfach ein Attribut zu setzen, bringt jedenfalls nichts, weil es sich schon seit dem Verschieben auf Fat32 um modifizierte Dateien handeln muss.
Das ist wie gesagt eine theoretische Betrachtung, weil ich nie was mit EFS auf Fat32 unter Windows 10 unternommen habe.
Dennoch ist ein Aspekt technisch unzweifelhaft: EFS ist ein NTFS-Feature, bzw. eben ein "Encrypted File System". EFS nutzt Alternate Data Streams (ADS) von NTFS, um verschlüsselte File-Encryption-Keys zu speichern (der ADS heißt auch $EFS). Mit dem Verschieben auf ein Dateisystem, das keine ADS unterstützt, wie Fat32, würden diese Schlüssel unweigerlich verloren gehen.
Nun hat MS unter Windows 10 eine Kompatibilität von EFS und Fat32 eingeführt. Die muss erstens ohne ADS auskommen und zweitens mit dem pfile-Format zusammenhängen. Pfile wiederum hängt mit einem "Microsoft Rights Management" zusammen, also einem Feature, das Dateien kryptografisch schützt, die über Organisationsgrenzen hinweg z.B. per E-Mail oder Blob-Storage ausgetauscht werden. Passt, denn solche Dateien müssen von Dateisystem-Features unabhängig sein und alle kryptografischen Informationen selbst enthalten.
Oben hatte ich daher vermutet, dass Windows 10 beim Verschieben von EFS-geschützten Dateien von NTFS auf Fat32 den Dateidatenstrom mit dem ADS zu einer pfile verkettet und das im Explorer maskiert, sodass der Nutzer keinen Unterschied merkt (solange es auf dem Fat32-Volume bleibt). Ich denke, das lässt sich so ähnlich noch aufrecht erhalten, nur werden die ADS ggf. gesammelt in eine Datei $EFS abgetrennt.
Wenn du jetzt den gesamten Dateibaum wieder auf einem Fat32-Volume hast, und das mit einem User im Explorer öffnest, der die nicht mehr existente EFS-geschützten Dateien entschlüsseln könnte, dann sollte der genauso betrachtet werden wie die Dateien auf dem ursprünglichen Fat32. Zumindest sind die Metadaten von Fat32 so überschaubar, dass der Umweg über das NTFS-Volume das nicht verhindern dürfte.
Wenn es doch nicht so simpel geht, dann reicht andererseits auch das Attribut nicht, sondern die pfile- und $EFS-Dateien müssten als Dateidatenströme und $EFS-ADS auf NTFS wieder zusammengefügt werden.
Ich würde es zumindest mal ausprobieren, und zwar mit dem gesamten Dateibaum, ...
Das habe ich natürlich. Es landen 1:1 Kopien im Ziel.
...weil ich nie was mit EFS auf Fat32 unter Windows 10 unternommen habe.
Ich auch nicht. Der blöde Convert Befehl...
Ein interessanter Ansatzpunkt scheinten kurz die ADS zu sein. Wobei ich nicht davon ausging, dass für jede einzelne Datei ein eigener ADS geschrieben wird. Das würde IMHO nur Sinn machen, wenn jede Datei mit einem *eigenen* eindeutigen Key verschlüsselt würde. Die Dateien verschlüsselter Ordner auf NTFS sind aber mit einem dem User zugeordneten Key verschlüsselt.
Ein "dir /r" zeigt folgerichtig für keine der verschlüsselten Dateien auf einem NTFS einen ADS an.
Also ADS adieu.
Ich gehe eher davon aus, dass das "E" Flag dem OS mitteilt, das auf alle zu öffnenden Dateien der Key aus dem Zertifikatsspeicher des Users anzuwenden ist.
Was das entschlüsseln einfacher macht, wenn man wüßte wie
EFS nutzt für jede Datei einen individuellen symmetrischen Key, der im $EFS-ADS der Datei gespeichert und mit dem asymmetrischen Key des Nutzers verschlüsselt ist.
Es kommt letztlich darauf an, ob in den $EFS-Dateien die abgetrennten ADS für alle Dateien rekonstruierbar vorliegen. Schlimmstenfalls wurden die wiederholt mit den jeweiligen ADS nur einer Datei überschrieben. Das ist recht interessant, also vielleicht stelle ich es in den nächsten Tagen mal nach.
Es kommt letztlich darauf an, ob in den $EFS-Dateien die abgetrennten ADS für alle Dateien rekonstruierbar vorliegen. Schlimmstenfalls wurden die wiederholt mit den jeweiligen ADS nur einer Datei überschrieben. Das ist recht interessant, also vielleicht stelle ich es in den nächsten Tagen mal nach.
