Como funcionam os anti-cheats de kernel

• Os sistemas modernos de anti-cheat baseados em kernel estão entre os softwares de segurança mais complexos no ambiente Windows, monitorando memória e eventos do sistema em nível de kernel mesmo durante a execução do jogo
• Para superar as limitações da proteção em modo de usuário, utilizam drivers de kernel e monitoram em tempo real criação de processos e threads, carregamento de imagens, alterações no registro etc.
• Sistemas importantes como BattlEye, EasyAntiCheat, Vanguard e FACEIT AC operam com uma arquitetura de três camadas composta por driver de kernel, serviço e DLL do jogo, sendo o Vanguard carregado na inicialização e, por isso, detentor do controle mais forte
• Eles bloqueiam trapaças combinando defesas em múltiplas camadas, como varredura de memória, detecção de hooks, verificação de integridade de drivers, resposta a ataques DMA e detecção baseada em comportamento
• No fim, a atualização remota baseada em TPM e a verificação de confiança do hardware estão emergindo como a base central da segurança em jogos

---

1. Limitações da proteção em modo de usuário e a migração para o kernel

• Processos em modo de usuário estão abaixo do kernel em termos de privilégio, então são facilmente contornados por trapaças em nível de driver de kernel ou hipervisor
  • Exemplo: uma chamada ReadProcessMemory pode ser falsificada por meio de hooking no kernel
• Cheats em modo kernel podem manipular diretamente a memória do jogo e evitar detecção em modo de usuário
• Para responder a isso, o anti-cheat migrou para o nível de kernel, realizando monitoramento no mesmo nível de privilégio

2. A “corrida armamentista” entre cheat e anti-cheat

• Continua a corrida por elevação de privilégios: modo de usuário → kernel → hipervisor → DMA
• O anti-cheat responde com bloqueio de drivers, detecção de hipervisor e defesa DMA baseada em IOMMU
• Esse processo aumenta o custo e a dificuldade de desenvolver cheats, com o efeito de barrar o acesso de usuários comuns

3. Principais sistemas de anti-cheat de kernel

• BattlEye: centrado no driver de kernel BEDaisy.sys, registra callbacks para criação de processos, threads e carregamento de imagens
• EasyAntiCheat (EAC): pertence à Epic Games e usa uma estrutura semelhante de três camadas
• Vanguard: carrega vgk.sys na inicialização e exerce controle forte com um modelo de lista de permissões para drivers
• FACEIT AC: obtém alto nível de confiança com monitoramento em nível de kernel
• O artigo da ARES 2024 destaca que esses sistemas têm uma estrutura técnica semelhante à de rootkits, embora seu objetivo seja defesa

4. Estrutura de três camadas do anti-cheat de kernel

• Driver de kernel: executa hooking de chamadas de sistema, varredura de memória e controle de acesso
• Serviço em modo de usuário: responsável por comunicação de rede, gestão de banimentos e envio de telemetria
• DLL do jogo: realiza verificações dentro do processo do jogo e IPC com o serviço
• A comunicação entre eles ocorre por IOCTL, Named Pipe e Shared Memory

5. Diferença entre carregamento na inicialização e em tempo de execução

• BattlEye/EAC: carregam o driver quando o jogo é iniciado e o descarregam ao encerrar
• Vanguard: é carregado na inicialização e monitora todos os drivers carregados depois disso
  • Por isso, é necessário reiniciar o sistema, mas a proteção começa já na fase de boot

6. Monitoramento baseado em callbacks do kernel

• ObRegisterCallbacks: controla acesso a handles de processo e bloqueia acesso à memória por processos externos
• PsSetCreateProcessNotifyRoutineEx: bloqueia a criação de processos de cheat
• PsSetCreateThreadNotifyRoutine: detecta threads anômalas dentro do processo do jogo
• PsSetLoadImageNotifyRoutine: detecta carregamento de DLLs não permitidas
• CmRegisterCallbackEx: monitora alterações no registro
• Driver minifilter: bloqueia acesso a arquivos de cheat no nível do sistema de arquivos

