[Anti-Cheat] In een opensource game [OpenFRAG]

[Falcon]

Zoals waarschijnlijk sommigen van jullie weten zijn er een aantal tweakers onder ons gestart met een project om een eigen 3d game te maken (Zoals hier te lezen [rml][ 3d games] Gezamelijk game-project[/rml]).

Op dit moment zijn we bezig met code en de engine. Maar nu lopen we tegen iets op .. waar we even gedachtens over willen wisselen met jullie. Het volgende:

Door dat de game 100% opensource zal worden.. zal er wel voor iets moeten gezorgd worden wat het cheaten tegen zal gaan.

Heeft iemand een idee om dit tegen te gaan?

Voorwaarden:

1. Geen beheer (kost geld)
2. Mag geen geld kosten
3. Geen 1 centrale server (kost geld)
4. Melden we straks wel

Alvast bedankt voor het meedenken

Ps: http://openfrag.sourceforge.net

[ Voor 8% gewijzigd door Falcon op 15-06-2003 21:47 ]

[Tomatoman]

Dat is per definitie onmogelijk. Als iemand volledige toegang tot de code heeft, kan hij die naar believen aanpassen. Iedere anti-cheat die jullie inbouwen, kan hij er weer vrolijk uithalen of er een workaround voor bouwen.

Je zult dus een andere benadering moeten kiezen dan volledig opensource (voor wat de cheats betreft)

[IFASS]

en als je een check vanaf de server maakt?

suggesties plz

[Vinnienerd]

idd...als je er nou een closed-source client inbouwt die voordat naar een server wordt geconnect van de in het geheugen geladen spel een soort van checksum maakt en die naar de server stuurt d.m.v. encryptie

[IFASS]

ja, maar (mij zit in het project) dat het 100% opensource is, dus wat dan? er moet toch iets mogelijk zijn

[Soultaker]

Wat voor cheats had je zoal in gedachte? Zaken als visibility cheats en aimbots zijn nooit uit te sluiten; zeker met een opensource spel niet. Veel andere cheats (sneller lopen, niet doodgaan, of iets dergelijks) zijn wel uit te sluiten door dit soort zaken in de server (desnoods steekproefsgewijs) te controleren en niet blindelings op de input van de clients te vertrouwen.

Verder kun je ook het spel zo ontwerpen dat de nadruk gelegd wordt op menselijke kwaliteiten, waardoor het ontwikkelen van cheats slecht mogelijk wordt. Als je niet al te donkere levels maakt, is zichtbaarheid geen element in het spel en is een visiblity cheat dus al veel minder nuttig (sowieso draai ik in veel spellen de brightness van m'n monitor omhoog; dat kun je nooit voorkomen). Een aimbot werkt vooral goed als er wapens in het spel zitten die in een rechte lijn schieten en direct raken. Een granaatwerper (vreemde baan) of een bazooka (traag) kan beter door een mens dan door een aimbot gebruikt worden; geef zulke wapens dus een belangrijke rol in het spel.

Ik heb me verder niet verdiept in jullie spelontwerp, maar het lijkt me nuttig om na te gaan welke cheats je zoal kunt bedenken, en hoe je die vanuit het spelontwerp tegen zou kunnen gaan.

[Verwijderd]

Iemand heeft blijkbaar mijn post op het openfrag forum gelezen *kuch*
(nick = Vich )

[ Voor 173% gewijzigd door Verwijderd op 15-06-2003 21:42 ]

[Falcon]

Verwijderd schreef op 15 June 2003 @ 21:36:
Iemand heeft blijkbaar mijn post op het openfrag forum gelezen *kuch*

Onze reddende engel

[IFASS]

offtopic:

yup, dat was ik

@ falcon, ja zeker

[ Voor 65% gewijzigd door IFASS op 15-06-2003 21:38 ]

[The-Source]

Die checksum maker kun je ook opensource houden.
De correcte checksums kunnen jullie natuurlijk los opslaan op de server.
Zo kan de user die volledige source toegang heeft nooit weten welke checksum hij hoort te hebben.
_{Ok hij kan eerst een checksum van zijn origineel berekenen en dat het checksum progje dus danig hacken zodat hij altijd de juiste checksum stuurt.
Maar voor elke revisie die er komt mag hij overnieuw beginnen}

[Verwijderd]

Hier is een overzichtje met wat je kan doen:

1) Kijken hoe snel een gebruiker gaat (te snelle gebruikers disconnecten)
2) Kijken of de spelers wel aan zwaartekracht onderheven zijn door een collisiedetectie uit te voeren voor elke speler met het level en te kijken of de speler werkelijk zakt als er geen collisie is. Dit is natuurlijk redelijk CPU-intensief
3) Aimbot kan worden gedetecteerd als een speler een hele tijd (paar seconden ofzo) naar een bewegende tegenspeler mikt terwijl die voor hem niet zichtbaar is. Sommige aimbots hebben een soort van storing ingebouwd, zodat hij niet handelt als een perfecte aimbot, dus daarmee moet je ook rekening houden als je een andere techniek gebruikt. Dit is ook nogal CPU-intensief.
4) Je kan ervoor zorgen dat er een bepaalde geencrypteerde dll wordt meegegeven met alle kritieke functies, die je dan niet open-source zet. Je publiceert dan enkel de API documentatie. Dit lijkt mij de beste mogelijkheid, maar zorgt ervoor dat het project niet meer 100% open source is.

[paknaald]

Ik heb hier wel eens voor de lol over nagedacht en kwam tot een paar dingen die volgens mij samen cheaters het wel moeilijk maken.

*Verplicht elke periode x updaten en alleen de up-to-date versies laten meespelen - zo doen ook veel commerciëlen het om hun onlineplay leuk te houden (ik weer niet of dit open-source is)
*Bij het opstarten hashes laten maken van belangrijke bestanden en deze checken met de andere spelers (hoeft volgens mij niet op een server, want als iedereen dezelfde heeft cheat niemand of iedereen)

Nu ga ik even verder denken omdat het open source moet zijn over wat het betekent als je de tweede implementeert terwijl cheaters gewoon in de source kunnen zien wat je doet. Dit wil zeggen dat ze het gewoon kunnen afvangen door de andere clients de gewenste output te sturen ipv de werkelijke output. Ze zouden gewoon hun client kunnen laten wachten op de anderen en onder het mom van een slechte verbinding de resultaten spiegelen. Oplossing hiervoor zou kunnen zijn:
Eenieder een ander bestand laten hashen en via een beveiligde lijn dit door te sturen. Iedere client checked de hashes van de anderen en stuurt deze, weer via een beveiligde lijn rond. Als je zorgt dat de versleuteling te hoog is om on-the-fly te kraken en de bestanden klein genoeg om razendvlug te versleutelen ben je volgens mij rond

Of niet?

Maar dan kunnen users hun bestanden veranderen nadat deze controle heeft plaatsgevonden.... Dan doe je hem toch ook tijdens het gamen at-random! Zelfs zonder de beveiligde verbindingen is een random controle nooit te voorspellen en te anticiperen.

[ Voor 12% gewijzigd door paknaald op 15-06-2003 21:48 ]

[Verwijderd]

5) Collisiedetectie controleren: kijken of iemand door een muur gaat dmv een ray-polygon collisie. De ray bestaat dan uit de vorige spelerpositie en de nieuwe.

[edit] On the fly encryptie is niet zo makkelijk te doen, omdat een goeie encryptie veel tijd inneemt. Daarom zou ik aanraden om enkel het deel te encrypteren dat de curciale data bevat.

[ Voor 38% gewijzigd door Verwijderd op 15-06-2003 21:49 ]

[Ramon]

je zou bijvoorbeeld een closed-source tooltje kunnen inbouwen wat met de server een waarde (checksum) vergelijkt met die van de grootte van het .exe bestand. Hebben ze er dan mee lopen kloten kunnen ze niet op die server?

