Si es así, ¿por qué estas empresas no ofrecen la verificación del lado del servidor para los videojuegos, sino que continúan insistiendo en confiar en el cliente?

Se trata menos de insistir en confiar en el cliente y más que no hay otro modelo anti-trampas viable. Al igual que DRM, y de hecho, el software anti-cheat como PB usa una forma de DRM, hay poco que se pueda hacer.

El software DRM tiene mitigaciones para evitar que el cliente toque demasiado, pero se debe poner en el cliente para evitar que el cliente haga cosas que las compañías de medios no quieren que el cliente haga.

La tecnología anti-trampas se basa en una metodología similar. La información sobre el cliente se recopila, se envía al servidor y, si se considera que un cliente se comporta mal, a través de cualquier serie de comprobaciones que se realicen para el software específico, se puede prohibir en el servidor.

Al final del día, todo se reduce a la gestión de riesgos. Sí, no confíe en que el cliente es uno de los primeros principios de seguridad. Pero para mitigar los riesgos que ocurren en el cliente, hay un análisis de costo-beneficio, que es lo que es la administración de riesgos. ¿El costo de permitir que los clientes continúen botando y engañando vale la pena perder a los clientes que quieren un juego justo y divertido? ¿O deberían colocarse algunas mitigaciones? PB y otros paquetes de software no están ahí para dejar de hacer trampa por completo, pero pretenden hacer que sea más costoso hacerlo.

También hay otra forma más sutil de limitar a los clientes a hacer trampa (hacks de pared, ...), en su mayoría implicados por juegos solo en línea, pero no limitados a ellos. Esto se logra al no alimentar al lado del cliente todos los datos. Por ejemplo, Unreal Engine 3 tiene comprobaciones si un actor se encuentra cerca de la visibilidad. Si esta verificación es positiva, el servidor le envía a USTED la ubicación exacta, así como a SU oponente. Por así decirlo, solo el servidor conoce todas las posiciones, acciones y movimientos de todos los actores en la instancia de juego.

Esto se puede leer en la documentación del motor irreal 3 / Client Server Model en el párrafo trampas, que se encuentra aquí: enlace

Por decirlo así, con los motores avanzados / códigos de red y modelos de servidor de cliente, no es necesariamente necesario confiar en el cliente al 100%. El Servidor puede decidir de antemano lo que el cliente debe saber, LIMITANDO efectivamente las posibilidades de hacks. Para ir aún más lejos, el servidor puede decidir lo que DEBE saber, no distraerse ni confundirse con los clientes que envían paquetes falsificados.

El software anticheat del lado del cliente en sí mismo no se trata de seguridad, se trata de la experiencia de juego (y cliente).

Por lo tanto, las reglas de seguridad no son tan aplicables. Confiar en el cliente "hit pixel 1056 por 1723" es muy diferente a confiar en que el cliente "puede transferir $ 1000 a Nigera", o que el cliente "puede acceder al correo electrónico de Bob".

Tenga en cuenta que estoy excluyendo específicamente transacciones financieras, solo trucos de juego como aimbots, trucos de cabeza grande, etc.

Primero: Hay muchos juegos, que utilizan el 100% de validación del lado del servidor y no confían en el cliente. Un ejemplo: Poker online

Simplemente no envía el valor de ninguna tarjeta al cliente que él no pueda saber. Así que incluso si hackea al cliente y lee la matriz, no hay nada oculto que pueda revelar ni movimientos que no pueda hacer con el cliente habitual.

Pero muchos juegos modernos son mucho más complejos. Un tirador en primera persona, por ejemplo. Aquí no es tan fácil decidir si y qué tan bien puede ver a otro jugador. Podría decir que es fácil, si hay una pared entre ustedes dos, no puede verlo. Y para estos casos simples, los juegos modernos ya pueden eliminar al jugador enemigo de tu vista, para que no obtengas la posición donde está. Pero tan pronto como el enemigo se encuentre en un rincón oscuro y apenas visible, el juego aún tiene que enviarte su posición, de modo que tu dispositivo de gráficos pueda pintarlo allí. Si usas un truco, que lo pinta en colores brillantes, puedes verlo fácilmente y hacer trampa. Esto es difícil de evitar, porque la lógica que lo pinta en colores oscuros en la sombra es muy compleja para los juegos con buenos gráficos, por lo que rasgar la imagen en el servidor y enviarte la imagen final hará que hacer trampa sea mucho más difícil, pero también requeriría una tonelada de recursos en el servidor y tendría el grave problema de LAG.

