Datei sicher löschen

[oki]

Hallo Leute,

ich schau mal gerade quer Beet, was es so an Code-Snippes zum Thema sicheres Löschen von Dateien gibt. Sinn ist es, eine eigene Funktion dafür zu implementieren.
Natürlich bin ich bei den Jedis fündig geworden. Aber auch im SwissDelphiCenter, siehe hier sicheres Löschen . Auf den ersten Blick sah der Code gegenüber den Jedis um Längen simpler aus. Eigentlich erschien er mir auch nicht weniger sicher. Bei genauerem Hinschauen musste ich aber feststellen, dass der imho ziemlich buggy ist.

Ich möchte hier noch mal den Code posten und die aus meiner Sicht vorhandenen Fehler und Problemstellen kommentieren. Ziel der Übung soll es sein daraus einen ordentlichen Code zu machen. Ich hoffe mit eurer Hilfe. Er soll sicher und einfach sein.

Delphi-Quellcode:

procedure ShredderFile(FileName: string);
const
  Buffer       = 1024;
  Counttowrite = 34;
  FillBuffer: array[0..5] of Integer = ($00, $FF, $00, $F0, $0F, $00);
var
  arr: array[1..Buffer] of Byte;
  f: file;
  i, j, n: Integer;
begin
  AssignFile(f, FileName);
  Reset(f, 1);
  n := FileSize(f);
  for j := 0 to Counttowrite do
  begin
    for i := 1 to n div Buffer do
    begin
      BlockWrite(f, FillBuffer[j], Buffer);
    end;
  end;
  CloseFile(f);
  RenameFile(FileName, ExtractFilepath(FileName) + '$000000.tmp');
  DeleteFile(ExtractFilepath(FileName) + '$000000.tmp');
end;

procedure ShredderAndDeleteFile(const FileName: string);
var
  newname: string;
begin
  // zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind
  // first rename the file
  newname := ExtractFilepath(FileName) + '$000000.tmp';

  if not RenameFile(FileName, newname) then
    raise
    Exception.CreateFmt('Fehlercode 2: Kann %s nicht umbenennen!', [FileName]);

  ShredderFile(newname);

  DeleteFile(newname);
end;


// Aufruf / Call: ShredderAndDeleteFile(Edit1.Text)

Erst mal die groben Sachen. Die procedure ShredderAndDeleteFile ruft die Procedure ShredderFile auf. In ShredderFile wird die Datei gelöscht. Das gleiche versucht ShredderAndDeleteFile aber nach der Rückkehr auch noch einmal. Das ist imho Unfug und wirft sowieso eine Fehlermeldung.
Ich würde den Teil für AssignFile in ShredderFile in einen Try finally Block setzen um die Datei sicher mit CloseFile wieder zu schließen. Läuft in der Mitte irgentwas schief, das eine Exception wirft, hat man ruckzuck ein offenes Dateihandle.

So, nun die richtigen Probleme.

Ich interpretiere den Code so, dass die Datei 35 x überschrieben werden soll, bevor sie gelöscht wird. Das ist mal ok.
Das Überschreiben soll in 1k-Blöcken erfolgen (denke ich an der Konstanten Buffer und deren Benutzung in WriteBlock erkennen zu können). Die Maske für die zu schreibenden Blöcke soll sicher FillBuffer liefern. Warum jetzt FillBuffer 6 Integer-Werte hält, was einer Recordlänge von 24 Byte enspricht ist mir überhaupt nicht klar. Zudem ist die Buffergröße von 1024 nicht einmal sauber durch 24 teilbar.
Dann wird ein Array arr als Variable definiert, kommt aber nie zum Einsatz. Bei der kann ich noch die Verwendung erahnen, soll mit der Länge von 1024 (Buffer) sicher die Daten für den Schreibblock halten und müßte somit kontinuierlich mit FillBuffer aufgefüllt werden. Wird halt nur nicht benutzt.
Völlig undurchsichtig wird die Sache aber in der Zeile:

Delphi-Quellcode:

   BlockWrite(f, FillBuffer[j], Buffer);