[Falcon]

Verwijderd schreef op 15 June 2003 @ 21:47:
5) Collisiedetectie controleren: kijken of iemand door een muur gaat dmv een ray-polygon collisie. De ray bestaat dan uit de vorige spelerpositie en de nieuwe.

Ben bang dat dit allemaal aan te passen valt met de goede output

[Z!oN]

Ik heb er niet zo heel veel vestand van hoor, maar als je spel opensource is (zelf compilen) dan is een checksum toch sowiso onzin ?

Een andere optimalisatie / compiler, etc = andere check...

Correct me if i'm wrong

[Verwijderd]

The Real Falcon schreef op 15 June 2003 @ 21:48:
[...]


Ben bang dat dit allemaal aan te passen valt met de goede output

Hoe zou dat dan kunnen? Als de server waarop je speelt 100% pure is, dan kan er niks fout lopen want: ofwel loopt de gebruiker rond de muur en loopt hij te snel waardoor de server ziet dat hij cheat, ofwel loopt hij door de muur heen, wat de server ook ziet, ofwel gaat hij erover, wat resulteert in geen of te weinig zwaartekracht: dit kan ook door de server worden onderschept.

[Verwijderd]

Nog zoiets: als iemand de server code aanpast, dan zijn alle controles die op de server gebeuren ook te niet gedaan. Hierdoor zijn clan wars heel betwistbaar, omdat de rivaliserende clan eventueel een gehackte serverversie heeft, die enkel bij hun client past.

[paknaald]

reggy schreef op 15 June 2003 @ 21:50:
Ik heb er niet zo heel veel vestand van hoor, maar als je spel opensource is (zelf compilen) dan is een checksum toch sowiso onzin ?

Een andere optimalisatie / compiler, etc = andere check...

Correct me if i'm wrong

Shit Daar gaat mijn idee..... maar het zelf compileerbaar zijn is 'nog' niet opgenomen in de vereisten (of valt dat automagisch onder opensource ~ hmm ja ik denk het trouwens wel).

[Falcon]

paknaald schreef op 15 June 2003 @ 21:53:
[...]

Shit Daar gaat mijn idee..... maar het zelf compileerbaar zijn is 'nog' niet opgenomen in de vereisten (of valt dat automagisch onder opensource ~ hmm ja ik denk het trouwens wel).

Ja!

[Soultaker]

Blijkbaar hebben nogal wat mensen er moeite mee te accepteren dat er nu eenmaal geen perfecte controle mogelijk is; ook niet bij closed-source spellen trouwens. Het lijkt mij daarom niet zinnig om qua beveiliging tot het uiterste te gaan. Je kunt je beter concentreren op het werk dat relevant is voor het spel zelf en vervolgens mensen zelf uit laten maken hoe ze het spelen. Uiteindelijk is het een spelletje en dat speel je toch vooral mét elkaar (en niet in de eerste plaats tegen elkaar). Kom je tegen een clan te spelen die de boel belazert, dan speel je gewoon nooit meer tegen ze.

[IFASS]

