Loodo

No último dia 5 a comunidade de desenvolvedores de jogos nacionais foi abalada por um dossiê, que mostra supostas evidências de que quatro campanhas de marketing foram fraudadas por o que seria uma mini-quadrilha de crackers. Preferimos usar o termo “supostas” pois por mais que as evidências pareçam mostrar o que realmente aconteceu, cabe à justiça verificá-las, achar e punir os culpados.

Esta polêmica toda acabou por expor o fato já conhecido pela grande maioria dos desenvolvedores, mas muitas vezes deixado em segundo plano, fato este de que nenhum software  é 100% seguro. Então, se todos sabemos disso, porque não fazemos nada para aumentar esta segurança? Na coluna de hoje vamos falar um pouco sobre estas vulnerabilidades, como os crackers as exploram e o que podemos fazer para dificultar a vida deles.Um dos motivos para a segurança reforçada ficar de fora do desenvolvimento de um jogo é o mesmo de sempre: custo. Construir uma barreira sólida para atrapalhar os crackers é uma tarefa árdua e demorada, e na maioria das vezes simplesmente não vale o esforço.

Mas o desenvolvedor deve ter sempre em mente os dois principais motivos que atraem a ação destes “desenvolvedores do mal”: fama e dinheiro. Se o seu jogo alcançou uma boa visibilidade, e o seu ranking já alçou um status de “Parada Billboard”, fique atento, pois ele já pode estar na mira de crackers em busca dos seus 15 minutos, e um screenshot, de fama. Além da vaidade, a cobiça atrai ainda mais olhos, pois ao oferecer ganhos materiais o seu game passa a ter valor, literalmente, real. Ainda mais se oferecer uma espécie de “remuneração” recorrente, como venda de ítens de jogo, etc.

Então, por onde começar a construir os tijolos? Por quais portas-dos-fundos eles costumam entrar?

Bem, podemos listar algumas dessas vulnerabilidades:

• Confidencialidade
• Criptografia baixa ou inexistente
• Confidencialidade
• Regras de negócio no cliente
• Confidencialidade

No livro Exploiting Online Games, publicado em 2007, os autores mostram o que um cracker deve fazer para burlar e trapacear em jogos online. As técnicas basicamente consistem em decodificar o cliente do jogo e analisar os valores dos endereços de memória e de conseguir emular a comunicação cliente-servidor.

A criptografia hoje em dia não é uma coisa tão complexa de se trabalhar, mas ainda oferece um certo desafio para ser quebrada, mas não é impossível. O melhor caminho é utilizá-la em vários pontos do código – na sua maioria na troca de mensagens entre o cliente e o servidor – e possuir um sistema regular de atualizações (patches) pode ajudar se as chaves forem sempre atualizadas. Desta forma você garante um trabalho contínuo para os crackers, que podem nunca conseguir alcançar a velocidade das atualizações. Ou não.

Quanto às regras de negócio do jogo, o ideal é pensar num modelo MVC, onde o cliente do jogo atua apenas como View, e apenas envia requisições ao servidor e exibe os dados de maneira apropriada. Um dos exemplos citados neste excerto do livro citado acima cita como fazer com que um item que esteja longe do usuário apareça na frente dele, e de maneira análoga, como alterar os atributos deste mesmo item.

A técnica usada em ambos os casos é a de quebrar o código que está sendo executado pelo jogo, analisando os valores dos endereços de memória, à procura de um padrão, e depois alterar este conteúdo. Se quem controlar estas informações, de fato, for o cliente do jogo temos aí uma falha. Mas se quem detiver estes dados for o servidor, e ele não oferecer nenhuma função para que o cliente mova ou altere algum item, estas alterações não terão efeito. O cracker pode colocar a poção na sua frente, mas ao passar por ela o servidor não vai detectar nenhuma colisão, logo, não vai ter efeito algum.

É claro que a segunda solução é a melhor, mas acaba aumentando o tráfico de informações na rede, porém hoje em dia esta não é uma preocupação real, pois com a qualidade das conexões aumentando as empresas têm segurança em investir na infra-estrutura de troca de dados.

Por fim, mas não o de menos, a Confidencialidade. Se tomarmos como verdade as informações divulgadas no supra-citado dossiê, a maior vulnerabilidade das campanhas não foi técnica – apesar do acusado ter admitido, num fórum de crackers, ter quebrado um arquivo de Unity para ganhar uma promoção – e sim pessoal, ética.

Aparentemente o desenvolvedor envolvido nos quatro jogos passou informações confidenciais a amigos, que de posse delas puderam burlar o sistema de ranking dos jogos. Além disso em uma delas há suspeitas de que o próprio desenvolvedor tenha alterado os dados do jogo – eliminando participantes que haviam delatado o suposto ganhador e colocando o amigo em primeiro lugar.

Se não houver ética e comprometimento por parte do time de desenvolvimento, nenhum artifício técnico vai proteger os dados dos jogos. E os dados são, no final das contas, a parte mais importante de qualquer software.

Cuide bem dos seus.