meuovo321 3 Postado 3 de Julho 2018 Denunciar Compartilhar Postado 3 de Julho 2018 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. :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: 1 Denunciar ᅠᅠTroféus e Medalhasᅠᅠ Link para o comentário Compartilhar em outros sites Mais opções de compartilhamento...
9 938 Postado 5 de Julho 2018 Denunciar Compartilhar Postado 5 de Julho 2018 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. 1 Denunciar серафими многоꙮчитїи ᅠᅠTroféus e Medalhasᅠᅠ Link para o comentário Compartilhar em outros sites Mais opções de compartilhamento...
~EvilCode 71 Postado 5 de Julho 2018 Denunciar Compartilhar Postado 5 de Julho 2018 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. 1 Denunciar ᅠᅠTroféus e Medalhasᅠᅠ Link para o comentário Compartilhar em outros sites Mais opções de compartilhamento...
meuovo321 3 Postado 6 de Julho 2018 Denunciar Autor Compartilhar Postado 6 de Julho 2018 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? ᅠᅠTroféus e Medalhasᅠᅠ Link para o comentário Compartilhar em outros sites Mais opções de compartilhamento...
Posts Recomendados