[.NET] Encryptie van game score

[Hobbles]

De titel is misschien niet heel duidelijk maar weet niet hoe ik dit beknopt kan samenvatten.

Ik ben bezig met het maken van een spel in .NET (met DirectX) en ik wil de scores opslaan op een server. Het probleem is dat ik wil voorkomen dat een speler zijn score handmatig kan aanpassen. Hiervoor wil ik de score encrypteren. Het probleem bij .NET is dat de assemblies gemakkelijk te decompilen zijn waardoor ik geen encryptie sleutel in de assembly kan opnemen.

Mijn voorlopige idee was om een unmanaged C++ dll te maken die de encryptie voor zijn rekening neemt. Maar ook dat is niet veilig aangezien de gebruiker dan ook de functies uit de C++ dll kan oproepen en zo de encryptie alsnog zou kunnen omzeilen.

Ik ben dus op zoek naar een manier om gegevens te kunnen encrypteren zodat de gebruiker er zelf niet mee kan knoeien (en dus ook niet het encryptie mechanisme of sleutel mag kunnen achterhalen). De score van het spel mag dus ook niet eerst raw worden opgeslagen.

offtopic:
Ik was aan het twijfelen of dit bij Programming of Architectuur hoorde, heb Programming gekozen omdat het een specifiek .NET probleem is.

[ Voor 3% gewijzigd door Hobbles op 18-10-2009 11:35 ]

[Haan]

Als je gebruik maakt van encryptie met een public en private key ( die alleen op de server bekend is), ben je toch al klaar?

Maar wat voor spel gaat dat zijn als je bij voorbaat al rekening gaat houden met mensen die dll's gaan decompilen en jouw encryptie gaan hacken

[Sebazzz]

Een simpele asymmetrisch cryptografie algoritme is hier goed op z'n plaats. Zo kan je bijvoorbeeld RSA gebruiken, eventueel in combinatie met AES.

[Verwijderd]

Het gebruik van asymmetrische versleuteling heeft geen zin. Asymmetrische versleuteling gebruik je als je het communicatiemedium niet vertrouwt. De TS vertrouwt de communicatiepartner niet.

[DataGhost]

Verwijderd schreef op zondag 18 oktober 2009 @ 11:55:
Het gebruik van asymmetrische versleuteling heeft geen zin. Asymmetrische versleuteling gebruik je als je het communicatiemedium niet vertrouwt. De TS vertrouwt de communicatiepartner niet.

Alleen weet hij dat zelf nog niet, volgens mij. Ik denk dat de insteek van de encryptie hier is om het verkeer te versleutelen zodat je niet zomaar met je browser (of gewoon een socket) valse scores kunt submitten. Encryptie heeft daar wel zin en is eigenlijk ook het enige wat je kan doen. Decompilen van assemblies is weer een stapje moeilijker, dus met encryptie zal je zeker een deel tegenhouden.
Het probleem is dat je dit nooit echt waterdicht kan maken, naast decompilen kan je namelijk ook gewoon de score in het geheugen aanpassen. Hoe je het ook wendt of keert, de score wordt door een machine buiten zijn macht gegenereerd en kan dus vervalst worden. Je kan het echter wel zo moeilijk mogelijk te maken om het aantal mensen wat het kan vervalsen en ook zin heeft er zoveel moeite in te stoppen zo klein mogelijk is.

TS, Ik denk dat het enige wat je naast encryptie kan doen is server-side kijken of bepaalde scores uberhaupt mogelijk zijn en die eruit filteren. Verder zou je ook kunnen zoeken naar verdachte patronen en mislukte submissions.

[ Voor 6% gewijzigd door DataGhost op 18-10-2009 12:03 ]

[Haan]

Misschien een idee: de score stuur je als hash naar de server, waarbij je gebruik maakt van een salt die je encrypted van de server haalt. Dan lijkt het mij vrij moeilijk om een valse score te genereren.

[Not Pingu]

