Técnicas para evitar clientes não oficiais em jogos em rede?

Em jogos em rede para vários jogadores, quais técnicas existem para tentar garantir que os usuários estejam se conectando ao aplicativo cliente oficial, e não a algum aplicativo cliente invadido?

Sei que provavelmente não há uma maneira certa de fazer isso, mas estou interessado em técnicas que podem ser empregadas para atenuar o problema.

Estou especialmente interessado em qualquer técnica que possa ser usada para jogos baseados na Web, mas imagino que a maioria possa ser aplicada em geral.

Obrigado!

Esse é um problema interessante, mas acho que você está fazendo a pergunta errada aqui. Deixe-me começar por detectar a abordagem do cliente invadido:

Se o seu cliente for executado no lado do usuário, ele poderá fazer o que quiser com seu código (até que seja muito complicado para ele, mas sempre haverá alguém mais inteligente na linha). Tudo o que você pode fazer, como codificação codificada de mensagens entre cliente e servidor, criação de certificados de cliente ou até fazer com que o cliente calcule sua soma de verificação, pode e com tempo suficiente, será descompilado e quebrado. Eu vi um software que veio com um dongle, este dongle tinha parte do código do aplicativo, mas, para poder executá-lo, o dongle primeiro verificou o CRC do aplicativo se não estivesse temperado .. é claro, depois de algum tempo, o dongle foi hackeado também .. além disso, se você fizer uma atualização de software, precisará reenviar o dongle ..

Além disso, o usuário pode usar seu próprio cliente para enganar - simulando o movimento do mouse e cliques, por exemplo.

Portanto, a pergunta deve ser - como detectar um bot player?

Aqui você tem algumas opções - medir o tempo entre cliques, medir a velocidade dos movimentos do mouse - o mouse se move exatamente do ponto A ao ponto B várias vezes e atinge exatamente as mesmas cordas? O movimento do usuário é repetível? Se quando o recurso que o usuário estava reunindo foi esgotado, o usuário passa para outra ação ou espera no local por horas? No final do dia, você acaba escrevendo o código de reconhecimento de padrões.

Em jogos em rede para vários jogadores, quais técnicas existem para tentar garantir que os usuários estejam se conectando ao aplicativo cliente oficial, e não a algum aplicativo cliente invadido?

Não acho que esse seja o caminho certo para abordar isso ou pelo menos não a única coisa com a qual você deve se preocupar.

1. Certifique-se de enviar apenas informações específicas do cliente para todos os clientes (por exemplo, um cliente não precisa saber o que um monstro, por exemplo, pode derrubar, basta enviar as informações após matá-las e apenas para os clientes especificados)

2. Faça a maioria dos cálculos no lado do servidor (posicionamento etc.). O cliente está fazendo seus próprios cálculos, mas nunca pode enviar seus próprios valores apenas suas ações. O servidor deve verificar se esta ação é válida e como afetará o jogo.

3. 1 e 2 são geralmente combinados com previsões. O cliente e o servidor tentam prever determinados comportamentos. O cliente, por exemplo, move o player, mas a cada x segundos ou ms. recebe uma correção pelo servidor

4. Cobrar os usuários por suas contas e não pelo cliente; dessa forma, um usuário pode se apossar de uma versão quebrada, mas não pode jogar sem uma conta.

Com o 2, você pode garantir que não haja hacks de dinheiro, de posição ou de parede, etc., mas os bots sempre foram um problema para muitas empresas. Até grandes nomes de empresas como a nevasca têm problemas com isso. O que você pode fazer é limitar o tempo de reprodução por conta, para que alguém não possa ficar on-line por mais de 540 horas por mês. Lembro-me de um bot que usava valores de cores de monstros + entrada de mouse para cultivar XP. Outra maneira seria fornecer um programa adicional que verifique outros aplicativos em execução e acesso à memória, mas isso traz uma série de novos problemas.

Editar:

Artigos muito bem escritos para iniciantes: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Não existe uma maneira verdadeira e infalível de garantir que o "cliente oficial" esteja em execução; qualquer mecanismo desse tipo dependerá do código de validação que comunica algum tipo de "segredo" ao servidor, que pode sofrer engenharia reversa, com tempo suficiente. Isso é basicamente o que acontece quando um software anti-hacking diz ao servidor que o cliente está OK.

Editar: para elaborar um pouco o exposto acima, considere o código que está validando o lado do cliente. Ele tem dois trabalhos muito difíceis: verificar se o código original está sendo usado (e nada mais está presente que possa interferir dinamicamente / em tempo de execução (!)), E comunicar esse resultado de volta ao servidor, de tal maneira que esta comunicação não pode ser falsificada. Enquanto a primeira parte é incrivelmente difícil, a segunda parte é totalmente impossível.

Se você pode atualizar o cliente e o servidor regularmente, pode trocar o segredo regularmente, com a esperança de dificultar o acompanhamento dos crackers. Com toda a probabilidade, no entanto, a menos que você esteja alterando a maneira como o segredo é codificado / implementado, ele pode ser descoberto rapidamente muito rapidamente. Então, basicamente, é uma corrida armamentista entre você e quem quiser decifrar - quem tem mais tempo e dinheiro para jogar no problema.

Tendo aceitado essa parte, há mais alguma coisa que possamos fazer? Em um mundo perfeito, com infinito poder de computação e largura de banda, você pode simplesmente transferir continuamente o estado entre o cliente e o servidor e fazer com que o servidor execute uma simulação perfeita do que está acontecendo no cliente. Esse modelo pode ser usado para validar as ações que o cliente alega estar realizando. Isso não detectará se um humano ou um bot está jogando, mas será capaz de validar se o cliente está reivindicando um tiro acontecendo através de uma parede ou alguma outra ação inconcebível.

Ter dados suficientes no servidor também é o primeiro passo para detectar comportamentos irregulares - com o objetivo de ser rápido demais para os seres humanos, etc. etc. Obviamente, a situação perfeita de simulação geralmente não é viável, mas algum tipo de modelo reduzido e estimado pode ser usado em muitas situações.

Você não especifica o tipo de jogo, então eu me inclinarei muito para os jogos de RPG / MMO. Mas muito disso pode e se aplica aos jogos de FPS, Estratégia e Ação. A maneira como grandes empresas de jogos multiplayer como a Blizzard lidam com esse problema em seus jogos é:

1. Faça todo o cálculo e ações do jogo no servidor, o cliente é apenas um terminal e um mecanismo de gráficos estúpidos. Portanto, se os jogadores estão usando um cliente diferente, isso realmente não importa em termos de jogo, eles não podem enganar a física do jogo.
2. Verifica programas / clientes óbvios de bot, procurando ações óbvias do computador, como repetição perfeita de eventos de clique e movimentos do mouse.
3. Verifica programas / clientes de bot não óbvios e alerta moderadores do jogo para o problema.

Eles então aparecem no jogo (se possível, para os mesmos jogos que o Starcraft 2 não é) ou assistem / conversam com o jogador sobre suas ações como um 'teste humano'. Ou pelo menos é assim que deve ser tratado. A Blizzard é muito boa nisso, mas historicamente outras empresas MMO não o foram.

A verificação de bots não óbvios não é fácil, mas algumas regras básicas a seguir incluem

• Procurando jogadores que, com apenas uma ligeira variação, estejam realizando as mesmas ações repetidamente. Isso pode estar em um nó de recurso em um MMO e cultivá-lo quando ele reaparece, ou pode estar rodando em círculos entre pacotes de saúde / munição em um FPS e nunca se desviar de um caminho específico e sempre usar a mesma arma. (Bots abaixo do ideal nos FPSs são raros, mas se o seu jogo tiver uma escada para subir, onde o número de jogos é mais importante que o talento do jogador, como alguns FPSs modernos, os bots se tornam valiosos novamente)
• Procurando jogadores que executam a mesma corrida ou estratégia exata repetidamente em um RTS. Existem certas ordens de construção no Starcraft que podem ser praticamente imbatíveis quando executadas por um bot.
• Procurando jogadores que coletaram vastas somas de recursos e agora estão destruindo infinitamente um item. Este foi um grande problema no Ultima Online.