haha, kijk maar op IRC, we komen ong tot dezelfde conclusie op het moment (irc.tweakers.net - # openfrag irc://irc.tweakers.net/openfrag )

[The-Source]

reggy schreef op 15 juni 2003 @ 21:50:
Ik heb er niet zo heel veel vestand van hoor, maar als je spel opensource is (zelf compilen) dan is een checksum toch sowiso onzin ?

Een andere optimalisatie / compiler, etc = andere check...

Correct me if i'm wrong

Dat kan worden opgelost door een installer te leveren die het spel gecompileerd en wel voor je installeert en daarnaast ook een mapje met de complete source mee levert

[Verwijderd]

Soultaker schreef op 15 June 2003 @ 21:57:
Blijkbaar hebben nogal wat mensen er moeite mee te accepteren dat er nu eenmaal geen perfecte controle mogelijk is; ook niet bij closed-source spellen trouwens. Het lijkt mij daarom niet zinnig om qua beveiliging tot het uiterste te gaan. Je kunt je beter concentreren op het werk dat relevant is voor het spel zelf en vervolgens mensen zelf uit laten maken hoe ze het spelen. Uiteindelijk is het een spelletje en dat speel je toch vooral mét elkaar (en niet in de eerste plaats tegen elkaar). Kom je tegen een clan te spelen die de boel belazert, dan speel je gewoon nooit meer tegen ze.

Klopt, maar toch is cheaten een groot probleem in de game wereld. Je kan bijna geen enkele goede speler meer vertrouwen en dat haalt de lol er wel van af. Een war verliezen tegen cheaters is ook zeker niet goed voor het gameplay gevoel en de sfeer. Een game zonder cheats bestaat echter niet.

Persoonlijk ben ik er voor dat de internetpolitie zich niet bezig gaat houdt met warez, maar met cheaters.

[Gotiniens]

je zou natuurlijk ook net zoals met steam, de gebruikers iedere keer dat ze willen spelen de cheat gevoelige bestanden laten downloaden, dit kan wel lang duren en zal bandbreedte kosten, maar als je dan zoiets als bittorent schrijft dan is een gedeelte van de bandbreede al opgelost.

maar ik weet niet of je die als source kan sturen of alleen binair, als het klein genoeg is zou je het elke keer kunnen compilen, is het een groot bestand dan kan het nog wel aardig lang duren

[Janoz]

Ik denk dat je het meeste aan Soultaker's opmerkingen hebt. Het beste is om 'by design' de boel wat hackvrij te houden. Lapmiddelen als checksums ed zijn eigenlijk gewoon een vorm van schijnveiligheid. Alles wat op de client gebeurt is te vervalsen. Richt je beveiliging dan ook vooral op de server en maak een thin client. Zorg dat de server veel bepaald mbt posities, scores en collisions en leg de focus ook vooral op het makkelijk ontdekken van valsspelen door bv veel te loggen.

Over het hacken van de server: Tja, desnoods voor clanwars werken met een uit thuis systeem. Stel je eens voor wat er met een clan gebeurt waneer uitkomt dat deze met een gehackte server spelen? Zoals rooie rinus en P daalemmer het ooit formuleerden : "Dai kunn'n wel zakjes pak'n"

[Falcon]

Klopt Janoz..

En de server valt misschien ook wel weer te beveiligen met een paswoord of zo..

[nero355]

OK het spel is opensource maar als jullie op jullie server op een of andere manier een niet aanpasbare versie zetten vooral een Windows versie kan gewoon met alleen de .exe product zeg maar dus dan is het aan julllie of er gecheat wordt of niet

Linux zou probleem kunnen opleveren met alleen de niet gecompilte bestanden voor de rest lijkt me dat het er van afhangt of jullie zelf cheaten of niet

[IFASS]

wij cheaten als een gek

nee hoor, maar het blijft natuurlijk wel een probleem...

[Verwijderd]

Soultaker schreef op 15 June 2003 @ 21:57:
Blijkbaar hebben nogal wat mensen er moeite mee te accepteren dat er nu eenmaal geen perfecte controle mogelijk is; ook niet bij closed-source spellen trouwens. Het lijkt mij daarom niet zinnig om qua beveiliging tot het uiterste te gaan. Je kunt je beter concentreren op het werk dat relevant is voor het spel zelf en vervolgens mensen zelf uit laten maken hoe ze het spelen. Uiteindelijk is het een spelletje en dat speel je toch vooral mét elkaar (en niet in de eerste plaats tegen elkaar). Kom je tegen een clan te spelen die de boel belazert, dan speel je gewoon nooit meer tegen ze.

No offends, maar imho kan een game geen toekomst hebben als het een paradijs voor cheaters wordt. Je hebt in dat geval twee scenario's:
- het spel gaat de grond in omdat er 75% cheaters rondlopen
- het spel gaat niet de grond in maar er zijn veel te veel cheaters, waardoor reviews een negatieve ondertoon krijgen

Er is ook een kleine kans dat mensen het project zo respecteren dat ze er geen cheats voor gaan ontwikkelen, maar die kans is heel klein denk ik.

[IFASS]

eigenlijk moet je dus psygisch gaan inwerken op de spelers wil je het laatste berijken

[Adion]

Zoals al wel een beetje gezegd is, zou ik er in ieder geval al voor gaan om te server zo veel mogelijk te laten afhandelen.
Dit betekend dat alle toetsaanslagen en muisbewegen (waarschijnlijk in de vorm van commando's zoals vooruit, achteruit, kijk hoger, kijk lager) naar de server gestuurd worden, en dat de server dan daaruit de positie en richting enzo bepaald.
Daarna krijg je zelf ook je eigen coordinaten terug van de server.
Om dit vloeiender te doen gaan kan je dan op de client al tonen wat er vermoedelijk gebeurd is.

Op die manier lijkt mij supersnel lopen, vliegen, door muren gaan, ... al onmogelijk indien je degene die de server runt kunt betrouwen.

Aimbots kunnen dan nog wel vrees ik...

[Soultaker]

Verwijderd schreef op 15 June 2003 @ 22:25:
No offends, maar imho kan een game geen toekomst hebben als het een paradijs voor cheaters wordt.

Dat ben ik met je eens; ik had daarom ook al wat punten genoemd om de mogelijkheden om te cheaten te beperken. Ik zag daarop echter een heleboel ontzettend ingewikkelde suggesties langskomen die een waterdicht systeem moesten opleveren, dus ik waarschuw maar alvast dat echt waterdicht nooit voor elkaar te krijgen is.

Uiteraard moet je er voor zorgen dat het aantal cheaters niet zo groot wordt dat het een kritieke massa bereikt waardoor het spel voor niet-cheaters niet meer aantrekkelijk is, maar het is, denk ik, niet haalbaar om cheaten volledig uit te bannen. Dat is ook niet noodzakelijk; als de mogelijkheden (baten gedeeld door kosten) zo beperkt zijn dat niemand er in de praktijk last van heeft, is het ook goed.

Het is daarbij van belang om na te gaan om wat voor spel het gaat. Bij individuele spellen op anonieme servers zul je meer cheaters aantreffen dan bij teamspellen met en een beperkte scene, omdat de sociale controle daarin veel groter is.

[paknaald]

Adion schreef op 15 June 2003 @ 22:42:
Daarna krijg je zelf ook je eigen coordinaten terug van de server.
Om dit vloeiender te doen gaan kan je dan op de client al tonen wat er vermoedelijk gebeurd is.

Lijkt me niet dat zoiets programmeerbaar is! De beste programmeur maakt nog fouten en zo'n programma verspelt dus soms fout, met als gevolg toch weer verspringende mannetjes en misgeschoten raakgeschoten

[Soultaker]

paknaald schreef op 15 juni 2003 @ 23:38:
Lijkt me niet dat zoiets programmeerbaar is! De beste programmeur maakt nog fouten en zo'n programma verspelt dus soms fout, met als gevolg toch weer verspringende mannetjes en misgeschoten raakgeschoten

Dat is een redelijk gangbare techniek, hoor. Je krijgt er inderdaad soms vervelende glitches door, maar in het algemeen werkt het gemiddeld juist soepeler dan wanneer de client altijd op de server zou wachten.

Een Quake3 server stuurt bijvoorbeeld niet alleen de positie van entiteiten, maar ook hun snelheid en versnelling door naar de clients, zodat die lokaal de spelsituatie kunnen extrapoleren totdat er een nieuwe update van de server komt.

[kvdveer]

De ultieme cheatpreventie is spelen met een dumb client. Dit houdt in dat zelfs de graphics op de server gegenereerd worden. Uiteraard is dat voor een actiespel onhaalbaar. In praktijk moet je gaan kijken wat je waar implementeert. Het is een illusie te denken dat een closed source game beter beschermd is dan een open source game. Van allebei is namelijk de source beschikbaar - alleen voor een closed source game is het binair.

Een game bestaat uit de de volgende functies:
- User input (moet op client)
- User display (moet op client)
- Construeren van de 3d-omgeving vanuit viewpoint.
- Renderen van graphics & sounds
- Interpreteren van userinput
- user input toepassen op karakter (bewegen, schieten, kijken)
- karakter/karakter interactie berekenen
- karakter/model interactie berekenen

Ieder van deze fucties kun je op de server of op de client uitvoeren. Als je het op de client uitvoert kan er mee gekloot worden. Als je ze op de server uitgevoerd worden genereer je mogelijk te veel dataverkeer. Het lastige is om een tussenweg te vinden.

Het schrijven van een aimbot is behoorlijk lastig als de client niet exact weet waar de andere karakters zich bevinden. Dit kun je doen door geen karakterinfo te verzenden als het karakter niet zichbaar is, of door nauwkeurigheid te verminderen op grote afstand. (op grote afstand maakt een halve meter ook niet zo veel meer uit voor het renderen). Dit maakt ook visibility mods lastig. Uiteraard maakt dat transparantie en reflectie erg lastig.


Een heel andere approach kan zijn: het bijhouden van de reputatie van een gebruiker - een modding-systeem bijvoorbeeld. Er zijn op deze planeet wel een aantal mod-systemen die redelijk werken...

[ Voor 1% gewijzigd door kvdveer op 16-06-2003 00:25 . Reden: spelling-bug ]

[.oisyn]

Verwijderd schreef op 15 juni 2003 @ 22:25:
[...]


No offends, maar imho kan een game geen toekomst hebben als het een paradijs voor cheaters wordt. Je hebt in dat geval twee scenario's:
- het spel gaat de grond in omdat er 75% cheaters rondlopen
- het spel gaat niet de grond in maar er zijn veel te veel cheaters, waardoor reviews een negatieve ondertoon krijgen

Er is ook een kleine kans dat mensen het project zo respecteren dat ze er geen cheats voor gaan ontwikkelen, maar die kans is heel klein denk ik.

Er komen pas cheaters als het heel erg populair wordt. Zie counterstrike. Beetje arrogant om te denken dat OpenFRAG ook zo populair wordt

Verder zijn alle dingen al zo'n beetje aangehaald... De server zoveel mogelijk laten doen, en de client zo min mogelijk. De client moet natuurlijk wel kunnen predicten door bijvoorbeeld extrapolatie om het soepel te laten lopen, maar in principe moet de server het laatste woord hebben.
Ook moet je uitkijken dat je niet teveel info verstuurt... in principe alleen datgene dat van belang is voor een bepaalde speler moet naar hem verstuurd worden (maar dat is sowieso al een vereiste om het netwerkverkeer laag te houden)

Verdere visibility cheats en aimbots kun je alleen voorkomen door in controle te zijn over code op de client. Dit kun je bijvoorbeeld bereiken door de client z'n gamecode te laden downloaden van de server. Als je die gamecode vaak anders laat zijn, door bijvoorbeeld reguliere updates of een soort systeem te maken die de gamecode steeds op een andere manier assembleert, is het ook een stuk moeilijker te hacken. Ook het netwerk-protocol kun je op die manier altijd wisselen: de codes genereer je van tevoren op een random manier, waardoor het protocol zelf elke keer anders is

[IFASS]

@ .oisyn: ja dat zou idd kunnen, maar je moet er uiteraard wel rekening mee houden, en het is natuurlijk fun als het, ook al word het niet populair, goed beveiligd tegen cheaten is in een open-souce projectje

[ Voor 88% gewijzigd door IFASS op 16-06-2003 17:04 ]

[Verwijderd]

Ik zou net zoiets als bij Generals gebruiken, de eigenschappen en misschien zelfs de inhoud van de files controleren met de mede spelers. Komen ze niet overeen dan is het balen en wordt je niet toegelaten. dan moet je het zo maken dat jij de files van de anderen controleert en hun die van jou en hun buren. Zo kunnen ze zichzelf ook niet uit de controlle schrijven.

[.oisyn]

Zoals al eerder is geopperd is dat niet te doen met opensource projecten, omdat iedereen in principe zou moeten kunnen compileren, en verschillende compilers, en zelfs verschillende compiler-opties, zorgen voor verschillende binaries

[Verwijderd]

waarom maak je niet zoiets als punkbuster voor q3..
en dan kunnen de servers zelf kiezen of ze het wel of niet aanzetten,
en de client moet het dan aan hebben staan als de server het ook aan heeft.

[-=bas=-]

De enige dingen die je kan voorkomen zijn zaken die op de server geregeld worden.
Alles wat op de client gebeurt of wordt bepaalt is mee te rommelen. Elke check die daar plaats vindt, kan er immers door iemand uitgesloopt worden.

Bijvoorbeeld door muren heenlopen kan je wel op de server detecteren maar als iemand met half doorzichtige polygons gaat werken (om door muren heen te kunnen kijken) dan kan je daar niets aan doen.
Net zoals die Asus-cheat die ze in hun driver voor een bepaalde GeForce kaart hadden gestopt.

Met logfiles zou je natuurlijk nog wel wat kunnen doen achteraf want een realtime-logfile interpreter maken lijkt me erg complex.

[.oisyn]

_bas_ schreef op 16 juni 2003 @ 17:21:
Bijvoorbeeld door muren heenlopen kan je wel op de server detecteren maar als iemand met half doorzichtige polygons gaat werken (om door muren heen te kunnen kijken) dan kan je daar niets aan doen.

Wat dacht je van gewoon niet sturen wat niet zichtbaar is voor iemand? Nou is de visibility check over het algemeen wat slordig, maar dat voorkomt iig al dat je de mensen van ver zit aankomen. Je kunt ze hooguit zien als ze net de hoek om komen, oid.

[kvaruni]

ah, cheaten kun je niet voorkomen. Het is net als inbreken. Zelf al leef je in een bunker, dan nog zijn er mannen die rondlopen met kernkopen en zo een gaatje maken om toch je bunker binnen te dringen.

Ben ook bezig met 2 open-source games (1 een web-based browser game, uds daar helemaal niet van toepassing, ander 3D massive multiplayer strategy game, heeft zowat dezelfde problemen te verduren als jullie)

Je moet het over een totaal andere boeg gooien. Wat je gewoon moet aanvaarden, is dat je cheaten geen 100% kan voorkomen. Maar wat als je nu eens cheats inwerkt in je game? Iedereen kan via ingebouwde commando's bepaalde cheats activeren (Wordt héél vaak gebruikt, denk maar aan al die games waar je gewoon op enter duwt en nadat je een bepaald woord getypt hebt de wondere wereld van het cheaten voor je geopend wordt).

Wat heeft dit nu als voordeel? Héél simpel, mensen zijn lui. Waarom zouden ze zelf verder uitzoeken hoe ze mogelijks kunnen cheaten door zogenaamde trainers of aim-bots of whatever als het er toch gewoon inzit? En wanneer je geen cheats wil, moet je enkel een optie aanvinken die net deze bepaalde cheats verbiedt. Voordelen? Héél eenvoudig in te bouwen, in zowel de client als het server deel. En wanneer men wil cheaten, kan men cheaten. Even terugkeren naar die inbreker. Als je je garage openlaat, daar wat waardevols verbergt en verder alle andere deuren in het huis op slot laat, waarom zou hij dan de moeite doen om verder in je huis binnen te dringen? hij heeft toch al iets waardevols!

En dan hebben we de die-hard cheaters die altijd God willen spelen. Wel, zoals je nu wel duidelijk is, kan je deze nu eens lekker niet tegenhouden! Maar lastig maken, dat kan weer wel! Want jullie hebben wel nog een troef achter de hand, namelijk de oneinidige rotzooi aan regels code. Wel, alleszinds voor een buitenstaander is dit een immense rotzooi en een huzarenwerk om dit allemaal te bekijken. Wat als je daar nu eens overal checks insteekt die kleine idngen onderzoeken die met cheats te maken hebben, en verder in de code een cheksum op deze heel specifieke code, en nog iets verder nog een controle op de controle van de cheat-preventie... Voordeel? Het kan er opieuw heel eenvoudig ingestoken worden, en de wanna-be cheater zal ongelooflijk veel afzien om toch nog daar te geraken. Weer terug naar onze inbreker. Met een alarminstallatie van 50 000 ballen en automatische machinegeweren die bewegen op elek beweging zal hij het wel al wat lastiger krijgen.

Nuja, ik hoop dat dit jullie wat helpt

[.oisyn]

kvaruni schreef op 16 juni 2003 @ 17:50:
Iedereen kan via ingebouwde commando's bepaalde cheats activeren (Wordt héél vaak gebruikt, denk maar aan al die games waar je gewoon op enter duwt en nadat je een bepaald woord getypt hebt de wondere wereld van het cheaten voor je geopend wordt).

Wat heeft dit nu als voordeel? Héél simpel, mensen zijn lui. Waarom zouden ze zelf verder uitzoeken hoe ze mogelijks kunnen cheaten door zogenaamde trainers of aim-bots of whatever als het er toch gewoon inzit? En wanneer je geen cheats wil, moet je enkel een optie aanvinken die net deze bepaalde cheats verbiedt. Voordelen? Héél eenvoudig in te bouwen, in zowel de client als het server deel. En wanneer men wil cheaten, kan men cheaten. Even terugkeren naar die inbreker. Als je je garage openlaat, daar wat waardevols verbergt en verder alle andere deuren in het huis op slot laat, waarom zou hij dan de moeite doen om verder in je huis binnen te dringen? hij heeft toch al iets waardevols!

dit is natuurlijk rijnste onzin. Als je cheats inbouwt, maar dan disablet, dan is het natuurlijk gewoon net alsof er geen cheats zijn, en volgen de modificaties dus even snel. Bovendien wordt het een multiplayer game, en dan zijn cheats dus sowieso niet gewenst. Dit in tegenstelling tot de spellen waar ook een singleplayer mode is, waar mensen er natuurlijk op los kunnen en mogen cheaten

En dan hebben we de die-hard cheaters die altijd God willen spelen. Wel, zoals je nu wel duidelijk is, kan je deze nu eens lekker niet tegenhouden! Maar lastig maken, dat kan weer wel!

oh ja, waar ging deze topic ook alweer over?

[ Voor 3% gewijzigd door .oisyn op 16-06-2003 18:00 ]

[IFASS]

ik denk idd dat cheats inbouwen gewoonweg geen nut heeft, want je zult toch altijd mensen houden die ze zelf proberen te maken

[Verwijderd]

kvdveer schreef op 15 juni 2003 @ 23:59:
... Het is een illusie te denken dat een closed source game beter beschermd is dan een open source game. Van allebei is namelijk de source beschikbaar - alleen voor een closed source game is het binair....

Hier ben ik niet volledig mee akkoord, want een binaire exe bestand kan worden geencrypteerd, wat geen snelheidsverlies betekent bij sommig exe encryptors (ik heb zo eentje gevonden :d).

[Verwijderd]

Cheats inbouwen heeft volgens mij ook geen nut, omdat échte cheaters niet willen dat andere weten dat ze cheaten, ze willen gewoon beter lijken dan anderen terwijl ze dat niet zijn. Het ergste is dan nog als het om wars gaat en dergelijke.

Waar ik nogmaals op wil benadrukken is dat ook de server kan 'gehackt' worden, dus alle controle op de server kan ook worden omzeild. Je zal dus een main server moeten maken die de naam en het IP van alle andere servers bijhoudt (dat was je hoogstwaarschijnlijk wel van plan), maar ook controleert of de gewone servers wel clean zijn.

[edit] Wat hou ik van zulke topics

[ Voor 5% gewijzigd door Verwijderd op 16-06-2003 20:16 ]

[Soultaker]

Verwijderd schreef op 16 June 2003 @ 20:11:
Hier ben ik niet volledig mee akkoord, want een binaire exe bestand kan worden geencrypteerd, wat geen snelheidsverlies betekent bij sommig exe encryptors (ik heb zo eentje gevonden :d).

En hoe krijg je Windows zover om een gecodeerde executable uit te voeren? Inderdaad, niet. Met een 'live' debugger (zoals SoftIce) heb je dus tenminste het relevante deel van de code bij executie gewoon ongecodeerd in het geheugen staan.

Uiteraard maakt dit het allemaal in de praktijk wel wat lastiger, maar in theorie is de beveiliging niet beter. Je kunt je afvragen of het oprichten van deze extra barrière het programmeerwerk waard is.

[Verwijderd]

Soultaker schreef op 16 June 2003 @ 20:33:
[...]

En hoe krijg je Windows zover om een gecodeerde executable uit te voeren? Inderdaad, niet. Met een 'live' debugger (zoals SoftIce) heb je dus tenminste het relevante deel van de code bij executie gewoon ongecodeerd in het geheugen staan.

Uiteraard maakt dit het allemaal in de praktijk wel wat lastiger, maar in theorie is de beveiliging niet beter. Je kunt je afvragen of het oprichten van deze extra barrière het programmeerwerk waard is.

Het is absoluut geen extra programmeerwerk, want er bestaan tientallen van die tooltjes gratis. Sommige werken volgens mij realtime, waardoor de software traag loopt. Een live debugger gebruiken is al een stap verder en dus minder makkelijk.

[simon]

Ik denk dat het er op neer komt dat de server dus die checks doet (snelheid van beweging, aantal kogels per seconde enz.). Meer kan je niet doen... Want dat wordt toch gehackt.

Dus kicken als de server ontdekt dat de user 'cheat'

[Soultaker]

Verwijderd schreef op 16 June 2003 @ 21:57:
Het is absoluut geen extra programmeerwerk, want er bestaan tientallen van die tooltjes gratis.

Hoe meer 'standaard' het tooltje is, des te groter de kans dat er een manier bestaat om de werking tegen te gaan.

Sommige werken volgens mij realtime, waardoor de software traag loopt.

Dat is voor een 3D-shooter uiteraard geen optie.

Een live debugger gebruiken is al een stap verder en dus minder makkelijk.

Dat klopt, maar het is geen principiële belemmering. Daarbij kan ik me voorstellen dat als je de broncode niet bij de hand hebt, je toch al graag een live debugger wilt gebruiken, aangezien daarmee veel makkelijker uit te zoeken is welke stukken code wanneer aangeroepen worden.

Overigens is het ook mogelijk om live debuggers te detecteren en het programma daarmee weigeren te starten, maar goed, dat is natuurlijk ook zo omzeilt. Ik blijf er bij dat je dan beter in je spelontwerp kunt investeren dan de ene na de andere hindernis op te werpen die wel tijd en moeite kost maar niets bijdraagt aan waar het om gaat.

[ Voor 19% gewijzigd door Soultaker op 16-06-2003 22:02 ]

[Verwijderd]

_bas_ schreef op 16 juni 2003 @ 17:21:
De enige dingen die je kan voorkomen zijn zaken die op de server geregeld worden.
Alles wat op de client gebeurt of wordt bepaalt is mee te rommelen. Elke check die daar plaats vindt, kan er immers door iemand uitgesloopt worden.

Bijvoorbeeld door muren heenlopen kan je wel op de server detecteren maar als iemand met half doorzichtige polygons gaat werken (om door muren heen te kunnen kijken) dan kan je daar niets aan doen.
Net zoals die Asus-cheat die ze in hun driver voor een bepaalde GeForce kaart hadden gestopt.

Met logfiles zou je natuurlijk nog wel wat kunnen doen achteraf want een realtime-logfile interpreter maken lijkt me erg complex.

Dit lijkt idd een van de veiligste oplossingen.
Alleen als je dit doet dan moet je een algemene server hebben die compiled is en NIET open-source, zodat er geen hacked servers kunnen komen.
Vedder mag je wel snelheid instellen, maar dit staat ingesteld op de server en als je vanuit de client te snel loopt auto kick / ban ofzo?
Ook moet je weten waar de persoon is en dat vergelijken met de server. Niet dat je de server fopt en dichter bij een tegenstander bent dan je werkelijk bent.

Wat dacht je er van om een website zo te maken dat je jezelf kan reggen met je mail adres(alles behalve hotmail enzo).
Als je dit vanuit mailadres+password doet dan is het al een stuk veiliger, want een cheater block je op mail adres.

[IFASS]

dat zou idd kunnen, maar als we het zonder reggen willen doen?

[CRiMiNaL]

ik ben toch een voorstander .... van een (RC5) key waarmee de inhoud/grote van de exe word vergeleken ... zelfs dan is cheaten nog mogelijk, maar het is het beste te implementeren in een opensource game.

[MisterData]

Verwijderd schreef op 16 June 2003 @ 21:57:
[...]

Het is absoluut geen extra programmeerwerk, want er bestaan tientallen van die tooltjes gratis. Sommige werken volgens mij realtime, waardoor de software traag loopt. Een live debugger gebruiken is al een stap verder en dus minder makkelijk.

Alles dat je aan code codeert, moet uiteindelijk ook weer gedecodeerd worden, begrijp dat goed Soms denk ik wel eens dat Palladium en TCPA wel eens handig zouden kunnen zijn voor cheat-preventie.... code is met palladium namelijk (in het geheugen) waterdicht af te schermen, dus....

[simon]

MisterData schreef op 17 June 2003 @ 21:26:
[...]


Alles dat je aan code codeert, moet uiteindelijk ook weer gedecodeerd worden, begrijp dat goed Soms denk ik wel eens dat Palladium en TCPA wel eens handig zouden kunnen zijn voor cheat-preventie.... code is met palladium namelijk (in het geheugen) waterdicht af te schermen, dus....

Maar dat heeft weinig zin bij een 100% open-source product...

[.oisyn]

CRiMiNaL schreef op 17 June 2003 @ 21:21:
ik ben toch een voorstander .... van een (RC5) key waarmee de inhoud/grote van de exe word vergeleken ... zelfs dan is cheaten nog mogelijk, maar het is het beste te implementeren in een opensource game.

[rml].oisyn in "[ Anti-Cheat] In een opensource game [ Ope"[/rml]

[Verwijderd]

.oisyn schreef op 17 juni 2003 @ 22:50:
[...]


[rml].oisyn in "[ Anti-Cheat] In een opensource game [ Ope"[/rml]

Misschien is dit een oplossing:

Een extra server/client communicatie inbouwen dat op een andere poort werkt dan het spel. Een server heeft dit systeem ook met de 'main server' die alle servers registreert en controleert. Dit stukje code gaat gewoon even handshaken met de server. Als de client dit niet goed doet met de server of een server dit niet goed doet met de main server, dan wordt de verbinding verbroken. Als je de uiteindelijke source published, dan zorg je ervoor dat die code vervangen wordt door een 'lege' handshake, dus gewoon een "ping-pong" reply.
De gebruikte code die júllie dan inbouwen vr de handshake moet dan geencrypteerd zijn. Bvb:

- Server stuurt begroeting
- Client stuurt een soort versleuteling van begroeting terug
- Server controleert of die versleuteling goed gebeurt is.

[ Voor 3% gewijzigd door Verwijderd op 17-06-2003 22:59 ]

[joepP]

Even een heel simpel ideeetje...

Er is toch wel een server progje nodig, deze maak je eventueel ook opensource. Als je nou eens alle spelerdata van een level opslaat en deze ter download aanbiedt aan de betrokken spelers, kunnen ze precies zien wie wanneer wat deed. Daaruit valt echt wel op te maken of er gecheat wordt, vooral als je de clients ook informatie over toetsaanslagen en muisbewegingen laat doorgeven.

Er kleven natuurlijk wat nadeeltjes aan, maar het is zeer transparant voor iedereen. Je voorkomt er cheaten niet geheel mee, maar wel voor een groot deel. Plus dat je het achteraf altijd nog kan checken, en bewijs hebt.

[Verwijderd]

-sorry laat maar idee is al een paar keer aangedragen. ik moet wat zorgvuldiger gaan lezen-

[ Voor 89% gewijzigd door Verwijderd op 17-06-2003 23:39 ]

[Verwijderd]

joepP schreef op 17 June 2003 @ 23:27:
Even een heel simpel ideeetje...

Er is toch wel een server progje nodig, deze maak je eventueel ook opensource. Als je nou eens alle spelerdata van een level opslaat en deze ter download aanbiedt aan de betrokken spelers, kunnen ze precies zien wie wanneer wat deed. Daaruit valt echt wel op te maken of er gecheat wordt, vooral als je de clients ook informatie over toetsaanslagen en muisbewegingen laat doorgeven.

Er kleven natuurlijk wat nadeeltjes aan, maar het is zeer transparant voor iedereen. Je voorkomt er cheaten niet geheel mee, maar wel voor een groot deel. Plus dat je het achteraf altijd nog kan checken, en bewijs hebt.

Tis geen bewijs, want het enige wat de cheater moet doen is zijn client een vals log laten wegschrijven.
Wat er volgens mij moet gebeuren is een controlemechanisme inbouwen (verificatie van een cleane client) dmv een stukje code dat niet open source wordt gezet.

[ Voor 9% gewijzigd door Verwijderd op 18-06-2003 19:38 ]

[OkkE]

Verwijderd schreef op 18 juni 2003 @ 19:37:
[...]


Tis geen bewijs, want het enige wat de cheater moet doen is zijn client een vals log laten wegschrijven.
Wat er volgens mij moet gebeuren is een controlemechanisme inbouwen (verificatie van een cleane client) dmv een stukje code dat niet open source wordt gezet.

Maar dan is het dus niet meer 100% open source, en dat is wel de bedoeling.

[Verwijderd]

misschien dat ze voor een multiplayer game op server allemaal de zelfde versie moeten draaien. dat de server scant of hij modificaties heeft gemaakt die cheatened kunnen zijn ;P of klinkt dit beetje dom? werkt vrij aardig nadat quake2 sourche code vrij gegeven was

[Verwijderd]

Gotiniens schreef op 15 June 2003 @ 22:04:
je zou natuurlijk ook net zoals met steam, de gebruikers iedere keer dat ze willen spelen de cheat gevoelige bestanden laten downloaden, dit kan wel lang duren en zal bandbreedte kosten, maar als je dan zoiets als bittorent schrijft dan is een gedeelte van de bandbreede al opgelost.

maar ik weet niet of je die als source kan sturen of alleen binair, als het klein genoeg is zou je het elke keer kunnen compilen, is het een groot bestand dan kan het nog wel aardig lang duren

[offtopic]Is ondertussen ook al achterhaalt er bestaan nu al cheats voor de laatste CS versie die nog beta is.

De enige haalbare mogelijkheid die ik zie is een cheatscanner te installen op de gameservers, die aan de user vragen of de server de HD mag scanner op cheats =>niet toelaten = kick
=>toelaten = scannen, maar vraag mij niet hoe (geen ervaring)

Ik weet wel dat het al een tijdje bestaat op counter strike!

[Soultaker]

Verwijderd schreef op 18 June 2003 @ 20:02:
De enige haalbare mogelijkheid die ik zie is een cheatscanner te installen op de gameservers, die aan de user vragen of de server de HD mag scanner op cheats =>niet toelaten = kick
=>toelaten = scannen, maar vraag mij niet hoe (geen ervaring)

Tja, en dan hack ik die applicatie even, dat 'ie altijd 't sein veilig geeft, ongeacht wat 'ie precies vind.... al dit soort suggesties zijn leuk, maar lossen het fundamentele probleem niet op.

[Guru Evi]

Ik hou me eigenlijk niet zo bezig met zulke dingen, alleen met beveiliging en servers eigenlijk en het is al aangehaald: je zou de server kunnen hacken, de client kunnen hacken of beide (als clan) ;-)
1: tis l4m3, als je gepakt wordt lijd je gezichtsverlies (als bekende speler dan toch)
2: sommige mensen willen gewoon cheaten omdat het spel te traag gaat of om hun reactiesnelheden te verbeteren door sneller te lopen ;-)
3: er is misschien een oplossing voor clanwars:
je bouwt zowel in je client als in je server een soort controle in
detecteert je server een cheatende client: kick him (or not)
detecteert je client een cheatende server: disconnect (or not) of geef
een berichtje