Maar dan zul je nog wel de score zelf moeten sturen, anders weet de server nog niet wat de score is

Dus je verstuurt:
-score
-speler ID
-hash(score+speler ID+salt)

De server maakt dan dezelfde hash van score+speler ID+salt en die moet gelijk zijn aan de meegestuurde hash.

[Haan]

Ja dat zou hem moeten zijn inderdaad.

[gorgi_19]

Haan schreef op zondag 18 oktober 2009 @ 12:04:
Misschien een idee: de score stuur je als hash naar de server, waarbij je gebruik maakt van een salt die je encrypted van de server haalt. Dan lijkt het mij vrij moeilijk om een valse score te genereren.

Of je nu een 1 of 10 door de method heen gooit als zijnde score, het principe met decompiling blijft eenvoudig. Sniffing maak je een stuk moeilijker, maar je hebt toegang tot de bron. Enige schijnoptie lijkt me obfuscation van de dll om het wat moeilijker te maken.

[DataGhost]

Haan schreef op zondag 18 oktober 2009 @ 12:04:
Misschien een idee: de score stuur je als hash naar de server, waarbij je gebruik maakt van een salt die je encrypted van de server haalt. Dan lijkt het mij vrij moeilijk om een valse score te genereren.

Not Pingu schreef op zondag 18 oktober 2009 @ 12:11:
Dus je verstuurt:
-score
-speler ID
-hash(score+speler ID+salt)

De server maakt dan dezelfde hash van score+speler ID+salt en die moet gelijk zijn aan de meegestuurde hash.

C:

int score;
// ....
score++;
// ....
submit(score);

code:

zoek een leeg geheugenadres en noem het [score]
// ....
stop de waarde op geheugenadres [score] in register 0
verhoog register 0
sla de waarde in register 0 op in het geheugen op adres [score]
// ...
stop de waarde op geheugenadres [score] in register 0
roep de functie submit aan

Als 'hacker' zijn er legio mogelijkheden om buiten de applicatie om te achterhalen wat het geheugenadres [score] is, waarna je tijdens of na het spel (doch voor het daadwerkelijke submitten, versleutelen of wat dan ook) die waarde kan verhogen. Als developer zijn er ook legio mogelijkheden dit te voorkomen, echter moet je zelf op de een of andere manier de score verhogen, waardoor een hacker exact dezelfde stappen kan uitvoeren om hetzelfde te bereiken.

[Verwijderd]

Het enige wat je kan doen is om alleen de server toe te staan de score te manipuleren. Zoiets als gold bij World of Warcraft.

Ik vermoed dat je dan wel je hele ontwerp tot nu toe opnieuw kan doen maar het is volgens mij de enige methode die werkt. Of je moet Trusted Computing van Microsoft gebruiken, maar de meeste computers kunnen daarmee niet overweg (is hardware op je moederbord voor nodig, de 'Fritz Chip').

[Zoijar]

Encryptie werkt idd niet. Wat je wilt is dat je client alle input naar de server stuurt die het dan valideert en dat de score op de server wordt berekend. Maar dat is meestal niet haalbaar. Je kan het dan in delen opsplitsen. Dat is niet helemaal veilig, maar wel al een stuk beter. Stel bijvoorbeeld dat je een puzzeltje op moet lossen en je neemt als score de tijd dat iemand daar over doet. Dan stuur je aan het begin een unieke code naar je client waar de server zelf de timestamp van bijhoudt en de "puzzel instance". Als de client klaar is, dan stuurt hij de oplossing naar de server met die unieke code. De server kijkt dan of de code klopt en weet dan hoe lang je er over hebt gedaan. Ook checkt hij nog een keer of de meegestuurde oplossing klopt.

Bijvoorbeeld een schuifpuzzel onthoudt de server de start van de puzzel, en de client stuurt alle aangeklikte stapjes mee. De server voert dan al die stapjes uit en kijkt of het daadwerkelijk een oplossing is.

