smart-roadster-forum.deForum rund um den smart Roadster und das smart Roadster Coupe.

[Klaus]

Bots können doch auch mit den Game-Controls selbst arbeiten, die müssen doch nicht einfach gefälschte IP-Pakete senden ? Die Leute die sowas programmieren machen sich dermassen viel Arbeit, was man da schon alles gesehen hat, Wahnsinn. Ich denke, man sollte einfach alles server-sided machen, und den Client so programmieren dass er wenn möglich komplett die Kontrolle über das Betriebssystem übernimmt und keine sonstigen Threads oder Programme zulässt.

Sobald jemand den Programmcode analysieren kann, kann er auch die Verschlüsselungsmethoden usw. kopieren. Wenn die Leute nur Pakete modifizieren, reicht eine normale Einweg-Verschlüsselung aus, die z.B. täglich oder bei jedem Anmelden des Clients geändert wird.

Bei anderen guten Spielen ist das Problem geschickt umgangen worden, indem Gameplay, Quests, Instanzen, Schlachtpläne usw. wichtiger sind als Grinden. Bei LOTRO z.B. kommt man mit Grinden nicht weit, darum spielt Botten auch kaum eine Rolle. Und ehrlich gesagt, wenn sich jemand einen Bot baut damit er nicht selbst vor dem Rechner sitzen muss und stundenlang Felle oder Erze farmen, hat er meinen Segen. Es ändert sich ja nichts, ausser dass der Spieler Zeit spart. Probleme bekommt man nur, wenn Transaktionen die was ändern nicht server-sided sind. Sowas macht man einfach nicht.

[2eck]

Problem an festen Keys die mit übermittelt werden ist halt das das imemr der Gleiche ist.
Kann man prima in eigenen oder manipulierten Requests einbauen.

Naja. genug geradet.
Es ging eigentlich darum die Promzahlengenerierung schneller zu machen.
Habe gestern noch mal was gefunden was mit Faktor 3 bringt und somit schnell genug.

[2eck]

Zum einen kann ich nicht hingehen und Zertifikate / Keys verteilen, und zum anderen kann man alles was an einen Http request als PArameter gehängt wird prima noch abfangen und für automatisierte requests vom gleichen rechner aus benutzen.
Ich kenne leider die Tricks - ich habe selber schon War-Browser und Script's geschreiben die genau so etwas ausgenutzt haben. Session Keys und so reicht leider nicht.

[Klaus]

Es geht also um ein Browser-Game das sich mit einem Server unterhält ? Wenn kein Browser, warum dann HTTP. Eigenes Protokoll definieren, Tickets verschlüsseln mit PGP o.ä., und den Key bei jedem Login oder periodisch wechseln. Bis dass jemand das entschlüsselt hat ist das längst nicht mehr gültig, ausserdem würden nur Genies auf das Protokoll kommen wenn es binär und kein lesbarer Text ist. Man kann auch ein fieses Protokoll bilden bei dem sinnlose Füllbytes zwischen sinnvollen Passagen liegen, die auch noch dynamische Länge haben, und einfach ständig mit was anderem gefüllt werden. Das bringt auch Hartgesottene um den Verstand, besonders wenn die Dynamik nicht trivial zu raten ist, mit nem Längenbyte oder so. Sprich, wenn es ein Längenbyte gibt, sollte man da ein bischen die Bits rotieren und mit zufälligen Müllbits verschleiern. Bringt aber nur was wenn das Programm kein einfach lesbares Format ist, und gegen Disassemble-Gurus schützt halt nichts.

Aber was genau befürchtest Du denn, wenn die gesamte Verarbeitung im Server passiert, und der Client nur sowas requesten kann wie "ich gehe jetzt nach Norden" ? Oder soll das ein server-loses Spiel sein bei dem sich die Clients direkt unterhalten ? Das endet immer im Fiasko.

[2eck]

Http weil das eigentlich perfekt für den Job ist und ich keinen eigenen Server samt Protokoll bauen will.
http gibt es als sehr flexibe Komponenten für Delpi.

Ich "komme" von einem Browser Game names Omega day.
Weltraum Strategie ect.

Da kann und tut man prima mit Bots, Scripts und spezialisierten Browsern arbeiten.
Nix gut. Ausloggen von unliebsamen Mitspielren aus deren Sesseions druch bebastelte SessionID und missgesaltete Logins ... da gibt es sehr viel unnetten Kram.

Ich will eigentlich nur einen Client, der seine Anfragen per http in der Art von
www.stella-incendium.de/Login=tmm&AuthC ... 80D341B485

www.stella-incendium.de/Planet=1001726& ... 80D341B485

Die Antwort bzw. das Ergebniss des Datenbankrequests den der Server aufgrund des Kommandos durchführt ist immer eine xml Datei die durch den http Request downgeloaded und im Client ausgewertet wird.

Wenn der AutoCode in einem Request nach dem erfolgreichen Login nicht stimmt -> Pech.
Der Client fürt entweder von selbst nach 3 Fehlversuchen ein erneutes erfolgreiches Login durch oder der Server fährt bis zum Session Timout damit fort die Anfragen des Clients zu ignorieren die einen falschen AuthCode haben.