7. Proteção de memória e varredura

• Restrição de acesso a handles para bloquear leitura/escrita externa de memória
• Verificação de hash das seções de código para detectar patches no código
• Percurso da árvore VAD para detectar memória executável mapeada manualmente
• Identificação heurística de memória executável anônima, DLLs mapeadas manualmente e shellcode

8. Detecção de injeção

• Detecta diversas técnicas de injeção, como CreateRemoteThread, APC, NtMapViewOfSection e Reflective DLL
• Análise de stack frames (RtlWalkFrameChain) para verificar execução de código anômala

9. Detecção de hooks

• Hooking de IAT: detecta adulteração da Import Address Table
• Hooking inline: verifica patches comparando instruções JMP no início de funções
• Verificações de integridade de SSDT, IDT e GDT para impedir hooking em nível de kernel
• Detecção de uso direto de syscall para bloquear tentativas de contornar a ntdll

10. Proteção em nível de driver

• Detecção de drivers não assinados e modo de assinatura de teste
• Operação de blocklist para impedir ataques BYOVD (abuso de drivers vulneráveis)
• Monitora estruturas internas do kernel como PiDDBCacheTable, MmUnloadedDrivers e BigPool para detectar drivers mapeados manualmente

11. Antidebugging e prevenção de análise

• NtQueryInformationProcess para verificar a presença de depurador
• Detecção de depurador de kernel pela variável KdDebuggerEnabled
• Detecção de threads ocultas com a flag ThreadHideFromDebugger
• Bloqueio de ambientes de análise por verificação de timing com RDTSC, breakpoints de hardware e presença de hipervisor

12. Cheats baseados em DMA e resposta

• Dispositivos DMA via PCIe leem memória sem intervenção da CPU
• A IOMMU restringe acessos DMA, mas pode ser neutralizada se estiver desativada ou mal configurada
• Disfarçar dispositivos FPGA como dispositivos legítimos dificulta a detecção
• Secure Boot e TPM 2.0 podem mitigar parcialmente o problema por meio da verificação de integridade de boot

13. Detecção baseada em comportamento e machine learning

• Análise da entrada do mouse para diferenciar movimento humano de mira automática
• Uso de modelos CNN e Transformer para detectar triggerbots e aimbots
• Redes neurais em grafo para detectar trapaças em equipe, como wallhack e conluio
• Pipeline de telemetria: captura de entrada no kernel → transmissão criptografada → análise de ML no servidor → decisão de banimento

14. Ambientes virtuais e evasão de análise

• Detecção de VM por meio do bit de hipervisor do CPUID e de strings do fornecedor
• Verificação de rastros de registro e dispositivos de VMware, VirtualBox e Hyper-V
• Ambientes com virtualização dupla podem ser identificados por atraso na execução de instruções

15. Identificação de hardware e aplicação de banimentos

• Geração de HWID com base em SMBIOS, disco, GPU, MAC, MachineGuid etc.
• Spoofing de HWID pode ser tentado por manipulação de registro, drivers ou hardware físico,
  mas pode ser detectado por inconsistência entre identificadores ou formatos anormais

16. Tendências futuras e transição tecnológica

• Após o DMA, a próxima etapa são cheats baseados em firmware, elevando ao máximo a dificuldade de detecção
• Aimbots de hardware baseados em IA são difíceis de distinguir de entradas humanas
• Atestação remota baseada em TPM e cloud gaming estão surgindo como alternativas de longo prazo
• O anti-cheat de kernel continua sendo a linha de frente prática,
  mas a verificação de confiança do hardware e a validação no lado do servidor são apontadas como o rumo final

[GN⁺]

Comentários do Hacker News

