spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

C++ ist genauso dekompilierbar. Man muss halt nur Assembler können, was jetzt nicht gerade schwer ist.
C++ hat zwar auch die Möglichkeit für binäres Lesen und Schreiben (wäre ja gruselig, wenn nicht), aber besitzt nicht die Klassen BinaryReader oder BinaryWriter. Natives C++ ist eben etwas ganz anderes und kennt die .Net Bibliotheken eben nicht. C++/CLI dürfte die kennen. Aber am Ende hast Du rein gar nichts gewonnen.
Wenn Du deinen Code wenigstens etwas schützen willst, Visual Studio kommt mit Dotfuscator im Gepäck. Auch das wird einen Hacker aber nicht aufhalten.

Was genau soll hier eigentlich "confused" werden?
Ich finde die Frage etwas konfus

Klingt so, als wollte der Threadersteller Obfuscation.

Es stimmt schon, dass man auch C++ dekompilieren kann, aber bei C# klappt das ähnlich wie bei Java richtig gut.

Ich meine mich daran erinnern zu könen, dass ein solches oder ähnliches Thema bereits gab. Und auch dort wurde schon darauf hingewiesen, dass solche Sicherheitsmaßnahmen nur eine gewise Hürde darstellen, die durchaus bewältigt werden können. Wenn es nicht gerade einen Grund gibt, warum dein Code über diesen Zeitraum keines Falls analysiert werden darf, dann ist ein solches Unterfangen grundsätzlich nicht den Aufwand wert, den man dort hineinstecken müsste.

Du solltest dir überlegen, was du daraus eigentlich zu befürchten hättest. Ist es wirklich nur das Hacking des Spiels?
Wenn ja: warum solle das schlecht sein? Bei sowas, sollte es denn tatsächlich vorkommen, müssen nicht nur Aimbots und Wallhacks entstehen, sondern auch Abwandlungen vom Spiel, die das eigentliche Spiel sogar noch etwas interessanter machen können.
Und bei Hacks musst du dir überlegen, ob diese wirklich ein Problem darstellen.
Ist es ein Spiel, welches nicht über Internet gespielt werden kann? -> Wo ist das Problem?
Ist es ein Spiel mit Onlinefunktionalität? -> Serverseitige Prüfungen, nur relevante Daten übertragen etc. ...

Und in bereits angesprochenem Thema wurde auch gesagt: das alles wird erst dann relevant, wenn dein Spiel bekannt genug ist.

Das ist nicht sicher. Auch nicht sicherer.
Eine GUID in einem Webdaten-Strom würde ich ohnehin nicht per Decompiler suchen, sondern per Wireshark, also einem Netwerk-Analyse-Tool. Statistiken können auch dann verändert werden, wenn Du das in C++ packst. Assembler ist nun echt nicht schwer zu lernen, das war meine zweite Sprache damals. Ich habe schon komplette Programme darin geschrieben und andere Leute ebenfalls.
Das ist Schutz für gar nix.

Zitat von »birdfreeyahoo«

(...)Außerdem erfolgt kein Anmeldeprozess auf dem Server.(...)

Das ist dein Sicherheitsproblem.

Stell dir vor, dein Spiel wäre eh Open Source. Das Sicherheitssystem, dass du dann entwickelst,
wird deutlich mehr taugen.

Es gibt allerdings kein Sicherheitssystem, welches es nicht erlauben würde einen alternativen Client in einer Client-Server-Architektur zu bauen und somit falsche Daten an den Server zu übermitteln - wie eben gefälschte Statistiken oder ähnliches.

Wenn es um Highscores geht, dann ist "Security by obscurity" wohl das einfachste Mittel der Wahl. D.h. diverse Prüfsummen berechnen und mitschicken, und der Server gleicht die ab. Natürlich kann man durch Ansehen des Quelltexts immer herausfinden, wie die Prüfsummen berechnet werden, und kann dann die Punktzahl verändern.

Eine nicht ganz so einfach zu implementierende Alternative: Das Spiel zeichnet sämtliche Eingaben des Spielers auf (z.B. "zum Zeitpunkt 462 hat der Spieler die Taste 'Links' gedrückt" oder "zum Zeitpunkt 7291 war die Joystickstellung -23, 120"), und der Server spielt das Spiel sozusagen nach. Danach weiß er die Punktzahl, die der Spieler erreicht hat. Dazu muss das Spiel deterministisch laufen (Zufallsgeneratoren sind möglich, indem man den Seed mitschickt). Das schützt gegen einfache Manipulationen der Punktzahl, aber nicht gegen Cheats wie z.B. Aimbots. Auf den ersten Blick könnte man denken, dass dabei große Datenmengen zum Server geschickt werden müssen. Aber die halten sich in Grenzen. Bei Tasten muss man nur ein Event mit einem Zeitstempel schicken. Bei analogen Achsen muss man den Wert potenziell jedes Frame schicken, aber wenn man das quantisiert und ein bisschen komprimiert, sollte das kein Problem darstellen.