Hier sollen sicher 1024 Byte (Buffer) an die aktuelle Position in der Datei geschrieben werden. Als Vorlage wird hier aber FillBuffer mit einer max. Länge von 24 Byte verwendet. Welchen tieferen Sinn die Angabe von FillBuffer[j], also dem Schleifenzähler der Überschreibvorgänge haben soll ist mir völlig unverständlich. Das j auch über die Grenzen von FillBuffer läuft muss eigentlich nicht erwähnt werden.

Normalerweise würde ich hier sagen "Käse" und gut. Erstaunlicherweise ist es aber so, dass das 35 malige Überschreiben einer Datei als sicheres Löschen angesehen und hier genau so verendet wird:

Zitat:

Als eine der sichersten Methoden des Überschreibens gilt das so genannte Gutmann-Verfahren. In seinem Papier "Secure Deletion of Data from Magnetic and Solid-State Memory" forderte der Sicherheitsexperte Peter Gutmann, zu löschende Dateien gleich 35-mal zu überschreiben.

Somit hatte ich auf den ersten Blick Kompetenz vermutet. Nach lesen des Codes jedoch eher das Gegenteil. Nun gibt es ja noch die Variante, dass ich der arogante Unwissende bin und heimlichen tiefsinnigen Tücken hinter dem Code nicht auf die Schliche komme. So ist arr als Variable mit einer Länge von 1024 Byte direkt hinter FillBuffer definiert. Der trickige Progger könnte ja jetzt vermuten, dass das Lesen über die Grenzen von FillBuffer zu einem Lesen der Werte in arr führt, das diese Bereich ja genau danhinter kommt :glaskugel: ; Man kann ja nie wissen.

Ach ja, die Folge der Bufferinhalte scheint auch nicht wahrlos gewählt zu sein:

Delphi-Quellcode:

  FillBuffer: array[0..5] of Integer = ($00, $FF, $00, $F0, $0F, $00);

Da vermute ich mal wieder einen echten Sinn. Leider erschließt sich auch der mir nicht.

Wenn mir hier jemand für klare Sicht behilflich sein kann, große Freude.

Gruß oki

[Fridolin Walther]

Hmmm ... der Code ist echt übel. Ich würde eine komplette Neuimplementierung empfehlen. Darüber hinaus ist das 35fache Überschreiben totaler Overkill. Bei den heutigen Datendichten reicht ein einzelner Überschreibvorgang aus. Der Mythos des "Restmagnetismus" ist auf moderne Hardware also nicht mehr zutreffend.

Prinzipiell solltest Du auch den Slack Space überschreiben. Das macht die Funktion derzeit nicht.

[oki]

Zitat:

Zitat von 0xF30FC7

Hmmm ... der Code ist echt übel. Ich würde eine komplette Neuimplementierung empfehlen. Darüber hinaus ist das 35fache Überschreiben totaler Overkill. Bei den heutigen Datendichten reicht ein einzelner Überschreibvorgang aus. Der Mythos des "Restmagnetismus" ist auf moderne Hardware also nicht mehr zutreffend.

Prinzipiell solltest Du auch den Slack Space überschreiben. Das macht die Funktion derzeit nicht.

Bist du dir sicher, dass einmal überschreiben wirklich reicht? Die nächste Frage ist, wie quantifiziere ich alt? 3 Jahre, 5 Jahre 10 Jahre? Die Aussage "Sicheres Löschen auf neuer Hardware!" kommt glaub ich nicht so gut.
Und jetzt mal ganz blöd gefragt; Was ist der Slack Space :gruebel:

Reicht das WriteBlock aus?

gruß oki

[himitsu]

ja, ist sicher ... such mal etwas ... gibt hier schon einige Threads dazu

[quendolineDD]

Zitat:

Was ist der Slack Space

Titel der Webseite

[Fridolin Walther]

Zitat:

Zitat von oki

Bist du dir sicher, dass einmal überschreiben wirklich reicht?

