INI-Dateien schützen

[PierreB]

Guten Morgen,

folgendes Problem: Ich arbeite in meinem Programm mit ini-Dateien, in denen die Daten abgespeichert werden. Jetzt möchte ich aber das diese Dateien (außer mit meinem Programm) von außen nicht bearbeitbar sind. Ich kann zwar die Dateiattribute der Ini's auf "Schreibgeschützt" oder "Versteckt" setzen, der User könnte diese Einstellungen aber auch einfach wieder zurücksetzen und wie wild in den Dateien herumschreiben. Was jemand eine gute Möglichkeit wie ich die ini's schützen kann ?

Vielen Dank schonmal,

[Totti]

a) Irgendwo verstecken
b) Im Hintergrund ein Programm offen lassen, das exklusive Lese- und SChreibrechte an der Datei besitzt

[Jelly]

oder

c) Die Datei verschlüsseln.

[DevilsCamp]

D)
Komprimiere die Datei mit irgendeinen Komprimier-Algorithmus (pkzip, gzip, rar, bzip2, o.ä.) in einen Stream, ändere den Header und speichere das dann als Datei.


So liegt das ganze dann auf der Platte.
Du solltest das ganze allerdings immer nur dann wieder dekomprimieren solange du die Daten brauchst (zum lesen, schreiben) und nicht während der gesamten Laufzeit des Programms (sonst kann man ja dann auch wieder in der ini-Datei navigieren...)



Soll das ganze dann noch sicherer sein, dann kannst du ja noch einen Verschlüsselungsalgorithmus verwenden...

[PierreB]

Zitat:

Zitat von Totti

a) Irgendwo verstecken
b) Im Hintergrund ein Programm offen lassen, das exklusive Lese- und SChreibrechte an der Datei besitzt

Moin,

a) Dachte ich auch schon, eigentlich wollte ich aber keine Systemordner o.a. zumüllen...
b) Können andere Programme dann nicht trotzdem noch in die Dateien schreiben ? :gruebel:

@Jelly: Hm, verschlüsseln, naja, hört sich gut an, müsste ja eigentlich mittels XOR reichen oder ?

[Daniel B]

benutze sie als .dat, dann kann man sie nicht einsehen

[PierreB]

Zitat:

Zitat von Daniel B

benutze sie als .dat, dann kann man sie nicht einsehen

Hm ? Mit UltraEdit kann ich auch diese öffnen und verändern !?

[Daniel B]

Mit irgend einem Tool kann man auch jede Datei öffnen. Warum verbietest Du dem Menschen das atmen? Wenn einer rumspielt und sich damit etwas beschädigt, isser selber schuld. Das liegt nicht in deiner Macht.

[Jelly]

Zitat:

Zitat von PierreB

Hm, verschlüsseln, naja, hört sich gut an, müsste ja eigentlich mittels XOR reichen oder ?

Das musst Du wissen. Wenn du deine Online TAN Liste und PIN damit verwaltest, würd ich mir was Besseres einfallen lassen.

[PierreB]

Zitat:

Zitat von Daniel B

Mit irgend einem Tool kann man auch jede Datei öffnen. Warum verbietest Du dem Menschen das atmen? Wenn einer rumspielt und sich damit etwas beschädigt, isser selber schuld. Das liegt nicht in deiner Macht.

Naja da hast du schon recht, aber es geht unter anderem darum das man nicht die Optionen pder Registrierungsinformationen manipulieren kann.

Aber ich werde das mit dem verschlüsseln mal probieren, vielen Dank für eure Antworten. ;)

@Jelly: Nein wie gesagt, nur normale Optionen und Daten wie Name, Adresse, etc..

[Elvis]

Och menno...
Schaut mal hier: Mit dem RC-Stromdekorierer INIs verschlüsseln
Das war doch nun wirklich easy zu finden...

btw: der Stream decorator ließe sich prima mit einer dpCollection kombinieren um den Übersetzungs code INI <-> Objekte loszuwerden. ;)

[runger]

Hallo Daniel

Zitat:

Mit irgend einem Tool kann man auch jede Datei öffnen. Warum verbietest Du dem Menschen das atmen? Wenn einer rumspielt und sich damit etwas beschädigt, isser selber schuld. Das liegt nicht in deiner Macht.