Zo kun je perfect je 'cheatende' server en clients bouwen voor een clan, maar zodra iemand 'clean' erop komt wordt dat of door de client(s) of door de server(s) gededecteerd.

Natuurlijk zal je bepaalde kritieke bestanden moeten hashen (vb: een stuk core en het hashprogramma zelf) met een bepaalde encryptie maar dan wel op een regelmatige basis - misschien zelfs per keer dat iemand inlogt een klein stukje hashen aan de hand van het tijdstip (anders kunnen ze de cleane hash copieren en doorsturen). Zo kun je de core noch de hasher gemakkelijk wijzigen op een goede manier. Natuurlijk zal het hier moeten gaan over een stuk bepaalde algemene data (zoals een soort actieve-cheat-instellingenbestand die op alle systemen hetzelfde blijft).

Just an idea, veranderen en verbeteren indien nodig.

Cheaten gebeurt altijd, maar om zoiets te 'tricken' heb je al heeeel veel kennis nodig.

[ Voor 7% gewijzigd door Guru Evi op 18-06-2003 21:26 ]

[Verwijderd]

is al een beetje opgekomen, maar waarom niet gewoon de gaminging communitie als politie agent laten spelen.

gewoon een optie maken dat mensen een klacht kunnen indienen tegen andere spelers en dat die dan met voldoende klachten gebanned word.