Musst nicht mein Wort nehmen ... Nimm halt http://www.heise.de/security/Sichere...meldung/121855. Ansonsten ist es so, daß alt bedeutet: So alt, daß keine der Platten mehr in Verwendung sein sollte, da sich ihre Größen im ein- bis zweistelligen MB Bereich befinden. Übrigens: Diese Standards mit dem 35 Mal überschreiben stammen aus dem Disketten Zeitalter. Und wir reden hier nicht von High Density 1,44 MB Disketten ...

Zum Thema Slack SpacE:
Der Einfachheit halber belegen Dateien bei den meisten Dateisystemen immer eine ganze Anzahl an Clustern (Cluster -> eine Ansamlung von Sektoren). Bei NTFS ist die Clustergröße normalerweise 4 KB (also 8 Sektoren). Also wenn eine Datei nur ein Byte groß ist, belegt sie trotzdem einen Cluster und somit 4 KB. Angenommen die Datei war irgendwann mal größer und wurde dann verkleinert, so befinden sich im Rest des letzten belegten Clusters (Slack Space) noch immer die Daten die dort mal waren. Entsprechend musst Du sicher stellen, daß Du bei Dateien deren Größe nicht zufällig durch die Clustergröße teilbar ist, auf die nächste Clustergrenze aufrundest.

[oki]

Sorry, dass ich so lange nicht rein geschaut habe, war an einem anderen Thread beschäftigt.

Hmmm :gruebel: da muss ich dann doch noch mal ne Runde lesen. Das mit dem Slack Space gefällt mir gar nicht.

Gruß oki

[himitsu]

ja und am Besten auch gleich noch die restlichen unallokierten Cluster und die Slack-Spaces hinter anderen Dateien mit löschst/überschreibst ... deine Datei könnte ja inzwischen verschoben wurden sein und somit noch irgendwo anders Daten der Datei rumliegen (z.B. bei der Defragmentierung und Größenänderung der Datei)

[shmia]

Delphi-Quellcode:

procedure ShredderFile(const filename:string);
const
  Fillchars: array[0..5] of char = (Char($00), Char($FF), Char($00), Char($F0), Char($0F), Char($00));
  BLOCK_SIZE = 8096;
var
   fs : TStream;
   buffer : String;
   i, j : Integer;
begin
   fs := TFileStream.Create(filename, fmOpenReadWrite or fmShareExclusive);
   try
      // Datei auf nächste Blockgrösse verlängern, damit der "Slack" überschrieben
      // wird
      fs.Size := ((fs.Size div BLOCK_SIZE) +2) * BLOCK_SIZE;

      // Datei soll mindestens 2 MB gross sein, damit die Schreibcaches der
      // Festplatten überflutet werden
      if fs.Size < 2097152 then
         fs.Size := 2097152;

      for i := 0 to 5 do
      begin
         fs.Position := 0;
         buffer := StringofChar(Fillchars[i], BLOCK_SIZE);

         for j := 1 to fs.Size div BLOCK_SIZE do
         begin
            fs.WriteBuffer(buffer[1], BLOCK_SIZE);
         end;
         FlushFileBuffers(fs.Handle);
      end;

      // zum Schluss belanglose Daten schreiben
      buffer := '2g642467894erp46FGHTZ&%%&/&)$%"&$%& 5675645 ';
      fs.Position := 0;
      for j := 1 to fs.Size div Length(buffer) do
      begin
         fs.WriteBuffer(buffer[1], Length(buffer));
      end;
   finally
      fs.Free;
   end;
end;


procedure ShredderAndDeleteFile(const filename:string);
var
   newname : string;
begin
   // zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind
   newname := ExtractFilepath(Filename)+'$000000.tmp';

   if not RenameFile(Filename, newname) then
      raise Exception.CreateFmt('Can''t rename file %s', [filename]);

   ShredderFile(newname);

   DeleteFile(newname);
end;

[oki]

@himitsu: das ist jetzt aber nicht fair :roll: Mich so ins Aus zu schicken. Wie ermittel ich die unalokierten Cluster?

