Contra cheats e roubalheiras online

Vamos fazer o sonho dos 'cheaters' virar mingau e tentar dificultar o máximo possível a ação de um cheatcode desleal.


O primeiro passo:

• Não usar qualquer função do tipo 'highscore_algumacoisa()'.
  
• Não usar a variável interna 'score'.
  
• Não usar actions de score (aqueles ícones que a gente arrasta pra dentro dos eventos)

Segundo passo:

• Você deve usar um array (ou mais de um), transferir continuamente o valor correto do score para índices aleatórios e não deve usar um nome de variável sugestivo de que esse array (ou qualquer outra variável que faz parte desse esquema) se trata de um score (vou usar, mas apenas como exemplo).
  
  A preocupação com o nome da variável é por causa da forma como o Game Maker carrega códigos para a memória. Muitos deles ficam expostos, então, não precisa facilitar ainda mais, certo? Em outra linguagem isso não é necessário, mas você pode usar em qualquer outro lugar o que eu vou explicar aqui.

Código:

pontos_anterior[indice_atual] := pontos_atual[indice_atual];
indice_anterior := indice_atual;
indice_atual := irandom(31999);
pontos_atual[indice_atual] := pontos_anterior[indice_anterior];

• Depois de passar o valor correto para o 'pontos_atual' (em 'indice_atual'), você nunca deve zerar os valores do restante do array. Você deve tornar todo o resto aleatório, inclusive o array 'pontos_anterior', também.
  
  
• A única maneira de um possível cheater encontrar qual valor quer trapacear é sabendo qual valor "é" ou qual probabilidade de tal valor "ser". Existem duas maneiras principais de ele saber qual é o valor que procura: 1) quando você informar a ele ou... 2) quando houver um evento em que ele já observou que há mudança no score. Partindo disso, você pode fazer o seguinte:
  
  
• Informar menos vezes qual é o score real e nunca informar isso no caption da janela do jogo. Uma alternativa legal é dizer quanto ele ganhou, mas não dizer qual é o valor total o tempo todo.
  
  
• Use variáveis score falsas. Você pode colocar o valor verdadeiro do pontos_atual em vários outros arrays e mantê-los lá (sem alterar a posição), mas não faça isso no mesmo array cujo valor é o verdadeiro! Isso vai atrair análises de memória pra caminhos falsos e, quanto mais caminhos, melhor. Não quer dizer que você tenha que programar tudo "no braço", pois basta criar um outro array.
  
  
• Não transforme seu score em string a menos que queira mostrá-lo num evento Draw e faça isso usando outra variável que não seja a verdadeira. A exemplo da função string(), qualquer outra função também pode ser monitorada pelo cheater, portanto, é outra brecha atraente. Passe o valor para uma variável temporária (declarada com 'var') e use a função nela.
  
  
• A má notícia é que qualquer valor que possa ser incrementado ao score também é passível de sofrer cheatcodes. Se o cheater não conseguir alterar determinado valor, ele vai tentar procurar um outro valor que é somado ao que estava procurando antes. Isso inclui obtenção de itens, danos, experiência, conquistas, etc.
  
  A melhor maneira de sair disso é usar o mesmo esquema de arrays que eu mostrei. Se você achar que dá muito trabalho, não use variáveis e dê preferência para constantes. Não ajuda muito, mas dificulta um pouco mais.
  
  
• Você pode informar ao jogador um valor diferente do que é real. Se o score do jogador é 12000, o valor não deve significar 12000 unidades de fato. Pode ser 12, mas quando o score é mostrado (no Draw), o valor é multiplicado por 1000. Isso dificulta a ação do cheater, também.
  
  
• Essa é a mais fraca de todas as dicas, mas ainda pode ser outra 'camada' de proteção. Você pode usar um número negativo em vez de um positivo. Num valor negativo, o bit significativo é sempre 1 e a maioria dos cheaters procuram por padrões onde o bit significativo é 0 (unsigned), ou seja, positivo. A única diferença no código é que você vai ter que, em vez de somar, subtrair pra aumentar o score. É só ir usando números negativos, sempre.
  
  Quando exibir a pontuação, use "abs(pontos)" e tenha o mesmo cuidado de usar uma variável temporária como eu comentei na dica sobre strings.
  
  
