Come prevenire l'imbroglio nei nostri giochi (multiplayer)?

Question

Se stai scrivendo un gioco dovresti pensare agli imbroglioni e come impedirgli di imbrogliare.

Non penso solo ai giochi multiplayer mmo, ma anche ai giochi mplayer in singleplayer o "casalingo" p2p.

Quando il gioco si basa su un'architettura completamente client-server, il lavoro è quasi finito, penso, ma ci sono anche hack da muro o altro.

Ho creato il mio gioco p2p e qualche tempo dopo sono apparsi imbroglioni. Erano solo scriptkiddies che utilizzavano il cheat engine e provavano speedhacks e hack di memoria.

La maggior parte dei speedhacks aggancia il gettickcount. Ho risolto i speedhackers con il seguente semplice trucco. Sto solo monitorando il valore time()-GetTickCount() e se la differenza cambia, ci sono degli inganni.

La corruzione della memoria può essere risolta mantenendo una copia con hash da qualche parte e spostandola sempre e rilanciandola sempre con un valore casuale. La mancata corrispondenza causa l'arresto anomalo.

di risolvere Cheat Engine a tutti, basta controllare:

if (OpenFileMapping(FILE_MAP_READ,false,'CEHYPERSCANSETTINGS')!=0) 
{ 
    // Cheat Engine runs. 
} 

(un amico mi ha detto questo, non l'ho ancora provato.)

Questi trucchi risolto il maggior numero di imbroglioni. Ma ci sono ovviamente più tecniche di barare. Ho aperto questo wiki, per discutere altre tecniche di imbroglio e il modo di evitarli.

Answer 1

Non penso che dovresti fare qualcosa per smettere di barare sui giochi per giocatore singolo. I tuoi utenti hanno acquistato il gioco, dovrebbero essere in grado di imbrogliare se lo desiderano, purché non giochino contro gli altri.

Ecco alcune cose che ho fatto. Questi sono stati fatti principalmente per i sistemi anti-cheat nei tornei, dove il denaro è in gioco, e certi livelli di intrusione nel sistema dell'utente sono considerati accettabili. Farei attenzione a fare alcune cose su giochi casuali, perché se il tuo gioco non è stabile, c'è il potenziale per causare problemi con il loro sistema.

1) Se possibile, "Non fidarsi del cliente" è il principio più sicuro da rispettare. Esegui tutte le azioni sul server e dai al cliente solo le informazioni necessarie a rendere ciò che dovrebbe essere in grado di vedere sullo schermo in un dato momento. cioè se un cliente non conosce la posizione di un giocatore che è nascosto dietro un muro, un muro di hack non farà bene all'utente. Per i giochi d'azione ad alta velocità questo può essere estremamente difficile - specialmente ora che le ombre in tempo reale e tali sono la norma, dove l'utente può aver bisogno di essere in grado di vedere un'ombra anche se il corpo del giocatore è visibile - ma dovrebbe sempre essere nella parte superiore delle opzioni. Anche estremamente difficile da fare sui giochi peer-to-peer, ma ci sono modi per limitare la conoscenza tra colleghi. Solo quando diventa una prestazione proibitiva o al di fuori del tuo budget di tempo/denaro, dovrebbero essere considerati i seguenti elementi.

2) Aprire tutti gli altri processi e agganciare le loro funzioni WriteProcessMemory in modo che non possano scrivere nella memoria nel processo del gioco. Fatto bene, questa fase bloccherà il 90% di tutti i cheat e i cheat engine.

3) Fare la stessa cosa, agganciare le varie funzioni di emulazione del mouse e della tastiera. Ciò impedirà un sacco di botole di mira e altri tipi di robot di automazione.

4) Collegarsi alle funzioni VirtualProtectEx/VirtualAllocEx/etc nel processo del proprio gioco e monitorare quali moduli stanno modificando i livelli di protezione o allocando nuovi blocchi di memoria. Devi essere furbo con questo per evitare che sia troppo carico di CPU quando il tuo gioco fa un sacco di allocazioni, ma può essere fatto.