@shmia: Dank für den Code. Das Thema mit den 2 MB ist mir nicht klar geworden. Was ist, wenn ich Dateien mit geringerer Länge habe? Oder soll die Datei künstlich auf 2MB vergrößert werden um den von dir beschriebenen Effekt des "überfluten des Schreibcash" zu erziehlen (was immer das für'n Zauber ist :glaskugel: ).
Das Thema unalokierte Cluster ist aber im Code nicht enthalten, somit muss wohl himitsu bluten wenn er noch Lust hat. :stupid:

Gruß oki

[himitsu]

wenn man genauer sucht, dann findet man bestimmt sogar meinen alten Shreder-Code hier irgendo, welcher auch nicht grad auf dem "aktuellen" Wissensstand ist :oops:

Zitat:

// zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind

du weißt aber, daß NTFS sich dennoch den alten Namen merkt?

Bei meiner Datenplatte mit 16-KB-Clustern würde zu 50% was vom Slack-Space übrig bleigen,
bei meiner Systemplatte mit nur 4 KB würde zu 50% mehr, als nötig überschrieben und beim USB-Stick zu 93%, da nur 0,5 KB.

Zitat:

Zitat von oki

@himitsu: das ist jetzt aber nicht fair :roll: Mich so ins Aus zu schicken. Wie ermittel ich die unalokierten Cluster?

ja wie nur ... bei FAT und NTFS könnte man sich das Volumebitmap laden,
und da drin nachsehn.
dann brauchst du noch direkten Schreibzugriff auf den Datenträger, was mindesten Adminrechte verlangt

aber solange du dich nicht mit dem Aufbau der Dateisysteme auskennst, weißt du dann immernoch nicht, welche Sektoren nun zu löschen sind :nerd:

Zitat:

Zitat von oki

Was ist, wenn ich Dateien mit geringerer Länge habe?

idealer Weise besorgst du dir die Clustergröße und rundest deine Dateigröße auf das nächste Vielfache davon auf ... ich glaub das konnte mein alter Code schon ... falls den wer findet :angel2:

[Fridolin Walther]

Zitat:

Zitat von shmia

Delphi-Quellcode:

const
  Fillchars: array[0..5] of char = (Char($00), Char($FF), Char($00), Char($F0), Char($0F), Char($00));
  BLOCK_SIZE = 8096;
var
   fs : TStream;
   buffer : String;
   i, j : Integer;
begin
   fs := TFileStream.Create(filename, fmOpenReadWrite or fmShareExclusive);
   try
      // Datei auf nächste Blockgrösse verlängern, damit der "Slack" überschrieben
      // wird
      fs.Size := ((fs.Size div BLOCK_SIZE) +2) * BLOCK_SIZE;

Sehr unschöne Lösung, vorallem weil Cluster durchaus größer als 8 KB sein können. Es wäre besser zur Laufzeit die Cluster Größe auf dem Laufwerk zu ermitteln, auf dem geschrieben werden soll: GetDiskFreeSpace

[oki]

Zitat:

Zitat:
// zuerst umbennen, dann später keine Rückschlüsse auf den Dateinamen möglich sind

du weißt aber, daß NTFS sich dennoch den alten Namen merkt?

Nein wußte ich nicht :oops: und der Code kommt nicht von mir :mrgreen: (Gott sei Dank).

Solange die Datei sicher gelöscht ist kann man zur Not damit leben. Sollte sich da noch ein Weg finden lasse, so währe es dann aber konsequent.

Zitat:

oki hat folgendes geschrieben:
@himitsu: das ist jetzt aber nicht fair Rolling Eyes Mich so ins Aus zu schicken. Wie ermittel ich die unalokierten Cluster?


ja wie nur ... bei FAT und NTFS könnte man sich das Volumebitmap laden,
und da drin nachsehn.
dann brauchst du noch direkten Schreibzugriff auf den Datenträger, was mindesten Adminrechte verlangt

aber solange du dich nicht mit dem Aufbau der Dateisysteme auskennst, weißt du dann immernoch nicht, welche Sektoren nun zu löschen sind

Die Dateien, die bei mir zu löschen sind werden nur für die aktuelle Sitzung auf den Datenträger kopiert und sollen bei Beenden des Programms sicher gelöscht werden. Somit gehe ich davon aus, dass ich das Verschieben der Dateien nicht berücksichtigen brauch. Ich will auch ehlich sagen, dass mir an der Stelle der Aufwand zu übertrieben scheint.

@0x...irgendwas:
Dank für den Hinweis auf GetDiskFreeSpace. Mir schwante schon so was. Um das Thema werd ich mich auf jeden Fall kümmern. Wenn ich schon den Slack Space mit lösche, dann ordentlich.

Ich bin für jede weitere Anregung dankbar. Entscheidend ist für mich nicht die Kürze des Codes, sondern dass die Funktion ordentlich umgesetzt ist.

Dank und Gruß oki

PS: Nicht, dass sich jemand wundert, ich will erst Infos sammeln und dann Coden. Ich werde aber auf jeden Fall die fertige Funktion hier posten.

[OldGrumpy]

Zitat:

Zitat von 0xF30FC7

Der Einfachheit halber belegen Dateien bei den meisten Dateisystemen immer eine ganze Anzahl an Clustern (Cluster -> eine Ansamlung von Sektoren). Bei NTFS ist die Clustergröße normalerweise 4 KB (also 8 Sektoren). Also wenn eine Datei nur ein Byte groß ist, belegt sie trotzdem einen Cluster und somit 4 KB. Angenommen die Datei war irgendwann mal größer und wurde dann verkleinert, so befinden sich im Rest des letzten belegten Clusters (Slack Space) noch immer die Daten die dort mal waren. Entsprechend musst Du sicher stellen, daß Du bei Dateien deren Größe nicht zufällig durch die Clustergröße teilbar ist, auf die nächste Clustergrenze aufrundest.

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

[himitsu]

Zitat:

Zitat von OldGrumpy

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

ich glaub vor kurzem gelesen zu haben, daß es 1050 Byte sind, also nichtmal ein ganzer Cluster

aber wenn es eh "einfach" sein soll und die betreffenden Dateien nicht verkleinert werden, dann würde es ausreichen, wenn die Dateien in ihrer aktuellen Dateigröße einfach einmal komplett mit 0 überschrieben werden und dabei der Slack Space ignoriert wird, denn da steht ja eventuell nur was "wichtiges" drin, wenn die Datei verkleinert wurde :angel:


PS: ich erwähne jetzt hier lieber nicht noch die Sparse-Dateien, komprimierten Dateien, die Junctions und was es sonst noch im NTFS gibt :nerd:

[oki]

Zitat:

Zitat von OldGrumpy

Bei NTFS ist das ganze nochmal eine Nummer trickreicher: Files die kleiner als ein Cluster sind, werden innerhalb der MFT abgelegt. Sobald du da dann nachträglich was anfügen willst, wird ein neuer leerer Block reserviert und der ganze Inhalt umgelagert.

Bleibt dann der originale "kleine" Bestandteil der Datei in der MFT? Und wie bekomme ich den da weg?

Dank für deinen Beitrag OldGumpy und Gruß

oki

[himitsu]

die MFT auslesen, direkten Zugriff auf Datenträger erlangen, MFT suchen, alle Mapping-LCNs der MFT besorgen, die MFT nach der Datei durchsuchen, die Position in der MFT berechnen, über die LCNs die Postition auf der Platte bestimmen und dann da löschen :stupid:


Legst du die Dateien selber an?
dann reservier Anfangs volle ihre Dateigröße und schreib erst danach die Daten da rein.

bzw. müssen die Dateien unbedingt auf den Datenträger?
notfalls direkt im RAM behalten.



PS: vergiß nicht, wenn du die Dateien verarbeitest und etwas da rauslädst, dann könnten diese Daten über die Auslagerungsdatei auch auf der Platte landen.


Datensicherheit ist schon ein schlimmes Thema :?

[oki]

Zitat:

Zitat von himitsu

Datensicherheit ist schon ein schlimmes Thema :?

:thumb: :thumb: :thumb: :thumb:

Vorallem, wenn man das liest.

Ich erstelle die Dateien nicht, leider. Ich entpacke sie und speichere sich temporär zwischen. Z.B. um sie durch eine Anwendung zu öffnen. Somit hab ich erst mal keinen Einfluss auf die Länge. Der Rest wird mir dann aber nicht erpart bleiben. Das Thema Auslagerung uf die Platte ist mir noch gar nicht in den Sinn gekommen :shock:
Noch ne Baustelle.

Thema nur in den RAM laden. Würde ich gerne, das Problem ist aber, dass die Dateien durch externe Anwendungen geöffnet werden sollen (Word, AcrobatReader, IE etc.). Bis jetzt habe ich noch nichts gefunden, was das Laden einer Datei in eine Anwendung ermöglicht, ohne diese als physisches File zur Verfügung zu stellen. Ich denke mal RAM fällt damit aus, so schön es auch sein könnte.

Gruß oki

[isilive]

Ich hab die erste Version mal weitergeschrieben und das ganze läuft sehr gut - mit AssignFile.
Hat ein "Filestream mit fs.WriteBuffer" Vorteile gegenüber "AssignFile und Blockwrite"? (Performance?)
Kann ich bei AssignFile auch ein FlushFileBuffers umsetzen (Dazu brauch ich aber ein Filehandle) ?

Delphi-Quellcode:

  
AssignFile(f, Name3);
Reset(f, 1);
...
Buffer[j] := random(256);           //Buffer mit Random Data füllen
BlockWrite (f, Buffer, Buffersize);

Delphi-Quellcode:

fs := TFileStream.Create(filename, fmOpenReadWrite or fmShareExclusive);
...   buffer := StringofChar(Fillchars[i], BLOCK_SIZE);
...   fs.WriteBuffer(buffer[1], BLOCK_SIZE);
...   FlushFileBuffers(fs.Handle);

[XoRiC]

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

Gruß Xoric

[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.

[p80286]

Da gibt es noch eine klitzekleine Kleinigkeit. Soweit ich weiß fertigt Windows ab Vista(?) auch auf Desktop-Maschinen einen "Snapshot" an. In dem müßte, dann auch die fragliche Datei entfernt werden.

Gruß
K-H

[oki]

Hi all!

Wie zu ersehen ist, sieht das Thema eben genau nicht so trivial aus wie es auf den ersten Blick scheint. Wenn man hier den notwendigen Aufwand betrachtet eine Datei wirklich restlos zu entfernen, dann sollte man dies entweder richtig tun oder klar die Grenzen benennen. Wir haben uns für zweites entschieden. Die Aussage, dass wir die Datei nur in den Speicher entpacken muss hier einfach reichen. Was das Betriebssystem damit macht ist dann eine Sache, die von vielen Faktoren abhängt. Ob hier dann in letzter Konsequenz wirklich sichergestellt werden kann, dass keine lesbaren Kopien bleiben wage ich zu bezweifeln. Erschwerend kommt noch hinzu, dass die Art der zu öffnenden Dateien nicht durch uns festgelegt wird. Es kann also alles mögliche sein. Word war hier nur ein Beispiel. Sicher ein treffliches für den Fall, dass eine beliebige Anwendung hier sein eigenes gegen jegliche Bestrebungen der Datensicherheit tut. Das für jede Anwendung, jede Windowsversion und jedes Filesystem sicherzustellen scheint somit eine Aufgabe zu sein, die man sich reichlich überlegen sollte. Wir haben da abgewunken. Aufwand/Nutzen! Da benenne ich dann die Grenzen und lass das so im Raum stehen.

Klar ist auf jeden Fall, dass das Überschreiben eines Files vor dem Löschen sicher ein Schritt gegen eine nachträgliche Wiederherstellung, bei weitem aber wohl nur die Spitze des Eisberges ist. Mit dieser Maßnahme zu deklarieren, die Datei sei sicher aus dem System entfernt, ist dann aber definitiv nicht korrekt.

Auch wenn ich wie beschrieben das Thema anderweitig für uns befriedigend abgeschlossen habe, Dank an alle für die Diskussion. Man lernt :mrgreen:

Gruß oki