Daten Shredder Sourcecode

[DelphiUser123]

Hallo liebe Delphi Community, ich komme mal wieder hobbymäßig zum Programmieren...
Folgenden Sourcecode habe ich gefunden auf delphitricks.com:

Category: Files
Title: Shred and Delete files without any trace
Date added: 15.03.2006
Hits: 12211

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) + '$temp.tmp'); 
end; 

procedure ShredderAndDeleteFile(const FileName: string); 
var 
  newname: string; 
begin 
  newname := ExtractFilepath(FileName) + '$temp.tmp'; 
  if not RenameFile(FileName, newname) then 
    raise 
    Exception.CreateFmt('Can''t rename %s', [FileName]); 
  ShredderFile(newname); 
  DeleteFile(newname); 
end;

Beim nachvollziehen fiel mir auf: die Variable arr wird definiert aber nicht benutzt. Also lasse ich diese weg!?
CounttoWrite ist bei 34, FillBuffer[j] hat aber nur 6 Elemente zum Ansteuern... Was passiert also in 29 Schleifendurchgängen- nichts?

Bei DeleteFile im ersten Block soll eine sog. $temp.tmp Datei gelöscht werden. Gibt es die überhaupt?

Ist es normal dass in veröffentlichtem Code so viele eigenartige Fehler stecken? Oder sehe ich etwas falsch?

Vielen Dank für Antworten.

[blawen]

Zitat:

Zitat von DelphiUser123 (Beitrag 1360257)

Beim nachvollziehen fiel mir auf: die Variable arr wird definiert aber nicht benutzt. Also lasse ich diese weg!?

Ja.

Zitat:

CounttoWrite ist bei 34, FillBuffer[j] hat aber nur 6 Elemente zum Ansteuern... Was passiert also in 29 Schleifendurchgängen- nichts?

Das eine hat mit im Normalfall mit dem anderen nichts zu tun. Ein Shredder überschreibt die selbe Stelle mehrfach, um die einzelnen Bit's nicht mehr rekonstruieren zu können. Allerdings wird es hier wie Du festgestellt hast knallen.

Zitat:

Bei DeleteFile im ersten Block soll eine sog. $temp.tmp Datei gelöscht werden. Gibt es die überhaupt?

Diese wird doch hier erzeugt

Delphi-Quellcode:

if not RenameFile(FileName, newname)

Insgesamt nicht unbedingt ein mustergültiges Beispiel.

[markus5766h]

Zitat:

Zitat von DelphiUser123 (Beitrag 1360257)

... Beim nachvollziehen fiel mir auf: die Variable arr wird definiert aber nicht benutzt. Also lasse ich diese weg!?

ist scheinbar überflüssig . . .

Zitat:

Zitat von DelphiUser123 (Beitrag 1360257)

... CounttoWrite ist bei 34, FillBuffer[j] hat aber nur 6 Elemente zum Ansteuern... Was passiert also in 29 Schleifendurchgängen- nichts?

bei j = 6 müsste es eigentlich knallen : BlockWrite(f, FillBuffer[j], Buffer);
denn FillBuffer ist ja nur als Array[0..5] definiert

Zitat:

Zitat von DelphiUser123 (Beitrag 1360257)

... Bei DeleteFile im ersten Block soll eine sog. $temp.tmp Datei gelöscht werden. Gibt es die überhaupt?

... ist etwas wirr, ebenso der Aufruf von ShredderFile(newname);
wenn schon dann :

Code:

 if not RenameFile(FileName, newname) 
  then raise Exception ...
    else ShredderFile ...

[markus5766h]

Zitat:

Zitat von blawen (Beitrag 1360261)

Diese wird doch hier erzeugt

Delphi-Quellcode:

if not RenameFile(FileName, newname)

vielleicht . . .
das ShredderFile(newname) wird aber immer aufgerufen, auch nach raise Exception . . . - oder liege ich da falsch ?

[blawen]

Zitat:

Zitat von markus5766h (Beitrag 1360264)

Zitat:

Zitat von blawen (Beitrag 1360261)

Diese wird doch hier erzeugt

Delphi-Quellcode:

if not RenameFile(FileName, newname)

vielleicht . . .
das ShredderFile(newname) wird aber immer aufgerufen, auch nach raise Exception . . . - oder liege ich da falsch ?

Ebenso das DeleteFile.

Grundsätzlich fehlt mir hier ein

Code:

if...
  then..
  else..

Block und da der zusammengehörige Code mehr als eine Zeile umfassr ein

Code:

begin...end

[himitsu]

Erstmal schreibst du in den WindowsFileCache und später dann auch noch in den Cache der Schnittstelle und des Datenträgers,
also auf dem Datenträger kommt nur ein Bruchteil dessen an, was du da schreibst. (unter der Annahme deine Schleife würde funktionieren und der Schreibcache wäre deaktiviert und würde sich schell genug leeren)

