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 server-side anti-cheat y diseño autoritativo 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 | Invariants y sanity checks | Produce una decisión o evidencia verificable |
| 2 | Rate limits y state machines | Produce una decisión o evidencia verificable |
| 3 | Simulación autoritativa | Produce una decisión o evidencia verificable |
| 4 | Reconciliación y regression tests | Produce una decisión o evidencia verificable |
Una invariante expresa lo que debe seguir siendo cierto: velocidad ≤ límite contextual, ammo nunca negativo, fire interval ≥ cooldown, daño solo desde un arma válida. Un sanity check descarta dominio inválido; un rate limit limita frecuencia; una máquina de estados impide transiciones como disparar durante reload. Juntos convierten reglas de diseño en controles ejecutables.
La simulación autoritativa evita enumerar todos los cheats posibles: si el cliente no puede fijar health o damage, muchas implementaciones distintas pierden efecto. Quedan abusos de intención válida —bots, información, colusión— que requieren detección. Reconciliation devuelve experiencia sin ceder verdad. Cada corrección debe incluir prueba del exploit y casos legítimos en bordes de latencia y física.
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 |
|---|---|
| Invariants | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| Rate | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| Simulación | Concepto de esta clase aplicado al Game Security Range y a su frontera de confianza. |
| Reconciliación | 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 353 — Arquitecturas Anti-Cheat