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.

[p80286]

das wesentliche hat CCRDude bereits geschrieben, darum nur eine kleine Anmerkung. Wenn du "leere Bereiche" nullst, werden logisch nicht genutzte Cluster(die sich u.U. aus mehreren Sektoren [512] zusammen setzen) überschrieben. Abgesehen davon, daß moderne Festplatten die 512-Sektoren teilweise simulieren (sind die 512er auch aufeinander folgend?), da das Betriebssystem die Dateien in Clustern verwaltet (1..n Sektoren) und die Verwaltungseinheit des Betriebssystems das Cluster ist. kann es also sein, daß Bereiche auf der Festplatte als belegt gekennzeichnet sind, die in Wahrheit nicht genutzt werden.
Ein weiteres Stichwort was Du suchst ist NTFS. Hierbei sollen kleine Dateien (<2k ?) nicht in den Datenbereich der Festplatte geschrieben werden, sondern gleich innerhalb des NTFS-Verwaltungsbereiches gespeichert werden. in diesem Falle gibt es also keinen Datenbereich den Du überschreiben könntest.

ggf. könntest Du hier noch ein paar interessante Informationen erhalten.

Sagt der Begriff Schlangenöl irgendetwas? :wink:

Gruß
K-H

[himitsu]

Zitat:

sektoren finden

Kleine Dateien werden bei NTFS garnicht in eigene Sektoren geschrieben, sondern landen direkt in der MFT, als "Attribut" am Datei-Index.

Alleine schon eine Defragmentierung kopiert Daten und diese Kopieen vollständig zu löschen ist bissl aufwändig.
* Datei überschreiben/löschen
* alle freien Sektoren überschreiben
** Wear Leveling, Fehlerbehandlungen für defekte Sektoren und Co. verhindern, dass du an alle Sektoren ran kommst
* bei allen anderen Dateien die "ungenutzen" Teile im letzten Sektor überschreiben
* dann das Selbe auch noch bei Sparse-Files und NTFS-komprimierten Dateien, welches zwischendrin mehrere nur teilweise genutze Sektoren haben
* zum Schluß auch noch alle "freien" Einträge in der MFT und zwischen den Attributen aller Indize
* ...
* und wer weiß was es sonst noch alles gibt oder bald gibt (z.B. SSD-HDD-Mixlaufwerke, wo eventuell beliebige Sektoren entweder in der SSD oder auf der HDD liegen können)

Aber ganz im Ernst, viele Programme versprechen sonstwas und halten oftmals nichts.
* Dateien sicher löschen (früher ging es mal, so wie geplant, das sogenannte NSA-sichere löschen durch mehrfaches Überschreiben)
* RAM Cleaner
* [GOOGLE]Vollbitverschlüsselung[/GOOGLE]
* ...

Bei heutigen Strukturgrößen der der HDDs reicht einmalüberschreiben eigentlich aus, denn die damaligen Tiefeneffekte gibt es praktisch nicht mehr, bzw. sind nur mit extremen Aufwand, für exorbitant viel Geld in unbegrenzter Dauer und durch zerstörendende Lesemethoden entzifferbar und das auch nur mit einer sehr geringen Wahrscheinlichkeit auf Richtigkeit für einzelne Bits ... bezogen auf eine Datei oder die ganze HDD gegen 0 gehend. (HDD zerlegen und Scheibe in Nanometerschritten abfräsen, die magnetischen Ausrichtungen fast jedes Atoms bestimmen und das dann in paar Supercomputern zu einer virtuellen mehrschichtigen Festplatte zusammensetzen)

[p80286]

Zitat:

* bei allen anderen Dateien die "ungenutzen" Teile im letzten Sektor überschreiben

Und das kann dann auch in die Hose gehen, da es cleverlies gab/gibt, die da das eine oder andere Byte vor dem offiziellen Zugriff verstecken :wall:

Gruß
K-H

[himitsu]

Dann mußt du eben noch 'ne Blacklist einbauen, für die natürlich dir meistens unbekannten Programme/Dateien. :lol: