Não há nenhuma novidade em dizer que o Eclipse Origins é falho. 
Por enquanto, só vou mostrar como algumas coisas funcionam.

Nada é criado dinamicamente, os slots para os jogadores (e conexões) são definidos assim que o servidor é iniciado. Quando uma conexão é aceita, esse slot fica ocupado como se o jogador já estivesse no jogo, e também, o tempo das conexões que não estão recebendo dados não são verificadas no servidor. Por causa disso, qualquer um pode deixar um servidor cheio usando um laço e criando novas conexões, impedindo outros usuários de fazerem uma nova ligação com o servidor.

Qualquer um com o mínimo de conhecimento em uma linguagem de programação e TCP pode criar uma conexão com qualquer servidor.

Além do código ser aberto, o servidor também é podendo receber pacotes de qualquer origem, você pode facilmente derrubar o servidor enviando valores diferentes do esperado onde não existe verificação no servidor.

Exemplo 1:
Um erro fácil de ser identificado está no PlayerSwitchSpellsSlots: 


Runtime Error: 9
Subcript out of range 


Este é o método que faz a troca de slots de magias.


A quantidade máxima de slots de magia no personagem é de 35.
Os arrays em VB6 podem ser declarados com índices definidos. Portanto, os slots de magia do personagem, seguem o valor entre 1 e 35.

Qualquer valor diferente de entre 1 e 35 irá gerar um erro.
Runtime Error: 9
Subcript out of range 




Quando um pacote com valores irregulares é recebido ocorrerá erros e fará com que o servidor caia.
A correção do problema é simples, é necessário apenas verificar se os números dos slots estão dentro da faixa, 1 entre 35.




Exemplo 2:
O problema de salvar os dados a todo momento.
Vou apresentar um possível problema com o banco. 




Quando o pacote para fechar o banco é recebido do cliente, o personagem e o banco são salvos. Alguns servidores salvam os dados dos personagens em arquivos binários, outros em arquivos de configuração (.INI).

O maior problema deste método, não é salvar os dados do personagem, mas a não verificação dele.

Se alguém atacar floodando este pacote, o aumento do uso de CPU e acesso ao disco irão aumentar, e isso irá AGRAVAR se o servidor salva os dados em arquivos de configuração, pois há muitas operações com strings por debaixo dos panos. 

Como em um VPS o processamento é limitado, a máquina ficará lenta e o processamento do restante dos usuários ficará comprometido.

Uma maneira de evitar isso, é verificar se o personagem está dentro do jogo e verificar se o banco está aberto.



Exemplo 3:
ReadString tentando ler mais do que deveria.


Uma string quando adicionada ao buffer, é convertida para bytes. 
Na primeira posição é adicionado o tamanho da string em 4 bytes no array, em seguida, cada caractere é escrito.

Exemplo: abc

Posição 0: 3  (Tamanho)
Posição 1: 97 (Letra a)
Posição 2: 98 (Letra b)
Posição 3: 99 (Letra c)

Este é o método de escrita, na parte de leitura, primeiro, deve-se obter a quantidade de caracteres para obter os dados posteriormente.

O problema aqui é que, o tamanho da string pode ser alterado fazendo com que o servidor tente ler uma quantidade de dados que não existe gerando outro erro.

A solução é obter quantos caracteres devem ser lidos e verificar a quantidade disponível no pacote para leitura. Mas também, há outra solução e ambas são simples.

Adicionar no início do método: 
On Error Goto ou On Error Resume Next



Exemplo 5:
Buffer Overflow

Por segurança, depois que o objeto for usado, sempre limpem o buffer e destruam o objeto para não ficar nada preso na memória.



Processando o recebimento de dados corretamente:
1. Se o metodo do pacote requisitar um acesso elevado, verifique sempre no início para não criar e não processar dados que serão descartados. Do contário, verifique se o usuário está realmente dentro do jogo usando a função IsPlaying.

2. Crie o objeto para ler os dados recebidos, leia, limpe e destrua. 
3. Verifique os valores recebidos e faça o tratamento de erros.
4. Processe os dados que foram recebidos.



Dicas finais:
Se o servidor cair, é culpa sua por não verificar e revisar o código, e principalmente por não procurar informação o suficiente. O atacante está apenas prestando um serviço gratuito para que você possa melhorar a merda do seu servidor.
Todos os valores que chegam no servidor devem ser verificados antes de serem processados. 

Jamais use On Error Resume Next ou On Error Goto se você não sabe o que está fazendo seu burro, essas coisas farão com que a mensagem do erro desapareça, mas o erro irá continuar. 


Quanto mais On Error Resume Next ou On Error Goto no projeto, menor será a manutenção e implementação de novos sistemas. O servidor irá rodar silenciosamente e quando você souber de um bug e precisar fazer a correção não conseguirá pois NÃO HAVERÁ MENSAGENS DE ERRO ALERTANDO ONDE ESTÁ O PROBLEMA.

Não seja burro, estude antes de fazer algo.

Jesus do Eclipse Origins

Sobre o problema do banco, acredito que seria melhor salvar o personagem e o banco apenas quando o jogador se desconectar (e a cada certo período de tempo definido no servidor). Não é uma boa ficar fazendo operação de entrada e saída durante o jogo (ao fechar o banco).

Ótima contribuição, Drago.

+ 1 crédito

Eu curto esse tipo de análise e é um bom conteúdo pra quem ta desenvolvendo jogos online, não só nessa engine em questão.

4. Verifique os valores recebidos e faça o tratamento de erros.
3. Processe os dados que foram recebidos.

Só muda a ordem ai.

Paulo Soreto escreveu:Eu curto esse tipo de análise e é um bom conteúdo pra quem ta desenvolvendo jogos online, não só nessa engine em questão.

4. Verifique os valores recebidos e faça o tratamento de erros.
3. Processe os dados que foram recebidos.

Só muda a ordem ai.

Além dessas coisas, ainda tem mais, só separei algumas.

Muito bom Drag, esse tipo de coisa ajuda muito pra quem está começando a mexer e a entender essa desgraça de VB6 + EO.

Se achar mais falhas, posta aqui pra gente. Irá contribuir muito para o meu servidor.