automation - software - Protección contra la automatización
helpsystem rpa (7)
Uno de nuestros próximos proyectos se supone que es un juego basado en MS Windows (escrito en C #, con una GUI winform y un control integrado de pantalla DirectX) para un cliente que quiere regalar premios a los mejores jugadores. Este proyecto tiene una duración de un par de años, con campeonatos, escalas, torneos, jugador contra jugador-acción, etc.
Una de las principales preocupaciones aquí es hacer trampa, ya que un jugador se beneficiaría dramáticamente si fuera capaz, por ejemplo, de permitir que un robot hecho a medida le jugara el juego (más en términos de decisiones estratégicas que en términos de jugar muchas horas) .
Entonces mi pregunta es: ¿qué posibilidades técnicas tenemos para detectar actividad de bot? Por supuesto, podemos rastrear el número de horas jugadas, analizar estrategias para detectar anomalías y demás, pero en lo que respecta a esta pregunta, estaría más interesado en conocer detalles como
- ¿Cómo detectar si otra aplicación hace capturas de pantalla periódicas?
- ¿Cómo detectar si otra aplicación escanea nuestra memoria de proceso?
- ¿Cuáles son buenas formas de determinar si la entrada del usuario (movimiento del mouse, entrada de teclado) es generada por el ser humano y no automatizada?
- ¿es posible detectar si otra aplicación solicita información sobre controles en nuestra aplicación (posición de controles, etc.)?
- ¿Qué otras formas existen en las que un tramposo puede recopilar información sobre el estado del juego actual, alimentar a un bot y enviar las acciones determinadas de vuelta al cliente?
¡Su retroalimentación es muy apreciada!
Debería ver qué pasa con Punkbuster, Valve Anti-Cheat y algunas otras cosas anti-trampas para algunos indicadores.
Editar: lo que quiero decir es, mira cómo lo hacen; cómo detectan eso.
Hace un tiempo escribí d2botnet, un motor de automatización de .net diablo 2, y algo que puedes agregar a tu lista de cosas de las que hay que tener cuidado son los paquetes mal formados / inválidos / falsificados. Supongo que este juego se comunicará a través de TCP. El olfateo de paquetes y la forja suelen ser la primera forma en que los juegos (en línea, de todos modos) son automáticos. Sé que Blizzard detectaría paquetes mal formados, algo que intenté evitar en d2botnet.
Así que asegúrese de detectar paquetes inválidos. Cifrelos. Hash ellos. haz algo para asegurarte de que sean válidos. Si lo piensas, si alguien puede saber exactamente lo que significa cada paquete que se envía de ida y vuelta, ni siquiera necesita ejecutar el software del cliente, lo que hace que cualquier detección basada en procesos sea un punto discutible. De modo que también puede agregar algún tipo de respuesta de desafío basada en paquetes a la que su cleint debe saber cómo responder.
La mejor protección contra la automatización es no tener tareas que requieran rectificado.
Dicho esto, la mejor manera de detectar la automatización es involucrar activamente al usuario y requerir pruebas periódicas tipo CAPTCHA (excepto sin la imagen, etc.). Recomiendo utilizar una base de datos de varios miles de preguntas sencillas y únicas que se presentan al usuario de vez en cuando.
Sin embargo, en función de su pregunta, diría que su mejor opción es no implementar las características anti-automatización en C #. Tienes muy pocas posibilidades de detectar hacks / bots bien escritos dentro del código administrado, especialmente cuando todo lo que el hacker tiene que hacer es simplemente entrar en ring0 para evitar la detección a través de cualquier método estándar. Recomendaría un enfoque similar al de Warden (módulo descargable que puede actualizar cada vez que lo desee) combinado con un Kernel-Mode Driver que engancha todas las funciones de la API de Windows y las vigila para llamadas "inapropiadas". Tenga en cuenta, sin embargo, que se encontrará con muchos falsos positivos, por lo que no debe basar su sistema de prohibición en sus datos automatizados. Siempre ten una mirada humana sobre él antes de prohibirlo.
No conozco los detalles técnicos, pero el programa BlitzIn de Intenet Chess Club parece haber integrado la detección de conmutación de programas. Eso es por supuesto para detectar personas que ejecutan un motor de ajedrez en un lado y no directamente aplicables a su caso, pero puede extrapolar el apporach a algo así como si el proceso X toma más de un Z% de tiempo de CPU en los próximos Y ciclos, es probable un bot corriendo.
Además de un "no debes ejecutar nada más mientras juegas para ser elegible para los premios", como parte de las reglas del concurso, podría funcionar.
Además, una regla draconiana "podríamos decidir en cualquier momento por cualquier motivo que hayas estado usando un bot y te descalifique" también ayuda con el enfoque heurístico anterior (utilizado en los preciados torneos de ajedrez de ICC).
Todas estas preguntas se resuelven fácilmente mediante la regla 1 anterior:
* how to detect if another application makes periodical screenshots?
* how to detect if another application scans our process memory?
* what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
* is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
Creo que una buena forma de hacer más difícil el problema para los crackers es tener las únicas copias autorizadas del estado del juego en sus servidores, solo enviando y recibiendo actualizaciones de los clientes, de esa manera usted puede incluir en el protocolo de comunicación la validación del cliente. (que no se ha descifrado y, por lo tanto, las reglas de detección siguen vigentes). Eso, y el monitoreo activo de nuevos comportamientos raros encontrados podría llevarte cerca de donde quieres estar.
No tengo una comprensión más profunda sobre cómo funciona PunkBuster y esos softwar, pero esta es la forma en que iría:
Iintercept llama a las funciones de API que manejan cosas de la memoria como ReadProcessMemory , WriteProcessMemory , etc.
Detectarías si tu proceso está involucrado en la llamada, lo registrarás y trampolínarás la llamada a la función original.
Esto debería funcionar también para la captura de pantalla, pero es posible que desee interceptar la función BitBlt.
Aquí hay un tutorial básico sobre la interceptación de funciones: interceptación de llamadas a la API del sistema
Solo una idea de qué pasa si el "tramposo" ejecuta su software en una máquina virtual (como vmware) y realiza capturas de pantalla de esa ventana. Dudo que puedas defenderte de eso.
Obviamente no puedes defenderte de la ''brecha analógica'', por ejemplo, el sistema del tramposo hace capturas de pantalla externas con una cámara de alta calidad, supongo que es solo un problema teórico.
Tal vez deberías investigar sitios de ajedrez. Hay mucho dinero en el ajedrez, tampoco les gustan los bots, quizás ya se les ocurrió una solución.
Un método común de escuchar la entrada de teclado y mouse en una aplicación es establecer un gancho de Windows usando SetWindowsHookEx. Los proveedores generalmente intentan proteger su software durante la instalación para que el hacker no automatice ni crackea / encuentre una serie para su aplicación. Google el término: "Key Loggers" ... Aquí hay un artículo que describe el problema y los métodos para prevenirlo.