Detectar o prevenir inyecciones de memoria de proceso en Windows (anti-hack)

Sé que has mencionado esto como ineficiente y estoy completamente de acuerdo, Sin embargo, seguramente podrías ejecutar un temporizador de algún tipo y buscar continuamente programas como Cheat Engine y Tsearch :)

Aquí hay otra idea completamente aleatoria: Podría escribir una función para verificar un byte en un desplazamiento en su juego y ver si coincide con el byte que desea que esté allí; si no, puede llamar a un evento para cerrar el juego o escribir el byte correcto para ese desplazamiento, otra opción podría ser verificar los bytes contra los bytes almacenados en un servidor y si el byte es diferente, entonces el usuario recibe una patada.

Espero que te dé algunas ideas :)

Ooooohh Me encantan las preguntas como esta.

Bien, primero:

  

estamos alojando un servidor de juegos

Bam, ahí tienes. Si el cliente debe enviar la actualización del estado al servidor del juego antes de enviarlo a otros clientes, tiene la oportunidad de analizar el estado del juego para ver si hay cambios. Esto significa que puedes detectar patrones anómalos. Así, por ejemplo, si de repente ve un cambio masivo de valor en el oro, puede dejar a ese usuario fuera del juego.

Hay muchos enfoques estadísticos que puedes tomar. Aparte del "cambio enorme" o la "acción imposible" obvia, puede aplicar más soluciones a largo plazo, como el oro con el tiempo. Suponiendo que conozco el truco de "no agregar grandes cantidades de oro a mi personaje", podría incrementar el oro en cantidades seguras con el tiempo. Genial, si siempre presiono el filo. Sin embargo, ese aumento constante no se correlacionará con el oro equivalente obtenido en un juego genuino y consistente, así que ... nuevamente, detecte y cierre la cuenta.

La clave aquí es que estas son cosas que puedes hacer en el lado del servidor que el usuario final no puede hacer nada, incluso si han manipulado el estado del juego.

Ahora, en sus preguntas secundarias de Win32. En primer lugar, no creo que WriteProcessMemory sea una llamada particularmente válida para cualquier DLL, con la excepción de los depuradores (que reemplazará las instrucciones en el código; así es como funcionan los puntos de interrupción establecidos por los depuradores), sin embargo, no hay manera Puede reemplazar esto de manera confiable para cada llamada en el sistema sin escribir lo que efectivamente es un rootkit, es decir, afectaría a todos, no solo a usted. Así que esto no es realmente una opción.

Una cosa que podrías hacer, y no es nada fácil, es revisar periódicamente tu propia memoria ejecutable para su modificación. Para obtener más información, consulte Tamper Aware / Self Healing Code en el proyecto de código. Básicamente, invoca esto periódicamente y bloquea el juego si detectas alguna modificación.

También puede considerar firma de código - no es ridículamente caro , y proporciona una forma integrada en Windows de prevenir modificaciones ejecutables sin conexión.

Si almacena el estado guardado localmente, puede considerar guardar sumas de comprobación y enviarlas a sus cuentas de servidor. No, esto no es a prueba de balas, pero agrega complejidad adicional.

Si vas a implementar cualquiera de estas funciones, necesitarás levantar un poco la barrera y dificultar que el cracker se desactive, salte o evite los mecanismos de protección. Seamos claros: si alguien tiene la determinación suficiente, ya está acabado, pero al menos puede hacer que sus vidas sean muy dolorosas.

El artículo principal para la ingeniería anti reversa en mi lista de lectura también es del proyecto de código . La guía es muy completa y debería proporcionarle una excelente base en exactamente lo que puede hacer para confundir y molestar a los depuradores. Voy a caminar a través de uno de ellos, que creo que es fantástico:

 SetUnhandledExceptionFilter(UnhandledExcepFilter);
 __asm{xor eax, eax}
 __asm{div eax}

Esto es malo. Básicamente, como explica el artículo, se llama a UnhandledExceptionHandler en un proceso de no depuración como el controlador de último recurso; sin embargo, en este caso eliminamos deliberadamente eax , luego dividimos por cero. Eso causará un fallo en el procesador, que luego el sistema operativo envía de vuelta al controlador de excepciones del ejecutable, solo si hay un depurador adjunto. Si hay un depurador adjunto, el depurador recibe una notificación y el ejecutable sale.

Por supuesto, es bastante fácil para un atacante reemplazar div eax con una o más instrucciones nop o algo así, lo que significa que la ejecución solo se deslizará, pero una pequeña auto verificación lo capta con bastante facilidad.

Entonces, en conclusión entonces:

• Mi primer consejo sería intentar detectar trucos en el servidor. Aquí tienes todas las llaves. Incluso podría introducir estos cambios "oscuros", es decir, verificar y ver quién está haciendo trampa, luego analizar sus estados para ver si funciona, sin cortarlos.
• Entonces, intentaría una auto verificación periódica en varias formas:
  • En la memoria, tanto como sea confiable, del ejecutable.
  • En la memoria, tanto como sea confiable, de estructuras de datos críticos.
  • El ejecutable en el disco, también.
• Finalmente, leí esa guía de ingeniería inversa de arriba a abajo y vería qué puedes aplicar a tu ejecutable. Me doy cuenta de que dijiste que no puedes modificar tu ejecutable, pero honestamente, a menos que lo hagas, es probable que estés en contra de él. Después de todo, un atacante puede matar un segundo "proceso de observador".

¿Harías tu propia función WriteProcessMemory y la vincularías al archivo exe del juego, y filtrarías las llamadas falsas? O cualquier otra función que pueda interceptar con algún flujo que pueda filtrar. De todos modos, esto es muy avanzado y deberías proporcionar todas las llamadas a kernel32.dll o algo así. Básicamente, tendrías que hacerlo si quieres protegerlo de esto, quizás algún tipo de filtrado de la secuencia ayudaría, pero para descubrirlo pasarías un tiempo con el depurador buscando un momento en el que el comando es decodificado, entonces puedes rellenarlo con ceros. El proxy SSL sería bueno tenerlo por separado como en CORREO ELECTRÓNICO, por lo que recibió el mensaje y, antes de entregarlo, ejecuta una verificación de escaneo en un proceso separado y luego lo entrega al buzón en otra cuenta.

Para obtener información sobre cómo derrotar a los chats en tus juegos, te recomiendo el siguiente artículo:

• Cómo lastimar a los hackers: la primicia sobre el engaño de Internet y cómo puedes combatirlo

Es un excelente resumen de algunos de los desafíos.

Si desea más, también puede consultar el siguiente libro:

• Explotación de juegos en línea: engaño de sistemas distribuidos masivamente , Greg Hoglund, Gary McGraw.