Driver anti-cheat Tower of Fantasy: vulnerabilidad BYOVD

¿Qué es un driver anti-cheat de kernel y por qué es crítico?

Los drivers anti-cheat de kernel operan en el nivel más privilegiado del sistema operativo (ring 0), lo que les otorga acceso sin restricciones para detectar software malicioso o trampas en videojuegos. Esta arquitectura, aunque efectiva para la detección, convierte a estos componentes en vectores de ataque si presentan vulnerabilidades. El análisis de Vespalec sobre el driver anti-cheat de Tower of Fantasy (identificado como ksophon_x64) expone precisamente este riesgo: un driver con capacidades peligrosas que, paradójicamente, nunca se carga durante la ejecución del juego.

Para founders tech que desarrollan soluciones en gaming, seguridad o SaaS, comprender estos fallos es esencial. La confianza del usuario y la integridad del sistema dependen de arquitecturas robustas, especialmente cuando se opera a nivel kernel.

Hallazgos técnicos: un toolkit BYOVD que no se activa

El análisis reverso del driver revela varias fallas críticas:

Driver no cargado por defecto: A pesar de estar firmado y referenciado en el sistema, el driver ksophon_x64 no se ejecuta durante el inicio del juego. Esto puede verificarse deshabilitando las claves de registro LoadImagePatch, Start y Type antes del lanzamiento, permitiendo que el juego funcione sin protección alguna.
Bypass trivial: Los atacantes pueden inyectar código malicioso inmediatamente después del arranque del juego o implementar drivers personalizados para eludir controles, ya que el anti-cheat no bloquea acceso a memoria kernel ni código sin firmar.
Capacidades de terminación y protección de procesos arbitrarios: El driver posee funciones que permiten matar procesos del sistema o protegerlos sin autenticación adecuada, lo que lo convierte en un BYOVD (Bring Your Own Vulnerable Driver) potencial para ataques de escalamiento de privilegios.

Aunque el driver no representa un riesgo inmediato al no cargarse, su existencia firmada con certificado válido y persistencia post-desinstalación abre la puerta a abusos futuros por actores maliciosos.

El concepto BYOVD: cuando los drivers legítimos se vuelven armas

BYOVD (Bring Your Own Vulnerable Driver) es una técnica de ataque donde los adversarios introducen en el sistema un driver firmado y legítimo, pero con vulnerabilidades conocidas, para ganar privilegios elevados y evadir controles de seguridad como el Driver Signature Enforcement de Windows.

¿Cómo funciona?

El atacante despliega un driver vulnerable (ej. anti-cheats de juegos como mhyprot2.sys de Genshin Impact o ksophon_x64 de Tower of Fantasy).
Explota las fallas del driver para realizar lecturas/escrituras arbitrarias en memoria kernel, terminar procesos críticos (antivirus, EDR) o mapear código malicioso.
El sistema confía en el driver porque está firmado digitalmente; la revocación de certificados es lenta y las pruebas de concepto (PoC) circulan públicamente.

Precedentes en la industria gaming

El caso de Genshin Impact es emblemático: su driver mhyprot2.sys fue explotado por operadores de ransomware para deshabilitar soluciones antivirus como 360 Total Security, permitiendo el despliegue de malware en controladores de dominio. Estos ataques se distribuyeron mediante instaladores falsos que simulaban software legítimo como AVG.

En el ecosistema de Tower of Fantasy, aunque el driver no se carga activamente, su arquitectura permite ataques similares si un adversario decide aprovecharlo.

Impacto para founders tech y startups

Este tipo de vulnerabilidades tiene implicaciones directas para founders que desarrollan productos tecnológicos:

Diseño de arquitecturas seguras: Operar a nivel kernel debe ser el último recurso. Alternativas como drivers de modo usuario con sandboxing o APIs nativas de Windows (ej. PatchGuard) reducen superficie de ataque.
Gestión de confianza: Un driver vulnerable puede destruir la reputación de marca. La transparencia en auditorías de seguridad y respuesta rápida ante reportes es crítica.
Compliance y responsabilidad: En sectores regulados (fintech, healthtech), el uso de componentes de kernel sin certificación rigurosa puede violar normativas de protección de datos.
Mitigación proactiva: Implementar detección de drivers vulnerables mediante soluciones EDR, monitoreo de integridad del sistema y uso de herramientas como Microsoft Autoruns para auditar servicios de kernel.

Lecciones prácticas del caso Tower of Fantasy

Para equipos técnicos y CTOs de startups, el análisis de Vespalec ofrece aprendizajes accionables:

Validación de carga de componentes críticos: Asegúrate de que los drivers de seguridad se carguen y ejecuten correctamente. Un componente dormido no aporta protección y sí riesgo latente.
Autenticación y autorización robustas: Cualquier función que permita terminar o proteger procesos debe requerir autenticación criptográfica fuerte, no solo llamadas IOCTL sin validación.
Minimización de privilegios: Si tu producto requiere interacción con el sistema operativo, evalúa si realmente necesitas ring 0 o si puedes lograr objetivos con APIs de ring 3.
Auditorías externas: Contrata equipos especializados en ingeniería reversa y seguridad ofensiva para identificar fallas antes de que lo hagan los atacantes.
Plan de revocación de certificados: Ten un proceso claro para revocar firmas digitales y actualizar componentes en caso de compromiso.

Vulnerabilidades comunes en drivers anti-cheat

El ecosistema gaming está plagado de drivers kernel con patrones de fallo similares:

Driver	Juego	Vulnerabilidad principal	Vector de ataque
mhyprot2.sys	Genshin Impact	Escalamiento de privilegios user-to-kernel	Terminación de procesos antivirus
ksophon_x64	Tower of Fantasy	No carga + falta de autenticación IOCTL	Inyección de cheats / BYOVD potencial
vgk.sys	Valorant (Vanguard)	Escaneo agresivo de hardware + persistencia	Evasión mediante mapeo manual en memoria

Estos casos refuerzan la necesidad de equilibrar seguridad y usabilidad sin comprometer la integridad del sistema host.

Conclusión

El análisis del driver anti-cheat de Tower of Fantasy ilustra una paradoja preocupante: un componente diseñado para proteger se convierte en un riesgo de seguridad latente. Aunque el driver no se carga activamente, su arquitectura vulnerable y persistencia en el sistema lo convierten en un candidato perfecto para ataques BYOVD. Para founders tech, este caso subraya la importancia de diseñar con seguridad desde el origen, realizar auditorías rigurosas y operar con el principio de mínimo privilegio. En un entorno donde la confianza del usuario es frágil y la superficie de ataque se expande, invertir en arquitecturas robustas no es opcional: es estratégico.

¿Desarrollas soluciones tech donde la seguridad es crítica? Únete gratis a Ecosistema Startup y conecta con founders que comparten retos similares en arquitectura, compliance y ciberseguridad.

Conectar con founders