source Calculo de Keys enviados no P_10A(CharList)

[DwarfDev 927]

Bem, um tempo atrás eu descobri que o WYD faz um calculo com as keys que são enviadas no packet 0x10A(CharList) pela TM. Sem esse calculo o servidor te dá DC, uma vez que a Key que o servidor espera deve ser exatamente a mesma gerada pelo calculo. Eu imagino que você tenha percebido que só consegue usar o WPE depois de um tempinho online no jogo né? Kaka

Uma dica para impedir completamente o uso do WPE, seria mudando o contador da Key(no codigo é o hashKeyCount) atual no Client, alterando algum pacote interno via hook. Mas lembre-se que o netcode do WYD é bem ruim, logo se o client  servidor comer algum pacote(Com isso quero dizer, se o servidor deixar de ler algum pacote por alguma falha no codigo, já que em algumas sources por ai, foi refeito o recv e não está processando direit), o client irá tomar DC, e é exatamente isso que causa alguns DC's randons quando você acaba de logar. Isso acontece porque o servidor deixou de receber processar algum pacote e entendeu o contador hashKeyCount errado.

Percebi que alguns WYD's 7.60 + estão sem esse calculo, logo eu fiz em C#, ai é com vocês passarem pra outra linguagem se quiserem, mas de qualquer forma é bem simples. Pelo que vi, você pode gerar uma Array de Bytes de tamanho 16 com Keys aleatórias e realizar o calculo no servidor para ver se a KEY enviada pelo cliente está correta. Para cada sessão(client) você deve gerar uma sequencia de Keys. 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

Editado 21 de Outubro 2019 por Dcan

[Shepher 496]

Legal, alguém começando a entender um pouco mais do protocolo. 

Sobre seu edit posterior, o WYD é feito sobre protocolo TCP/IP, isso não é do "WYD". É diferente de um protocolo UDP, por exemplo.

O cliente não vai comer pacote algum. Se algum pacote não chegar, é por falha de conexão, apenas, porque o protocolo TCP/IP garante certas coisas de acordo com sua especificação. Além disso, após o 16° pacote, a Key não muda, então não é um motivo de queda (não após mover um pouco dentro do jogo). 

O uso de WPE foi corrigido implementando timestamp. Onde pacotes deveriam respeitar o tempo do servidor. Pacotes enviados com WPE são sempre com o mesmo timestamp.

Editado 7 de Outubro 2019 por Shepher

[DwarfDev 927]

31 minutos atrás, Shepher disse:

Legal, alguém começando a entender um pouco mais do protocolo. 

Sobre seu edit posterior, o WYD é feito sobre protocolo TCP/IP, isso não é do "WYD". É diferente de um protocolo UDP, por exemplo.

O cliente não vai comer pacote algum. Se algum pacote não chegar, é por falha de conexão, apenas, porque o protocolo TCP/IP garante certas coisas de acordo com sua especificação. Além disso, após o 16° pacote, a Key não muda, então não é um motivo de queda (não após mover um pouco dentro do jogo). 

Sabe, eu sempre tive uma duvida. Eu não entendo muito de rede(comecei a estudar há pouco tempo), mas eu percebi que quando estou lendo os pacotes, acontece caso em que chega vários pacotes no mesmo buffer, ou pelo menos é isso que o servidor me mostra. E quando isso acontece, em uma source que vi onde foi refeito o recv, ele lê o primeiro pacote e ignora o resto. 

 

Sobre a 16° key não mudar, estou ciente. Mas o DC que acontece quando você acaba de logar, é exatamente por não ter chegado na 16° key, e o client incrementou o contador sem que o servidor tenha recebido o pacote(falha de rede?). Por isso, disse que além do timestamp existe outra maneira, apesar de não ser tão eficiente quanto e ser mais perigosa de se colocar. Seria enviando um pacote pro client, solicitando que ele mude o keyCount para X valor(menor que 16). São só ideias :v

Editado 7 de Outubro 2019 por DwarfDev

[Shepher 496]

12 minutos atrás, DwarfDev disse:

Sabe, eu sempre tive uma duvida. Eu não entendo muito de rede(comecei a estudar há pouco tempo), mas eu percebi que quando estou lendo os pacotes, acontece caso em que chega vários pacotes no mesmo buffer, ou pelo menos é isso que o servidor me mostra. E quando isso acontece, em uma source que vi onde foi refeito o recv, ele lê o primeiro pacote e ignora o resto. 

É o modo como o WYD implementou o sistema de pacotes. Ele acumula todos os pacotes e em 500ms envia. Nesse intervalo pro próximo envio, ele vai acumulando todos os pacotes e os envia todos em ordem.

Isso não foi inventado pela equipe do WYD. O nome disso é Algoritmo de Nagle (Nagle-Algorithm).

Deve ser implementado o método contrário. Lê pacote por pacote dentro do mesmo buffer.

[DwarfDev 927]

3 minutos atrás, Shepher disse:

É o modo como o WYD implementou o sistema de pacotes. Ele acumula todos os pacotes e em 500ms envia. Nesse intervalo pro próximo envio, ele vai acumulando todos os pacotes e os envia todos em ordem.

Isso não foi inventado pela equipe do WYD. O nome disso é Algoritmo de Nagle (Nagle-Algorithm).

Deve ser implementado o método contrário. Lê pacote por pacote dentro do mesmo buffer.

Hm... não tinha ouvido falar desse Algoritmo, apesar de já ter usado várias vezes, hehe.

No meu caso que uso a base do open-wyd (em c#), eu salvo todos os pacotes em uma lista do tipo List<byte> e vou lendo/removendo de acordo com a size informada no header, e caso esteja faltando um "pedaço" do pacote(o que acontece as vezes) eu espero o client mandar o resto, pois na leitura feita pelo sistema do @Rechdan DOD estava simplesmente ignorando uma porrada de pacote. 

 

 

Editado 7 de Outubro 2019 por DwarfDev

[Shepher 496]

18 minutos atrás, DwarfDev disse:

Hm... não tinha ouvido falar desse Algoritmo, apesar de já ter usado várias vezes, hehe.

No meu caso que uso a base do open-wyd (em c#), eu salvo todos os pacotes em uma lista do tipo List<byte> e vou lendo/removendo de acordo com a size informada no header, e caso esteja faltando um "pedaço" do pacote(o que acontece as vezes) eu espero o client mandar o resto, pois na leitura feita pelo sistema do @Rechdan DOD estava simplesmente ignorando uma porrada de pacote. 

 

 

É o jeito de se fazer. O recv tem que ser byte a byte. Ler 4 bytes, pegar o valor deles, ler o tamanho lido anteriormente e assim sucessivamente. 

Detalhe: a implementação do IList<T> no C# é como um std::vector no C++.
Sempre que um item é adicionado, e este item supera o size que já havia previamente alocado, ele aloca um novo espaço com o dobro do tamanho, depois move todos os elementos para a nova área. Isso pode ocorrer perda de performance, não sei se tão notória para o mundo do WYD, mas pode ser melhor feito. 

[thebad.cb 40]

fiz um pouco diferente 
só no resultado que eu dou um ''XOR''

Editado 10 de Outubro 2019 por thebad.cb

[seitbnao 357]

Me perguntaram no pv se isso teria na .c da TM 7556, a função original abaixo.

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

[thebad.cb 40]

uma vez deu uma treta com o xbenny e o skinf4xi no tempo da cb que o skin postou o bot dele pra derrubar o wyd da ongame
ai o benny postou a src, isso em 2015- se não me engano
o raphaelxd tbm soltou na src do bot dele 

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

em delphi eu fiz assim
 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Editado 14 de Outubro 2019 por thebad.cb

[DwarfDev 927]

8 horas atrás, thebad.cb disse:

uma vez deu uma treta com o xbenny e o skinf4xi no tempo da cb que o skin postou o bot dele pra derrubar o wyd da ongame
ai o benny postou a src, isso em 2015- se não me engano
o raphaelxd tbm soltou na src do bot dele 

 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

em delphi eu fiz assim
 

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Esses viciados em Delphi. Parece até o Fabio kk