[QNA] Proteção anti-hack

[[Admin] tierrilopes 3052]

Até há cerca de 1 ano e pouco, vendia proteção anti-hack para metin2.

Deixei de o fazer pois houve tentativas de revenda e chargebacks no paypal, por isso projecto tornou-se privado.

Atualmente já a restruturei completamente, indo na v3.4.

________________

O problema está na filosofia que adotei para a mesma. Até agora, a minha filosofia era prevenir todo e qualquer acesso "maligno" ao cliente, negando acesso à memória, imports e certos ficheiros.

Cheguei à conclusão que este método é falível, principalmente pois atingi uma extensão de código que e difícil manter tudo "organizado". Portanto, decidi mudar de filosofia. Atualmente o meu objectivo é inutilizar todo e qualquer hack, sem negar acesso nenhum ao processo do cliente.

Com isto, os hacks acedem ao cliente como se não existisse proteção, mas as suas funções literalmente não fazem nada. A isto chamo a fase de Imunização.

Após os hacks estarem inutilizados, ou seja, as suas funções não terem impacto nenhum no cliente, aplico a proteção "antiga" em cima. Como a antiga já era difícil de manter, comecei projecto do zero, desta vez usando métodos e classes para organização.

Este projecto NÃO será vendido, até porque o mesmo implica mudanças substanciais na source de cliente e game, no entanto aberto a quem queira juntar-se ao desenvolvimento do mesmo.

 

Isto tudo para explicar a razão pela qual não vendo proteção anti-hacks, apesar de o ter feito no passado. Não se trata de descriminação perante individuo X ou Y, simplesmente quero concentrar-me no seu desenvolvimento por estar insatisfeito de como funcionava.

[Mário. 191]

Apoio totalmente a nova filosofia e já tive oportunidade de ver e analisar a mesma em ação.

Considero que é mais prático e eficiente tornar o cliente disponível para todos e mudar a estrutura interna de forma a que ir no sentido contrário de módulos pré-definidos pela source (headers, modules, imports, etc.). 

Um exemplo disso é a forma como o lalaker funciona. Se analisares como ela se comporta e que tipos de headers ela usa (graças a um packet reader) consegue-se descobrir que utiliza o header que se encontra disponível para o ataque (SPACE) = 3. Ora mudando o número, com a opção ProDamage ligado, a personagem acabaria por levar dc pois o objetivo do mesmo é utilização do default. O m2bob funciona de outra forma, excluindo a utilização de headers.

 

 

De certa forma, concordo e apoio.

[[Admin] tierrilopes 3052]

No tempo do alone, m2bob bastava modificar nome dos módulos, algo como:

import cenouradoida as net

Para que o mesmo deixasse de funcionar. Nessa altura, m2bob integrou um scanner para identificar os nomes dos.módulos, sendo que atualmente mudar o nome dos modules não tem efeito contra o m2bob.

Tenho algumas camadas, tanto heurísticas como dinâmicas, mas a mais simples e a primeira de todas é o processo modificar as suas próprias permissões. Quando o cliente é aberto, muda de permissões corretamente. No entanto, quando o mesmo é aberto pelo m2bob, não é possível auto ajustar-se pois o m2bob é que é o "dono".  Esta maneira simples já funciona desde 2015 sem qualquer atualização.