Parte: 19 — Seguridad de videojuegos, cheats y anti-cheat · Fuente principal: documentación de Epic Games y Valve ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Comprender y verificar arquitecturas anti-cheat sobre el Game Security Range, conectando vulnerabilidad, abuso controlado, telemetría, evidencia, causa raíz, mitigación y prueba de regresión sin actuar sobre software de terceros.
Al finalizar, el alumno podrá:
| # | Tema | Evidencia esperada |
|---|---|---|
| 1 | Defensa por capas | Produce una decisión o evidencia verificable |
| 2 | Integridad, telemetría y comportamiento | Produce una decisión o evidencia verificable |
| 3 | User-mode y kernel-mode | Produce una decisión o evidencia verificable |
| 4 | Privacidad, privilegio y enforcement | Produce una decisión o evidencia verificable |
Anti-cheat es una arquitectura socio-técnica: prevención autoritativa, integridad del cliente, telemetría, análisis conductual, reputación, revisión y enforcement. Cada capa observa cosas distintas y falla de forma distinta. Delayed enforcement puede proteger señales, pero alarga el daño; una revisión inmediata reduce daño, pero puede revelar el detector y amplificar falsos positivos.
User-mode comparte restricciones con aplicaciones; kernel-mode obtiene visibilidad y control mayores a costa de privilegio, superficie de ataque, compatibilidad y confianza. Que una capacidad sea técnicamente posible no la vuelve proporcional. El laboratorio permanece en user-space y estudia drivers solo como frontera arquitectónica: threat model del propio componente, actualización segura, mínimo privilegio, auditoría, rollback y respuesta a vulnerabilidades.
El diagrama se lee como un bucle de ingeniería, no como una cadena de sanción. El supuesto habilita un abuso dentro del target propio; la señal solo permite formular una hipótesis; la decisión incorpora contexto; la mitigación debe volver al supuesto y demostrar con una regresión que la confianza cambió. Si el último arco no puede verificarse, solo se ocultó el síntoma.
| Término | Definición en contexto |
|---|---|
| Defensa | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| Integridad, | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| User-mode | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| Privacidad, | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
python -m unittest discover -s tests -v desde labs/game-security y conserva la línea base.síntoma → timeline → evidencia → hipótesis → causa raíz → fix → regresión.Entrega una ficha con threat boundary, reproducción en el rango, evento de telemetría, decisión explicada, alternativa legítima, causa raíz, mitigación y prueba de regresión.
Criterio de aceptación: otra persona puede ejecutar los comandos con la misma semilla, obtener la evidencia citada y comprobar que la mitigación bloquea el caso adversarial sin romper el caso normal.
| Síntoma | Causa y corrección |
|---|---|
| La anomalía se trata como culpabilidad | Falta contexto; correlaciona y revisa alternativas legítimas. |
| El control solo oculta un valor | La autoridad no cambió; valida o deriva el estado en servidor. |
| El experimento no se reproduce | Faltan semilla, versión, unidades o configuración; regístralas. |
| El detector castiga lag/FPS | El dataset no estratifica condiciones; evalúa por subpoblación. |
| Se propone instrumentar terceros | Fuera del alcance; usa exclusivamente el target educativo. |
¿Una alerta basta para sancionar? No. Es una hipótesis con un nivel de confianza; la consecuencia exige evidencia proporcional, política, auditabilidad y apelación.
¿Ofuscar el cliente resuelve el problema? Puede elevar costo, pero no reemplaza autoridad, invariantes ni minimización de información.
¿Por qué el laboratorio es sintético? Permite controlar verdad, semilla y falsos positivos sin invadir jugadores ni construir una herramienta reutilizable contra terceros.
Clase 352 — Seguridad del protocolo de juego