spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wegen Man-in-the-Middle Angriffen wäre es halt sinnvoll einen Key vom Server zu schicken um verschlüsselte Daten entschlüsseln zu können oder noch besser, wenn man direkt absolut notwendige Daten vom Server abrufen *muss*, ohne die das Programm nicht geht - bei jedem Start. Ist eklig und auch das kann man brechen, ist aber deutlich härter als ein Boolean, weil man dann zumindest *eine* echte Version braucht, um an die abgerufenen Daten zu kommen. Die bräuchte man bei einem reinen CD-Key oder einem Boolean nämlich nicht, das könnte man komplett brechen ohne dass auch nur irgendwer jemals eine echte Variante auch nur gesehen hat.

Zitat von »Jonathan_Klein«

@Sylence: Dein Verfahren steht und fällt mit der Art der verwendeten Prüfsumme. Die Lookuptabelle ist im Prinzip witzlos, die erhöht die Sicherheit nicht wirklich. Damit es sicher ist, bräuchte man schon einen kryptografischen Hash, der irgendwie ein Password benutzt, damit ihn der Angreifer nicht selber berechnen kann. Sowas gibt es natürlich alles schon in fertig, aber damit ist der Implementationsaufwand immer noch etwas höher, als in meinem Vorschlag.
Natürlich muss es nicht unbedingt super sicher sein. Man kann sich einfach irgendeine simple Prüfsumme ausdenken und benutzen, es ist trotzdem noch schwer zu knacken. Die Frage ist nur, wieso sollte man eine eigene Lösung benutzen, die komplizierter zu implementieren ist, als ein Standardverfahren, das sehr viel sicherer und schneller eingebaut ist?

Die Lookuptable ist dafür gedacht, dass ich mit dem gleichen Verfahren Keys für verschiedene Tools machen könnte. Einfach die Tabelle ändern und fertig. Prüfsumme ist nur die Quersumme also nichts exotisches. Zum Implementieren hab ich einen Nachmittag gebraucht. Mehr wärs mir auch nicht wert gewesen, weil es eben imho sinnlos ist viel Zeit in Sachen wie Kopierschutz zu stecken, die eh geknackt werden, wenn es jemand will, egal obs selbst gebastelt ist oder eine Multimillionen-Dollar-Lösung ist.

@Pixma: Du bekommst keine Zeichen, du bekommst Bit. Erst wenn du diese Bits irgendwie ausgibts, werden sie zu konkreten Zeichen. Und die Art und Weise, wie du sie aus- oder einliest, kannst du ändern. Zum Beispiel hiermit:
http://www.cplusplus.com/reference/iostr…nipulators/hex/
Die ganze Funktionalität ist irgendwo schon da, es geht nur darum ein wenig in der Doku zu suchen. Wenn du immer nach 16 Bit (4 Hex Zeichen) ein Trennzeichen (z.B. - ) einfügen willst, kannst du zum Beispiel Bitshifts benutzen. Das ganze ist eigentlich ein Thema, das man drauf haben sollte, wenn man mit CD-Keys rum hantiert. Ich weiß jetzt vielleicht auch nicht jede einzelne Formatierungsfunktion auswendig, aber wie gesagt, es ist alles schon da, du musst nur ein bisschen die Dokumentation durchstöbern.

@Sylence: Gut, der Vorteil deiner Idee ist natürlich, dass man keine Kryptobilbiothek benötigt. Aber naja, ein Problem an der Quersumme ist halt, dass es nur wenig mögliche Werte gibt. Sagen wir du hast zur Basis 36 kodiert, und der Key hat 25 Stellen. Dann hast du bloß 15*25=875 mögliche Quersummen. D.h. sollte man nur irgendwie die Möglichkeit haben, einen Bruteforce-Angriff zu starten, hat man extrem schnell einen passenden Key gefunden. Und bzgl. viel Zeit rein stecken. Ich dachte an etwas in der Art:


Die AES Funktion bekommt man aus irgendeiner Bibliothek. GenKey bekommt einen Schlüsselindex i, der einfach eine hochzählende Zahl ist und einen Produkttyp, der einem sagt, welches Programm es ist und ob es eine Vollversion ist oder nur die Studentenversion, oder was weiß ich was. Die 2 Nullen sind nur dafür da, damit ein zufällig geratener Schlüssel quasi immer ungültig ist, statt 0 kann man hier auch jede andere Zahl nehmen.
Überprüfen läuft analog. Erst entschlüsseln, dann gucken, ob die 4 Werte stimmen. Das Key-Anzeigen hat jetzt halt nur 4 große Blöcke, das könnte man mit mehr Mühe alles schöner hinbekommen. Beim Einlesen muss man dann noch die Trennzeichen ignorieren und vielleicht alles in Kleinbuchstaben umwandeln, damit Groß/Kleinschreibung egal ist. Ein RegEx ist sicherlich auch nützlich, ob vorab schonmal die Grobe Form zu prüfen.
Also wie man sieht alles in sehr kurzer Zeit umsetzbar. Die größte Mühe dürfte das raussuchen und installieren einer AES-Implementation sein, und das sollte man ja wohl noch hinbekommen.

das Problem, was bereits angedeutet wurde:
egal, wie viel Aufwand man rein steckt, man wird keine absolut sichere Lösung bekommen

wenn das Programm nicht online prüft, ob ein Key bereits verwendet wurde o. ä., dann kann es lediglich auf Basis einer Quersumme o. ä. prüfen, ob ein Key gültig ist
da ein Key immer gültig sein wird, wird er von jeder Installation anerkannt, da diese weder direkt, noch indirekt miteinander kommunizieren können

