[Admin] tierrilopes 3052 Posted March 26, 2018 Share Posted March 26, 2018 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. 2 2 Link to post Share on other sites
Mário. 191 Posted March 26, 2018 Share Posted March 26, 2018 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. 1 Link to post Share on other sites
[Admin] tierrilopes 3052 Posted March 27, 2018 Author Share Posted March 27, 2018 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. 1 Link to post Share on other sites
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now