Fondamentalmente, non puoi ...
Qualsiasi cosa sul lato client deve essere considerata pubblica. Certo, puoi provare a offuscare l'API con varie tecniche, ma c'è sempre un modo per decodificarlo e costruire la tua API di botting. Devi considerare che un hacker può controllare tutto sul lato client.
Che cosa puoi proteggere?
L'unica cosa che puoi proteggere è il tuo server. Quindi, se vuoi controllare ciò che i tuoi giocatori possono o non possono fare, devi convalidare ogni loro azione sul lato server. Il server deve essere la fonte della verità. A questo punto, se il server è in grado di rilevare qualsiasi azione non valida, un utente malintenzionato potrebbe comunque creare un client "non valido", ma le uniche azioni che questo client potrebbe eseguire sono azioni valide. Quindi, è facile vero?
Bene, non così tanto. Cercare di convalidare tutto sul lato server crea molti problemi. Molti sono legati al modo in cui il gioco funzionerà ma anche, devi capire come includere i problemi di rete, come un utente in ritardo. Ad esempio, se si va all'estremo in termini di protezione, andrà in questo modo:
- Il client invia il comando di azione al server
- Il server esegue l'azione (se è valida) e invia il risultato al client
- Il client visualizza semplicemente il risultato che il server gli ha detto di visualizzare.
È semplicissimo da fare e sconfiggere qualsiasi azione non valida, MA distrugge totalmente l'esperienza dell'utente per chiunque abbia una cattiva rete. Quando un utente preme un tasto per andare avanti, si aspetta di andare avanti immediatamente. Dal momento che ogni azione esegue un round trip sul lato server, gli utenti che sono in ritardo subiranno un'azione lenta ad ogni turno.
Che cosa puoi fare?
L'idea migliore è avere un sistema di mix. Si esegue la convalida sul lato server, MA si esegue ancora "l'azione" sul lato client non appena si verificano. In questo modo l'utente pensa che la sua azione avvenga nel momento in cui li fa, mentre in realtà potrebbero essere eseguiti pochi millisecondi o secondi dopo. In pratica stai facendo una simulazione sul lato client, e se il server ti conferma che tutto era a posto, la simulazione viene mantenuta. Nel caso in cui la simulazione è stata ritenuta errata dal server, queste azioni sono "invertite".
È una specie di sofferenza avere quel tipo di sistema giusto, ma è l'unica cosa che fornisce una buona esperienza utente mentre sconfigge completamente l'azione non valida.
Un approccio più semplice: registrazione
Dal momento che controllare realmente tutto sul lato server può essere un problema, poiché è difficile decidere cosa fare quando la cronologia deve essere riscritta, un approccio più semplice è quello di fare il logging. Lasciate che il client faccia quasi quello che vuole, è la fonte della verità, ma poi, dal lato server, registrate ogni azione e rilevate ogni singola azione non valida. Le azioni non valide si verificheranno ancora, ma se un cliente ne fa troppe, puoi tranquillamente presumere che non sia un cliente valido e, in ultima analisi, lo benda.
Informazioni offuscanti: Effort VS Gain
L'offuscamento di elementi sul lato client rende molto più difficile per un utente malintenzionato creare un programma di imbottigliamento in modo da scoraggiare molti aspiranti in cerca di un minor numero di giocatori problematici.
Non sono un esperto in tali tecniche, ma è qualcosa di simile a:
- modifica di tutti i nomi di variabili / metodi
- inserimento di codice inutile per confondere il reverse engineer
- crittografia del codice (ma la password è ancora nascosta da qualche parte nel codice ...)
È davvero roba da rendere più doloroso provare a decodificare il client del gioco ...