• Em resumo, os cheats modernos burlam o anti-cheat usando hipervisores, patches de BIOS, dispositivos DMA etc.
  Quanto mais a proteção é reforçada no nível de hardware, mais os criadores de cheats evoluem junto.
  Mas, com o surgimento da análise de gameplay baseada em IA, a abordagem de detectar o próprio trapaceiro vem mostrando resultado.
  No fim, o futuro está em anti-cheat em modo de usuário, não em modo kernel, e na análise de gameplay.

  • Dizer que patch de BIOS é “muito popular” parece exagero.
    Na verdade, isso parece ser prova de que o anti-cheat está funcionando bem.
    Antes, bastava baixar um programa e já dava para trapacear, mas agora a barreira de entrada ficou tão alta que muita gente nem tenta.
    Ainda assim, no começo do texto foi dito que essas medidas defensivas podem ser neutralizadas, então fica a dúvida se elas são confiáveis ou não.
  • Eu jogo WoW, e havia muitas reclamações de que a Blizzard baniu usuários inocentes.
    Eu mesmo tive duas contas banidas, mas consegui reverter pelo suporte ao cliente.
    Porém, como parece que IA está sendo usada no atendimento, imagino que haja muitos bans injustos.
    Esse tipo de sistema de banimento baseado em comportamento tem o risco de punir por engano até usuários dedicados, então é difícil confiar.
  • As técnicas que você mencionou têm o efeito de aumentar o custo do ataque.
    Ou seja, como qualquer um já não consegue mais criar cheats, o anti-cheat está tendo algum sucesso.
    Mas a análise de gameplay provavelmente só pega trapaceiros mais óbvios, e pode deixar passar cheats do tipo ESP.
  • A análise comportamental não pega os ‘trapaceiros discretos’.
    Esse tipo de trapaceiro destrói a comunidade aos poucos, então é ainda mais perigoso.
  • A ActiBlizz é praticamente a única empresa que toma medidas legais com regularidade contra desenvolvedores de cheats pagos como Bossland e EngineOwning.

• Mexer no kernel é ignorar todo o modelo de segurança do sistema operacional.
  Na prática, já houve casos em que anti-cheats com bugs tiveram privilégios de root comprometidos.
  O certo é usar os recursos de sandbox do SO e a cadeia de confiança da fase de boot.

  • O ecossistema de PCs não leva a segurança da cadeia de boot tão a sério quanto os celulares.
    Por isso é difícil depender só dos recursos do SO, e a attestation também tem alcance prático limitado.
    Mesmo sem ser perfeito, se isso puder reduzir estatisticamente o número de trapaceiros, já tem valor.
  • Segurança de verdade não é trancar o cliente, e sim validar no servidor apenas os comportamentos permitidos.
  • Fica a dúvida se isso significa “vender PCs travados onde só é possível instalar software verificado”.
  • A afirmação de que “não faz sentido reduzir o dano depois que o atacante já entrou” não é verdadeira para cibersegurança em geral.
  • É exagerado querer impedir cheats ao custo de todo mundo perder a liberdade de executar o software que quiser.

• Eu gostaria de ver jogos com um sistema opcional de pareamento por anti-cheat.
  Só quem ativou o anti-cheat jogaria entre si, e quem desativou ficaria em uma estrutura regulada pela própria comunidade.
  Parece que só uma empresa do porte da Valve conseguiria testar algo assim.

  • O CS2 da Valve usa algo parecido, mas ouvi dizer que a taxa de cheats é maior do que em Valorant.
  • O FACEIT já cumpre esse papel.
    Mas autorregulação da comunidade nunca é eficiente em grande escala.
  • Também houve quem reagisse com “isso não é o PlaySafe ID?”.
  • Eu também apoio essa ideia.
    Pessoalmente, acho que, se houver trapaceiro, é melhor simplesmente fechar o jogo e sair para tomar um ar.
    Em vez de instalar um anti-cheat em nível de kernel, “parecido com malware”, prefiro jogar em console.