[.oisyn]

Het enige wat wel min of meer werkt is wat ik al eerder voorstelde, namelijk een stukje code dat gestuurd wordt van server naar client dat op de client uitgevoerd moet worden. Deze code moet steeds anders zijn, anders is het natuurlijk te hacken. Maar het is vrij ingewikkeld om de code elke keer anders te laten zijn... er zitten altijd wel herkenningspunten in.

Maar we moeten ophouden met discussieren over anti-cheatpreventie aan de client kant. Sommige dingen zijn onmogelijk om te verwijderen, zoals aimbots en visibility cheats. En die kunnen beide zonder ook maar 1 regel van de gamecode clientkant te wijzigen. Er moet dus aan de serverkant gezorgd worden dat deze cheats vrij nutteloos worden. Aan aimbots is weinig te doen. Iemand die vaak headshots doet kan een aimbot gebruiken, maar hij kan ook gewoon goed zijn. Visibility cheats zijn op zich wel wat te doen, namelijk alleen info versturen over entities die voor de speler ook echt zichtbaar zijn

En verder de server zoveel mogelijk laten doen, zodat jump en speed cheats bijvoorbeeld niet mogelijk zijn

En zoals ik al eerder zei, het is echt nutteloos om hier nu al enorm mee bezig te zijn. Zorg eerst maar dat er een werkend spel op tafel komt, cheaters komen toch pas als iets populair wordt