• A alternativa mais eficaz de todas é usar uma alternância lógica de bits. Isso é um pouco mais complicado, mas é muito bom. Você pode alternar um número ímpar de bits (do valor que quer proteger) para a esquerda (respeitando o limite de double do Game Maker), mas quando usar esse valor em algum cálculo, alternar para a direita e recolocar o resultado alternando para a esquerda novamente.
  
  Na memória, o valor mostrado será diferente do valor usado no jogo. Nesse caso, esses tópicos talvez ajudem: Bits e Bytes, Operadores bitwise 1, Operadores bitwise 2

Vou acrescentando mais dicas ao post à medida que eu for me lembrando. Grande abraço.

Esse é um assunto complicado. Muito interessante este tópico, as dicas são realmente boas.

Quanto a não colocar nomes sugestivos, nunca usei, mas acho que há um programa que avacalha os códigos (isto é, torna ilegíveis), certo?

Creio que seria também uma boa ideia ficar testando se o valor do score está mudando com valores ou frequência anormais ou, ainda, se está com um valor que não pode ser atingido normalmente (por exemplo, num jogo onde o score sempre é múltiplo de algum número).

Sobre o esquema de colocar o valor real numa posição aleatória do array, pensei em fazer todos os valores do array ficarem dançando. Daí, por exemplo, "adicionar pontos" a alguns dos valores (escolhidos aleatoriamente, claro) de vez em quando, e sempre que o score mudar mesmo.

Exemplo de valores dançantes...:

Não sei se seria muito eficiente, mas é legal viajar um pouco nisso.

Incrivel brendan640! Eu já tinha pensado nessas alternativas! sério! mas só iria colocar em prática quando criasse um game com retorno financeiro real ou mesmo quando tivesse um higscore online(o que vai demorar) Mas antes disso ainda eu pesaria no anti decompiler.
Mas dependendo da situação... em conjunto ao anti decompiler as ideias do seu tuto, crendo que mesmo protetor não seria suficiente. E quando se trata de grana, todas defesas tem uma falha.

Mesmo assim vale a pena tentar.

Igor KinGamer escreveu:Quanto a não colocar nomes sugestivos, nunca usei, mas acho que há um programa que avacalha os códigos (isto é, torna ilegíveis), certo?

É uma alternativa. O antigo 'Obfuscator' fazia isso no código, mas acho que somente nas variáveis e nomes dos scripts. Estou certo? Tem anos que não ouço falarem nele...

Tenho um programa parado aqui, mas acho que funciona bem pra proteger o código porque além das variáveis, ele criptografa todo o resto, inclusive funções internas, palavras-chave, statements e tudo mais. O problema é que a pessoa tem que aplicar um patch no executável do Game Maker antes de gerar o stand-alone e outro patch no executável do jogo (depois de criado). Eu consegui funcioná-lo nas versões 7 e 8 piratas, mas não na 6 e não testei no Studio, ainda.

Igor KinGamer escreveu:Sobre o esquema de colocar o valor real numa posição aleatória do array, pensei em fazer todos os valores do array ficarem dançando. Daí, por exemplo, "adicionar pontos" a alguns dos valores (escolhidos aleatoriamente, claro) de vez em quando, e sempre que o score mudar mesmo.

Muito legal! Gostei muito dessa forma de fazer o valor mudar de posição. Poderia ser muito útil pra reduzir o número de loops no código. Em vez de criar um esquema pra cada valor a proteger, por que não indexar tudo num só array e misturar? É uma ótima ideia, principalmente se o range abrangente for mais alto.

moisesBR escreveu:Mas antes disso ainda eu pesaria no anti decompiler.
Mas dependendo da situação... em conjunto ao anti decompiler as ideias do seu tuto, crendo que mesmo protetor não seria suficiente. E quando se trata de grana, todas defesas tem uma falha.

Pois é, sempre há uma falha. A ideia é dificultar e vencer a tentativa de hack por desistência. Isso é eficiente porque a maioria dos "aspirantes" (principalmente) a cheaters não são tão experientes assim. Eles usam ferramentas prontas (famosas, inclusive) e com pouco conhecimento. Quanto mais situações o cheater tiver que prever ou contornar, menor será a chance de ele conseguir e quando se trata de análise de memória, cada tentativa de criar um cheatcode pode ser demorada. Chega um momento em que ele apenas desiste.

O problema maior é que é muito difícil proteger um jogo do Game Maker. De uma forma ou outra, o código interpretado vai ter que ser exposto na memória em algum momento da execução e o GML não tem nenhum método de proteção além de ferramentas como o Obfuscator (que é bem antigo, aliás).

Mesmo o anti-decompiler não é capaz de proteger o jogo contra cheatcodes. Ele é eficiente pra evitar que o jogo volte a ser um projeto editável, mas não protege o código quando ele cai na memória.