Wir haben hier in Deutschland Produkthaftung. Wie willst du hnterher jemandem nachweisen, dass er an der Datei gespielt hat und nicht dein Programm einen Fehler verursacht.

Wir haben z.B. alle unsere Sprachinformationen in INI's.
Stell dir vor an einem Butoon, der einen Hochspannungsschalter schalten soll steht
statt Hochspannungsschalter ein --> Erdungsschalter ein.
Ich gebe zu, dass das weit hergeholt ist.

Rainer

[bigg]

Hi,

ich würde die Daten in einer ZIP mit Passwort-Schutz verpacken.
Die Verschlüsselung ergäbe sich dann aus dem Passwort.

Der Benutzer könnte so auch an die Daten herankommen, sofern
er einen Packer und das jeweilige Passwort besitzt.

Das ODT-Format funktioniert übrigens genauso.

[faux]

Zitat:

Zitat von Totti

a) Irgendwo verstecken

Das finde ich nicht gut. Wie soll der Benutzer dann seine Daten sichern?

[mumu]

Zitat:

Wir haben hier in Deutschland Produkthaftung. Wie willst du hnterher jemandem nachweisen, dass er an der Datei gespielt hat und nicht dein Programm einen Fehler verursacht.

muss der Kunde nicht beweisen, dass dein Programm einen Fehler verursacht hat und nicht umgedreht.

[Totti]

Naja ... man könnte ja in das Programm ne Sicherungsprozedur einbauen ;)

Und ich ging eigtl. davon aus, dass wenn dieses Hintergrundprogramm exklusiven Lese- und Schreibzugriff hat, dass auch andere Programm den net umgehen können. Wenn dem nicht so ist, bitte ich das zu entschuldigen ... und dann müsste ich mla eben lachen, wäre ja irgendwie blöd :D

[angos]

Zitat:

Zitat von mumu

Zitat:

Wir haben hier in Deutschland Produkthaftung. Wie willst du hnterher jemandem nachweisen, dass er an der Datei gespielt hat und nicht dein Programm einen Fehler verursacht.

muss der Kunde nicht beweisen, dass dein Programm einen Fehler verursacht hat und nicht umgedreht.

Jepp, der Kunde muss beweisen, dass das Programm Mist macht.

[PierreB]

Zitat:

Zitat von bigg

ich würde die Daten in einer ZIP mit Passwort-Schutz verpacken.
Die Verschlüsselung ergäbe sich dann aus dem Passwort.

Hallo bigg,

ja, aber dann müsste mein Programm das ZIP ja auch erst entpacken um die Daten lesen können. Und wenn diese entpackt werden müssen sie irgendwo gespeichert werden, also könnte man wieder auf sie zugreifen und verändern. Ich habe es mittlerweile ganz simpel mit XOR gemacht, scheint für meine Zwecke zu reichen. Vielen Dank für die Antworten. ;)

[DevilsCamp]

Zitat:

Zitat von PierreB

Zitat:

Zitat von bigg

ich würde die Daten in einer ZIP mit Passwort-Schutz verpacken.
Die Verschlüsselung ergäbe sich dann aus dem Passwort.

Hallo bigg,

ja, aber dann müsste mein Programm das ZIP ja auch erst entpacken um die Daten lesen können. Und wenn diese entpackt werden müssen sie irgendwo gespeichert werden, also könnte man wieder auf sie zugreifen und verändern. Ich habe es mittlerweile ganz simpel mit XOR gemacht, scheint für meine Zwecke zu reichen. Vielen Dank für die Antworten. ;)

Leider gibt es keine INI-File-Klasse, die ihre Daten komplett im Speicher verwaltet. Es müsste also eine TMemIniFile sein, ohne den Zwang Create mit einem Dateinamen als Parameter aufrufen zu müssen (entsprechend müsste natürlich die UpdateFile-Methode abgeändert werden).

Dann wären solche Operationen um ein Vielfaches einfacher...


Vielleicht schreibe ich ja mal bei Gelegenheit so eine Klasse. :coder2:

[bigg]

Hi,

Zitat:

ja, aber dann müsste mein Programm das ZIP ja auch erst entpacken um die Daten lesen können. Und wenn diese entpackt werden müssen sie irgendwo gespeichert werden, also könnte man wieder auf sie zugreifen und verändern. Ich habe es mittlerweile ganz simpel mit XOR gemacht, scheint für meine Zwecke zu reichen. Vielen Dank für die Antworten.

Wenn dir die XOR-Kodierung ausreicht, okay.
Deine Lösung ist ja nicht verkehrt. :wink:

Nochmal was zum ZIP:
Entpacken ja, aber nicht zwingend auf der Platte :wink:.
Man kann die Daten im Speicher entpacken, muss sie also nicht zwangsläufig
auf der Festplatte ablegen.
(ähnlich wie bei komprimierten Bildern, du weist was ich meine :stupid: )

mfg :mrgreen:

[DevilsCamp]

Um aber mit einer INI-Klasse (TIniFile oder TMemIniFile) auf die Daten zugreifen zu können, muss eine Datei existieren.

Oder gibt es noch eine andere Klasse?

[PierreB]

Zitat:

Zitat von bigg

Nochmal was zum ZIP:
Entpacken ja, aber nicht zwingend auf der Platte :wink:.
Man kann die Daten im Speicher entpacken, muss sie also nicht zwangsläufig
auf der Festplatte ablegen.
(ähnlich wie bei komprimierten Bildern, du weist was ich meine :stupid: )

Ja, wie gesagt, XOR müsste eigentlich reichen, ich habe ja nur einen kleinen schnell realisierbaren Schutz gesucht, wenn trotzdem jemand meint er müsse in den Dateien rumpfuschen ist es mir letztendlich auch egal. Trotzdem danke. ;)

[Elvis]

Ich verweise mal nochmaaaal ( :wall: ) auf den Beitrag, einfacher und sicherer werdet ihr's so schnell nicht kriegen...

[Binärbaum]

Zitat:

Zitat von PierreB

Ja, wie gesagt, XOR müsste eigentlich reichen, ich habe ja nur einen kleinen schnell realisierbaren Schutz gesucht, wenn trotzdem jemand meint er müsse in den Dateien rumpfuschen ist es mir letztendlich auch egal. Trotzdem danke. ;)

Immerhin besteht doch die Möglichkeit, von der INI-Datei einen Hash-Wert (z.B. MD5) zu berechnen. Den speichert man dann z.B. in der Registry und kann beim nächsten Start des Programmes den Hash-Wert in der Registry mit dem aktuellen Hash-Wert der Datei vergleichen. Damit hat man zwar keinen Schutz vor Manipulation der Datei, aber man kann zumindest feststellen, ob in der Datei "rumgepfuscht" wurde und entsprechend darauf reagieren. ;)

MfG
Binärbaum

[bigg]

Es geht auch noch einfacher, überhaupt nicht verschlüsseln :mrgreen:.
Wozu eigentlich?

Wenn man davon ausgeht, das sich alle 2 Jahre die Rechenleistung eines Computer-Systems verdoppelt,
könnte man nahezu jede Codierung in kürzester Zeit knacken.
Und wenn man eh nichts zu verbergen hat, würde ich mir solche Sachen gänzlich sparen.

Zitat:

Zitat von Rechenleistung

2005. 3 GHz
2007. 6 GHz
2009. 12 GHz
2011. 24 GHz
2013. 48 GHz
2015. 96 GHz
2017. 192 GHz
2019. 384 GHz
2021. 768 GHz
2023. 1536 GHz
2025. 3072 GHz
2027. 6144 GHz

mfg :mrgreen:

[Tubos]

bigg, wie kommst du auf solch exorbitant hohen Werte?
Hab das im Excel nachgerechnet, deine Werte können nicht stimmen.

Code:

(jährlich)
2,25
4,5
9
18
36
72
144
288
576
1152
2304
4608
9216
18432
36864

Ganz abgesehen davon ist Rechenleistung ungleich Taktfrequenz. Möglicherweise wird die Taktfrequenz nicht mehr so stark steigen (wegen Überhitzung etc...), die Rechenleistung sich aber weiterhin alle xx (waren es 15?) Monate verdoppeln.

