Como se proteger de macros e bots em seu jogo utilizando: SetWindowDisplayAffinity

 O jogador vê o jogo, mas o programa de macro (ou qualquer gravador de tela como OBS/Discord) vê uma tela preta — você precisa utilizar recursos de Proteção de Conteúdo do Sistema Operacional.

Essa é a mesma tecnologia que a Netflix, a Udemy e aplicativos de banco usam para impedir que você tire print ou grave a tela.

Aqui estão as abordagens para implementar isso no seu jogo:

1. A Solução "Mágica": SetWindowDisplayAffinity (Windows)

No Windows, existe uma API nativa feita exatamente para isso. Se você configurar a sua janela com essa flag, o Windows remove a imagem da janela do fluxo de composição que é enviado para softwares de captura.

• O que acontece: O jogador vê o jogo normal. O Python (mss, pyautogui), o OBS e o Discord veem uma janela preta.

• Como implementar: Você precisa chamar uma função da user32.dll.

Se o seu jogo é feito em Unity (C#), o código seria algo assim:

C#

using System;
using System.Runtime.InteropServices;
using UnityEngine;

public class AntiScreenCapture : MonoBehaviour
{
    // Importa a função do Windows
    [DllImport("user32.dll")]
    private static extern uint SetWindowDisplayAffinity(IntPtr hwnd, uint dwAffinity);

    // Constante que diz "Esconda essa janela de capturas"
    private const uint WDA_MONITOR = 0x00000001; 

    [DllImport("user32.dll")]
    private static extern IntPtr GetActiveWindow();

    void Start()
    {
        // Pega o ID da janela do jogo
        IntPtr hWnd = GetActiveWindow();
        
        // Ativa a proteção
        SetWindowDisplayAffinity(hWnd, WDA_MONITOR);
    }
}

Limitações dessa técnica:

1. Isso bloqueia tudo: streamers não conseguirão transmitir seu jogo pelo OBS (a menos que usem captura de janela específica ou placa de captura, dependendo da versão do Windows).

2. Macros mais avançados podem tentar injetar código (DLL Injection) dentro do processo do jogo para ler a memória direto da GPU, ignorando o Windows.

2. A Solução "Adversária": Ruído Visual (Visual Noise)

Se você não quer bloquear totalmente a tela (para permitir streamers, por exemplo), mas quer quebrar o Image Search do Python, você pode usar técnicas que confundem a visão computacional.

Os macros geralmente buscam pixels exatos ou uma correspondência muito alta (ex: 90% de similaridade).

• Técnica: Renderizar uma camada quase invisível de "ruído" sobre a UI do jogo.

• Como funciona:

  • Imagine que o botão do seu jogo é Vermelho (RGB: 255, 0, 0).

  • A cada frame, você muda aleatoriamente a cor dele para (254, 0, 0), (255, 1, 0), etc.

  • Para o olho humano, nada mudou.

  • Para o cv2.matchTemplate ou pyautogui.locateOnScreen, a imagem nunca é idêntica à imagem de referência que o criador do macro salvou. Isso obriga o criador do macro a baixar muito a "precisão" (confidence), o que faz o macro começar a clicar em lugares errados.

3. A Realidade: A "Corrida Armamentista"

É importante ser realista: Não existe proteção perfeita.

1. Placas de Captura: Se o criador do macro usar uma placa de captura externa (Elgato, etc.) conectada em outro PC, ele "pula" qualquer proteção de software que você criar no Windows. Ele vai analisar o sinal HDMI direto.

2. Leitura de Memória: Cheats profissionais não olham para a imagem. Eles leem o endereço de memória onde está a variável HP_Inimigo. Contra isso, você precisa de ofuscação de código ou anti-cheats de kernel (como Easy Anti-Cheat ou Vanguard), o que é bem caro e complexo.

Resumo

Para um desenvolvedor independente (Indie):

A Opção 1 (SetWindowDisplayAffinity) é a melhor. É fácil de implementar (poucas linhas de código), custo zero e bloqueia 99% dos "macros de pixel" feitos em Python, AutoHotKey e JitBit.

Explicação sobre como funciona o meio que trapaceiros utilizam para burlar a proteção utilizando Placas de Captura como Elgato entre outras.

Imagine que o seu jogo é uma carta secreta que você está escrevendo dentro de um quarto (o Computador).

1. Proteção de Software (SetWindowDisplayAffinity): É como se você proibisse qualquer outra pessoa que está dentro do quarto (outros programas como OBS, Discord, Python) de olhar por cima do seu ombro. O Windows é o guarda na porta e garante que ninguém lá dentro espie.

2. Placa de Captura (Hardware): O problema é que, para você jogar, a carta precisa ser mostrada em uma janela (o Monitor). A Placa de Captura não entra no quarto. Ela intercepta o "correio" que leva a carta do quarto até a janela.

O Fluxo do "Crime" Perfeito

Para o computador onde o jogo está rodando, tudo parece normal. Ele não sabe que está sendo espionado porque a interceptação acontece fora dele, no cabo HDMI.

Aqui está o diagrama de como esse setup funciona fisicamente:

Passo a Passo da Trapaça de Hardware:

1. A Saída Obrigatória: Para o jogador humano ver o jogo, a sua placa de vídeo (GPU) é obrigada a enviar a imagem pelo cabo HDMI. Se o seu jogo bloquear isso, a tela do jogador fica preta e ele não consegue jogar.

2. O Interceptador (Capture Card): O cheater conecta o cabo HDMI do PC dele em uma placa de captura (como uma Elgato, Avermedia), e não direto no monitor.

3. A Duplicação: A placa de captura faz duas coisas simultaneamente:

   • Passthrough: Envia a imagem para o monitor real (para o cheater ver e jogar).

   • Stream: Envia uma cópia digital exata da imagem via USB para um Segundo Computador.

4. O Cérebro Externo (PC 2): No segundo computador (que pode ser um laptop simples), roda o script de Python/OpenCV.

   • Como esse script está em outro PC, o anti-cheat do seu jogo (que está no PC 1) não consegue escanear os processos dele. Ele nem sabe que o PC 2 existe.

5. O Ataque (Input Falso): O script no PC 2 analisa a imagem, acha o inimigo, e manda um comando para um dispositivo USB (como um Arduino ou Raspberry Pi) conectado ao PC 1.

   • O PC 1 recebe o comando do Arduino e pensa: "Ah, o usuário moveu o mouse". Ele não tem como saber que foi um robô, pois o sinal elétrico é idêntico ao de um mouse real.

Por que isso anula sua proteção?

A função SetWindowDisplayAffinity diz ao Windows: "Não deixe softwares de captura de tela lerem essa janela".

O Windows obedece e bloqueia o PrintScreen, o Snipping Tool e o OBS. Porém, o Windows não tem poder sobre o sinal elétrico que já saiu da placa de vídeo e está trafegando pelo fio HDMI. A partir do momento que a imagem saiu do PC, o Windows perdeu o controle sobre ela.

Existe defesa contra isso?

Para um desenvolvedor Indie, não.

Mesmo grandes empresas (Riot Games com o Vanguard, Blizzard com o Ricochet) sofrem para detectar isso. As únicas formas de mitigar são:

1. Análise Heurística de Input (Server-side): O seu servidor percebe que o mouse do jogador se move de forma "perfeita demais" ou reage rápido demais (humanos levam ~200ms para reagir, robôs levam 5ms). Se o padrão for desumano, você bane.

2. Custo e Complexidade: A boa notícia é que esse método exige 2 computadores e uma placa de captura cara ($150+). Isso elimina 99% dos "script kiddies" que só querem baixar um hack grátis na internet. Esse método é usado apenas por criadores de cheats profissionais ou usuários muito dedicados.

Checagem de inputs enviados, uma boa opção para se proteger: 

Para o sistema operacional (Windows), um clique vindo do seu dedo (mouse USB) e um clique vindo de um script (Python pyautogui, AutoHotKey) percorrem caminhos diferentes até chegarem no seu jogo.

Aqui estão as técnicas para diferenciar e bloquear esses inputs:

1. A Flag "Injected" (A barreira mais eficaz)

Quando um programa simula um clique (usando a função SendInput do Windows, que é o que 99% dos macros usam), o Windows, por segurança, marca esse evento com uma "etiqueta" (flag) chamada LLMHF_INJECTED.

Seu jogo pode instalar um "gancho" (Hook) de baixo nível no mouse e no teclado. Antes do clique ser processado pelo jogo, você verifica: "Esse clique tem a etiqueta de injetado?". Se tiver, você ignora.

Como funciona na prática (Lógica):

1. O jogo monitora a fila de eventos do sistema (LowLevelMouseProc).

2. Chega um evento de clique.

3. O jogo verifica a propriedade flags.

4. Se flags & LLMHF_INJECTED for verdadeiro -> Bloqueia.

5. Se for falso -> Deixa passar (é hardware físico).

Exemplo de implementação (Conceito em C#): Isso bloquearia instantaneamente PyAutoGUI, AutoHotKey, teclados virtuais e macros de software comuns.

C#

if ((mouseEvent.flags & 0x01) == 0x01) // 0x01 é a flag de Injected
{
    // É um robô! Ignorar o comando.
    return 0; 
}

2. Uso de "Raw Input" (Entrada Bruta)

A maioria dos jogos usa APIs de alto nível (como Input.GetAxis na Unity). Essas APIs já entregam o dado "mastigado" e misturado.

Se você usar a API de Raw Input do Windows, você consegue ver a origem do dispositivo.

• Mouse Real: Envia sinais com um ID de hardware específico (VID/PID).

• Driver Virtual: Softwares de macro às vezes criam um "Mouse Virtual". Pelo Raw Input, você pode ver que o clique veio de um dispositivo chamado "Virtual HID Device" e não de um "Logitech G502".

• Ação: Você pode criar uma "Allowlist" (Lista Branca). O jogo só aceita inputs que venham de dispositivos que o Windows reconhece como hardware físico legítimo.

3. A Análise Heurística (O "Teste de Turing" de Movimento)

Se o atacante for esperto, ele pode tentar burlar as flags. Mas é muito difícil esconder a matemática do movimento.

• Humanos: Quando movemos o mouse, o movimento é "sujo". Existe micro-tremor, aceleração curva e overshoot (passar um pouco do alvo e voltar).

• Macros:

  • Teleporte: O mouse pula de X:100 para X:500 em 0 segundos. (Impossível fisicamente).

  • Linha Reta: O mouse move em uma linha perfeitamente reta (pixel perfect). Humanos fazem arcos.

  • Tempo Fixo: O clique ocorre exatos 100ms após o movimento. Humanos variam (95ms, 112ms, 98ms).

Defesa: Você cria um script que calcula a "entropia" (caos) do movimento. Se o movimento for matematicamente perfeito demais por muito tempo, você bloqueia os inputs temporariamente.

O "Chefão Final": Arduino e Hardware Cheats

Aqui voltamos à limitação que mencionei antes.

Se o usuário usar um Arduino Leonardo (ou Raspberry Pi) programado para agir como um mouse:

1. Ele é conectado na porta USB.

2. O Windows reconhece ele como um "Mouse HID Compatível".

3. Quando o script manda o Arduino clicar, o Arduino envia um sinal elétrico real pela porta USB.

Neste caso:

• A flag LLMHF_INJECTED não existe (porque veio da porta USB).

• O Raw Input vê um dispositivo de hardware real.

Como se proteger disso? A única defesa contra Hardware Cheats é a Opção 3 (Heurística). Mesmo que o sinal venha de um hardware, se o Arduino mover o mouse em linha reta perfeita ou clicar 20 vezes por segundo com intervalo exato de 0.05s, seu sistema de análise comportamental deve detectar a anomalia e bloquear.

Resumo do Plano de Defesa

Se você quer proteger seu jogo sem gastar milhões:

1. Nível 1 (Fácil): Implemente a checagem de LLMHF_INJECTED. Isso elimina 90% dos macros simples (Python, AHK).

2. Nível 2 (Médio): Implemente SetWindowDisplayAffinity (a tela preta que falamos antes). Isso impede que o macro "veja" onde clicar.

3. Nível 3 (Difícil): Análise estatística de cliques (Heurística). Se o jogador clicar mais de 15 vezes por segundo (CPS), bloqueie os inputs por 5 segundos. Ninguém clica tão rápido consistentemente.

Como se proteger de burlarem LLMHF_INJECTED

Quando um criador de cheats quer burlar a verificação de LLMHF_INJECTED, ele geralmente recorre a duas táticas avançadas:

1. Drivers de Kernel (Ring 0): Eles criam um driver falso que "fala" diretamente com o núcleo do Windows, inserindo o clique antes que o sistema possa etiquetá-lo como "software".

2. Hardware Spoofing (Arduino/Microcontroladores): Como discutimos, eles usam um dispositivo físico que simula ser um mouse.

Para um desenvolvedor independente, combater drivers de Kernel é uma batalha perdida (exige milhões em investimento, como o Vanguard da Riot). No entanto, você pode se proteger muito bem focando na Análise Comportamental (Heurística).

Se você não pode confiar na "etiqueta" do input, analise a qualidade do input. Robôs, por definição, tendem a ser perfeitos ou repetitivos demais.

Aqui estão 3 camadas de defesa que funcionam mesmo contra inputs "reais":

1. Análise de Distribuição Temporal (O "Clique Humano")

Essa é a forma mais eficiente de pegar Arduinos e Macros de driver. Humanos nunca pressionam e soltam um botão no mesmo intervalo exato de tempo.

• A Lógica: Um clique de mouse tem dois eventos: MouseDown (apertar) e MouseUp (soltar).

• O Bot Ruim: Manda o Down e o Up instantaneamente (0ms de diferença) ou usa um atraso fixo (ex: exatos 50ms sempre).

• O Bot "Bom": Tenta variar (45ms, 55ms, 52ms), mas geralmente usa uma função randômica simples (distribuição uniforme).

• O Humano: Segue uma "Distribuição Normal" (Curva de Gauss). Às vezes somos rápidos, às vezes lentos, dependendo da adrenalina do jogo.

Implementação: Crie um buffer que guarda os últimos 50 tempos de duração do clique (tempo entre Down e Up). Calcule o Desvio Padrão.

• Se o Desvio Padrão for 0 (tempos idênticos) = BAN.

• Se a média for muito baixa (< 30ms consistentemente) = Provável Macro (humanos raramente clicam tão rápido o tempo todo).

2. Análise de Trajetória do Mouse (Entropia de Movimento)

Mesmo que o cheat use um driver para mover o mouse, ele precisa calcular como chegar do ponto A ao ponto B.

• Teleporte: Se o mouse desaparece da coordenada (100,100) e reaparece na (500,500) sem passar pelos pontos intermediários num único frame. Isso é fisicamente impossível para um mouse real.

• Linha Reta Perfeita: Mover em linha reta pixel-perfect é muito difícil para humanos. Nós fazemos arcos sutis.

• Correção de Mira (Overshoot): Quando movemos o mouse rápido para um botão, muitas vezes passamos um pouco e voltamos (micro-correção). Robôs param no pixel exato instantaneamente.

Implementação: Monitore a posição do mouse a cada frame. Se a "eficiência do caminho" (distância real percorrida vs. distância em linha reta) for consistentemente igual a 1 (linha reta perfeita) por muitas vezes, marque como suspeito.

3. Honeypots (Armadilhas Visuais)

Já que o macro depende de "ver" algo na tela (leitura de pixel ou imagem), você pode usar isso contra ele.

• A Isca: Desenhe um pixel ou um pequeno objeto que o bot está procurando (ex: a barra de vida de um inimigo) em uma área invisível para o jogador, ou fora da área jogável, ou coberto por uma UI transparente.

• A Detecção: O jogador humano nunca clicaria ali porque ele sabe que não é um inimigo real ou ele nem está vendo. O bot, que apenas escaneia a memória de vídeo procurando a cor vermelha #FF0000, vai tentar clicar.

• O Gatilho: Se receber um clique nessa coordenada "proibida", é 100% de certeza que é um bot.

Resumo da Defesa em Camadas

Não confie em apenas uma técnica. A segurança vem da soma delas:

1. Nível Básico: Cheque LLMHF_INJECTED. (Pega 90% dos scripts amadores).

2. Nível Intermediário: Use SetWindowDisplayAffinity. (Impede a visão dos bots baseados em imagem).

3. Nível Avançado: Monitore a consistência dos cliques (Desvio Padrão). (Pega bots de Hardware/Arduino).

4. Nível "Mestre": Armadilhas Visuais (Honeypots). (Pega bots que varrem a tela cegamente).

Vamos entender o que é Drivers de kernel (Ring 0):

Para entender isso, precisamos visualizar o seu computador como um sistema de castas ou hierarquia militar. Nem todo programa tem a mesma "autoridade".

O processador (CPU) do seu computador divide o acesso em anéis de proteção (Protection Rings).

1. A Hierarquia: "User Mode" vs. "Kernel Mode"

• Ring 3 (User Mode - O Plebeu): Aqui vivem os programas normais: Navegador, Discord, Bloco de Notas, seu Jogo e também scripts de Python (pyautogui) e AutoHotKey.

  • Regra: Eles não têm acesso direto ao hardware. Se o Python quer mover o mouse, ele não fala com o mouse. Ele tem que pedir "por favor" para o Windows (API).

  • Consequência: Quando o Python pede "Windows, clique ali", o Windows diz "Ok, vou clicar, mas vou colocar uma etiqueta (flag) dizendo que foi você que pediu, e não o mouse". É aqui que nasce o LLMHF_INJECTED.

• Ring 0 (Kernel Mode - O Rei): Aqui vivem o Kernel do Windows (o núcleo do sistema) e os Drivers de Dispositivo (o software que controla sua placa de vídeo, seu mouse, seu teclado).

  • Regra: Eles têm acesso total à memória e ao hardware. Se um código no Ring 0 diz "o mouse moveu", o sistema aceita como verdade absoluta. Ninguém questiona o Rei.

2. O Golpe: "Furando a Fila"

O sistema de segurança que aplica a etiqueta LLMHF_INJECTED funciona como um porteiro na entrada do Ring 0.

• Fluxo Normal (Macro Comum):

  1. Python (Ring 3) manda comando.

  2. Porteiro (Windows API) recebe, coloca o crachá de "Visitante/Injected" e deixa passar.

  3. Jogo (Ring 3) vê o crachá e bloqueia.

• Fluxo do Kernel Driver (Cheat): O cheat instala um driver falso que roda no Ring 0.

  1. O programa de cheat fala secretamente com esse driver.

  2. O driver (já dentro do castelo) injeta o comando de clique depois do porteiro, diretamente na fila de processamento de hardware.

  3. Para o resto do sistema, aquele clique brotou lá dentro como se tivesse vindo do cabo USB do mouse.

  4. O Jogo recebe o clique sem crachá nenhum, acha que é legítimo e aceita.

3. Por que isso é difícil de fazer? (A Barreira de Entrada)

Se é tão eficiente, por que todo mundo não faz isso?

1. Assinatura Digital: O Windows moderno (especialmente o 10 e 11) se recusa a carregar qualquer driver no Ring 0 que não tenha uma assinatura digital válida da Microsoft. Para conseguir essa assinatura, você precisa ser uma empresa legítima e pagar caro.

2. Risco de Tela Azul (BSOD): No Ring 3 (Python), se seu código falhar, o programa fecha. No Ring 0, se o código tiver uma vírgula errada, o computador inteiro trava instantaneamente (Tela Azul da Morte), pois você corrompeu o núcleo do sistema.

3. Anti-Cheats de Kernel: Jogos competitivos (Valorant, Fortnite, Apex) instalam seus próprios drivers no Ring 0 (Vanguard, Easy Anti-Cheat).

   • Eles funcionam como "polícia secreta". Eles escaneiam outros drivers no Ring 0 para ver se tem algum não autorizado ou agindo de forma estranha. É uma guerra de gato e rato que acontece nas profundezas do sistema.

Resumo para sua defesa

Como desenvolvedor Indie, você não conseguirá bloquear drivers de Kernel via código simples (C#/Python), pois eles têm mais autoridade que o seu jogo.

A sua melhor aposta continua sendo a Heurística (Análise de Comportamento) que mencionei antes. Mesmo que o clique venha do "Rei" (Kernel) e pareça legítimo, se o "Rei" estiver clicando 50 vezes por segundo exatamente no mesmo pixel, você sabe que é um impostor. A estatística não mente, mesmo que o driver minta.

Como o trapaceiros fariam para burlar o Fluxo do Kernel Driver (Cheat) instalando um driver falso que roda no Ring 0.

Entender como o ataque funciona é o primeiro passo para a defesa. O que os desenvolvedores de cheats fazem nesse nível é engenharia reversa avançada do Windows.

Para "vencer" o sistema de flags (LLMHF_INJECTED) e proteção do Windows, o trapaceiro precisa resolver 3 problemas:

1. Entrada: Como colocar um código não autorizado no Ring 0 (Kernel) se o Windows bloqueia drivers sem assinatura?

2. Comunicação: Como o aplicativo do cheat (que tem interface gráfica) manda ordens para esse driver invisível?

3. Execução: Como o driver move o mouse sem o Windows perceber que é fake?

Aqui está a anatomia técnica desse processo:

1. O Problema da Entrada: "O Cavalo de Troia" (Driver Mapping)

O Windows 10/11 tem um recurso chamado DSE (Driver Signature Enforcement). Ele impede que qualquer driver sem uma assinatura digital válida da Microsoft seja carregado.

Como o trapaceiro burla isso? Eles raramente criam um driver do zero e assinam (isso custa caro e deixa rastro). Eles usam a técnica de "Vulnerable Driver Exploit" (ou Mapping).

• O Passo a Passo:

  1. O trapaceiro acha um driver legítimo e antigo que tem assinatura válida da Microsoft (ex: um driver velho da Capcom, de um antivírus antigo ou de controle de ventoinhas RGB).

  2. Esse driver antigo tem uma falha de segurança conhecida (vulnerabilidade) que permite leitura/escrita de memória arbitrária.

  3. O programa de cheat carrega esse driver legítimo (o Windows aceita, pois a assinatura é válida).

  4. Através da falha desse driver, o cheat escreve o código malicioso dele direto na memória do Kernel.

  5. Resultado: O código do cheat está rodando no Ring 0, sem nunca ter sido um arquivo de driver "oficial". Ele está morando clandestinamente na memória.

2. A Comunicação: IOCTL (O Telefone Secreto)

Agora o código malicioso está no Kernel, mas o menu do cheat (onde o usuário configura "Aimbot Speed: 100%") está no User Mode (Ring 3). Eles precisam conversar.

Eles usam uma função do sistema chamada DeviceIoControl (IOCTL).

• O Cheat (App) cria um pacote de dados: { Comando: MOVER_MOUSE, X: 500, Y: 300 }.

• Ele envia isso para um endereço de memória específico que o Driver está monitorando.

• O Driver lê esse pacote e executa a ação.

Sua Proteção: Alguns anti-cheats tentam detectar essa comunicação. Se um processo estranho (o cheat) está enviando muitos pedidos IOCTL para um driver de sistema, isso é suspeito.

3. A Execução: MouseClassServiceCallback (Onde o crime acontece)

É aqui que o clique falso vira "verdadeiro".

O Windows funciona com uma cadeia de responsabilidade. Quando você move o mouse físico: Hardware (USB) -> Driver HID -> Driver de Classe de Mouse (mouclass.sys) -> Sistema Operacional -> Seu Jogo.

O Driver de Classe de Mouse tem uma função chamada MouseClassServiceCallback. É essa função que diz ao Windows: "Ei, recebi dados novos de posição!".

O que o Cheat faz: O driver do cheat, estando no Ring 0, consegue localizar essa função na memória e "chamar" ela diretamente ou injetar dados na estrutura que ela lê.

1. Ele cria uma estrutura de dados idêntica a que o driver USB criaria.

2. Ele chama a função MouseClassServiceCallback passando esses dados falsos.

3. Como a chamada veio de dentro do Kernel (Ring 0), a função mouclass.sys não adiciona a flag LLMHF_INJECTED. Ela assume que, se veio do Kernel, veio do hardware.

---

Como você se protege disso? (Sua Defesa)

Como desenvolvedor Indie, você não consegue impedir que o usuário carregue drivers no Kernel (nem a Microsoft consegue totalmente). Mas você pode detectar os efeitos colaterais.

1. Verificação de Integridade (Difícil)

Drivers de cheat muitas vezes precisam alterar (hookar) funções do Windows para funcionarem.

• Técnica: Se você souber verificar a integridade da memória de certas DLLs do sistema, pode ver que elas foram alteradas. (Isso é complexo e perigoso de fazer sem causar crash no PC do usuário).

2. Monitoramento de Processos (Médio)

Para fazer o "Driver Mapping" (passo 1), o cheat precisa de um programa carregador (mapper.exe).

• Técnica: Monitore a lista de processos rodando junto com seu jogo. Se encontrar nomes conhecidos de ferramentas de cheat (ex: kdmapper, drvmap), feche o jogo.

3. A Defesa Comportamental (Sua melhor arma)

Volto a bater nesta tecla porque é onde o trapaceiro falha, não importa quão bom seja o driver dele.

Mesmo que o driver dele consiga inserir um clique "limpo" (sem flag de injected), o cheat ainda precisa decidir PARA ONDE mover o mouse.

• O Aimbot calcula: "A cabeça do inimigo está em X:800, Y:400".

• O Aimbot manda o driver mover para lá.

• O Erro: Aimbots tendem a travar a mira exatamente no centro da cabeça (bone) ou fazer movimentos lineares.

A solução definitiva para Indie Devs: Crie uma "pontuação de suspeita" no servidor (Server-Side).

• O jogador acertou 10 tiros seguidos? +10 pontos suspeitos.

• O tempo de reação dele foi menor que 100ms? +20 pontos suspeitos.

• O mouse dele fez uma linha reta perfeita? +50 pontos suspeitos.

• Total > 100? Kick ou Ban.

Dessa forma, você não precisa brigar com o Kernel do Windows (uma briga que você vai perder). Você briga contra a lógica do cheat, onde você tem controle total.