O problema é que, quanto mais popular é o seu jogo, e quanto mais frutíferos forem os bots na redução do tédio, maior será a probabilidade de as pessoas usarem e criarem esses bots. E é trivial restringir a velocidade de movimento do mouse, adicionar variação humanística aleatória aos cliques, até fazer com que o bot cometa erros em uma taxa humana, abrindo e fechando partes do menu, pressionando o botão errado e fechando a janela, alternando entre teclado e teclado. o mouse funciona como os humanos para reduzir a fadiga das mãos. (você nem percebe que faz)

Portanto, o último passo em que alguém ou um bot está fazendo algo repetitivo por muito tempo realmente tem que ser um mod humano chegando ao jogador e conversando com ele. Se eles estão lá e respondem com respostas humanas, eles são humanos. Normalmente, os mods pedem ao jogador que pare um pouco ou os siga em algum lugar e execute outras ações, os aros se tornam mais complexos com o tempo.

Tanget

É claro que, eventualmente, alguém criará um bot que é indistinguível de uma pessoa real, passando no teste de Turing. E há muitos escritores de bot por aí que pretendem fazer exatamente isso.

Eu próprio tinha um fascínio passageiro pela ideia quando comecei a programar e criei bots inúteis para o Ultima Online, que ficariam na cidade e imitariam os NPCs. Os comandos eram super simples, por isso eram fáceis de executar, apenas pressionamentos de tecla para avançar em direções diferentes, e assistindo o bate-papo registrar seu próprio nome e enviar as mensagens para o ALICE por meio de uma versão web da IA. Não me lembro qual e provavelmente não existe mais.

/Tangente

O ponto é que você precisa decidir onde desenhar a linha. Se você não pode permitir que um exército de moderadores converse com pessoas que seu sistema identifica como bots, é melhor deixar a comunidade marcar as pessoas como bots e, quando isso acontecer com o tempo, chute o jogador por cerca de uma hora. Não proibir, apenas chutar. O verdadeiro problema para a maioria dos jogadores é que os robôs consomem recursos que outros jogadores humanos poderiam estar usando. Se os mobs são escassos, como foi o problema do Ragnarok Online, os bots que circulam e limpam áreas inteiras de inimigos enquanto pegam itens (ou não) são comuns e arruinam o jogo para outras pessoas. Assim, você pode evitar o custo dos exércitos administrativos dessa maneira.

Por fim, você também pode conviver com os bots como uma realidade do seu espaço de jogo e incentivar o uso deles. Isso requer que você projete seu jogo com base no uso eventual e comum de bots, treinadores e programas auxiliares. Quero dizer que houve um MMO que fez isso há cerca de 10 anos, mas não me lembro qual era. Foi o fim do jogo, porque os MMOs são pesados ​​e isso significava que 95% dos jogadores estavam longe de seus teclados a qualquer momento e destruíam a comunidade. Se você seguir esse caminho, tenha cuidado.

evite ter recursos de jogos dos quais um usuário possa vencer executando tarefas repetitivas , especialmente em jogos semelhantes a navegadores. características do jogo que causam tarefas repetitivas não apenas irritam os outros usuários, porque eles não têm tempo para fazê-las, mas também tornam o jogo muito facilmente botável (e muito menos divertido!)

Se um determinado recurso do jogo pode ser botável, por que existe esse recurso no jogo? Esse recurso está claramente chamando o usuário para criar um bot.