Jeder "verbrauchte" AuthCode wird aus derListe der beim Login genereireten/ausgehandelten AuthCode gestrichen, ist also nur ein Mal verwendbar.
Falls JEmand auf die Idee kommt einen AuthCode in einem eigenen Request "wiederzuverwenden" -> ignore durch den Server.

[2eck]

wie auch immer.

Ich will es ja nicht 100% sicher machen, sondern nur den ScriptKiddies soviele Steine in den Weg legen das es einfach zu Mühsam ist de Berechnung und Aushandlung der AuthCodes nachzubauen.

Das das nicht 100%ig ist weiss ich.
Aber ich kann besser mit Sachen Arbeiten die ich verstehe bzw. selber gebaut habe.
Wenn ich mir alleine Schon die Bildung eines SHA1 hashes ansehe was ich aus der Synape web Protocol Libary übernommen habe dann geht mir das schon zu tief.

[2eck]

naja wie auch immer man dei Authentifizierung beim Login nennt

/Login=Username

Der AuthCode wird beim Client mit dem MD5 und SHA1 hash de eignegebene Passworts gebildet,
Der Client genereirt für alle 100000 Primzahlen (nur jede 1000ste ist aufgelistet) mit deren jeweiligem SHA1hash, dem Passwort MD5 und SHA1 und ein wenig "Salz" mit der Stunde des Tages und dem Tag des Jahres den Authcode und wählt eine nzufälligen aus der oberen Hälfte der Liste aus und packt den mit zu dem Login Request.

Der Server macht das Gleiche anhand der in der DB hitnerlegten MD5 und SHA1 hashes des unter Login=Unsername angegebenen Benutzers. Primzahlenliste.

AuthCode := SHA1HexStr(DayOfYear +
PasswordMD5 +
HourOfDay +
Prime1000IndexSHA1 +
PasswordSHA1);

Anhand des vom Client übermittelten Authcodes - so denn er denn überhaupt mit einem der 100000 erzeugten Übereinstimmt . weiss der Server welche der 100000 Primzahlen der Cleint gewählt hat.
Cleint udn Server haben ja die Gleiche Liste von 100000 Authcodes erzeugt.

Der Server wählt jetzt eine zufälligen AuthCode aus der unteren Hälfte der 100000er Tabelle und schickt den in der Antwort xml an den Cleint.
Bzw. der client downlaoded die Antwort xml auf seinen http request hin.
Der Cleint findet den AuthCode aus der xml in seiner genereirten Liste und weiss weche der 100000 Primzahlen der Server ausgewählt hat.

Da Server udn Client nun wissen weche beiden Primzahlen aus der 100000er Tabelle ausgewählt wurden können beide Seiten daraus den Intervall der nun zu generierenden Primzahlen errechnen
Prime1000ListInterval := Trunc(3 + (22 * Frac(Prime1000ListIndex / Prime1000ListIndex2)));

Sowohl Server als auch Cleint generieren jetzt 256 (oder mehr - mal schauen) Authcodes indem Primzahlen ab der vom Server ausgewähltem im errechneten Intervall (als beispielsweise nur jede 14te Primzahl wird berücksichtigt) errechnet werden.
Die werden dann wie oben mit HourOfDay und DayoftheYear des Logins gesalzen und zusammen mit den MD5 und SHA1 hases des Passwortes in Authcodes umgewandelt.
cleint und Server haben jetzt wieder die gleichen Listen von AuthCodes.
Nur der Server hat halt je eine Liste pro eingelogtem User zusammen mit einer Tabelle welche clientIP welcher Authcode Liste zugeordent ist. Wird eine anfragende ClientIP hier nicht gefunden muss halt in allen AuthCodeLsite nachgeschaut werden (ist eine reine performance Sache)

Der client unterschreibt nun jeden Request mit einem der generierten Authcodes und der Server bearbeitet den Request nur wenn der Authcode auch in seiner Liste vorhanden, und noch nciht als verbraucht makriert ist.

[2eck]

Ja, theoretisch kann man den Kram per MITM abfangen.
Der Request selbst wird auch noch zusammen mit der im AuthCode verwendeten Primzahl gehashed und byteweise mit dem autcode verschachtelt.
Dazu kommt dann noch mal die im AuthCode verwendete Primzahl was wiederum gehashed wird und mit dem verschachtelten von eben weiter verschaltelt.

R = SHA aus Command + der Primzahl im AuthCode
A = Der AuthCode
wird zu RARARARARARARA......

O = SHA1 aus RARARARARA.... + der Primzahl im Authcode
wird zu RAORAORAORAORAORAO....

Ja, kann man alles raus finden, aber ...
Maximum obscurity

[einLiterVollmilch]

Thomas, wenn du über HTTP gesicherte Requests senden möchtest, dann schau dir doch mal OAuth an. Ist inzwischen der gängige Standard geworden, was das signieren von Requests angeht. Du generierst zu beginn der Authentifizierung 2 Tokens, bekommst nen Schlüssel und damit wird alles signiert und vom Server verifiziert. Bisher gibt es da noch keine Möglichkeit, das Verfahren irgendwie zu brechen...

Wird u.a. benutzt, damit andere Systeme z.B. auf die Facebook API zugreifen können oder auch für Twitter Clients und deren Kommunikation zw. Twitter und Client.

Das sollte den Job optimal machen und dafür bekommst du in fast jeder Programmiersprache inzwischen eine Lib, die den ganzen Low-Level Kram erledigt.