Datei sicher löschen

[Teekeks]

Zitat:

Zitat von Fridolin Walther

[...] da sich ihre Größen im ein- bis zweistelligen MB Bereich befinden.[...]

Also wir haben hier noch so einen Rum stehen und im Dauerbetrieb...
Man kann also nicht sicher davon ausgehen das so was nicht mehr benutzt wird...

[oki]

Zitat:

Zitat von XoRiC

Der Thread ist zwar nun 2 Monate alt, aber falls es noch von Interesse ist siehe hier.

Gruß Xoric

Hallo XoRiC,

ja, das Thema ist immer noch interessant, wenn auch nicht mehr so brisant. Dank auch für deine Mühe mit dem Link. Das war aber schlußendlich nicht das Problem. Die grundlegende Frage ist, was passiert alles mit einer Datei auf der Platte und wie stelle ich sicher, dass da nach dem Löschen auch nichts mehr zu finden ist. Aktuell lösen wir das Thema so, dass wir die Datei nicht auf der Platte zwischenspeichern, sondern in einer VM in den Ram (virtuelle Platte) legen und von da aus mittels externer Anwendung öffnen. Ob dann aber nicht auch irgendwas durchs swappen des Speichers auf die Platte zurückbleibt ist noch offen.

Gruß oki

[XoRiC]

Hm, da dein Wissensstand den von mir gelinkten Code wohl übertrifft.. ich wäre an deiner Lösung sehr interessiert wenn es dir nichts ausmacht deinen Code hier zu posten :wink:

Würde mich darüber freuen.
Gruß Xoric

[oki]

Zitat:

Zitat von XoRiC

Hm, da dein Wissensstand den von mir gelinkten Code wohl übertrifft.. ich wäre an deiner Lösung sehr interessiert wenn es dir nichts ausmacht deinen Code hier zu posten :wink:

Hallo XoRiC,

ob mein Wissensstand den Code übertrifft kann ich nich ohne schlechtes Gewissen pauschal beantworten. :) Derzeit kann ich aber erkennen, dass mittels des Codes im Link die zu löschende Datei geöffnet, mit Zufallswerten überschrieben und erst dann gelöscht wird. Da Dateien ja nicht wirklich mit ihrem Inhalt gelöscht werden sondern nur deren "Eintrag zum Speicherort" entfern wird ist das der Weg, um auch den Inhalt der Datei soweit zu verändern, dass er nicht wieder hergestellt werden kann.
Im Laufe dieses Threads hat sich aber herausgestellt, dass Windows leider eine Menge mehr mit einer Datei anstellt. Das leider auch noch unter unterschiedlichen Voraussetzungen. Somit scheint dieses Verfahren eben leider nicht auszureichen um wirklich alle Inhalte sicher von der Festplatte zu entfernen. Soll das so sein, so scheint der Aufwand doch imens zu sein, auch unter dem Gesichtspunkt, dass unterschiedliche Windows-Versionen und Dateisysteme zu bedenken sind.
Da drängt sich der Ansatz auf, das Zwischenspeichern der Datei auf die Festplatte grundsätzlich zu vermeiden. Bleibt das Problem, dass die zu behandelnde Datei mit einer beliebigen anderen Anwendung automatisch geöffnet werden soll. Legt man also die Datei im Speicher ab, ist zumindest mittels ShellExecute so einfach kein Rankommen an diese (wir nehmen mal an, wir wollen diese Datei mit Word öffnen). Ich muss hier fairerweise erwähnen, dass die Datei nicht vom externen Datenträger gestartet werden kann, da sie auf diesem in verschlüsselter Form abgelegt ist.

Unsere derzeitige Lösung ist, die Datei in einer kleinen VM auf einen virtuellen Laufwerk zu speichern und von dort aus zu starten. Das passiert dann natürlich alles im Speicher. Somit umgeht man das Thema Festplatte. Leider scheint dann aber immer noch das Problem offen zu sein, was passiert, wenn mangels ausreichend RAM das System die Speicherbereiche auf die Platte swapt. Dann müsste da eigentlich was von der Originaldatei übrig bleiben. Aber das ignorieren wir erst mal höflich :mrgreen:

Somit gibt es meinerseits erst mal keinen speziellen Code den ich hier posten kann. Wir haben das Problem sozusagen über einen Trick "ausgehebelt". Da jetzt keine Datei auf der Platte zwischengespeichert werden muss, muss auch nichts gelöscht werden. :mrgreen:

Gruß oki

[himitsu]

Im eigenem Programm gibt es Wege, um zu verhindern, daß Teile des Arbeitsspeichers ausgelagert und in der Pagefile gespeichert werden.