RETARDO o LAG: El segundo gran problema para los juegos transmitidos es el retraso. Si mueves el mouse, puedes mirar a tu alrededor muy rápido en un shooter en primera persona. Pero enviar este comando a través de Internet y recibir el resultado para mostrarlo en su pantalla deberá llevar más tiempo que el procesamiento local. Si tiene una conexión rápida a Internet, puede tener suerte con un Ping por debajo de 20 ms, pero la mayoría de las conexiones pueden ser muy inestables y el retraso puede ser mayor a veces. Un juego que reacciona lentamente jugará terriblemente lento y casi no será divertido en absoluto. Por el contrario, muchos juegos modernos aplican una tonelada de técnicas como la predicción de movimientos, la distorsión del tiempo y otras para que pueda disminuir el retraso percibido de otros jugadores haciendo que su juego calcule mucha lógica local y predice los movimientos de otros jugadores, por lo que el juego se siente más fluido de lo que realmente es.

Hardware / Fuera de la caja. Y siempre hay un montón de oportunidades para hacer trampa que el software no puede vencer fácilmente. ¿Qué pasa con el dopaje? (algo real en los deportes) o dejar que un robot juegue por ti. ¿O tener una cámara web sobre tu hombro, que detecta a los enemigos en tu pantalla y te dice dónde están? ¿O incluso cosas como los ataques DDoS de una botnet en tu equipo enemigo para perturbar sus comunicaciones?

Hay algunas posibilidades para hacer validaciones soportadas por el servidor. El servidor puede probar la corrección del código del juego / software anti trampas como la protección DRM (pero, por supuesto, puede ser falsificado). El servidor también puede verificar la lógica del juego, medir sus movimientos, recopilar estadísticas y datos sobre su comportamiento y compararlos con otros jugadores y ciertos límites y tratar de decidir si está jugando de manera anormal o si está infringiendo alguna regla ... pero nada de esto es perfecto.

  

Si es así, ¿por qué estas empresas no ofrecen la verificación del lado del servidor para los videojuegos, sino que continúan insistiendo en confiar en el cliente?

¡Ellos lo hacen!

La mayoría de los juegos en línea tienen cierta comprobación de coherencia de vez en cuando.

Player32517 movió 100 unidades en 3 segundos, ¿es posible?

Sin embargo, comprobar si cada movimiento es válido es una enorme cantidad de cálculos.

Toma cualquier tirador, por ejemplo:

Tu PC de juego promedio comienza a tener problemas si hay demasiados granades / enemigos en tu pantalla. Esta carga se distribuye a 20 computadoras.

Ahora imagina que tendrías que calcular todo eso de nuevo en un servidor y revisar cada movimiento, cada golpe del mouse, cada disparo del gatillo para detectar patrones de trampa. En tiempo real.

Debido a todo esto, es mucho más barato o incluso posible comprobar de vez en cuando si realmente podría haber saltado tan lejos, haber movido tan rápido o haber mantenido el mouse exactamente en la cabeza del enemigo durante 3 segundos antes de que pudiera verlo detrás de esa pared.

Y si todo eso falla, todavía tienes los informes de la comunidad con imágenes de video.

Editar:

Gracias Num Lock por señalarlo:

El retraso no es causado por la lógica sino por la representación. Calcular todos los vectores para la luz y las animaciones es mucho más que calcular si algo estaba dentro del rango para ser alcanzado.

Hay dos elementos que deben abordarse aquí.

En primer lugar, la detección de trampas del lado del cliente rara vez es el único elemento en la prevención de trampas. Dado que el software del servidor para algunos juegos también se distribuye, el software de detección de trampas del lado del servidor puede no estar completamente distribuido con él para evitar que se exponga a la ingeniería inversa. No puede deducir la falta de detección de trucos del lado del servidor del código del servidor que puede estar ejecutando en comparación con el código del servidor que pueden ejecutarse internamente. Además, las empresas pueden ser reacias a discutir sus soluciones anti-trampas por razones similares: la oscuridad no es algo malo tener sobre una solución robusta.

Sin embargo, también hay una necesidad de detección de trampas en el lado del cliente debido a que los juegos dependen de la habilidad del jugador. Esto significa que el engaño puede ocurrir en muchos niveles: hardware, entrada y software. El software es simplemente el más conveniente y preciso, se puede hacer muy poco para protegerse contra un robot competente. Para protegerse contra las trampas basadas en software, debe tener algún tipo de monitor residente en el cliente para tener la oportunidad de detectarlo.