• Trapaceiros, por natureza, mostram padrões de comportamento anormais, então seria possível pegá-los registrando todas as entradas no servidor e aplicando detecção de anomalias com machine learning.
  Também dá para criar objetos “honeypot” para induzir apenas trapaceiros a reagirem.

  • Mas não dá para concluir que alguém é trapaceiro só com base em outliers estatísticos.
    Como em p-hacking, você pode confundir variações acidentais com sinais significativos.
  • Eu também venho defendendo há muito tempo um modelo estatístico de honeypot.
    De fato, o Dota 2 baniu todas as contas que leram áreas anormais de dados dentro do cliente.
    Anúncio de patch relacionado
  • Porém, a Valve também já usa modelos de ML, e mesmo assim ainda há muitos trapaceiros em Counter-Strike.
    Não é um problema que se resolve simplesmente jogando ML em cima.
  • Honeypots são úteis, mas não suficientes.
    A análise comportamental tem dificuldade para acompanhar a velocidade com que a comunidade muda.
  • No CS2, só as estatísticas de ‘time-to-damage’ já conseguem distinguir muitos trapaceiros.
    Trapaceiros normalmente reagem cerca de 100 ms mais rápido que jogadores profissionais.

• Eu não sou gamer, mas acho que o problema de prevenção de cheats em jogos online é um desafio tecnicamente interessante.
  O conselho simplista de “processar tudo no servidor” não é realista.

  • Impedir cheats é praticamente impossível.
    Jogos são mais como liga de bairro do que Olimpíadas, então o mais importante é a diversão, não a equidade perfeita.
    Se trapaceiros forem pareados entre si, o impacto sobre usuários comuns diminui.
  • O método mais eficaz é ter administradores de servidor ativos observando e aplicando bans diretamente.
    Mas grandes empresas de jogos não mantêm esse tipo de equipe.
  • Tecnicamente, trapaceiros sempre têm vantagem porque controlam a máquina em que o jogo está rodando.
    O anti-cheat só serve para elevar a barreira de entrada.
  • Talvez também fosse possível uma estrutura distribuída com servidores perto dos ISPs, como a da Netflix.
  • A solução fundamental é uma mudança de percepção cultural.
    É preciso criar um ambiente em que trapacear online seja visto como coisa de perdedor.

• O anti-cheat em nível de kernel tenta travar o cliente o máximo possível, mas ainda assim trapaceiros continuam existindo.
  No fim, isso significa que o servidor não pode confiar completamente no cliente.

  • Isso não é só uma questão de custo, mas também de latência e diferença de perspectiva.
    Nem o código de rede consegue resolver isso por completo.
  • Um trapaceiro realmente motivado pode até automatizar entradas com uma câmera e outro computador.

• A cultura competitiva dos jogos hoje em dia é uma estrutura em que as empresas fazem os usuários competir com estranhos, em vez de amigos.
  Mas fica a dúvida se é mesmo necessário chegar a esse ponto.

  • Ainda assim, muita gente gosta da competição em si.
    Disputar habilidade, como nos esportes ou no xadrez, é um desejo humano instintivo.

• A expressão de que anti-cheat em kernel seria “o software mais sofisticado” parece exagerada.
  Interceptar system calls não é nenhuma técnica especial.

  • A frase de que ele “escaneia estruturas de memória que a maioria dos programadores nunca tocará na vida” é meio engraçada.

• Parece haver muita gente que nunca jogou jogos competitivos.
  Kernel-level anti-cheat (KLAC) realmente funciona.
  Soluções em kernel como FACEIT ou Vanguard têm muito menos cheats do que abordagens baseadas em VAC/VACNet.
  Claro que não são perfeitas, mas aumentam bastante a barreira de entrada.
  Só um dispositivo DMA já custa centenas de dólares, e cheats avançados são caros por serem vendidos por assinatura.
  Jogos são uma escolha, então, se você não gosta de KLAC, é só não jogar.
  Mas, se recusar isso, vai ter de aceitar um ambiente tomado por trapaceiros.

• Ouvi dizer que medições de boot com TPM e UEFI Secure Boot permitem atestação remota, e surpreende saber que um atacante ainda pode manipular isso.

  • Como exemplo, em tee.fail há uma explicação de como neutralizar a atestação remota.
    Devemos ter a liberdade de garantir plenamente a propriedade do nosso dispositivo sem sofrer discriminação.
  • A comunicação entre a placa-mãe e o chip TPM não é criptografada, então é possível alterar valores com um ataque MITM.