Met een spel kan je meestal niet alle input opslaan en naspelen, maar misschien kan je op bepaalde tijdstippen samples verzamelen van de game state en dan kijken of die kloppen. Je weet bijvoorbeeld met hoeveel de score maximaal omhoog kan gaan in hoeveel tijd. Je weet ook misschien dat mensen niet nooit geraakt worden, en je weet hoeveel tijd een level ongeveer duurt. Log dat allemaal en stuur het mee met de score voor validatie. (en dus niet checken op je client! Gewoon blind mee sturen. De server gooit de score wel weg als het niet klopt)

[ Voor 33% gewijzigd door Zoijar op 18-10-2009 13:05 ]

[Hobbles]

Veel reacties zeg! Ik heb ze nog niet allemaal grondig nagelezen maar tijd sampling en cheaters afvangen op basis van verdachte waardes ga ik zoiezo al doen.

Bij encryptie blijft natuurlijk het nadeel dat een cheater/hacker de dll's kan decompilen en op die manier het encryptie mechanisme kan achterhalen. Obfuscation kan hier inderdaad al iet of wat (schijn)veiligheid brengen. Ik verwacht dat ik heus niet de enige ben die dit probeert.

tjboschl haalde het gold verhaal uit WoW aan, maar die waardes worden rechtstreeks op hun servers opgeslagen vermoed ik. In tegenstelling tot WoW kan mijn spel offline gespeeld worden, en wanneer er een verbinding is met het internet kunnen deze scores gesubmit worden. Ik weet dat ik iets probeer te doen dat erg lastig is, maar het is zich eigenlijk net daarom te doen Ik hou van een uitdaging.

Ik vermoed wel dat absolute waterdichtheid niet te verkrijgen is, maar ik wil het wel zo moeilijk mogelijk maken voor een cheater/hacker.

PS: DataGhost vat mijn probleem goed samen

[CMG]

Is er met Strong Naming niet iets te doen?

Je kan je assembly strong namen en dan je in je C++ dll met de encryptie de caller checken (je strong named assembly). Zou zo iets niet werken?

[Hobbles]

Strong naming is misschien nog niet zo'n slecht idee. Sowieso weer een extra optie om te bekijken!

[Woy]

CMG schreef op zondag 18 oktober 2009 @ 16:46:
Is er met Strong Naming niet iets te doen?

Je kan je assembly strong namen en dan je in je C++ dll met de encryptie de caller checken (je strong named assembly). Zou zo iets niet werken?

En dan haalt een hacker gewoon de check uit de C++ dll. Je kunt hier allemaal kunstgrepen uit gaan halen om het een hacker moeilijk te maken, maar een waterdichte oplossing ga je toch niet vinden.

Een C++ dll kun je net zo goed aanpassen als een .NET assembly. Het enige voordeel van een C++ dll is, dat je daar de C++ code niet meer zo eenvoudig uit kunt achterhalen, maar op assembly nivo is dat geen probleem.

[mocean]

Ik heb hier in het verleden met verschillende Flash-games (met fysieke prijzen) ook wel eens mee lopen stoeien. Toen zijn we ook niet verder gekomen dan het voor de fraudeurs zo moeilijk mogelijk te maken. Echter voorkomen doe je nooit. Er waren wel wat tooltjes die de-compilen verhinderde, maar die werken maar tijdelijk (Dat is dus wel een mogelijkheid bij kortlopende games). Ik weet niet wat daarvoor beschikbaar is in andere talen.

Je kan wel in je voorwaarden e.e.a. afvangen. En bijvoorbeeld loggen wat er door een client wordt gesubmit (dat gaat vast een paar keer verkeerd voor het wel lukt). Als je een behendigheids-spel hebt, kan je ook wel wat grenzen stellen aan hoe snel iemand een maximale score zou kunnen halen (oefening).

Maar al met al, he compleet uitsluiten van fraude is onmogelijk. En als het spel offline te spelen is, is het nog wat moeilijker fraude te detecteren dan wanneer het met een internet-verbinding gespeeld wordt.