Deep Dive: Arquitectura y Mecanismos de los Anti-Cheats a Nivel de Kernel

La lucha contra las trampas en los videojuegos ha escalado desde el espacio de usuario hasta el nivel de kernel, impulsada por la necesidad de establecer un modelo de confianza en un entorno inherentemente hostil. Los sistemas anti-cheat modernos operan en el anillo 0 de Windows, utilizando primitivas del sistema operativo que tradicionalmente se asocian con rootkits, para obtener la visibilidad y el control necesarios para detectar y neutralizar software malicioso. Esta evolución es una respuesta directa a la persistente "carrera armamentista" donde los desarrolladores de cheats explotan continuamente nuevas capas de abstracción del sistema, desde el usermode hasta los hipervisores y los dispositivos PCIe DMA, forzando a los defensores a operar en niveles de privilegio cada vez más bajos y con mayor intrusión.

El problema fundamental de la computación que estos sistemas abordan es la seguridad en un entorno de ejecución no confiable. Cuando un cliente ejecuta un juego, el entorno local es inherentemente vulnerable a la manipulación por parte del usuario. Los anti-cheats de kernel buscan establecer un "enclave" de confianza dentro de este entorno no confiable, monitoreando y protegiendo la integridad del proceso del juego y del sistema operativo subyacente. La justificación de su existencia radica en la necesidad de mantener la equidad competitiva en los juegos multijugador, lo que a su vez impulsa la inversión en defensas cada vez más sofisticadas.

Arquitectura del Sistema

Los anti-cheats de kernel modernos siguen un modelo arquitectónico de tres componentes: un driver de kernel (Ring 0), un servicio de usermode (privilegios SYSTEM) y una DLL inyectada en el proceso del juego (Ring 3). El driver de kernel, como BEDaisy.sys de BattlEye o vgk.sys de Vanguard, es el componente central que registra callbacks del kernel (ObRegisterCallbacks, PsSetCreateProcessNotifyRoutineEx, PsSetLoadImageNotifyRoutine, CmRegisterCallbackEx, minifilters) para monitorear eventos del sistema en tiempo real, como la creación de procesos/hilos, la carga de imágenes, las operaciones de registro y el acceso al sistema de archivos. Este driver también realiza escaneos de memoria, incluyendo el recorrido del árbol VAD (Virtual Address Descriptor) para detectar código inyectado manualmente o regiones de memoria ejecutables sin respaldo de archivo, y hashing periódico de secciones de código para detectar parches.

La comunicación entre el driver de kernel y el servicio de usermode se realiza a través de IOCTLs (I/O Control Codes), un mecanismo mediado por el kernel que permite solicitudes controladas. El servicio de usermode gestiona la comunicación con los servidores backend, la aplicación de prohibiciones y la recolección/transmisión de telemetría. La DLL inyectada en el juego realiza verificaciones del lado del usermode, interactúa con el servicio a través de named pipes o shared memory sections (creadas con NtCreateSection y NtMapViewOfSection), y sirve como punto final para las protecciones específicas del proceso del juego. Vanguard se distingue por cargar su driver de kernel en el arranque del sistema (boot-time loading), lo que le permite observar y validar todos los drivers que se cargan posteriormente, implementando un modelo de allowlist más estricto que el blocklist de otros sistemas. Las defensas también incluyen la detección de hooks (IAT, inline, SSDT, IDT/GDT), técnicas anti-depuración (NtQueryInformationProcess, KdDebuggerEnabled, ThreadHideFromDebugger, RDTSC, DRx) y la mitigación de ataques BYOVD (Bring Your Own Vulnerable Driver) mediante blocklists y la verificación de estructuras internas del kernel como PiDDBCacheTable y MmUnloadedDrivers. La telemetría conductual, que incluye el análisis de entrada de ratón y teclado, y modelos de Machine Learning, complementa las defensas estáticas para detectar patrones de trampas que son invisibles a nivel de software.