O jogo deve ser jogado dando ao jogador uma quantidade razoável de entretenimento, normalmente por um conjunto de opções não triviais. A capacidade de decidir enfrentar escolhas não triviais separa um humano de um bot. Por fim, em vez de procurar bots, pesquise no seu jogo onde um bot pode ser implementado e implemente você para ser usado por todos. Ao fazer isso, você economiza tempo para um jogador do jogo, evitando que ele execute tarefas chatas, enquanto luta contra os bots desde a raiz: se não há recursos de jogo com botões, como pode haver bots?

Minha conclusão é: eu diria que existe um limite na quantidade mínima de complexidade que um jogo precisa para não ser botável. Faça seu jogo acima desse limite, adicionando opções não triviais que, em última análise, aumentarão a experiência do usuário.

Enfim, talvez esse paradigma não se aplique mais nos dias atuais ... mas ainda acredito que é isso que faz um bom jogo.

As respostas existentes já são boas, mas eu gostaria de salientar que, se suas verificações forem caras (por exemplo: executar todo o servidor do jogo para garantir que o cliente não esteja trapaceando), você poderá optar por fazer apenas algumas o tempo .

Por exemplo, você só pode verificar ações em uma região específica ou por jogadores específicos (mudando aleatoriamente após algum tempo), ou apenas ter uma fila de ações e escolher aleatoriamente quais validar (e ignorar as outras). Talvez venha com uma heurística de quem provavelmente está trapaceando (basicamente procure por pessoas que tenham mais sucesso) e valide suas ações no servidor.

Verifique se o servidor não cede quando está validando ações e quando não está. Sempre envie sua resposta padrão até estar pronto para tomar uma ação (e não a exponha demorando mais para enviar uma resposta quando estiver validando e quando não estiver).

Dessa forma, você pode obter uma proteção muito boa contra trapaças, usando apenas a energia do servidor que você pode poupar (embora, obviamente, quanto mais perto você estiver da validação de cada ação, melhor será a proteção contra trapaças).

Bem, eu não acho que exista uma "solução de ultiamte". Você pode codificar os pacotes de dados e fornecer algumas regras ao servidor que recebe os pacotes. Por exemplo, você pode definir que o maior movimento realista / permitido é +1 e não como um trapaceiro / hacker que o definiria para 5 ou superior apenas para ser mais rápido. Basta pensar no que um hacker poderia fazer para ser melhor que outros jogadores e definir regras para isso.

A maneira mais simples é essencialmente tornar o cliente um terminal burro. Tudo é feito no servidor, e o cliente apenas envia comandos para o servidor. Dessa forma, o servidor está totalmente no controle de tudo.

No entanto, esse provavelmente não é o caso mais adequado para você, porque o servidor precisa executar mais cálculos e a experiência do usuário será pouco clara. Portanto, quanto mais lógica você deixar para o cliente executar, melhor a experiência do usuário, mas menos segurança haverá. Então você terá que encontrar um meio termo aceitável para você.

Além disso, envie apenas ao cliente o que "deveria" saber. Por exemplo, se um jogador inimigo estiver atrás de um muro, não envie essas informações para um cliente, ou um cliente invadido poderá discernir essas informações (leia-se: wallhack).

EDIT: Eu entendi mal a pergunta. Eu interpretei isso como "impedir chave pirateada / hackeada" em vez de "software hackeado que pode enviar uma mensagem para gerar 1 bilhão de ouro para o jogador".

Atualmente, a maioria dos jogos tem um valor vinculado a uma conta em um banco de dados, pois qualquer coisa que um cliente possa enviar para um servidor pode ser modificada. Este é provavelmente o método mais simples e eficaz.

Com a prevalência de Internet de alta velocidade e transferência de arquivos P2P, as empresas passaram de chaves de CD armazenadas localmente no cliente para chaves vinculadas a uma conta em seus servidores. Não há mais software cliente "oficial" ou "não oficial", pois qualquer um pode fazer o download do cliente. Mas você só pode jogar se tiver uma conta com acesso para jogar.

Isso também traz benefícios para a empresa, pois eles não precisam gastar tanto produzindo cópias físicas do software.