Cómo funcionan los anti-cheat de kernel

• Los sistemas anti-cheat modernos basados en kernel son uno de los software de seguridad más complejos del entorno Windows, ya que monitorean memoria y eventos del sistema a nivel kernel incluso mientras el juego está en ejecución
• Para superar las limitaciones de la protección en modo usuario, utilizan controladores de kernel y supervisan en tiempo real la creación de procesos e hilos, la carga de imágenes, los cambios en el registro y más
• Los sistemas principales como BattlEye, EasyAntiCheat, Vanguard y FACEIT AC operan con una estructura de 3 capas compuesta por controlador de kernel, servicio y DLL del juego; Vanguard, que se carga durante el arranque, tiene el control más fuerte
• Combinan defensas multicapa como escaneo de memoria, detección de hooking, verificación de integridad de drivers, mitigación de ataques DMA y detección basada en comportamiento para bloquear trampas
• En última instancia, la atestación remota basada en TPM y la verificación de confianza del hardware están emergiendo como la base clave de la seguridad en juegos

---

1. Limitaciones de la protección en modo usuario y el paso al kernel

• Los procesos en modo usuario están por debajo del kernel en nivel de privilegio, por lo que pueden ser burlados fácilmente por trampas a nivel de controlador de kernel o hipervisor
  • Ejemplo: una llamada a ReadProcessMemory puede falsificarse mediante hooking en kernel
• Las trampas en modo kernel pueden manipular directamente la memoria del juego y evadir la detección en modo usuario
• Para responder a esto, el anti-cheat se movió al nivel kernel, donde realiza la supervisión con el mismo nivel de privilegio

2. La “carrera armamentista” entre trampas y anti-cheat

• Sigue en curso una competencia de escalada de privilegios que va de modo usuario → kernel → hipervisor → DMA
• Los anti-cheat responden con bloqueo de drivers, detección de hipervisores y defensa DMA basada en IOMMU
• Este proceso eleva el costo y la dificultad de desarrollar trampas, con el efecto de bloquear el acceso de usuarios comunes

3. Principales sistemas anti-cheat de kernel

• BattlEye: centrado en el controlador de kernel BEDaisy.sys, registra callbacks para procesos, hilos y carga de imágenes
• EasyAntiCheat (EAC): propiedad de Epic Games, con una estructura similar de 3 capas
• Vanguard: carga vgk.sys durante el arranque y aplica un modelo de lista blanca de drivers para un control fuerte
• FACEIT AC: logra un alto nivel de confianza mediante monitoreo a nivel kernel
• El artículo de ARES 2024 señala que estos sistemas tienen una estructura técnica similar a la de un rootkit, aunque con un propósito defensivo

4. La estructura de 3 capas del anti-cheat de kernel

• Controlador de kernel: realiza hooking de system calls, escaneo de memoria y control de acceso
• Servicio en modo usuario: se encarga de la comunicación de red, la gestión de baneos y el envío de telemetría
• DLL del juego: realiza validaciones dentro del proceso del juego y se comunica con el servicio mediante IPC
• Se comunican entre sí mediante IOCTL, Named Pipe y Shared Memory

5. Diferencia entre carga al arranque y carga en tiempo de ejecución

• BattlEye/EAC: cargan el driver al ejecutar el juego y lo descargan al cerrarlo
• Vanguard: se carga durante el arranque y monitorea todos los drivers que se cargan después
  • Por esto, requiere reiniciar el sistema y puede proteger desde la etapa de arranque

6. Monitoreo basado en callbacks del kernel

• ObRegisterCallbacks: controla el acceso a handles de procesos y bloquea el acceso a memoria desde procesos externos
• PsSetCreateProcessNotifyRoutineEx: bloquea la creación de procesos de trampas
• PsSetCreateThreadNotifyRoutine: detecta hilos anómalos dentro del proceso del juego
• PsSetLoadImageNotifyRoutine: detecta la carga de DLL no permitidas
• CmRegisterCallbackEx: monitorea cambios en el registro
• Mini-filter driver: bloquea el acceso a archivos de trampas a nivel del sistema de archivos