Además, una simulación de juego es compleja. Como bien ha dicho, hay pocas cosas que impidan que alguien cree un cliente simulado que copie correctamente todos los protocolos que usa el juego y pueda generar entradas arbitrariamente en el momento adecuado para realizar trampas. Solo que hacerlo es una gran empresa; Es mucho más fácil intentar romper el cliente existente. Lo mismo ocurre con la construcción de un cliente falso anti-trampa. Como tal, la seguridad del lado del cliente es más un caso de hacer las cosas lo más difíciles posible en lugar de ser 100% infalible. En particular, las válvulas realizan actualizaciones a VAC para competir en una batalla continua con los desarrolladores de trampas.

La mayoría de las otras respuestas se centran en los aspectos técnicos de la prevención de trampas, me gustaría agregar que VAC evita las trampas al hacerlas económicamente inviables:

TL; DR: La protección contra trampas del lado del cliente funciona porque el esfuerzo y la habilidad necesarios para engañarlo son altos y el castigo por los errores es grave.

El pirateo implica muchos intentos de error e incluso si tiene acceso completo a la fuente, se requiere una gran cantidad de trabajo para descubrir cómo modificar un cliente mientras se pretende que no sea así. Y todo este trabajo se vuelve discutible cada vez que se actualiza el cliente.

Por otra parte, si comete el más mínimo error, corre el riesgo de que se lo prohíba para siempre en todos los servidores VAC.

Tampoco tiene sentido distribuir tu hack, ya que Valve también sabe cómo buscar trucos en Google y, una vez que encuentren el hack, agregarán una lógica de detección adicional para encontrar a todos los que lo usan. Esto nuevamente desalienta a los usuarios de usar herramientas de trucos disponibles públicamente.

El desafío con una seguridad como esta es que tienes que hacer el cálculo donde está la información. O bien, debe hacer el lado del cliente de los cálculos anti-trampas, o mover el lado del servidor de información para que los cálculos se puedan hacer allí. Para muchos juegos, pasar toda la información al servidor puede ser exorbitantemente costoso. Para hacerlo, el cliente tendría que guardar todas las interacciones del usuario y la hora en que ocurrieron. El envío de toda esa información al servidor para realizar el análisis es demasiado, por lo que, en cambio, el cálculo se envía al cliente.

Eso no quiere decir que sea el final de esto. Muchos juegos implementan ambos cliente y pruebas del lado del servidor. Algunas pruebas se pueden realizar en función de la información que ya se envía al servidor. Es posible que no pueda capturar todos los hacks de velocidad ya que alguien hace zigs y zags, pero podría atrapar a alguien que logra moverse del punto A al punto B mucho más rápido de lo que permiten las reglas del juego.

También hay una opción intrigante: compromisos. Un cliente podría ofrecer un compromiso criptográfico que describa todas las interacciones del usuario, como un hash SHA-1. En un comando del servidor, pueden estar obligados a proporcionar los datos que generaron ese hash. Este patrón se usa en algunos juegos distribuidos que no tienen servidor para mantener a los jugadores honestos. Los clientes están obligados a comprometerse con las acciones que realizaron en el pasado antes de que otros clientes envíen los datos actuales. Eso evita que un cliente vuelva a escribir su historial.

La válvula hace la VALIDACIÓN del lado del servidor para todo.

Toda la entrada del cliente es perfectamente VÁLIDA.

La válvula ya verifica los datos de usuario válidos. Por ejemplo, el cliente no puede decirle al servidor: "Le disparé a Sparkles desde el engendro de CT, cuando estaba en el engendro de T".

También comprueba que cuando compras algo, no intentas comprar esa arma a crédito. Si el servidor no hiciera eso, entonces el tramposo estaría comprando AWPs en rondas de pistola.

Hacer trampa es VÁLIDO

El problema es que las trampas (en CSGO, por ejemplo) están haciendo una acción perfectamente válida (las trampas que realizan acciones no válidas, como la falla de Spawn Teleport, pueden solucionarse fácilmente). El problema es que los tramposos utilizan una variedad de métodos para ingresar una entrada válida que es mejorada o hecha por una computadora.

En efecto, VAC está intentando aplicar la prueba de Turing en un jugador. Incluso un servidor no puede verificar la identidad del agente que toma las decisiones.

Las verificaciones del lado del servidor son para asegurarse de que las operaciones solicitadas por el cliente son legales. Básicamente, para que no intentes correr el doble de rápido de lo permitido.

Las verificaciones del lado del cliente son para tratar de verificar que la decisión de realizar ese cambio sea realizada por un humano, no por la computadora, por ejemplo. Los aimbots que realizan comandos legales del cliente (y, por lo tanto, no son detectables por el servidor) pero aún no están permitidos.

Además, en el lado del servidor, puede hacer un procesamiento posterior de grandes conjuntos de datos para tratar de determinar si el jugador está haciendo trampa, pero eso es algo que debería ver después del hecho y siempre es una ciencia imperfecta.