OB_CALLBACK_REGISTRATION callbackReg = {0};
OB_OPERATION_REGISTRATION opReg[2] = {0};
UNICODE_STRING altitude = RTL_CONSTANT_STRING(L"31001");
opReg[0].ObjectType = PsProcessType;
opReg[0].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE;
opReg[0].PreOperation = ObPreOperationCallback;
opReg[0].PostOperation = ObPostOperationCallback;
opReg[1].ObjectType = PsThreadType;
opReg[1].Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE;
opReg[1].PreOperation = ObPreOperationCallback;
opReg[1].PostOperation = NULL;
callbackReg.Version = OB_FLT_REGISTRATION_VERSION;
callbackReg.OperationRegistrationCount = 2;
callbackReg.Altitude = altitude;
callbackReg.RegistrationContext = NULL;
callbackReg.OperationRegistration = opReg;
NTSTATUS status = ObRegisterCallbacks(&callbackReg, &gCallbackHandle);

VOID ScanForManuallyMappedCode(PEPROCESS Process)
{
    KAPC_STATE apcState;
    KeStackAttachProcess(Process, &apcState);
    PVOID baseAddress = NULL;
    MEMORY_BASIC_INFORMATION mbi;
    while (NT_SUCCESS(ZwQueryVirtualMemory(
        ZwCurrentProcess(),
        baseAddress,
        MemoryBasicInformation,
        &mbi,
        sizeof(mbi),
        NULL)))
    {
        if (mbi.State == MEM_COMMIT &&
            (mbi.Protect & PAGE_EXECUTE_READ ||
             mbi.Protect & PAGE_EXECUTE_READWRITE ||
             mbi.Protect & PAGE_EXECUTE_WRITECOPY) &&
            mbi.Type == MEM_PRIVATE)
        {
            ReportSuspiciousRegion(mbi.BaseAddress, mbi.RegionSize,
                "Executable private memory without file backing");
        }
        baseAddress = (PVOID)((ULONG_PTR)mbi.BaseAddress + mbi.RegionSize);
        if ((ULONG_PTR)baseAddress >= 0x7FFFFFFFFFFF) break;
    }
    KeUnstackDetachProcess(&apcState);
}

BOOLEAN IsRunningInVM(void)
{
    int cpuInfo[4];
    __cpuid(cpuInfo, 1);
    if (cpuInfo[2] & (1 << 31)) {
        __cpuid(cpuInfo, 0x40000000);
        char vendor[13];
        memcpy(vendor, &cpuInfo[1], 4);
        memcpy(vendor + 4, &cpuInfo[2], 4);
        memcpy(vendor + 8, &cpuInfo[3], 4);
        vendor[12] = '\0';
        if (strcmp(vendor, "VMwareVMware") == 0 ||
            strcmp(vendor, "VBoxVBoxVBox") == 0 ||
            strcmp(vendor, "Microsoft Hv") == 0 ||
            strcmp(vendor, "KVMKVMKVM") == 0) {
            return TRUE;
        }
        return TRUE;
    }
    return FALSE;
}

Fundamentos Teóricos

La arquitectura de los sistemas anti-cheat de kernel se conecta directamente con los principios de seguridad de sistemas operativos y la taxonomía de rootkits. El paper de ARES 2024, "If It Looks Like a Rootkit and Deceives Like a Rootkit" (Vella et al., 2024), analiza cómo estos sistemas comparten características técnicas con los rootkits, como la operación a nivel de kernel, el registro de callbacks a nivel de sistema y una visibilidad amplia de la actividad del sistema operativo. Esto subraya que las primitivas necesarias para una defensa efectiva son las mismas que las utilizadas por el software malicioso, debido a las limitaciones impuestas por la arquitectura de Windows.

La detección de anomalías conductuales, especialmente en el análisis de entrada de usuario, se basa en principios de la interacción humano-computadora y la estadística. La Ley de Fitts, que describe el tiempo necesario para moverse rápidamente a un área objetivo, es un fundamento para entender los patrones de movimiento del ratón humano. Los trabajos como "Anti-Cheat: Attacks and the Effectiveness of Client-Side Defences" (Collins et al., 2024) y "AntiCheatPT: A Transformer-Based Approach to Cheat Detection in First-Person Shooter Games" (Sousa et al., 2025) aplican técnicas avanzadas de Machine Learning, incluyendo CNNs y arquitecturas Transformer, para modelar y detectar desviaciones de estos patrones humanos, conectando la seguridad de juegos con la investigación en inteligencia artificial y análisis de series temporales.