OK, man kann Windows auch anweisen, daß es die Pagefile löschen soll (löschen heißt im Falle von Windows, daß diese Datei komplet mit Nullen vollgeschrieben wird),
womit selbst ausgelagerte Daten theoretisch sicher wären.
Aber wenn Windows (absichtlich) abstürzt, dann bleiben diese Daten natürlich erhalten.

Ein anderes Problem:
Selbst wenn man es schaft die Daten, ohne daß sie irgendwie auf die Platte gelangen, zu behandeln und an ein anderes Programm, wie z.B. Word, weiterzugeben ... wer sagt uns, daß Word diese Daten nicht auf der Platte ablegt?
(Word legt sich eine Kopie der Daten an, um bei einem Absturz diese wiederherstellen zu können)


Ergo: sobald die Daten auch nur irgendwo die Möglichkeit haben auf die Platte zu gelangen, kann man sie ohne genauste Kenntnis des Dateisystems und ohne direkten Zugriff (an der Speicherverwaltung des Dateisystems vorbei) auf den Datenträger, keine Chance diese wirklich zu löschen.


Und bei heutigen Datenträgern und bei dem Aufwand, um auch nur theoretisch ein Bit wiederherzustellen, kann man sich diesen ganzen Quatsch mit dem Mehrfachüberschreiben sparen.

[Luckie]

Zitat:

Zitat von himitsu

Im eigenem Programm gibt es Wege, um zu verhindern, daß Teile des Arbeitsspeichers ausgelagert und in der Pagefile gespeichert werden.

Das gibt es meines Wissens nicht.

[OldGrumpy]

Zitat:

Zitat von Luckie

Zitat:

Zitat von himitsu

Im eigenem Programm gibt es Wege, um zu verhindern, daß Teile des Arbeitsspeichers ausgelagert und in der Pagefile gespeichert werden.

Das gibt es meines Wissens nicht.

Jein. Zunächst gibts da durchaus die VirtualLock API. Der kleine Haken daran ist aber: VirtualLock sperrt nur Pages im Working Set gegen die Auslagerung. D.h. solange ein Thread in dem Prozess aktiv ist, wird nicht ausgelagert. Die Jungs bei MS die den Memory Manager verwalten sagen dazu zwar dass in der Praxis nix ausgelagert wird was gelockt ist, aber davon abgesehen bleiben noch zwei weitere Scheunentore:

a) ReadProcessMemory -> anderer Prozess liest den gelockten Speicher ganz einfach aus

b) Suspend-to-Disk -> alle belegten Hauptspeicherseiten landen im hibernation file...

[Luckie]

Eben:

Zitat:

Zitat von Raymond Chen

When you lock memory with VirtualLock it locks the memory into your process's working set. It doesn't mean that the memory will never be paged out. It just means that the memory won't be paged out as long as there is a thread executing in your process, because a process's working set need be present in memory only when the process is actually executing.

http://blogs.msdn.com/oldnewthing/ar...6/5924058.aspx

[OldGrumpy]

Zitat:

Zitat von Luckie

Eben:

Zitat:

Zitat von Raymond Chen

When you lock memory with VirtualLock it locks the memory into your process's working set. It doesn't mean that the memory will never be paged out. It just means that the memory won't be paged out as long as there is a thread executing in your process, because a process's working set need be present in memory only when the process is actually executing.

http://blogs.msdn.com/oldnewthing/ar...6/5924058.aspx

Wenn Du schon von eben dort zitierst, dann aber auch den wichtigen Nachtrag nicht vergessen (gleicher Link, Hervorhebung von mir): :mrgreen:

Zitat:

Zitat von Raymond Chen

Follow-up: I've been informed by the memory manager folks that the working set interpretation was overly conservative and that in practice, the memory that has been virtually locked won't be written to the pagefile. Of course, the other concerns still apply, so you still have to worry about the hibernation file and another process sucking the data out via ReadProcessMemory.

[himitsu]

Zitat:

Zitat von Luckie

Das gibt es meines Wissens nicht.

Geben tut es schon.

Erstmal können sich Treiber physischen Speicher reservieren

und dann besteht die Möglichkeit, daß eine Anwendung Speicherseiten sperrt, welche vorher geziehlt angefordert wurden.
Allerdings benötigt sie dafür gewisse Rechte, welche man sich als "normales" Programm (Nicht-Admin) nicht so leicht besorgen kann
und dann ist die Frage, in wie weit sowas berhaupt sinnvoll ist, denn bei Problemen könnte man sich leicht sein Windows zerschießen ... vorallem wenn man ihm sämtlichen Speicher nicht auslagerbar zuschüttet.

[edit]
OK, B) wäre noch ein Grund,
aber da könnte man notfalls vor dem Runterfahren den Speicher verschlüsseln oder löschen.