7. Protección y escaneo de memoria

• Restricción de acceso a handles para bloquear lectura/escritura externa de memoria
• Verificación hash de secciones de código para detectar parches en el código
• Recorrido del árbol VAD para detectar memoria ejecutable mapeada manualmente
• Identificación heurística de memoria ejecutable anónima, DLL mapeadas manualmente y shellcode

8. Detección de inyección

• Detección de diversas técnicas de inyección como CreateRemoteThread, APC, NtMapViewOfSection y Reflective DLL
• Análisis de stack frames (RtlWalkFrameChain) para comprobar si hay ejecución de código anómala

9. Detección de hooking

• Hooking de IAT: detección de alteraciones en la Import Address Table
• Hooking inline: comprobación de parches comparando instrucciones JMP al inicio de funciones
• Verificación de integridad de SSDT, IDT y GDT para impedir hooking a nivel kernel
• Detección del uso directo de syscall para bloquear intentos de evasión de ntdll

10. Protección a nivel de drivers

• Detección de drivers sin firma y modo de firma de prueba
• Uso de una blocklist para bloquear ataques BYOVD (abuso de drivers vulnerables)
• Monitoreo de estructuras internas del kernel como PiDDBCacheTable, MmUnloadedDrivers y BigPool para detectar drivers mapeados manualmente

11. Anti-debugging y prevención de análisis

• NtQueryInformationProcess para verificar la presencia de un depurador
• Detección del depurador de kernel mediante la variable KdDebuggerEnabled
• Detección de hilos ocultos mediante la bandera ThreadHideFromDebugger
• Bloqueo de entornos de análisis usando pruebas de temporización basadas en RDTSC, breakpoints de hardware y la presencia de un hipervisor

12. Trampas basadas en DMA y respuesta defensiva

• Los dispositivos PCIe DMA pueden leer memoria sin intervención de la CPU
• La IOMMU restringe el acceso DMA, pero puede quedar anulada si está deshabilitada o mal configurada
• Es difícil detectar dispositivos FPGA disfrazados de dispositivos legítimos
• Puede mitigarse en parte mediante verificación de integridad de arranque con Secure Boot y TPM 2.0

13. Detección basada en comportamiento y machine learning

• Análisis de entrada del mouse para distinguir movimiento humano de apuntado automático
• Detección de triggerbots y aimbots mediante modelos CNN y Transformer
• Detección de trampas coordinadas por equipos (wallhack y colusión) con redes neuronales de grafos
• Pipeline de telemetría: captura de entrada en kernel → transmisión cifrada → análisis ML en servidor → decisión de baneo

14. Evasión de entornos virtuales y de análisis

• Detección de VM mediante el bit de hipervisor de CPUID y cadenas del vendor
• Verificación de rastros de registro y dispositivos de VMware, VirtualBox y Hyper-V
• Los entornos de virtualización anidada pueden identificarse por retrasos en la ejecución de instrucciones

15. Identificación de hardware y ejecución de baneos

• Generación de HWID usando SMBIOS, disco, GPU, MAC y MachineGuid, entre otros
• El spoofing de HWID se intenta mediante manipulación del registro, drivers o cambios físicos, pero
  puede detectarse por inconsistencias entre identificadores o formatos anómalos

16. Tendencias futuras y cambio tecnológico

• La etapa posterior al DMA son las trampas basadas en firmware, con una dificultad de detección extrema
• Los aimbots de hardware basados en IA son difíciles de distinguir de la entrada humana
• La atestación remota basada en TPM y el cloud gaming emergen como alternativas de largo plazo
• El anti-cheat de kernel sigue siendo la primera línea práctica pero
  la verificación de confianza del hardware y la validación del lado del servidor se plantean como la dirección final

[GN⁺]

Opiniones de Hacker News