[Olaf van der Spek]

kvdveer schreef op 15 June 2003 @ 23:59:
De ultieme cheatpreventie is spelen met een dumb client.

Dat is minder ultiem dan je zou denken. Zeker in de toekomst als computer vision verder ontwikkeld is.

Dit houdt in dat zelfs de graphics op de server gegenereerd worden. Uiteraard is dat voor een actiespel onhaalbaar. In praktijk moet je gaan kijken wat je waar implementeert. Het is een illusie te denken dat een closed source game beter beschermd is dan een open source game. Van allebei is namelijk de source beschikbaar - alleen voor een closed source game is het binair.

Dat is dus geen source code. En reken maar dat het met source code veel makkelijker is cheats voor een game te schrijven.

[Olaf van der Spek]

.oisyn schreef op 16 juni 2003 @ 11:39:
Verdere visibility cheats en aimbots kun je alleen voorkomen door in controle te zijn over code op de client. Dit kun je bijvoorbeeld bereiken door de client z'n gamecode te laden downloaden van de server. Als je die gamecode vaak anders laat zijn, door bijvoorbeeld reguliere updates of een soort systeem te maken die de gamecode steeds op een andere manier assembleert, is het ook een stuk moeilijker te hacken. Ook het netwerk-protocol kun je op die manier altijd wisselen: de codes genereer je van tevoren op een random manier, waardoor het protocol zelf elke keer anders is