Daraus folgt dass die heutigen Verschlüsselungen auch in der Zukunft noch sicher sein werden.

[Binärbaum]

Zitat:

Zitat von bigg

Es geht auch noch einfacher, überhaupt nicht verschlüsseln :mrgreen:.
Wozu eigentlich?

Wenn man davon ausgeht, das sich alle 2 Jahre die Rechenleistung eines Computer-Systems verdoppelt,
könnte man nahezu jede Codierung in kürzester Zeit knacken.
Und wenn man eh nichts zu verbergen hat, würde ich mir solche Sachen gänzlich sparen.

Zitat:

Zitat von Rechenleistung

2005. 2,25 GHz
2007. 5,0625 GHz
2009. 25,62890625 GHz
2011. 656,840835571289 GHz
2013. 431439,883273989 GHz
2015. 186140372879,473 GHz

Also entweder hast du eine völlig andere Definition von Verdopplung als der Normalbürger, oder aber dein Rechner war so schnell, dass er aus Versehen schon etwas mehr berechnet hat.
(War ja auch gleich verdächtig, dass jemand zweimal den :mrgreen: Smilie innerhalb eines Beitrags benutzt.) ;)

[bigg]

Ich hoffe ihr seit nicht gleich vom Stuhl gefallen. :mrgreen:
Die geposte Tabelle war exponentiell, sry. :stupid:

ps: mr. green mit seinem grün grünen :wall: mützchen ist aber auch genial :wink:

[Der_Unwissende]

Zitat:

Zitat von bigg

Ich hoffe ihr seit nicht gleich vom Stuhl gefallen. :mrgreen:

Nicht bei der Rechnung, aber wenn ihr bedenkt, dass sich die Komplexität des Chips verdoppelt passiert das schon eher. Da kann man ausrechnen (hat man schon gemacht), dass so 2050 ein Chip dichter sein müsste als ein Schwarzes Loch und beim einschalten heißer wird als die Sonne... (wenn Moore recht behält).

Zitat:

Zitat von PierreB

Ja, wie gesagt, XOR müsste eigentlich reichen

Eigentlich reichen?! Wie eigentlich reichen, XOR ist absolut sicher, entgegen der Meinung die hier vor zu herrschen scheint. Schaut euch einfach mal Hagens Beiträge zur Verschlüsselung und dort insbesondere zu XOR an.
Kurzes Fazit: XOR bedeutet 50% Wahrscheinlichkeit für 0 und 50% für 1 / bit -> Jede Lösung ist gleich wahrscheinlich -> XOR ist nur durch durchrechnen aller Möglichkeiten lösbar. Damit hängt die Rechenzeit nur noch von der Länge der verschlüsselten Daten ab (sollten dann natürlich groß genug sein). Etwas weit hergeholte Ansätze behaupten ein Quantencomputer (eine NTM) berechnet alle Ergebnisse auf einmal (also in THETA(n)) in kurzer Zeit (relativ zu konventionellen Rechnern). Ok, nun hat man 2^{n} Lösungen, die alle immer noch gleich wahrscheinlich sind -> Suchen der Richtigen dauert mindestens 2^{n} (wenn man sie erkennen kann).

Also ist ein müsste eigentlich reichen nett gesagt, aber wenn XOR mal nicht reicht hast du ein (IMHO) unlösbares Problem

Gruß Der Unwissende

edit: Zu blöd zum zitieren :mrgreen: Sorry @bigg

[Tubos]

Zitat:

Da kann man ausrechnen (hat man schon gemacht), dass so 2050 ein Chip dichter sein müsste als ein Schwarzes Loch und beim einschalten heißer wird als die Sonne... (wenn Moore recht behält).

Wenn du "dichter als ein Schwarzes Loch" sagst, dann verwechselst du die Dichte der Leitungsbahnen auf dem Chip mit der physikalischen Dichte.

[bigg]

@Der_Unwissende: Korrigier doch bitte mal deinen Beitrag das mit dem xor habe ich nicht gesagt ;-)

Zitat:

Zitat von Tubos