• En resumen, los cheats modernos evaden el anti-cheat usando hipervisores, parches de BIOS, dispositivos DMA, etc.
  Cuanto más se refuerza la protección a nivel de hardware, más evolucionan también los creadores de cheats.
  Pero con la llegada del análisis de juego basado en IA, está funcionando el enfoque de detectar al propio tramposo.
  Al final, el futuro parece estar en el anti-cheat en modo usuario y en el análisis de gameplay, no en el modo kernel.

  • Suena exagerado decir que el parcheo de BIOS es “muy popular”.
    Más bien parece una prueba de que el anti-cheat está funcionando bien.
    Antes bastaba con bajar un programa y ya podías hacer trampa, pero ahora la barrera de entrada es tan alta que muchos ni siquiera lo intentan.
    Aun así, al principio del texto se decía que estas defensas pueden quedar anuladas, así que queda la duda de si realmente son confiables.
  • Yo juego WoW, y hubo muchas quejas de que Blizzard baneó a usuarios inocentes.
    A mí también me banearon dos cuentas, pero soporte al cliente me las devolvió.
    Sin embargo, parece que usan IA en soporte, así que probablemente haya muchos baneos injustos.
    Este tipo de sistemas de baneo basados en comportamiento corren el riesgo de castigar por error incluso a usuarios muy dedicados, por lo que cuesta confiar en ellos.
  • Las técnicas que mencionas sirven para elevar el costo del ataque.
    Es decir, ya no cualquiera puede crear cheats, así que el anti-cheat está teniendo cierto éxito.
    Pero el análisis de gameplay probablemente solo atrape a los tramposos más obvios, mientras que cosas tipo ESP podrían pasar desapercibidas.
  • El análisis de comportamiento no detecta a los “tramposos discretos”.
    Y esos son más peligrosos, porque arruinan poco a poco a la comunidad.
  • ActiBlizz es casi la única empresa que emprende acciones legales de forma regular contra desarrolladores de cheats de pago como Bossland o EngineOwning.

• Meterse con el kernel es básicamente ignorar todo el modelo de seguridad del sistema operativo.
  De hecho, ya hubo casos de anti-cheats con bugs a los que les robaron privilegios de root.
  Lo correcto sería aprovechar las funciones de sandbox del sistema operativo y la cadena de confianza del proceso de arranque.

  • El ecosistema de PC no se toma la seguridad de la cadena de arranque tan en serio como los teléfonos.
    Por eso es difícil depender solo de las funciones del sistema operativo, y la attestation también tiene un alcance práctico bastante limitado.
    Aunque no sea perfecto, si puede reducir estadísticamente la cantidad de tramposos, ya tiene valor.
  • La seguridad real no consiste en bloquear el cliente, sino en validar en el servidor solo las acciones permitidas.
  • Surge la duda de si eso equivale a “vender PCs bloqueadas donde solo se pueda instalar software verificado”.
  • La afirmación de que “no tiene sentido reducir el daño después de que el atacante ya entró” no es cierta en la ciberseguridad en general.
  • Pretender detener los cheats a costa de que todos pierdan la libertad de ejecutar el software que quieran es excesivo.

• Me gustaría ver juegos con un sistema opcional de emparejamiento con anti-cheat.
  Los que lo activen solo se emparejan entre sí, y los que lo desactiven quedan bajo autorregulación de la comunidad.
  Parece el tipo de experimento que solo una empresa del tamaño de Valve podría intentar.

  • El CS2 de Valve usa algo parecido, pero por lo que dicen tiene más cheats que Valorant.
  • FACEIT ya cumple más o menos ese rol.
    Pero la autorregulación comunitaria nunca es realmente eficiente a gran escala.
  • También hubo quien respondió: “¿eso no es básicamente PlaySafe ID?”.
  • Yo también apoyo esa idea.
    Personalmente, si hay un tramposo, prefiero cerrar el juego y salir a tomar aire.
    Antes que instalar un anti-cheat a nivel kernel “tipo malware”, prefiero jugar en consola.

