~EvilCode

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.

p.PClassP := $00C221D8;

p.PWall := $01049860;

De nada.

O Trainer não será atualizado, pode fechar.

Da pra trabalhar com pacotes sem a necessidade de reescrever a função de encrypt packet do game.

Acabei de testar aqui e o xign ta detectando =/

Ele não está detectando a DLL, e sim seu injetor. Troca seu injetor.

no post principal, porém também não está funcionando. A atualização do cheat foi dia 02/05 e a atualização do Cabal foi dia 24/05 eu acho.

O Trainer continua funcional.

Todas as 3 versões estão desatualizadas.

Todos os trainers foram atualizados hoje (02/05/2018) para o EP19.

Basta ir no tópico principal e fazer o download da nova versão.

Bom uso.

GMHack 0x0107D588 = Seta valor 2 para ativar.

AOEHack 0x010CDC44

Passa as address Plzz

Tem um tópico com a source postada com as addrs antigas, está fácil atualizar ela.

poucos dias de farm me trouserao alegria e BAN hj de manha!!!

A vida cobra.

SALVE!!!!

Fiz uma M4 de R$220,00 virar uma Karambit Marble Fade de R$1800,00

Tio Gaben não é tão generoso. upgradecsgo tomou um prejuízo comigo.

Semana passada decidi comprar R$300,00 reais em skins. Uma AK, USP e uma AWP Assimov. Dei upgrade na assimov, o resto vocês acompanham na imagem.

Cagada? que nada.

Quando se trabalha com endereços fixos se usa:

PDWORD($ADDR)^:=Value;

Você pode variar o tipo alterando para PSINGLE, PBYTE, etc...

Para se trabalhar com Ponteiros deve apontar o endereço da struct e o deslocamento.

PDWORD(PDWORD($AddrPClass)^+$Offset)^:=Value;

Entenda que ele vai fazer ponteiro para o AddrPClass e ler oque está dentro dele, o valor encontrado la dentro + offset vai apontar para um elemento único dentro daquela struct, que normalmente é onde fica guardado os valores por exemplo dos status do personagem.

O Primeiro PDWORD que citei no exemplo é para o ponteiro, logo ele vai ler como um DWORD o elemento encontrado na struct, porém se você quizer ler um elemento do tipo float por exemplo, bastaria você trocar por PSINGLE, e assim vai variando os tipos.

Você pode adicionar mais offsets adicionando + PDWORD e fazendo a soma.

É bom ressaltar que as offsets são sempre do tipo PDWORD, nunca se altera.

No endereço de memória da sua DLL "0D71E0BD" uma linha de código está tentando "ler" o endereço de memória "0006C48A" que é inválido. Como se trata de um DLL creio que o endereço que não pode ser lido é do .text do processo que você injetou a DLL, normalmente esses erros ocorrem pois aquela seção da memória necessita de privilégios, read, write ou execute, ou as 3 juntas. Para contornar isso basta você chamar a função VirtualProtect apontando para o endereço e passando os privilégios.

Outra hipótese é que o endereço de memória não existe .-.

Porque não usar uma linguagem mais facil de dar manutenção? Python por exemplo, ou até mesmo NodeJS. Os Cheats e dlls não precisam ficar atrelados ao Loader/Projeto, apenas ser injetado quando instalado. Não adianta nada colocar me C++ e cada um programar de uma forma, com uma identação e tudo mais. Um Python te obriga a programar bonito, simples e identado. Javascript também poderia ser uma zona, mas eu posso ajudar vocês ai. O que acho válido antes de mais nada, é um repositório privado num bitbucket da vida para sempre ter a source e os membros envolvidos tendo acesso nela.

 

É uma ideia que tenho chamado alguns cheats pra fazer, uma plataforma de cheats. É muito difícil isso porque tem muito nego de um cheat só, entende o que digo? Achou um source e se deu bem, mas se falar em compartilhar isso com a comunidade o bixinho sai correndo. Enfim, não cheguei a conhecer e esse Loader, mas acredito que seria uma central de cheats. Isso é bem interessante, eu posso ajudar, seja qual linguagem for. Abs

Minha ideia é fazer com que as funções da DLL Hack só funcione com dados transmitidos após autenticação entre Server->Cliente, não vejo efetividade em você fazer um loader que só vai baixar uma DLL e injetar ela, fica fácil pra qualquer um descobrir onde ela foi extraída e ai já sabe, a DLL roda mundos sem a presença do loader.