Außerdem ist deine Schleife falsch, denn du schreibst alle "Durchläufe" hintereinander und nicht "übereinander".

Und wenn es um Datenträger ala SSD, USB-Stick und SD-Karte geht, dann kannst du sowas sowieso vergessen, weil du niemals die eigentlischen physischen Speicherbereiche erwischst, wo die Daten drin standen und Mehrfachschreiben ist da auch sinnlos.


[edit]
Du = der gefundene Code


[add]
Noch besser, Buffer ist 1024 Byte lang, aber FileBuffer nur 6*SizeOf(Integer), also zusätzlich zu dem Offset, gibt es hier immer einen Bufferoverflow.

FileFuffer ist Integer, aber wird nur mit Bytes befüllt, also würde nur jedes vierte Byte wie gewünnscht überschrieben und der Resst immer wieder mit 0.

[p80286]

Wenn du Deine Daten nicht mehr auf Disketten (oder Festplatten die inzwischen ca. 20Jahre alt sind) speicherst, ist der praktische Nutzen dieses Programms gleich null. Wenn du sichere Löschung willst, dann greif zu einem 500 Hammer.
Ansonsten ist das Beispiel ein schönes für "so sollte man es nicht machen".
Neben der etwas seltsamen Handhabung verschiedener Typen, hat das Programm ein wichtiges Manko, es verläßt sich darauf, das die Datei xyz.xxx immer an der gleichen Stelle auf dem Datenträger ist. Wer hierfür nicht die FAT und andere Organisationsstrukturen auf dem Datenträger bemüht, glaubt auch, daß Zitronenfalter Zitronen falten.

Gruß
K-H

[DelphiUser123]

Danke für die vielen Antworten.
Jetzt mal abgesehen vom Hammer...
es gibt doch einige kleine Tools, die sicheres Löschen versprechen.
Wo/ in welche Themen muss ich mich einarbeiten, um so etwas programmieren zu können?

[DelphiUser123]

Nochmals Danke für die Korrekturen am vorgestellten Code.

Himitsu und p80286 haben grundlegende Kritik geäußert.

Es gibt da ein Programm namens "Sicher Löschen", eine Version vom Oktober 2016.
Man kann es downloaden bei Chip.de, 166,3 kB (!)

Chip.de sagt:
"CHIP Fazit zu Sicher Löschen
Sensible Daten können Sie mit der Sicher Löschen Freeware endgültig löschen. Das kleine, kostenlose Tool ist portabel, muss also nicht installiert werden. Unser Download-Paket beinhaltet sowohl die 32-, als auch die 64Bit-Version.
Christian Schwalb | CHIP Software-Redaktion"

Es kann doch nicht so schwer sein, die richtigen Datenblöcke zu erwischen und zu überschreiben.
Es viel das Wort FAT, welche Stichworte sind noch relevant?

Wie komme ich weiter, wo muss ich was nachlesen? Gibt es irgendwo Tutorials/ gute Bücher zum Thema?
Ist Delphi überhaupt geeignet oder wäre eine andere Programmiersprache ratsam?

[CCRDude]

Zitat:

Zitat von DelphiUser123 (Beitrag 1361426)

Es kann doch nicht so schwer sein, die richtigen Datenblöcke zu erwischen und zu überschreiben.
Es viel das Wort FAT, welche Stichworte sind noch relevant?

Wie komme ich weiter, wo muss ich was nachlesen? Gibt es irgendwo Tutorials/ gute Bücher zum Thema?
Ist Delphi überhaupt geeignet oder wäre eine andere Programmiersprache ratsam?

Wieso kann das nicht so schwer sein?

Ein Stichwort bzgl. SSD, SD, USB etc. wäre Wear leveling. Ich behaupte, bei diesen Medien solltest Du Dein "nicht so schwer" in "unmöglich" ändern.

Auch bei HDDs gibt es jede Menge erschwerende Techniken, z.B. Volume Shadow Copies, aber auch schon allgemein eben, dass es keine Garantie gibt, dass eine geänderte Datei an die gleichen Stellen zurückgeschrieben wird. Selbst wenn Du da die Sektoren findest und hard überschreibst, könnten Altlasten von vorigen Schreibaktionen anderswo auf der Platte rumgeistern.

"Sicheres Löschen" klappt sehr oberflächlich natürlich trotzdem. Aber um was vor Tante Erna zu verstecken ist schon ein Leeren des Papierkorbes ausreichend, sobald man aber anfängt, gute Entlösch-Tools blockieren zu wollen, wird's exorbitant speziell und schwer.