5) Agganciare le funzioni LoadLibrary e monitorare le DLL caricate dinamicamente, per evitare l'iniezione di DLL.

6) Utilizzare una codifica polimorfica leggera sulle connessioni di gioco.

7) Utilizzare alcune tecniche anti-debug per impedire ai debugger di collegarsi ai processi. Anti-debug di Google e dovresti riuscire a trovare molte cose.

8) Utilizzare un pacchetto PE proprietario personalizzato per impedire un utile smontaggio del gioco.

9) Collegati alle funzioni e ai metodi OpenGL o Direct3D che trattano della trasparenza e della fusione alfa.

10) Se si utilizzano shader, checksum, shader e valori dello shader.

11) Utilizzare le tecniche di abbattimento occlusione aggiuntive sui personaggi dei giocatori per impedire che vengano riprodotti quando la linea di vista verso di loro è bloccata da un'altra geometria. Può o non può aiutare anche con la tua performance, ma impedirà molti wallhacks.

Answer 2

È possibile trovare questo documento su Cheat Proof Game Protocols interessante. Sono tutte variazioni sulla stessa idea: usare gli hash come promessa, e poi rivelare il significato della promessa dell'hashed una volta soddisfatte le condizioni sul comportamento degli altri giocatori. È complicato e ha un impatto sulle prestazioni, ma alcune idee potrebbero essere utili, in particolare per i giochi peer to peer.

Answer 3

Quando il gioco si basa completamente su un'architettura client-server, il lavoro è quasi finito, penso, ma ci sono anche hack da muro o altro.

Se non è possibile spostare la maggior parte delle logiche da eseguire sul lato server, cerca almeno di condividere come piccolo stato nel modo più realistico possibile durante ogni fase di gioco, in altre parole: mantenere modalità di gioco attiva di ogni giocatore in account e condividere solo le informazioni che sono effettivamente rilevanti in quel momento.

Ciò non solo riduce la possibilità di imbrogliare, ma riduce anche il traffico causato dal protocollo, ossia migliorerà l'efficienza.

Questa è una tecnica che è già da tempo conosciuta e applicata nel settore del gioco/simulazione per migliorare l'efficienza durante il rendering di scene 3D di grandi dimensioni.

Lì, "cianfrinatura" consente di determinare quali parti di una scena sono effettivamente visibili, in modo che vengano visualizzate solo le parti pertinenti.

Analogamente, la stessa tecnica può essere utilizzata per limitare i client multiplayer a ricevere solo determinati aggiornamenti/informazioni se sono effettivamente pertinenti, ad es. se altri client sono effettivamente all'interno di un intervallo "di pertinenza", in modo che altri client possano recuperare gli aggiornamenti corrispondenti.

Ancora, differenziare tra rilevanza e "visibilità": due giocatori separati da una porta potrebbero non "vedere" realmente, ma a seconda di ciò che li circonda, potrebbero sentirsi molto bene. Quindi, distinguere tra diversi tipi di "visibilità": la propagazione dello stato udibile non deve necessariamente implicare la propagazione della posizione effettiva del giocatore nelle coordinate del gioco. Lo stesso vale viceversa: solo perché "vedi" un giocatore, non hai necessariamente il diritto di ascoltare anche il cliente (ad esempio, immagina un mirino su un fucile).

In altre parole, provare ad accoppiare in modo univoco i pacchetti di aggiornamento supportati, in modo che non abbiano reciproche dipendenze l'uno sull'altro e possano anche essere propagati/sottoscritti in modo indipendente.

Barare può essere in gran parte controllata solo mediante l'applicazione corretta incapsulamento ed i dati nascondono meccanismi, in modo che i client multiplayer generalmente non condividono stato globale, ma stato condiviso è invece direttamente dipendente dal contesto attivo del giocatore (posizione, direzione, orientamento, velocità eccetera).