Als de game-code alleen anders wordt geassembleerd kun je de client gewoon zo aanpassen dat die de update links laat liggen.

[ Voor 26% gewijzigd door Olaf van der Spek op 18-06-2003 21:56 ]

[Soultaker]

Guru Evi schreef op 18 June 2003 @ 21:23:
Zo kun je perfect je 'cheatende' server en clients bouwen voor een clan, maar zodra iemand 'clean' erop komt wordt dat of door de client(s) of door de server(s) gededecteerd.

En hoe detecteer je dat iemand clean is?

Natuurlijk zal je bepaalde kritieke bestanden moeten hashen (vb: een stuk core en het hashprogramma zelf) met een bepaalde encryptie maar dan wel op een regelmatige basis - misschien zelfs per keer dat iemand inlogt een klein stukje hashen aan de hand van het tijdstip (anders kunnen ze de cleane hash copieren en doorsturen). Zo kun je de core noch de hasher gemakkelijk wijzigen op een goede manier. Natuurlijk zal het hier moeten gaan over een stuk bepaalde algemene data (zoals een soort actieve-cheat-instellingenbestand die op alle systemen hetzelfde blijft).

Dat werkt niet. Ik kan prima een hashcode berekenen aan de hand van de originele 'core' en het huidige tijdstip, die terugsturen, en vervolgens een andere 'core' gebruiken (als ik dan toch al in die core heb zitten hacken, kan dat er ook nog wel bij).

Cheaten gebeurt altijd, maar om zoiets te 'tricken' heb je al heeeel veel kennis nodig.

Accoord, maar dat lijkt me geen lange-termijn oplossing. Uiteraard helpt het wel dat het 'moeilijk' is, maar je kunt, denk ik, veel beter de voordelen van het cheaten beperken. Als de kosten (het hacken van het systeem) lager zijn dan baten (de voordelen die door de hack geboden kunnen worden) dan blijven hacks vanzelf uit.

[Sponge]

Niet alles gelezen, maar goed:

op www.gamasutra.com staat er een artikel over cheaters e.d., was wel interessant artikel.
op www.gamedev.net -> multiplayer forum moet je zoeken op "cheat", ik heb er eens eens topic gepost met een aantal verscheidene cheat methodes, en hoe je ze tegen kon gaan ofzo

