Wurde Datei verändert?

[BrotherLui]

Hallo Leute,

in meinem Programm kann man Einstellungen in einer Textdatei speichern und auch wieder laden.
Wird nun diese Datei nach dem speichern außerhalb mit einem editor verändert bekomme ich Probleme im Programm.

Frage:
Wie kann ich ganz einfach (muss nicht verschlüsselt und auch nicht sicher sein) feststellen ob die Datei verändert wurde und dann nur eine Meldung ausgeben: Datei wurde verändert. Laden nicht möglich!

Er soll dann die Datei gar nicht erst laden.


Danke.
Gruß



P.S.: hab schon einiges über MD5 gelesen aber nicht verstanden wie ich das auf mein Problem anwenden kann.

[Der_Unwissende]

Hi,
also am einfachsten ist es, wenn du dir das Änderungsdatum der Datei anschaust. Du weißt ja wann die letzte Änderung stattgefunden haben darf, gab es danach noch eine...
Genauso sicher gehst du natürlich auch, wenn du einfach einen MD5 (oder anderen) Hash über die Datei errechnest. Hier ist die Wahrscheinlichkeit, dass du einen gleichen Hash bei einer veränderten Datei bekommst nahezu 0 (wirklich nahe an der 0!).

Gruß Der Unwissende

[Andreas L.]

Du musst eine md5-Checksum der Datei generieren lassen, später nochmal und dann die Checksums vergleichen. Leider habe ich selbst noch nichts mit md5 gemacht.

Vielleicht kannst du das brauchen: http://www.fichtner.net/delphi/md5.delphi.phtml

[BrotherLui]

Danke euch.

@ Unwissender: Das mit dem Änderungsdatum ist gar keine schlechte Idee. Muss mal schauen wie ich das auslesen kann.

Zitat:

Zitat von onlinehome

Du musst eine md5-Checksum der Datei generieren lassen

und wo speicher ich die am besten ab? dass ich sie auch nach einem Neustart wieder hab.

Gruß

[EDatabaseError]

Und wo speicherst du das Änderungsdatum wieder ;-)

[3_of_8]

Registry (Ich hör jetzt schon die Buh-rufe)
Eine Datei in deinem Programmordner (checksums.dat oder so ähnlich)
Ein Ordner in deinem Programmordner (checksums zum Beispiel)

Da gibts viele Möglichkeiten.

Edit: MD5 kann gar nicht gehen, ohne die Datei zu laden.

[Mavarik]

Warum speicherst Du die Daten nicht einfach in einem anderen Format?

Dann kann auch keiner mit einem Texteditor die Datei ändern?

Frank

PS.: Klar geht das auch... Aber i.d.R. reicht es!

[BrotherLui]

Zitat:

Warum speicherst Du die Daten nicht einfach in einem anderen Format?

Aber dann muss nur mal jemand aus Spass die Datei mit dem Editor öffnen und verändern und schon stürtzt mein Programm ab.

Ich glaub ich werd das mal versuchen mit der checksum.dat

Dank euch

[3_of_8]

Die lässt sich natürlich auch verändern.

Aber ich formuliere es mal so:
Wenn ein Benutzer will, dass ein Programm abstürzt, dann schafft er das auch.
Du solltest so weit gehen, dass ein Benutzer nicht fahrlässig oder grob fahrlässig ein Programm abstürzen lassen kann, aber bei reinem Vorsatz kannst du auch nichts dagegen tun. ;)

[Mavarik]

Ja klar...

Ich kann auch die Exe in einen Editor laden und verändern.!

:wall:

Frank

[3_of_8]

*räusper*

Genau das wollte ich damit sagen. Es ist also völlig egal, in welchem Format du die Dateien abspeicherst. Ein normaler User, der einfach nur ein funktionierendes Programm will, wird sich garantiert nicht an diesen Dateien vergreifen. Alle anderen kann man vernachlässigen.

[BrotherLui]

Zitat:

Ein normaler User, der einfach nur ein funktionierendes Programm will, wird sich garantiert nicht an diesen Dateien vergreifen.

So rum hab ich mir das auch noch nicht überlegt. Aber irgedwo hast du Recht. :gruebel:

[Der_Unwissende]

Zitat:

Zitat von 3_of_8

Edit: MD5 kann gar nicht gehen, ohne die Datei zu laden.

Na ja, wenn du das Änderungsdatum lesen möchtest, wird auch lesend auf das Dateisystem zugegriffen (gut, nicht direkt die Datei, aber egal). Ich denke es ging hier eigentlich nur darum, dass sein Programm die Datei einliest und dabei irgendwas mit der Datei macht. wenn die jetzt extern verändert wurde, muss die also nicht mehr konsistent sein und das möchte er verhindern. Lesen sollte also kein Problem sein, es darf halt nur nichts mit dem Inhalt gemacht werden (ausser erstmal den Hash berechnen).

