Básicamente, no puedes ...
Cualquier cosa en el lado del cliente debe ser considerada como pública. Claro, puedes intentar ofuscar la API con varias técnicas, pero siempre hay una forma de realizar ingeniería inversa y crear tu propia API de creación de bots. Debe tener en cuenta que un pirata informático puede controlar todo en el lado del cliente.
¿Qué puedes proteger?
Lo único que puedes proteger es tu servidor. Por lo tanto, si desea controlar lo que sus jugadores pueden o no pueden hacer, debe validar todas sus acciones en el lado del servidor. El servidor debe ser la fuente de la verdad. En este punto, si el servidor puede detectar cualquier acción no válida, un atacante aún podría crear un cliente "no válido" pero las únicas cosas que este cliente podría hacer son acciones válidas. Por lo tanto, es fácil ¿verdad?
Bueno, no mucho. Tratar de validar todo en el lado del servidor crea muchos problemas. Muchos se relacionan con la suavidad con la que se ejecutará el juego, pero también hay que descubrir cómo incluir problemas de red, como un usuario que se está retrasando. Por ejemplo, si va al extremo en términos de protección, irá así:
- El comando de acción de envío del cliente al servidor
- El servidor ejecuta la acción (si es válida) y envía el resultado al cliente
- El cliente simplemente muestra el resultado que el servidor les dijo que mostraran.
Es super simple de hacer y anular cualquier acción no válida, PERO destruye totalmente la experiencia del usuario para cualquier persona con una mala red. Cuando un usuario presiona una tecla para avanzar, espera avanzar de inmediato. Dado que cada acción realiza un viaje de ida y vuelta al lado del servidor, los usuarios que se retrasen experimentarán una acción lenta en todo momento.
¿Qué puedes hacer?
La mejor idea es tener un sistema mixto. Usted realiza la validación en el lado del servidor, PERO todavía "ejecuta" la acción en el lado del cliente tan pronto como ocurren. De esa manera, el usuario piensa que su acción ocurre en el momento en que los realiza, mientras que, de hecho, pueden realizarse unos milisegundos o segundos más tarde. Básicamente, está haciendo una simulación en el lado del cliente, y si el servidor le confirma que todo estaba bien, esa simulación se mantiene. En el caso de que la simulación haya sido considerada incorrecta por el servidor, estas acciones se "invierten".
Es un poco molesto conseguir que ese tipo de sistema sea el correcto, pero es lo único que proporciona una buena experiencia de usuario y al mismo tiempo derrota completamente la acción no válida.
Un enfoque más sencillo: el registro
Dado que, realmente controlar todo en el lado del servidor puede ser una molestia, ya que es difícil decidir qué hacer cuando la historia necesita ser reescrita, un enfoque más fácil es hacer el registro. Deja que el cliente haga casi lo que quiera, él es la fuente de la verdad, pero luego, en el lado del servidor, registra cada acción y detecta cada acción no válida. Las acciones no válidas seguirán ocurriendo, pero si un cliente hace demasiadas, puedes asumir con seguridad que no es un cliente válido y, finalmente, prohibirlo.
Acerca de la ofuscación: Esfuerzo VS Ganancia
Las cosas ofuscantes en el lado del cliente hacen que sea más difícil para un atacante crear un programa de bots, por lo que desalentará a muchos atacantes aspirantes, por lo que tendrá que lidiar con un subconjunto más pequeño de jugadores problemáticos.
No soy un experto en tales técnicas pero es algo similar a:
- cambiando todos los nombres de variables / métodos
- insertar código inútil para confundir al ingeniero inverso
- cifrar el código (pero la contraseña aún está oculta en algún lugar del código ...)
En realidad, solo son cosas para que sea más doloroso tratar de hacer ingeniería inversa al cliente del juego ...
