Bem-vindo ao Fórum!

Registre-se agora mesmo e fique por dentro da maior comunidade de Cheats do Brasil!

meuovo321

Hacking detected [Wall perfeito]

Recommended Posts

Bom dia a todos, alguêm poderia me dizer como funciona o sistema de detecção do cabal online, mesmo com o xingcode desativado, após modificar a memoria para desativar o wall protect, cerca de 30 a 60 segundo depois aparece a seguinte mensagem.

t6DfLBW.png :cry:

Esta mensagem não aparece só para na hora que modifico a memoria para o wall protect, também para outras coisas como GM/AOE/RANGE.

Eu acredito que isso seria algo do tipo Integrity Check, mais não tenho conhecimento suficiente para dizer isso e muito menos para superar esta defesa.

Aceito videos, topicos, ou documentos em outra língua, como tutoriais para superar este obstaculo.

Obrigado pela atenção! :think:

  • Like 1

Share this post


Link to post
Share on other sites

Existem diversos tutoriais sobre burlar integrity check, mas é bem provável que não seja o caso. Se souber depurar, checa o que verifica os endereços alvos pra entender melhor o que tem acontecido.

Uma outra saída seria procurar essa string "Hacking detected" e fazer um backtracing pra descobrir a origem dela.

 

Em sumo: você pode desativar o que tem verificado os bytes originais, o que tem verificado os bytes atuais ou o que dá o output de detecção quando constata modificação na memória. É preciso entender melhor o que exatamente tem acontecido no seu caso em específico.

  • Like 1

серафими многоꙮчитїи

k7OeJm8.png

Share this post


Link to post
Share on other sites

Uma aplicação PE(Portable-Executable) é dividida por seções, [.idata, .rsrc, .data, .text, .src] cada seção tem sua finalidade, armazenar variáveis, constantes,etc..., e a que lhe interessa nesse caso, o código compilado.

O código compilado de um .EXE fica dentro da seção .text, esse código não recebe modificações originarias, ou seja, um código FIXO, com bytes FIXOS.

Muitos anti-hacks usam a famosa verificação CRC para checar a integridade da seção .text, e isso tudo está dentro da lógica, já que o código compilado não vai se alterar, a não ser que alguma aplicação ou algum módulo interno faça essa alteração, resumindo, algum hack.

 

Então o padrão é, o executável abre, gera um cálculo único e retorna um valor e salva em uma variável. Exemplo: 0xFFFFFFFF

 

Após isso o mesmo só vai ficar executando uma tarefa padrão para checar a integridade do .text. Ele vai ficar pegando o CRC em tempo de execução e comparando com o valor que está salvo dentro da variável, caso esteja diferente é porquê alguém alterou alguma parte daquela seção, dando a entender que comprometeu o código original.

 

Quer fazer um teste legal para comprovar isso? Se sim, vamos la.

 

Levando em conta que o .text do cabal é bem extenso, podemos deduzir que vai levar um certo tempo para a função calcular o CRC e salvar em uma variável, certo? Então nesse meio tempo você pode alterar a memória, que ele vai salvar o valor já com a alteração, logo você vai ter um código original alterado e a função que checa a integridade não vai conseguir identificar.

 

No seu caso, coloque para alterar o código da função da verificação de coordenada logo quando sua DLL der Attach no processo e o resultado será positivo.

 

Existe inúmeras maneiras de se burlar essa verificação, essa que te expliquei é a pior delas, já que no CABAL se altera o código do .text para ativar diversas funções.

 

Boa sorte.

  • Like 1

Share this post


Link to post
Share on other sites
Existem diversos tutoriais sobre burlar integrity check, mas é bem provável que não seja o caso. Se souber depurar, checa o que verifica os endereços alvos pra entender melhor o que tem acontecido.

Uma outra saída seria procurar essa string "Hacking detected" e fazer um backtracing pra descobrir a origem dela.

 

Em sumo: você pode desativar o que tem verificado os bytes originais, o que tem verificado os bytes atuais ou o que dá o output de detecção quando constata modificação na memória. É preciso entender melhor o que exatamente tem acontecido no seu caso em específico.

 

Vou fazer isso pra ver o que consigo. obrigado!

 

Uma aplicação PE(Portable-Executable) é dividida por seções, [.idata, .rsrc, .data, .text, .src] cada seção tem sua finalidade, armazenar variáveis, constantes,etc..., e a que lhe interessa nesse caso, o código compilado.

O código compilado de um .EXE fica dentro da seção .text, esse código não recebe modificações originarias, ou seja, um código FIXO, com bytes FIXOS.

Muitos anti-hacks usam a famosa verificação CRC para checar a integridade da seção .text, e isso tudo está dentro da lógica, já que o código compilado não vai se alterar, a não ser que alguma aplicação ou algum módulo interno faça essa alteração, resumindo, algum hack.

 

Então o padrão é, o executável abre, gera um cálculo único e retorna um valor e salva em uma variável. Exemplo: 0xFFFFFFFF

 

Após isso o mesmo só vai ficar executando uma tarefa padrão para checar a integridade do .text. Ele vai ficar pegando o CRC em tempo de execução e comparando com o valor que está salvo dentro da variável, caso esteja diferente é porquê alguém alterou alguma parte daquela seção, dando a entender que comprometeu o código original.

 

Quer fazer um teste legal para comprovar isso? Se sim, vamos la.

 

Levando em conta que o .text do cabal é bem extenso, podemos deduzir que vai levar um certo tempo para a função calcular o CRC e salvar em uma variável, certo? Então nesse meio tempo você pode alterar a memória, que ele vai salvar o valor já com a alteração, logo você vai ter um código original alterado e a função que checa a integridade não vai conseguir identificar.

 

No seu caso, coloque para alterar o código da função da verificação de coordenada logo quando sua DLL der Attach no processo e o resultado será positivo.

 

Existe inúmeras maneiras de se burlar essa verificação, essa que te expliquei é a pior delas, já que no CABAL se altera o código do .text para ativar diversas funções.

 

Boa sorte.

 

Entendi, já deu uma clareada nas ideias aqui, eu tentei fazer o que você disse mais sem a DLL, só pausando o cabalmain pelo processhacker logo no começo, e do attach do CE com o AOB modificado para ver se rola, mais não funcionou, vou tentar com a DLL, pra ter exito com esse método, que provavelmente com mais conhecimento eu troque por outro mais versátil.

 

Poderia me dizer como encontro essa variável, que ele utiliza para fazer o CRC e assim fazer comparação?

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.