Voorkomen van "nep data" in webservice

[NickThissen]

Ik ben bezig met het ontwikkelen van een Windows applicatie (C# .NET) welke communiceert met een web service (WCF). De applicatie draait op de achtergrond terwijl de gebruikers een race spel spelen, en verzamelt data zoals hun rondetijden. Deze worden daarna opgestuurt naar de webservice, welke ze in een database opslaat.

Mijn probleem is eigenlijk vrij eenvoudig: hoe voorkom ik dat de meer technisch aangelegde mensen mijn applicatie eventjes decompilen en "nep rondetijden" gaan doorsturen?

De webservice heeft een method "UploadLaptime" die naast wat user authentication een paar eigenschappen van een ronde accepteert, onder andere de rondetijd, wat sector tijden, gebruikte auto/track, etc.

Op het moment zou het heel eenvoudig zijn voor iemand om een eigen client te schrijven die een nep rondje upload met een ronde tijd die veel beter is dan hij werkelijk kan rijden. Voor zover ik kan zien heb ik geen enkele manier om 100% zeker te zijn dat een ronde "echt" is en niet zomaar ingevuld in Fiddler of wat dan ook.

Ik zou natuurlijk de data encrypted kunnen opsturen, maar wat schiet ik daar mee op? De encryptie zal op de client moeten gebeuren dus met een beetje goeie decompiler kun je dat ook wel nabouwen. Dit is eigenlijk het probleem waar ik tegen aan loop: alles wat ik kan bedenken om dit tegen te gaan verloopt op de client en kan iemand dus ook gewoon na doen, met wat moeite.


Als er niets tegen te doen is, hebben jullie dan misschien wat tips wat ik kan doen om het in ieder geval wat moeilijker te maken? Als het wat moeite kost dan vertrouw ik mijn doelgroep er wel op om niet vals te spelen, maar momenteel is het weel heel erg gemakkelijk heb ik het idee...

PS:
Ik zou deze applicatie later ook graag open source maken dus middelen tegen decompilen helpen ook niet echt. Hopelijk zijn er betere alternatieven?

[ Voor 4% gewijzigd door NickThissen op 08-02-2016 14:17 ]

[Salandur]

Je zou SSL versleuteling kunnen gebruiken met een client certificaat dat je alleen in de installer mee distribueert. Dat maakt het iets lastiger, hoewel je eigenlijk nooit een sluitende oplossing kan vinden omdat (cr|h)ackers altijd wel iets zullen proberen & vinden

[Styxxy]

Kan je ook niet per "track" de minimum tijd berekenen (rekening houden rijden tegen topsnelheid en de afstand)? Alle waarden onder dit theoretische minimum, zijn fake tijden;

[kunnen]

Je kunt een screenshot van het spelvenster meesturen, precies op het moment dat een lap/ronde voorbij is. Als het goed is staat daar dan dezelfde tijd als de tijd die opgestuurd wordt; zo kun je in ieder geval handmatig tijden controleren.

Het is een bak extra werk voor een "hacker" om ook de screenshots te gaan faken.

[Janoz]

SSL versleuteling en encryptie zijn natuurlijk compleet zinloos in deze context. Dat helpt alleen tegen MitM attacks waar hier geen sprake van is.

Eigenlijk de enige oplossing is om niet (alleen) de rondetijden, maar (ook) het gereden rondje op te sturen. Op die manier is het op de server te controleren (steekpriefsgewijs bv) of een dergelijk rondje uberhaupt wel mogelijk is.

[Cloud]

Zou je iets kunnen met MAC? Ligt natuurlijk dichtbij volledig encryptie toepassen maar ja. Het enige probleem is denk ik je secret key echt geheim houden maar daar zijn vast wel mogelijkheden voor denk ik?

Bijvoorbeeld delen van je app.config encrypten, zie dit.

Zie:

quote: https://msdn.microsoft.co...raphy.hmac(v=vs.110).aspx

A Hash-based Message Authentication Code (HMAC) can be used to determine whether a message sent over an insecure channel has been tampered with, provided that the sender and receiver share a secret key.

Het zal misschien wel met wat inzet te breken zijn maar ik denk dat je hier mensen al aardig mee ontmoedigd. Verder gewoon adequaat tegen misbruik optreden en dat duidelijk vermelden.

[ Voor 46% gewijzigd door Cloud op 08-02-2016 15:26 ]

[SinergyX]

kunnen schreef op maandag 08 februari 2016 @ 15:02:
Je kunt een screenshot van het spelvenster meesturen, precies op het moment dat een lap/ronde voorbij is. Als het goed is staat daar dan dezelfde tijd als de tijd die opgestuurd wordt; zo kun je in ieder geval handmatig tijden controleren.

Het is een bak extra werk voor een "hacker" om ook de screenshots te gaan faken.

Maar wat hem ook weer dus een bak tijd kost en mocht er toch even iemand tussen zitten met tijd teveel, moet je die ook nog eens herkennen.

Styxxy schreef op maandag 08 februari 2016 @ 14:56:
Kan je ook niet per "track" de minimum tijd berekenen (rekening houden rijden tegen topsnelheid en de afstand)? Alle waarden onder dit theoretische minimum, zijn fake tijden;

Hiermee haal je inderdaad wel gros van de '1 seconde baantje rond' eruit, maar de 'eerlijke' valspelers die legitieme tijden laten posten ondervang je dan ook niet.

[Waster]

Volgens mij is de oplossing om het te encrypten. Als je de versleuteling van rondetijden op de client doet en in een debieus algoritme kun je in ieder geval niet zomaar een client schrijven. Het enige wat een hacker dan kan doen is de code decompilen, wat vrij makkelijk is voor .NET. Dus als je dotfuscator eroverheen gooit zou het haast onmogelijk moeten zijn voor de hacker om dit te faken.

[vso]

meest effectieve is actie en reactie niet gelijkwaardig te behandelen.. iemand "hackt" je moment A en jij doet + ? tijd erna een reactie (wissen v.d tijden) .. of bannen.. gaat de hacker jij al de mist in met debuggen.. want hij weet niet welke actie de "ban of wissen vd. tijden, als gevolg van zijn actie is"

Als jij 128 bit string gebruikt om tussen client/server te communiceren .. van winst/verlies etc ..
kan jij enorm veel controles client side gebruiken/inbouwen .. verander deze string regelmatig want jij bepaald wat je daadwerkelijk gebruikt .. shift deze in in fysieke code / string positie van de key values .. gebruik code obscure-software .. en release deze at random intervallen ..
maak de string dan weer 128 , 256, 1028, oeps 256, en andere variaties ..

Nu ja dan heb je de luie script kid er al uit gefiltert, .. de "winnaar" tja .. zou je die niet in dienst nemen

[ Voor 13% gewijzigd door vso op 08-02-2016 15:51 ]

[AlphaRomeo]

@vso: dat gaat dus niet werken als de client code open source wordt.

[Alexji]

Zoals bovenstaand al vermeld zou ik niet te veel tijd stoppen in het obfuscaten/encrypten van de rondetijden. Dit is uiteindelijk een kat & muis spelletje.

Volgens mij heb je bij dit soort dingen meer een een community-driven "report" systeem waarbij verdachte rondetijden worden aangemerkt (bij x aantal reports de rondetijden al van een andere kleur/disclaimer voorzien) en dan zelf bepalen of je deze tijd toestaat of bij genoeg reports automatisch de tijd verwijderen (natuurlijk ook weer vatbaar voor misbruik).

[Haan]

Het is eigenlijk niet mogelijk om te voorkomen, ik heb me zelf toevallig bij wijze van hobby verdiept in de racegame Asphalt 8, wat een behoorlijk grote game is. Op Windows (en Android )wordt die game aan alle kanten gehackt, waarbij je dus ook de lap times naar wens in kunt stellen. Met een tool als CheatEngine kan je altijd met genoeg geduld achterhalen waar variabelen gezet worden, omdat deze tool naar de assembly code kijkt. Encryptie maakt het moeilijker om een bepaald geheugenadres te vinden, maar uiteindelijk kom je er toch. Wat vaak gedaan wordt is een XOR operatie op een adres, zodat je niet direct naar een waarde kunt scannen.
Omdat de lap times ingame dus al gemanipuleerd kunnen zijn, heb je dan helemaal niks meer aan het beveiligen van je webservice omdat de request gewoon valide is. Dan zal je toch terug moeten vallen op een schatting van de minimale rondetijd, maar wat je dan gaat krijgen is dat ze rond die tijd gaan zitten zodat niet meer is uit te maken of het gemanipuleerd is of niet.

Dit neemt verder niet weg dat je de webservice wel tegen manipulatie moet beschermen, anders wordt het wel heel makkelijk om gemanipuleerde data in te schieten.

[Standeman]

Worden de races singleplayer gespeeld of multiplayer?

In het laatste geval kan je iedereen zijn ronde tijden versturen en kom je afwijkingen vanzelf tegen..

[ Voor 12% gewijzigd door Standeman op 08-02-2016 16:03 ]

[gamer13]

Wat Janoz zegt is een playback van de ronde de beste optie. Gezien de playback plausibel moet zijn (binnen de boundaries van de track) valt deze niet extreem te forgen. Het is nog steeds mogelijk, maar dat neemt voor de hacker enorm veel tijd in beslag. Bovendien moet de playback ook nog eens correleren met de rondetijd.

De playback zou je kunnen sampelen op X keer per seconde, waarna je die vervolgens kunt terugrekenen tot de rondetijd. Als dit overeenkomt, dan is het een geldige entry, anders wordt het ongeldig verklaard.

[NickThissen]

Bedankt voor de reacties alvast, een paar zijn zeker nuttig.


Zelf had ik ook al gedacht om het hele rondje mee te sturen. Het is dan even de vraag hoe je een "rondje" definieert, het makkelijkst (en ook makkelijk in te bouwen) is om op vast interval de positie rond de baan "spline" op te slaan (na 1s is de auto op 2.13%, na 2s is hij op 3.59%, etc). Dat is zeker mogelijk en ook genoeg werk om hacken tegen te gaan, dus ik denk dat ik inderdaad die kant op ga.

Het grootste probleem daar is inderdaad dat het nogal wat werk is om handmatig na te moeten checken of een rondje wel echt is. Dit kan bijna niet automatisch (er zijn tientallen verschillende auto's met elk heel verschillende rondetijden mogelijk) dus moet ik het echt met de hand gaan doen. Iemand die zonder veel moeite gewoon wat oplopende getallen van 0-100% ingeeft in de verwachtte intervallen (hij zou immers kunnen checken op welke intervallen de data gesampled wordt) komt er vast vrij makkelijk doorheen... Dus heel erg nuttig is het ook weer niet. Maar het is in ieder geval een manier om verdachte rondjes na te checken.

Hier komt echter wel nog een probleem kijken; ik wil namelijk niet genoeg data opslaan om elk rondje precies na te kunnen checken. Het is namelijk nogal een serieus spel (sim eigenlijk) en als men het idee heeft dat ik te veel data aan het op slaan ben (ik zou bijv alle gas/rem en stuur inputs kunnen opslaan, en nog veeeeel meer), dan gaat het niet populair worden omdat dit "geheime" informatie is. Niet omdat men cheat, maar omdat dit soort data veel waard is voor de snellere rijders. Dit soort data wordt door real-life telemetry programma's gebruikt om rijstijl te verbeteren etc, als zomaar iedereen aan deze data komt van de snelle mensen dan is dat niet best.
Maar ik denk niet dat het een groot probleem zal zijn zolang de data die ik opsla ruw genoeg is. Men moet mij dan maar vertrouwen (grootste deel zal de source code niet snappen) dat ik inderdaad niet alle data op sla.

[Cloud]

Je hoeft denk ik ook niet alles te checken maar primair de afwijkingen t.o.v. de gemiddelden. Gegeven genoeg 'echte' data, dan kun je die data gebruiken om nieuwe rondjes tegen te checken. Niet alleen op totale ronde tijd maar vooral ook op de segments. Uiteraard rekening houden met de verschillende voertuigen. Er zullen ook mensen zijn die niet cheaten om op de 1e plaats te komen maar cheaten om überhaupt mee te komen. Die zullen wellicht één segment flink sneller maken zodat hun totale rondetijd nog een beetje acceptabel is.

Misschien kun je een aantal spelers inschakelen die je vertrouwd, om per baan, per auto, wat echte waarden binnen te krijgen?

[ Voor 3% gewijzigd door Cloud op 08-02-2016 16:33 ]

[WernerL]

Het rondje + totale tijd meesturen en vervolgens anomaly detection algoritme draaien op de complete dataset om te kijken of er afwijkende entries zijn.

Local outlier algoritme bijvoorbeeld: Wikipedia: Local outlier factor

Kost wel wat moeite om te implementeren, maar wellicht zijn er libraries beschikbaar die dit al voor je geïmplementeerd hebben.

[Cilph]

De enige foolproof manier is om de client gewoon niet te vertrouwen en een replay van de match naar de server sturen. De server kan zo de tijden verifieren wanneer/als hij dat wil. De vraag is alleen hoe je zo'n replay gaat encoden - als opsomming van inputs? snapshots van positie+snelheid?, en hoe je dat dan gaat verifieren (de hele client simuleren lijkt me niet wenselijk)

Dit voorkomt dan helaas geen Tool Assisted Speedruns, maar die kun je uiteindelijk dan ook niet voorkomen. Verifieren of er een mens of machine achter het 'toetsenbord' zit is nog geen opgelost probleem.

[ Voor 21% gewijzigd door Cilph op 09-02-2016 11:32 ]

[HuHu]

NickThissen schreef op maandag 08 februari 2016 @ 16:18:
Bedankt voor de reacties alvast, een paar zijn zeker nuttig.


Zelf had ik ook al gedacht om het hele rondje mee te sturen. Het is dan even de vraag hoe je een "rondje" definieert, het makkelijkst (en ook makkelijk in te bouwen) is om op vast interval de positie rond de baan "spline" op te slaan (na 1s is de auto op 2.13%, na 2s is hij op 3.59%, etc). Dat is zeker mogelijk en ook genoeg werk om hacken tegen te gaan, dus ik denk dat ik inderdaad die kant op ga.

Ik zou niet opslaan hoe ver de speler is over de baan, maar de exacte x, y(, z) coordinaten van het voertuig. Dan krijg je daaruit een 2D/3D spline, die je kunt vergelijken met de baan en andere spelers (bijv. Hausdorff afstand). Ook kun je lokaal controleren of de maximumsnelheid van een auto, minimale bocht/curve, et cetera wel mogelijk zijn.

[ Voor 45% gewijzigd door HuHu op 09-02-2016 12:23 ]

[NickThissen]

Cilph schreef op dinsdag 09 februari 2016 @ 11:30:
De enige foolproof manier is om de client gewoon niet te vertrouwen en een replay van de match naar de server sturen. De server kan zo de tijden verifieren wanneer/als hij dat wil. De vraag is alleen hoe je zo'n replay gaat encoden - als opsomming van inputs? snapshots van positie+snelheid?, en hoe je dat dan gaat verifieren (de hele client simuleren lijkt me niet wenselijk)

Dit voorkomt dan helaas geen Tool Assisted Speedruns, maar die kun je uiteindelijk dan ook niet voorkomen. Verifieren of er een mens of machine achter het 'toetsenbord' zit is nog geen opgelost probleem.

Het opsturen van de "replay" (encoded als snapshots van positie+snelheid bijv inderdaad) is dus wel een goeie oplossing maar het verifieren is het grote probleem in dit geval. Dit kan gewoon echt niet automatisch tenzij ik het spel ga nabouwen. Dat is natuurlijk onzin. (Even voor de duidelijkheid: het spel staat verder los van dit programma, ik heb het spel niet geschreven).

Maar het maakt het wel veel werk om een nep rondje te produceren.

Ik ben er ook niet op uit om cheaters tegen te gaan die daadwerkelijk in het spel zelf cheaten (hoe dan ook, door een "computer" te laten sturen ofzo). Dat is misschien wel mogelijk (elk spel is wel te hacken) maar is toch wel redelijk dicht getimmerd. Als iemand het klaar krijgt om een rondje te rijden dan kan ik er van uit gaan dat er niet gecheat is, en zo wel nou ja dan zijn er veel meer problemen waar ik verder niet aan wil denken

HuHu schreef op dinsdag 09 februari 2016 @ 12:22:
[...]

Ik zou niet opslaan hoe ver de speler is over de baan, maar de exacte x, y(, z) coordinaten van het voertuig. Dan krijg je daaruit een 2D/3D spline, die je kunt vergelijken met de baan en andere spelers (bijv. Hausdorff afstand). Ook kun je lokaal controleren of de maximumsnelheid van een auto, minimale bocht/curve, et cetera wel mogelijk zijn.

Die data heb ik helaas niet, enkel de afstand over de spline. De sim geeft best wel veel data vrij in de vorm van een mooie SDK maar met opzet zijn er wat dingen dicht getimmerd om cheaten te voorkomen en om realistisch te blijven. Zo zou je bijvoorbeeld naar de bandenslijtage kunnen kijken (tot tig cijfers achter de komma) om te bepalen wanneer een band blokkeert en op die manier een traction control bouwen. Om dat tegen te gaan kun je niet live de banden slijtage zien (plus dat is ook niet mogelijk in real life racen). Daadwerkelijke x,y,z coordinaten kan ik ook niet live uitlezen voor vergelijkbare redenen.

De afstand langs de spline en snelheid is verder simpel, dus ik denk dat ik het daar bij hou.