Updatesystem (Windows)
-
Hello!
Ich mache mir gerade Gedanken über ein Updatesystem. Es soll auch einen gewissen Schutz gegen Cracker haben, zumindest soll es nicht ganz so einfach sein, ein Update zu umgehen.
Zunächst wollte ich die aktuelle Programmversion in der Haupt-.exe als Resource speichern. Allerdings lässt sich das wohl ziemlich leicht manipulieren. Versionsresource auf die aktuelle Version ändern und somit würde kein Update mehr durchgeführt werden.Außerdem kann nicht jede Datei eine Versionsresource beinhalten.
Dann dachte ich an Checksum/Hashwerte. Ist das gebräuchlich? Kann das klappen? Es geht darum, eine Datei eindeutig zu identifizieren, dieser Wert wäre dann also die Version der Datei.
Ich dachte mir das so:
Eine Infodatei am Updateserver listet alle aktuellen Dateien mit deren Checksum/Hashwert (keine Ahnung was am besten ist) auf.
Bei einem Update werden die lokalen Dateien des Clienten mit der Liste am Server synchronisiert.
Dateien, die lokal, aber nicht in der Infodatei gelistet sind, werden gelöscht.
Dateien, die lokal nicht vorhanden sind, aber in der Infodatei gelistet sind, werden heruntergeladen.
Dateien, die lokal eine andere Checksum/Hash haben als in der Infodatei, werden neu heruntergeladen.Somit würde man einfach immer die aktuellen Dateien vom Server bekommen, egal, wenn man mal ein Update auslässt. Es sollte dann nie Probleme geben.
Was meint ihr? Dies ist mein erster Versuch, ich danke euch schon mal für eure Tipps!
MfG
-
Herwig schrieb:
Dateien, die lokal, aber nicht in der Infodatei gelistet sind, werden gelöscht.
Einfach mal Dateien auf dem fremden Rechner loeschen? Ich hoffe Du hast einen guten Anwalt
-
der hack0r kann doch einfach deine funktion die die liste downloadet umbiegen und schon ist dein zwangsupdate fürn p0p0. ich würde einfach solche zwangsupdates gänzlich vermeiden, was bringen die denn, außer den kunden/user zu agitieren? wenn man updaten will, soll man es machen können, aber zwing die leutz doch ned dazu.
-
Ich wuerde ein Button, wo der User selber auf Updates pruefen kann.
Wenn das Programm ich einmaechtig zu einen Server verbindet, kann das Misstrauen ausloesen.
Button klicken, signiertes(!) File herunterladen, die Pruefsummen checken und dann dem User eine Meldung ausgeben.
-
eeeh, wo ist meine Antwort hin... hab doch gerade geschrieben. Nagut, dann nochmal:
@Ivo
Natürlich nur die Dateien meiner Anwendung, im Programmordner; was hast du denn gedacht? Der ganzen Festplatte?@hack0r
Klar, aber ich möchte es halt erschweren. Im Nutzumfeld gibt es nur wenige potentielle Cracker.Es handelt sich um ein AntiCheat-System, da ist ein Zwangsupdate nunmal nötig (Sorry, das hätte ich schon früher erwähnen können).
Ich mag keine clientseitigen AntiCheats, aber da ich ein Tool für ein Spiel mache, baue ich gleich AntiCheat-Funktionen mit ein.Welchen Algorithmus soll ich nun für die digitale Signatur verwenden, vorhandene, vollständige C/C++ -Implementation vorausgesetzt?
Danke!
MfG
-
Herwig schrieb:
eeeh, wo ist meine Antwort hin... hab doch gerade geschrieben. Nagut, dann nochmal:
@Ivo
Natürlich nur die Dateien meiner Anwendung, im Programmordner; was hast du denn gedacht? Der ganzen Festplatte?Voellig egal, Du kannst auf einer fremden Festplatte nicht einfach Daten loeschen, es sei denn der User stimmt zu.
-
Ivo schrieb:
Herwig schrieb:
eeeh, wo ist meine Antwort hin... hab doch gerade geschrieben. Nagut, dann nochmal:
@Ivo
Natürlich nur die Dateien meiner Anwendung, im Programmordner; was hast du denn gedacht? Der ganzen Festplatte?Voellig egal, Du kannst auf einer fremden Festplatte nicht einfach Daten loeschen, es sei denn der User stimmt zu.
türlich, wieso denn nicht? er will ja nicht irgendwelche daten löschen, sondern welche aus seinem game. nach deiner logik muss man den user jedes mal fragen wenn man ne temp datei löcshen will? na prost
-
Bleib ernst. Beispiel: Du kopierst irgendwas nach system32, weil Du meinst es ist dort gut aufgehoben. Beim naechsten Update wird es geloescht, weil es dort laut Microsoft nicht hingehoert. Findest Du sicher auch ganz toll...
-
freibier? schrieb:
türlich, wieso denn nicht? er will ja nicht irgendwelche daten löschen, sondern welche aus seinem game. nach deiner logik muss man den user jedes mal fragen wenn man ne temp datei löcshen will? na prost
Das Problem ist, dass er einfach alle lokalen Files löschen will, welche nicht in der Info aufgelistet sind. Dabei kann es aber passieren, dass er Files vom User löscht, weil dieser diese dort abgelegt hat.
Klar, der User sollte dies nicht tun, aber davon kann man nicht ausgehen. Der User tut immer das, was er nicht tun sollte, davon sollte man wenn schon ausgehen.
Korrekt wäre hier also irgendwie ein Log mitzuführen, welche Files denn zum Programm gehören und welche nicht. Dann mit der Info einen Abgleich machen und gegebenenfalls diese Files löschen, welche nicht mehr auftauchen.
Grüssli
-
Hmmm, stimmt, in meinem Fall werden die Programmdateien im Spielverzeichnis gespeichert. Gerade dann muss ich mir da noch was einfallen lassen.
Registry kommt nicht in Frage, da es keine Installation gibt. Eine zusätzliche Textdatei möchte ich vermeiden, zumal die ja vom unwissenden User auch als "Müll" gesehen werden könnte und im Papierkorb landet..., auch wenn man es in die Readme schreibt...
Wie könnte ich noch (möglichst unkompliziert) vorgehen?
-
Eine Funktion schreiben die die .text section deiner Binary hasht.
MD5 oder SHA1 bietet sich da an.Dann baust du viele Abfragen ein wo der korrekte Hash vom Server angefordert wird und mit dem aktuellen verglichen wird.
-
@Icematrix
Verstehe ich leider nicht; gar nicht.
-
Als digitale Signatur werde ich wohl dies verwenden (SHA-256):
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=12669&lngWId=3
Eine fremde Implementation ist natürlich immer ein gewisses Risiko, aber eine "offizielle" C/C++ -Implementation fand ich nicht, falls es sowas überhaupt gibt.
Ich habe mich nun entschlossen, keine Funktion einzubauen, welche Dateien löscht, da ich dies mit höchster Wahrscheinlichkeit gar nicht brauchen werde. Eine .exe und eine .dll, dabei wirds wohl auch bleiben.
Eine Funktion, welche eine zusätzliche Datei herunterlädt, plane ich allerdings, sicher ist sicher.
-
@Icematix
Ah, irgendwas hab ich da überlesen.Also, warum nur die .text Sektion?
Zur Sicherheit möchte ich SHA-256 verwenden, oder denkst du, MD5/SHA-1 reicht für eine digitale Signatur aus?Ja, ich plane mehr als eine Abfrage im Programm.
> Security through obscurityClienten sind immer irgendwie knackbar, deshalb möchte ich es einem einfach möglichst schwer machen (Ach, noch irgendwelche Tipps dazu?).
-
Herwig schrieb:
Zur Sicherheit möchte ich SHA-256 verwenden, oder denkst du, MD5/SHA-1 reicht für eine digitale Signatur aus?
Der konkrete Hash-Algorithmus dürfte IMHO überhaupt keine Rolle spielen, weil es sowieso viel einfacher sein wird, die Abfrage komplett auszuhebeln, als eine Hash-Kollision zu verursachen.
-
Herwig schrieb:
Clienten sind immer irgendwie knackbar, deshalb möchte ich es einem einfach möglichst schwer machen (Ach, noch irgendwelche Tipps dazu?).
Wenn du es halbwegs sicher haben willst, wirst du um einen Kernelmode Treiber, der deinen Prozess und das System überwacht, wohl kaum herumkommen. Das sollte die gröbsten Kids draußen halten.
-
@Christoph
Ok@hack0r
Schade, so erfahren bin ich nicht.Naja, bin für jeden weiteren Tipp dankbar.
MfG
-
Es spricht doch nichts gegen eine Benachrichtigung wenn neue Updates verfügbar sind, machen doch viele Programme so und fragen bei der Installation ob das Feature aktiviert werden soll (ggf. kann man es dann über die Einstellungen (de-)aktivieren).
In deinem Fall könnte das Programm beim ersten Start den Benutzer fragen.Zur Signierung würde ich übrigens keinen Hash benutzen, den benutzt man nur um sicherzugehen, dass eine Dateie korrekt übertragen wurde, sondern eine public-/private-Key-Verschlüsselung, z.B. GPG um die Updates zu signieren. So lange du den privaten Schlüssel nicht veröffentlichst kann niemand Pakete erstellen die deine Software akzeptieren würde.
-
Herwig schrieb:
Es handelt sich um ein AntiCheat-System, da ist ein Zwangsupdate nunmal nötig
Hmm, wo ist denn der Vorteil bei einer public/private-Key Verschlüsselung? Warum jetzt nicht SHA-256? Da kann doch auch niemand die Datei so verändern, dass ein bestimmter message digest entsteht, oder?