Ich würde dir ehrlich gesagt eher zum Hash raten. Du hast ein fertige Unit in dem geposteten Link, der übergibst du die Datei und bekommst einen Hash fester Länge. Das hat echt ein paar Vorteile (beim wieder einlesen). Klar, Datumsangaben haben auch eine feste Länge, die dann aber auf anderen Systemen, z.B. englischem Windows ganz anders aussehen. Ist immer wieder ein Problem mit recht neuen Programmierern, deren Programme zwar in eigenen Tests super laufen, beim Kunden dann aber nicht mehr (es gibt wirklich häufig englische Windows Systemeinstellungen!).

Wie hier schon gesagt wurde, kannst du am leichtesten das ganze als Textdatei abspeichern. Von der Registry würde ich dir abraten, ist hier einfach nicht nötig. Klar, kann man verwenden, aber dann ist die Portierbarkeit (einfach umkopieren) nicht mehr gegeben.
Nimm einfach ein TIniFile. Da kannst du eine Sektion anlegen und in der dann die Zuordnungen vom Dateinamen und deinem String (z.B. dem Hash).
Das ganze hätte dann ungefähr die Form:

Delphi-Quellcode:

uses iniFiles, md5;

...


procedure saveMd5ToFile(const FileName : String);
var iniFile : TIniFile;
    hash : MD5Digest;
begin
  if FileExists(FileName) then
  begin
    iniFile := TIniFile.Create(ExtractFilePath(ParamStr(0)) + INI_FILE_NAME);

    try
      hash := MD5File(FileName);

      iniFile.WriteString(MD5_SECTION, FileName, MD5Print(hash));
    finally
      iniFile.Free;
    end;
  end; // if FileExists(FileName)
end; // procedure saveMd5ToFile(const FileName : String);

function hasChanged(const FileName : String) : Boolean;
var iniFile : TIniFile;
    currentHash : MD5Digest;
    buffer : String;
begin
  result := True;

  if FileExists(FileName) then
  begin
    currentHash := MD5File(FileName);

    iniFile := TIniFile.Create(ExtractFilePath(ParamStr(0)) + INI_FILE_NAME);

    try
      buffer := iniFile.ReadString(MD5_SECTION, FileName, '');

      if trim(buffer) <> '' then
      begin
        result := buffer = MD5Print(currentHash);
      end; // if trim(buffer) <> ''
    finally
      iniFile.Free;
    end;

  end; // if FileExists(FileName)
end; // function hasChanged(const FileName : String);

[NACH roten Kästen]
Es schadet jedenfalls nichts die Informationen abzuspeichern. Wie gesagt, man kann so leicht feststellen, ob jmd. die Datei verändert hat oder nicht. Ob es ein normaler Benutzer macht oder nicht ist ja eine andere Sache.
Ich denke es war hier ja auch nicht als ernster Schutz vor der Manipulation gedacht (er wollte immerhin auch gar nicht erst verschlüsseln). Und wenn man irgendein Hashverfahren nimmt, müsste der Benutzer dann auch wissen welches genau verwendet wurde, raten kann auch dort schnell zu einem falschen Hash führen (gut, kann man natürlich disassemblieren und auslesen, aber wozu die Mühe?!)
[/NACH roten Kästen]

[BrotherLui]

Super so etwas hab ich gesucht!
Danke Unwissender auch für den ausführlichen Beitrag. :thumb:

Gruß
wallerking

[3_of_8]

Ich will ja nichts sagen, aber ich tus trotzdem mal:
Eine ähnliche Lösung hätte ich dir auch bieten können, aber dann sag bitte nicht "Laden nicht möglich!"

[jfheins]

Es gibt nur 2 Fehler soweit ich das sehe:

1. (kleiner Fehler)

Delphi-Quellcode:

if FileExists(FileName) then 
  begin 
    iniFile := TIniFile.Create(ExtractFilePath(ParamStr(0)) + INI_FILE_NAME);

FileName bringt ja quasi nix - es wird immer auf die inifile im Programmverzeichnis zurückgegriffen ...

2. (größerer Fehler)

Beim speichern wird über die gesamte Datei gehasht, und dann in der Datei gespeichert. Beim Laden wird wieder über die gesamte Datei - jetzt inkl. Hash - gehasht und mit dem alten verglichen. Glaubst du, dass die beiden jemals gleich sein werden?

Alles klar? ;)

[Der_Unwissende]

Zitat:

Zitat von 3_of_8

Ich will ja nichts sagen, aber ich tus trotzdem mal:
Eine ähnliche Lösung hätte ich dir auch bieten können, aber dann sag bitte nicht "Laden nicht möglich!"