Ganz abgesehen davon ist Rechenleistung ungleich Taktfrequenz. Möglicherweise wird die Taktfrequenz nicht mehr so stark steigen (wegen Überhitzung etc...), die Rechenleistung sich aber weiterhin alle xx (waren es 15?) Monate verdoppeln.

Daraus folgt dass die heutigen Verschlüsselungen auch in der Zukunft noch sicher sein werden.

So wie es momentan ausschaut werden immer mehr Kerne in einem Prozessor integriert.
Daher ist meine These gar nicht soweit hergeholt.

IBM macht es mit der XBox 360 (3 Kerne mit jeweils 3,2 GHz),
AMD bald mit 4 Kernen und auch Sony entwickelt fließig daran (mit 10 Kernen).

Vielleicht geht uns ja bald das Silizium aus. *hust* :mrgreen:

[stefangeorg]

Servus,

hatte auch das gleiche Problem.
Hab es auf folgende Weise gelöst, vielleicht nicht die eleganteste,
aber funktioniert und wer dann noch drinne rumpfuscht ist selber schuld:

Habe ein TMemIniFile, welches erzeugt und gecleart wird.
Danach wird eine codierte Datei (meine Ini) in einen Stream geladen,
dieser decodiert und an eine StringList übergeben.
Dann weise ich dem TMemIniFile per SetStrings die StringList zu.

Speichern genau umgekehrt.

mfg

Georg Härting

[Hansa]

Bigg (u.a.) hat mal wieder dafür gesorgt, daß das Thema überhaupt nichts mehr mit der Frage zu tun hat. 8)

Und die war so :

Zitat:

Zitat von PierreB

..Ich arbeite in meinem Programm mit ini-Dateien, in denen die Daten abgespeichert werden. Jetzt möchte ich aber das diese Dateien (außer mit meinem Programm) von außen nicht bearbeitbar sind...

Keiner geht darauf ein, also : was sind "die Daten" Sind damit Programmeinstellungen gemeint, oder "echte" Daten, die sich laufend ändern ? Ich habe das dumpfe Gefühl, daß das ganze Konzept nicht stimmt. 8)

[Klaus01]

Es wäre auch möglich einen Hashwert(Footprint) der ini Datei zu ermitteln
und diesen abzuspeichern. Wird die ini Datei nun verändert, ändert sich auch
der Hashwert/Footprint der Datei. Man kann dan zumindest erkennen das die Datei
verändert wurde.

Grüße
Klaus

[PierreB]

Zitat:

Zitat von Hansa

Zitat:

Zitat von PierreB

..Ich arbeite in meinem Programm mit ini-Dateien, in denen die Daten abgespeichert werden. Jetzt möchte ich aber das diese Dateien (außer mit meinem Programm) von außen nicht bearbeitbar sind...

Keiner geht darauf ein, also : was sind "die Daten" Sind damit Programmeinstellungen gemeint, oder "echte" Daten, die sich laufend ändern ? Ich habe das dumpfe Gefühl, daß das ganze Konzept nicht stimmt. 8)

Zum einen handelt es sich wirklich um Programmeinstellungen (z.B. Symbolleisten ausbleden, andererseits aber auch Daten die sich fortwährend ändern können.

[diComm]

Aber wenn du die Daten "nur" verschlüsselst, hindert das ja keinen daran, die Daten zu ändern, oder?

Ich denke, wenn du auch normale Daten darin hast wäre vielleicht eine Filebasirte Datenbank wie z.B. AbsoluteDB oder SQLite eine Lösung für dich. diese Dateien sind dann auch nicht so einfach zu ändern ohne entsprechende Tools.

[PierreB]

Zitat:

Aber wenn du die Daten "nur" verschlüsselst, hindert das ja keinen daran, die Daten zu ändern, oder?

Stimmt, aber ich glaube das es den normalen Entanwender in seinem Büro schon abschrecken wird, wenn er nur Zahlen- und Buchstabenmüll sieht. Und dann wird er nicht darin rumschreiben, weil es ja nichts bringen würde.

[sh17]

Ich sponsor mal meine IniFile-Klasse

[PierreB]

Zitat:

Zitat von sh17

Ich sponsor mal meine IniFile-Klasse

Danke, ich guck mir das gleich mal an. ;)