wenn eine Kommuniktion mit einem Server besteht, muss eine verschlüsselte Verbindung bestehen
die Kommunikation läuft grundsätzlich mit einer symmetrischen Verschlüsselung (wie AES) ab, dessen Schlüssel mit Hilfe eines asymmetrischen Verfahrens (wie RSA) verschlüsselt übertragen wird
würde einfach nur der Schlüssel verschlüsselt an den Client übertragen werden, könnte ein Men-in-the-Middle diesen und den öffentlichen Schlüssel zum Entschlüsseln abfangen und die Verschlüsselung wäre nutzlos
deswegen könnte der Client den öffentlichen Schlüssel an den Server senden, dieser den Schlüssel für die eigentliche Kommunikation verschlüsseln und zurück senden
dafür müsste der vom Client gesendete Schlüssel allerdings ausreichend komplex sein, sodass ein Men-in-the-Middle zu lange benötigen würde, um diesen zu entschlüsseln und zu verwenden
er darf auch nicht vorher bekannt sein, da sonst in einer Tabelle nachgeschaut werden kann, was das äquivalent des öffentlichen Schlüssel ist und die Kommunikation wieder unsicher ist

ein vergleichbarer Ansatz wäre es, die Antwort des Servers zu "signieren"
dafür wird von der Antwort ein Hashwert erstellt, welcher mit einem asymmetrischen Verfahren verschlüsselt an die eigentliche Nachricht angehangen und an den Client gesendet wird (der öffentliche Schlüssel ist öffentlich zugänglich)
das alleine würde aber nicht reichen, da sonst der Men-in-the-Middle einfach seinen eigenen öffentlichen Schlüssel anbieten könnte, das Paket abfangen, auspacken, manipulieren, mit eigenem privaten Schlüssel wieder einpacken und weitersenden könnte
dafür ist es notwendig, dass bei einer anderen, bekannten und sicheren Stelle die Identität (also meines Wissens der verwendete öffentliche Schlüssel) verifiziert werden kann
für einen Men-in-the-Middle Angriff wäre es also nicht nur notwendig, sich zwischen den eigentlichen Server zu hängen, sondern man müsste auch den bekannten, sicheren Server im Verhalten imitieren


letztendlich sind die Sicherheitsaspekte immer eine Kosten-Nutzen-Frage (auf beiden Seiten)
beispielsweise sind ausreichend sichere RSA Schlüssel nur sicher, weil das ermitteln dieser viel zu lange dauern würde (das Ermitteln an sich ist durchaus möglich - wenn man genug Zeit hat)

Ein weiteres Problem was hier noch nicht betrachtet wurde, ist meiner Meinung nach, wie man einen solchen Key einsetzt, um die Software zu sichern. Beispielsweise würde der klassische Freischaltdialog wie man ihn aus Shareware von vor 10 od. 20 Jahren kennt nicht viel bringen, da man sowas recht einfach in der EXE hacken kann. D.h. der schöne sichere Key-Generator-Algorithmus ist für die Katz. Ich denke man müßte mit diesem key während der Auführung des Programms kontinuierlich immer wieder darauf testen, ob ein eingetragener Key gültig ist, so dass es nicht eine einzige, einfach zu hackende Stelle im Programm gibt an der man den Hebel zur Umgehung ansetzen kann. Ich hoffe ich war jetzt nicht zu unspezifisch mit meinen Erläuterungen und der Punkt den Key richtig einzusetzen kam rüber.

Problem an der Idee ist, dass man dann den Code an vielen Stellen duplizieren und am besten auch leicht anders schreiben müsste, damit er sich nicht per STRG+F einfach finden lässt. Ohne Duplizierung müsste man noch immer ja nur eine einzelne Methode ändern. Aber mit Duplizierung wird's auch sehr schnell hässlich.

Ich würde den Aufwand gar nicht betreiben. Sicher kriegst du es so oder so nicht, und wenn du es trotzdem tust, hast du das gleiche Problem wie die großen: Die legitimen Kunden bekomme Probleme beim Installieren oder Spielen und die Raubmordkopierer haben keine Schwierigkeiten.

Gib deinen Kunden lieber einen Anreiz, freiwillig deine Online-Angebote zu nutzen, z.B. durch Downloadangebote, irgendeinen Social-Aspekt oder irgendwas, die du dann selbst schützen könntest. So vergrätzt du nicht die Spieler, die grade mal kein Internet zur Hand haben (weil sie im Ausland oder grade umgezogen sind oder sonstewas) und hast trotzdem einen Anreiz für potenzielle Raubkopierer, es sich doch zu kaufen.

Ich hab mir nicht alles durchgelesen, aber meine Meinung: lass es bleiben, es bringt eh nichts, außer das Programm ist so schlecht das es eh niemand hacken will. Guck dir mal die ganze Top Spiele an. Die sind teilweise nach 1-2 Tagen gehackt.
Das einzige was wirklich hilft ist eine starke Server<->Client Beziehung, wie z.B. bei Diablo 3 (ich verfolge so ein bisschen was alles wie gecrackt wird, durchaus interessantes Thema). Da gibt es jetzt soweit ich weiß einen Server Emu, aber der ist verglichen mit dem Original natürlich schrott und ich persönlich kaufe eh lieber Spiele und spiele diese dann auch richtig (und nicht nur einmal durch den Fleischwolf -> Müll).

Also, vertraue deinen Kunden oder bau dein Programm so das es ohne Server nicht leben kann. Natürlich sollte es nicht komplett ungeschützt sein. Aber es reicht ja quasi zu sagen dieses Programm ist nicht kostenlos und darf nicht verteilt werden blabla.