Hey, ist doch hier kein Contest oder so. Ich meine es zweifelt doch keiner an deiner Kenntnis! Sicherlich hätten du und andere sogar eine schönere Lösung hinbekommen, aber ich habe jetzt einfach mal in die Beiträge von BrotherLui reininterpretiert, dass er da noch gar keine (sehr geringe) Kenntnis hat und von daher den Code gepostet. Also ganz entspannt nochmal lesen, was er sagte und dann siehst du, dass er sicherlich auch aus deinen Tipps eine Menge gelernt hat! (z.B. über die Möglichkeiten eine Datei zu verändern)

Gruß Der Unwissende

Zitat:

Zitat von jfheins

Es gibt nur 2 Fehler soweit ich das sehe:

1. (kleiner Fehler)

Delphi-Quellcode:

if FileExists(FileName) then 
  begin 
    iniFile := TIniFile.Create(ExtractFilePath(ParamStr(0)) + INI_FILE_NAME);

FileName bringt ja quasi nix - es wird immer auf die inifile im Programmverzeichnis zurückgegriffen ...

INI_FILE_NAME soll natürlich eine Konstante sein, die den Namen der Ini-Datei enthält! [EDIT]Und FileName enthält den Pfad zu der Datei, über die der Hash gebildet wird![/EDIT]

Zitat:

Zitat von jfheins

2. (größerer Fehler)

Beim speichern wird über die gesamte Datei gehasht, und dann in der Datei gespeichert. Beim Laden wird wieder über die gesamte Datei - jetzt inkl. Hash - gehasht und mit dem alten verglichen. Glaubst du, dass die beiden jemals gleich sein werden?

Alles klar? ;)

Der Hash einer Datei (nicht der Ini!) wird in einer Ini abgelegt. Das heißt du bildest den Hash über die Datei Blubb.txt und speicherst den Hash in deiner Ini. Hoffe das wurde von anderen richtig verstanden.

[jfheins]

Oh :oops: das habe ich wohl falsch verstanden - ich dachte, er wollte die Info in derselben Datei haben, wie das abgespeicherte ...

Naja ... ist ja noch nachtschlafende Zeit ... :stupid:

[Christian Seehase]

Moin Zusammen,

Zitat:

Zitat von 3_of_8

Ein normaler User, der einfach nur ein funktionierendes Programm will, wird sich garantiert nicht an diesen Dateien vergreifen. Alle anderen kann man vernachlässigen.

Das sehe ich anders.
Genau die die das nicht wollen würden den Fehler, dass ein Programm bei ungültigen Daten abstürzt dazu benutzen zu versuchen das System zu korrumpieren.
Die ganzen Angriffe die auf Buffer-Overflow und ähnlichem basieren nutzen genau so ein Verhalten eines Programmes aus.

Besser wäre es die Datei auf Gültigkeit zu überprüfen, und erst dann zu verarbeiten, wenn die Daten OK sind.

[3_of_8]

Zitat:

Zitat von Der_Unwissende

Zitat:

Zitat von 3_of_8

Ich will ja nichts sagen, aber ich tus trotzdem mal:
Eine ähnliche Lösung hätte ich dir auch bieten können, aber dann sag bitte nicht "Laden nicht möglich!"

Hey, ist doch hier kein Contest oder so.

Hab ich auch nie behauptet. Ich wollte damit sagen, dass es schwer ist, jemandem zu helfen, wenn er falsche Angaben macht, also sagt "Laden nicht möglich", im Endeffekt das doch möglich ist.

[Der_Unwissende]

Zitat:

Zitat von BrotherLui

Frage:
Wie kann ich ganz einfach (muss nicht verschlüsselt und auch nicht sicher sein) feststellen ob die Datei verändert wurde und dann nur eine Meldung ausgeben: Datei wurde verändert. Laden nicht möglich!

Er soll dann die Datei gar nicht erst laden.

Na ja, ist hier doch stark Interpretationssache, er sagt doch es soll erst geprüft werden ob die Datei verändert wurde und wenn das festgestellt wurde, kommt die Fehlermeldung: "Laden nicht möglich". Die nächste Zeile würde ich jetzt also im Kontext dieser Meldung sehen und sagen, dass seine Bearbeitung/Programm die Datei nun nicht mehr öffnet um irgendwas mit der gespeicherten Information zu machen. Das Prüfen ob die Datei geändert wurde ist ja allein stehend unabhängig, es könnte ja auch eine andere Exe angewurfen werden, die das Ergebnis über eine Windowsbotschaft weiterreicht, dann hat sein Programm die Datei nie geladen...

[3_of_8]

Argh, ich hab mich verlesen. Entschuldigung an alle.