Jump to content
Sign in to follow this  
Tierri Lopes

[QNA] Proteção anti-hack

Recommended Posts

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.

  • Like 2
  • Upvote 2

Share this post


Link to post
Share on other sites

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.

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.

Our website is made possible by displaying online advertisements to our visitors.
Please consider supporting us by disabling your ad blocker.
You will be able to see content when you disable your adblocker and enable javascript.