- Packets encrypten kan .. mischien als key een hash van de file (crc32 oid)
- Variabele packet header (ene keer is "1" lopen, de andere keer schieten..ofzo)
- Won id principe
- Doet iets tegen "geheugen cheaten".. het is zo simpel, gewoon de waarden xorren oid.
- Kritieke dingen == server (health, ammo, e.d.) (anders lock in m'n health gewoon op 100..)
- Wapens vuren doet server.. zie ook www.flipcode.com -> networking (links van scherm)

Zo kan ik nog wel ff doorgaan met de meest simpele dingen. Gamedev.net forum is hier erg interessant voor.

Maar.. zoals al vele malen hierboven gezegd, is het niet te voorkomen.. tenzij je screenshots wilt ontvangen en alleen de key states gaat versturen, alhoewel dat niet echt een success zal worden.

Alles wat client side is, valt te veranderen.

Voor mijn eigen MMPOG heb ik verscheidene technieken bekeken, en ingevoerd.. en heb ook geleerd dat er gewoon dingen zijn waar je niets tegen kan doen.

hth

[Verwijderd]

Won ID zoals bij Half-Life werkt natuurlijk niet open source, dan pak je zo weer een nieuwe key, want die is toch gratis. Dus dan komt het volgende probleem, hoe ban je cheaters, niet dus of op ip. IP bans werken natuurlijk alleen op statische ip's.

Ik ben toch van mening dat het beter is om gewoon veel dingen server-side te doen en geen encryptie te gebruiken ofzo. Dat vertraagt denk ik alleen de gameplay. Als het spel een succes wordt komen er waarschijnlijk vanzelf anti-cheat systemen, daar hoef je zelf niet eens aan te werken. Als daar goed werkende systemen tussen zitten kan je misschien wel met die mensen samen gaan werken op dat gebied.

[Olaf van der Spek]

Verwijderd schreef op 19 juni 2003 @ 12:15:
Won ID zoals bij Half-Life werkt natuurlijk niet open source, dan pak je zo weer een nieuwe key, want die is toch gratis. Dus dan komt het volgende probleem, hoe ban je cheaters, niet dus of op ip. IP bans werken natuurlijk alleen op statische ip's.

Ik ben toch van mening dat het beter is om gewoon veel dingen server-side te doen en geen encryptie te gebruiken ofzo. Dat vertraagt denk ik alleen de gameplay. Als het spel een succes wordt komen er waarschijnlijk vanzelf anti-cheat systemen, daar hoef je zelf niet eens aan te werken. Als daar goed werkende systemen tussen zitten kan je misschien wel met die mensen samen gaan werken op dat gebied.

Won ID kan opzich wel nut hebben, maar dan moet je wel een centrale server hebben.
Dan hoef je alleen bij de uitgifte van Won ID IPA ranges te controleren. En als je een range banned, hebben mensen die al een Won ID hebben daar geen last van.

Er zijn wel wat zwakke punten, maar het is beter dan zo maar IPA ranges bannen.

[Soultaker]

41.6C.6D.61.72 schreef op 19 juni 2003 @ 08:35:
- Packets encrypten kan .. mischien als key een hash van de file (crc32 oid)

Dat is inderdaad wel een aardig punt: ik kan me herinneren dat iD software voor de Quake 3 netwerk code een eigen variant op MD5 (of iets dergelijks?) in elkaar gedraait hadden. Per pakketje wordt dus een hash van de inhoud meegestuurd. De server dropt alle niet-kloppende pakketjes. Het idee was daarvan niet zozeer dat dat onkraakbaar zou zijn, maar dat het daardoor tenminste noodzakelijk was om de code te reverse engineren (wat voor een gewoon protocol doorgans niet nodig is).

Uiteraard weerhield dit mensen er niet van om die encrypte te kraken, maar aangezien reverse engineering (zoals redelijk gebruikelijk) expliciet door de license verboden wordt, werden mensen nogal ontmoedigd om de (illegaal verkregen) informatie openbaar te maken. Uiteindelijk waren er dan ook een aantal websites waar het hele Quake 3 protocol gespecificeerd stond, maar dan zonder informatie over de cruciale hash code.

In principe zou dit ook werken bij een programma waarvan de broncode beschikbaar is, tenzij er dan een GPL-achtige licentie gebruikt wordt.

[ Voor 7% gewijzigd door Soultaker op 19-06-2003 14:40 ]

[Verwijderd]

Wat ik eigenlijk een schitterende oplossing vond is een kleine client te maken, die eigenlijk niet meer is dan een soort van downloader, dewelke de gamecode van de server haalt, de server checkt de gamecode dan om de x tijd op de masterserver. Op die manier houd je de code 1/ gemakkelijker updatebaar (niet steeds enorme updates doorsturen enzo)

*tobe edited*

[Olaf van der Spek]

Verwijderd schreef op 19 June 2003 @ 14:56:
Wat ik eigenlijk een schitterende oplossing vond is een kleine client te maken, die eigenlijk niet meer is dan een soort van downloader, dewelke de gamecode van de server haalt, de server checkt de gamecode dan om de x tijd op de masterserver. Op die manier houd je de code 1/ gemakkelijker updatebaar (niet steeds enorme updates doorsturen enzo)

*tobe edited*

Nee, elke keer de volledige code doorsturen. Denk je dat dat sneller gaat dan een update doorsturen om de zoveel tijd?

[leuk_he]

een belangrijk deel echte oplossing is niet meer naar de client te sturen dan hij echt nodig heeft.
-Als een speler achter een muur staat -> dit niet naar andere spelers sturen.
-Als een speler niet in het blikveld staat -> dit niet naar andere spelers sturen.

Aimbot probleem is daarmee nog niet echt opgelost. Maar doorzichtige muren wel.

kvdveer heeft dat hierboven al aardig beschreven

Reputatie is maar zo zo. Als je heel goed bent zullen er mensen tegen je stemmen omdat ze denken dat je cheat. En sommige mensen maken er een spelleltje van om eerste net genoeg reputatie op te bouwen en dan zoveel mogelijk schade aan te richten.

Deel van de oplossing is 2 gebieden te maken (2 typen server): No cheat allowed, en cheat allowed(wiekan het beste cheaten).

[ Voor 40% gewijzigd door leuk_he op 19-06-2003 15:36 . Reden: nog eens goed gelezen ]

[Olaf van der Spek]

leuk_he schreef op 19 June 2003 @ 15:08:
een belangrijk deel echte oplossing is niet meer naar de client te sturen dan hij echt nodig heeft.
-Als een speler achter een muur staat -> dit niet naar andere spelers sturen.
-Als een speler niet in het blikveld staat -> dit niet naar andere spelers sturen.

Aimbot probleem is daarmee nog niet echt opgelost. Maar doorzichtige muren wel.

Het nadeel daarvan is dat het CPU time kost om die checks uit te voeren.

[Olaf van der Spek]

Soultaker schreef op 19 June 2003 @ 14:36:
Dat is inderdaad wel een aardig punt: ik kan me herinneren dat iD software voor de Quake 3 netwerk code een eigen variant op MD5 (of iets dergelijks?) in elkaar gedraait hadden. Per pakketje wordt dus een hash van de inhoud meegestuurd. De server dropt alle niet-kloppende pakketjes. Het idee was daarvan niet zozeer dat dat onkraakbaar zou zijn, maar dat het daardoor tenminste noodzakelijk was om de code te reverse engineren (wat voor een gewoon protocol doorgans niet nodig is).

Waarom stelden ze in de licentie dan niet gewoon dat het verboden was om het protocol te reverse-engineren?

[leuk_he]

Verwijderd schreef op 16 juni 2003 @ 17:05:
Ik zou net zoiets als bij Generals gebruiken, de eigenschappen en misschien zelfs de inhoud van de files controleren met de mede spelers.

Sorry, hier is een redelijk simple workarround voor als cheater. Als er controler op files wordt uitgevoerd wordt deze niet uitgevoerd op het nu runnende "aangepaste" programma, maar op een set files in een andere directory die wel goed is.

[leuk_he]

OlafvdSpek schreef op 19 June 2003 @ 15:27:
[...]

.. niet sturen wat niet zichtbaar is...

Het nadeel daarvan is dat het CPU time kost om die checks uit te voeren.

Het voordeel is dat je minder over je netwerk hoeft te sturen. Tenzij je ALLES, eigenlijk je hele rendering gaat sturen.

[Soultaker]

OlafvdSpek schreef op 19 June 2003 @ 15:34:
Waarom stelden ze in de licentie dan niet gewoon dat het verboden was om het protocol te reverse-engineren?

Volgens mij kan dat een stuk minder makkelijk (maar ik ben geen expert). Ik kan me voorstellen dat als dat zou kunnen, dat dan bijvoorbeeld Microsoft keihard zou optreden tegen allerlei MSN clients, die wel van hun netwerk gebruik maken maar niet hun advertenties laten zien.

[IFASS]

maar als ik het zo zie is het dus eigenlijk het kiezen van of preciese controle/snelheid

i mean:

preciese controle:
zoveel mogelijk door server laten doen maar gaat ten koste van de snelheid (ping)

snelheid:
minder checks mogelijk maar wel sneller

[ Voor 3% gewijzigd door IFASS op 25-06-2003 19:45 ]

[MisterData]

Anders doe je die checks toch steeksproefgewijs? Iedere ronde checked de server dan een andere speler, en als iemand het vermoeden heeft dat iemand cheat, laat je de server diegene checken... Verder denk ik dat je ook een zekere onprecizie moet inbouwen...

[.oisyn]

IFASS schreef op 25 June 2003 @ 19:44:
preciese controle:
zoveel mogelijk door server laten doen maar gaat ten koste van de snelheid (ping)

niet helemaal, de pingtijden zullen niet stijgen als de server meer gaat doen. Wat je echter wel merkt is dat je relatief meer last krijgt van dezelfde ping, omdat de client meer moet wachten op antwoord van de server.

Bijvoorbeeld in het ergste geval bij een ultra-thin client die alleen het grafische werk doet: als je de schiet-toets indrukt, gaat er een bericht naar de server. De server reageert hierop en schiet vervolgens een kogel, die toevallig iemand doodt. Vervolgens krijg je een update dat je wapen afgeschoten is en dat er iemand dood neervalt.

Door de round-trip time zie je de knal pas later dan dat je de knop hebt ingedrukt. En dat zijn weer dingen die min of meer op te lossen zijn door goede prediction. Je zou bijvoorbeeld op het moment van het drukken op de schietknop het geluid en de wapen-animatie al af kunnen spelen (mits je nog kogels hebt). Evt. kun je aan de client-kant ook nog kijken of je iemand raakt en al dan niet alvast beginnen met het afspelen van de dood-ga-animatie van die andere speler. Is het door een hoge ping nou net het geval dat je eigenlijk misschiet terwijl je op de client denkt dat het raak was, dan krijg je daar een update van en kun je de animaties cancelen. Goed, dit zorgt natuurlijk voor een niet echt mooie glitch in het spel, maar als je dit afweegt tegen de server-mis/client-raak ratio en natuurlijk gewoon het feit dat je cheaten wilt voorkomen is dit imho wel acceptabel.

Verder zou je nog bij de schietmessage een timestamp op kunnen geven, zodat de server terug kan rekenen tot het moment dat de client daadwerkelijk geschoten heeft. Deze timestamp kan natuurlijk nooit langer dan ping/2 ms in het verleden liggen. Daardoor creeer je wel iets meer ruimte voor cheaters, maar veel is het niet. Bovendien, wat is nou het voordeel dat als je op de knop drukt dat je dan eigenlijk 20 ms eerder schoot? Da's ten eerste al 1/50e van een seconde, dus nauwelijks merkbaar, plus het spel wordt er niet makkelijker door aangezien je nog steeds dezelfde tijdsperiode hebt om raak te schieten. Je hoeft alleen maar iets later op de knop te drukken (wat alleen maar verwarrend kan werken)