• Como los tramposos muestran por naturaleza patrones de comportamiento anómalos, se los podría detectar registrando todas las entradas en el servidor y aplicando detección de anomalías con machine learning.
  También se puede crear objetos “honeypot” para provocar reacciones que solo tendría un tramposo.

  • Pero no se puede concluir que alguien hace trampa solo por ser un outlier estadístico.
    Como con el p-hacking, uno puede confundir variaciones aleatorias con señales significativas.
  • Yo también llevo mucho tiempo defendiendo un modelo estadístico de honeypots.
    De hecho, Dota 2 baneó a todas las cuentas que leyeron regiones de datos anómalas dentro del cliente.
    Anuncio del parche relacionado
  • Pero incluso Valve ha usado modelos de ML, y aun así sigue habiendo muchos tramposos en Counter-Strike.
    No es un problema que se resuelva simplemente arrojándole ML.
  • Los honeypots son útiles, pero no suficientes.
    El análisis de comportamiento tiene dificultades para seguir el ritmo al que cambia la comunidad.
  • En CS2, incluso solo con la estadística de “time-to-damage” se puede distinguir a muchos tramposos.
    Los tramposos suelen reaccionar unos 100 ms más rápido que los pros.

• Yo no soy gamer, pero me parece que el problema de prevenir cheats en juegos online es un desafío técnico muy interesante.
  El consejo de simplemente “procesarlo todo en el servidor” no es realista.

  • Prevenir cheats es, en la práctica, imposible.
    Los juegos son más como una liga de barrio que unas Olimpiadas, así que divertirse importa más que la equidad perfecta.
    Si se empareja a los tramposos entre sí, el impacto sobre los usuarios normales se reduce.
  • El método más efectivo es que administradores de servidor activos observen directamente y baneen.
    Pero las grandes compañías de videojuegos no mantienen ese tipo de personal.
  • Técnicamente, los tramposos siempre tienen ventaja porque controlan la máquina en la que corre el juego.
    El anti-cheat solo sirve para elevar la barrera de entrada.
  • También podría existir una estructura distribuida con servidores cerca de los ISP, como hace Netflix.
  • La solución de fondo es un cambio en la percepción cultural.
    Hace falta un ambiente donde hacer trampa online sea visto como cosa de perdedores.

• El anti-cheat a nivel kernel busca bloquear el cliente lo máximo posible, pero los tramposos siguen existiendo.
  Eso al final significa que el servidor no puede confiar completamente en el cliente.

  • No es solo un problema de costo, sino también de latencia y de diferencias de sincronización.
    Ni siquiera el código de red puede resolverlo por completo.
  • Un tramposo realmente motivado podría automatizar la entrada usando una cámara y otra computadora.

• La cultura actual de los juegos competitivos hace que las empresas empujen a los usuarios a competir contra desconocidos en vez de amigos.
  Pero uno se pregunta si realmente hace falta llegar a eso.

  • Aun así, mucha gente disfruta competir.
    Igual que en los deportes o el ajedrez, medir la habilidad es un deseo humano muy instintivo.

• La frase de que el anti-cheat de kernel es “el software más sofisticado” suena exagerada.
  Interceptar system calls no tiene nada de particularmente especial.

  • También da un poco de risa eso de que “escanea estructuras de memoria que la mayoría de los programadores nunca tocarán en su vida”.

• Parece que hay mucha gente que nunca ha jugado juegos competitivos.
  El Kernel-level anti-cheat (KLAC) sí funciona en la práctica.
  Los sistemas de kernel como FACEIT o Vanguard tienen una tasa de cheats mucho menor que los basados en VAC/VACNet.
  Claro, no son perfectos, pero suben muchísimo la barrera de entrada.
  Solo los dispositivos DMA ya cuestan cientos de dólares, y los cheats avanzados son caros porque funcionan por suscripción.
  Jugar es opcional, así que si no te gusta el KLAC, simplemente no juegues.
  Pero si lo rechazas, tienes que aceptar un entorno lleno de tramposos.

• Me sorprende saber que con medición de arranque basada en TPM y UEFI Secure Boot se puede hacer atestación remota, pero que aun así un atacante pueda manipularlo.

  • Como ejemplo, en tee.fail explican métodos para anular la atestación remota.
    Debemos tener la libertad de conservar plenamente la propiedad de nuestros dispositivos sin ser discriminados por ello.
  • La comunicación entre la motherboard y el chip TPM no está cifrada, así que se pueden alterar valores mediante ataques MITM.