Quanto a manutenção, a ideia é fazer arquivos separados (.dat) por exemplo, onde ele vai ter a lista de hacks com todas as infos deles, não sendo necessário a modificação da source do próprio servidor para adição, remoção, ou alteração de algum hack no loader.

Sobre identação não tem muito oque falar, ou você é organizado, ou não é. Porém em um trabalho onde envolve muitas pessoas é difícil todo mundo identar da mesma maneira, ou pensar da mesma forma de fazer certo código, mas da pra organizar tudo isso.

Como eu disse, me responsabilizo em executar o projeto e de criar uma lib para facilitar a integração nos hacks.

Bom, levando em consideração suas palavras vou apresentar algo que tenho em mente.

Antes de mais nada, não vejo problema em compartilhar o repositório da source, contanto que a mesma esteja apenas na mão de pessoas confiáveis.

- Estrutura do Loader

Eu tenho e mente fazer toda a estrutura do loader via WinSock, onde teríamos serviços separados(LoginServer, ShopServer, DownloadServer). Cada um deles ficaria responsável em responder para o cliente determinada tarefa.

LoginServer : Responder toda requisição de login no loader, autenticando ou recusando e enviando as informações da conta(fórum) para o cliente.

ShopServer : A primeira ideia que tenho do ShopServer é que ele ficaria responsável por enviar toda lista de cheats, com imagens, descrição, status, e um preço em (WCOINS?) por exemplo para o player usar por x dias. Assim que o player efetuasse tal compra o mesmo ficaria disponível para download, e aí que entra a parte do DownloadServer.

DownloadServer : O nome resume tudo, vai responder por toda requisição de download dos cheats, atualizações, e atualização do próprio loader.

Todo método que citei está bem resumido, levando em consideração que quando se trata de winsock deve se trabalhar com muitos recursos, porém tenho plena capacidade de executar o projeto todo.

A questão que deveria ser discutida é a questão de controle dos cheats pagos ( WCOINS?), minha ideia de segurança é fazer com que a DLL só consiga trabalhar mediante a envio de informações pelo servidor, e para isso teríamos que trabalhar com a source do cheat também, então pensei em deixar pago( WCOINS?) somente cheats de programadores do fórum, ou de membros que disponibilizem a source para implementação do módulo no mesmo, e os cheats free ficaria livre para uso a qualquer momento, sem interferência de controle do ShopServer.

A parte do lado do cliente seria legal se tivesse algum designer do fórum com capacidade de desenhar os forms mediante os requisitos que eu for apresentando, daria uma cara muito boa para o loader.

Bom, minha ideia inicial é essa, creio que na parte de estrutura para comunicação não tenha muito a acrescentar. Acho que trabalhando junto com os administradores do fórum a gente conseguiria chegar em um resultado muito bom.

Abraço.

Olá.

Antes de tudo, se possível gostaria de saber oque levou o projeto do Loader ir por água abaixo.

A média de usuários que vocês tinham na época que estava ativo era satisfatória?

Os lucros com adsense compensava o trabalho de quem estava por trás programando e trabalhando na manutenção do Loader?

É válida a ideia do fórum ainda possuir um sistema desse? Tenho em mente algumas ideias, caso isso seja algo discutível ainda na WC posso falar um pouco mais.

c++ jovem, or = ||.

e no lugar desse if para comparar string use lstrcmp.

FAZ UM VIDEO MOSTRANDO COMO USAR PQ AQUI INJETOR MAIS NÃO APARECEU NADA

Após injetar, loga no char q o hack vai aparecer.

Não consigo achar nenhum funcional, o senhor havia postado um anteriormente tentei baixar mas foi retirado.

Leia oq eu disse acima, e vai entender q tem uma dll funcional dentro da pasta da source q eu postei.

entendi nada, sou leigo de mais kkkkk

Tem uma DLL dentro da pasta, é só pegar um injetor funcional e injetar ela, quando você logar no char o hack vai abrir.

Isso é uma Source Hack(código fonte) para compilar uma DLL para usar no Cabal, a source está atualizando para o Episódio Atual. Na pasta da source contém uma DLL já compilada para quem quiser usar.

[HIDE-THANKS]https://www.sendspace.com/file/wvmpjw[/HIDE-THANKS]