Protimus

Administrador
  • Total de itens

    1.637
  • Registro em

  • Última visita

  • Days Won

    18

Reputação

97 Contribuidor

Sobre Protimus

  • Rank
    Administrador & Fundador
  • Data de Nascimento 20-02-1991

Informa??o do Perfil

  • Sexo:
    N?o informado

Últimos Visitantes

17.405 visualizações
  1. Olá, Venho conversar com vocês um pouco sobre a nossa central de traduções. Alguns devem se lembrar do antigo brACT que foi desenvolvimento pelo Wiskovisky, ela funcionava muito bem. Infelizmente ele já não se encontra entre nós *não conseguimos mais contato*, a central foi perdida e na época ficou desatualizada para determinadas funções do PHP e conexões com o IPB (as contas eram integradas). Por questões de necessidade, vejo que precisamos fazer um novo controle de traduções. Eu comecei a desenvolver por conta própria um CMS que servirá para gerenciar as traduções. O sistema funcionará da seguinte maneira: - O painel terá gráficos que mostram a porcentagem de traduções feitas mensalmente, anualmente e o percentual das que faltam ou já foram feitas. - As contas de usuário serão integradas ao fórum (IPB). - O sistema contará com os status das traduções e cada pessoa poderá selecionar um arquivo especifico de tradução que deseja. - Teremos a opção de envio de arquivos prontos em txt para o painel. - Haverá a sincronização com o repositório do GIT. Todas as traduções que tiverem em status de concluído, serão enviadas ao GIT todos os dias. Para a tradução ter o status de concluído é necessário que alguém da equipe de traduções do brAthena ou um desenvolvedor aprove sua tradução. As aprovações de traduções serão feitas diretamente pelo sistema, sem necessidade de comunicação ao membro. Os créditos deverão ser acrescentados dentro dos arquivos do script. Caso a tradução não seja aprovada, enviaremos uma MP com o motivo para o membro do fórum ou então através de email fornecido no sistema de traduções. O desenvolvimento da central está sendo feito em PHP e utilizarei algumas tecnologias como: Bootstrap, REST, AngularJS e Smarty. Ela é Open Source e pode ser acessada através de: https://github.com/Protimus/brACT Pretendo fazer o layout principal o mais rápido possível, estou colocando esse projeto como prioridade. Toda ajuda é bem vinda, caso queiram fazer algum pull request, sintam-se livres. * Lembrando que esse é um projeto essencial para a produção do novo emulador do brAthena. Só com esse projeto, podemos dar inicio efetivo ao novo emulador e as novas mudanças. Atenciosamente, Protimus.
  2. Há algum tempo é possível quebrar senhas md5 com ataques de força bruta. Eu já tinha conhecimento disto há alguns anos, mas felizmente poucas pessoas sabem disso e como funciona o ataque de força bruta em cima do md5. Sabemos que muitos banco de dados utilizam o md5 para encriptar as senhas de jogadores e manter seguro o sistema. Então proponho a mudança no algoritmo de encriptação, inicialmente penso em algo como SHA256 (AES), pois demoraria demasiado tempo em quebrar este tipo de encriptação. Gostaria de saber se vocês tem sugestões quanto ao tipo de algoritmo que podemos utilizar no lugar do md5.
  3. Apenas um aviso para downtime de ontem. Ontem foi dia de renovação da máquina, foi tudo pago 1 dia antes mas a empresa por falha de alguém/sistema desligou nossa máquina mesmo com todos os pagamentos realizados. Eu tive que esperar reabilitarem a máquina suspensa para poder fazer mount dos discos SSD/HD da máquina novamente, felizmente nada foi perdido com a recuperação. Quanto a algumas questões que vocês abordaram, eu prometo resolver entre essa semana e a próxima. Estou um pouco ocupado pessoalmente e por isso não pude resolver todas as pendências que ficaram da manutenção. A manutenção dos downloads começará hoje, ela será feita pelo Tidus e o sistema não necessitará ficar offline.
  4. Sabe qual é o problema? 5% dos usuários sabem administrar corretamente um servidor. Eu já cansei de ver as vezes que servidores foram hackeados e não faziam logs de tudo. 1. O cara pega a conta de GM e dropa os itens no chão pro poring comer e assim já era mais um servidor... 2. O administrador mesmo que use máquina virtual para lidar com arquivos de jogadores e não faça login no servidor pela máquina virtual, pode acabar um dia caindo na tentação de precisar usar o próprio sistema... Assim se vai um backdoor nele (90% usa windows) e já era o sistema operacional dele (até os nudes vazam se tiver), ou simplesmente ele pega um simples keylogger e sua senha é comprometida. Não existe segurança total para um servidor, por isso é importante fazer os logs de tudo. Se caso o servidor seja invadido, você pode simplesmente fechá-lo e rastrear todos os itens e comandos pelos logs, depois fazer uma limpeza deles e voltar com seu servido ao ar sem precisar dar wipe ou continuar com itens edits.
  5. Se EU fosse administrar um servidor, eu utilizaria esse sistema e colocaria para ele deletar logs de semana em semana. Antes dele deletar os logs, ele faria um backup deles e enviaria para nuvem (Dropbox, iCloud, Azure, Google Cloud, ou um próprio servidor NAS que seria o mais indicado). Mantendo um servidor de backup de 50GB é possível fazer backup dos logs e guardá-los como logs semanais e inclusive facilitar a pesquisa. Se algo aconteceu há 2 meses atrás e eu preciso consultar, basta eu saber a semana em que aconteceu e importar o backup daquela semana para um banco de dados em localhost e fazer um SELECT para pesquisar. Vai ser algo prático e ágil... Agradeço muito a todos que contribuíram com suas opiniões e indicações.
  6. Você precisaria criar uma definição nova para máscaras de classe. Assim você utiliza no battle.c para cálculos de dano por exemplo, as definições com checagem para determinada classe e pode colocar um cálculo de dano diferente caso a classe pertença a essa máscara. Não é necessário duplicar a skill e nem é indicado fazer isso.
  7. Eu verifiquei e encontrei alguns erros de SQL Injection no site, não posso mostrar aqui ou estarei ensinando como se faz SQL Injection e essa não é a minha intenção. O site funciona com index.html ao invés de index.php nas páginas principais e também utiliza um sistema chamado Surge para hospedar o painel de registro: http://www.surge.sh Infelizmente é verdade, não sei se isso é proposital ou não (lembrando que não podemos acusar). Mas para um sistema que promete defender o usuário, ter um site totalmente exposto dessa forma não é o ideal. Eu tentei deixar esse tópico/projeto vivo, até que o dono viesse dar sua resposta mas como não há resposta do desenvolvedor do software, não me resta outra alternativa ao não ser trancar este tópico e pedir que não utilizem o shield por questão de segurança própria (até mesmo para não serem utilizados em uma botnet ou terem suas senhas roubadas por keylogger). ISSO é claro, se existir malícia por parte do desenvolvedor ou real conhecimento para fazer isso. Portanto o tópico está fechado e os links removidos para evitar problemas. Caso o autor queira provar sua inocência, ele terá o direito desde que apresente para mim o código fonte. Não irei ficar vasculhando o executável com debuggers para achar informações, pois meu tempo é curto para me preocupar com isso.
  8. Eu estava pensando em fazer assim mesmo e aí fazer uma expressão algorítmica que trabalha apenas com o sufixo da tabela, exemplo: picklog_03_25_17 picklog_02_24_17 Aí a o algoritmo trabalharia fazendo verificação apenas dos sufixos. Uma coisa interessante é deixar separado em um banco de dados diferente, pois muitas pessoas usam junto com o banco de dados original. Como será gerada uma tabela por dia, é melhor manter em um banco separado. Quem sabe seja interessante revisar todo esse sistema de logs... Talvez fosse viável trabalhar com NoSQL na questão de logs.
  9. Sim, é possível mas não é indicado. Porque se o log teve um consumo maior do que o esperado, ele pode deletar o log do dia/mês inteiro.
  10. Eu sempre percebi um grande problema em servidores de médio-grande porte, que são os problemas com armazenamento de logs. Geralmente os logs ficam armazenados em um banco de dados, visto que todos os servidores agora utilizam SQL. O maior problema nisso é que alguns backups chegam à 3~5GB por causa de picklog e algumas tabelas que armazenam rudimentarmente os logs. Então eu pensei em desenvolver uma ferramenta que faça a limpeza através de uma battleflag configurável por arquivo de configuração. A cada 24h que o map-server estiver ligado, ele realiza uma leitura de checagem com o SQL e elimina logs antigos, conforme o período de data configurado pelo administrador. Há também a possibilidade de colocar uma checagem sempre que o map-server é ligado. A checagem da data será através de consultar com o próprio SQL. O que acham da ideia?
  11. Posso criar uma regra de moderação, onde os tópicos resolvidos continuam na área de suporte para possíveis respostas dentro de um período de 7 dias, com a tag (Resolvido), para só depois ser enviado para o fórum de resolvidos e fechado.
  12. Seria interessante começarmos o desenvolvimento dessas habilidades, mesmo sem alguns dados nós podemos fazer esboços de código e deixá-los prontos para apenas aplicar.
  13. Sugestão aceita. Aplicado um novo plugin para melhor resposta aos tópicos de suporte. Quanto a questão de fechamento de tópicos, encaro como desnecessária no momento e por isso não aplicaremos.
  14. Os bugs que você citou são correções que devem ser feitas no próprio código, exceto a questão do bloqueio de palavra classe. Pois dentro do seu manner.txt na pasta data deve estar com a palavra "ass" em inglês e assim bloqueia quando vai exibir a palavra classe. O restante vou deixar para que o Kyomai resolva, pois o código é dele. Sobre a questão de mudança de classe dentro da guilda, o único jeito que imagino de fazer com que isso seja resolvido é fazendo uma checagem constante (o que não é indicado, pois é de grande consumo) ou usando máscara de jobs, onde só poderão haver 2 classes de cada máscara raiz. Não é para usar uma máscara de classe específica, mas utilizar uma máscara global para classes pai, onde as classes filhas serão restritas logo que a classe pai não permite o uso de mais de 2 classes do mesmo gênero. OBS.: Não confundir com classes de orientação à objetos, estou falando de classes do jogo. Porém a ideia é bem semelhante a questão de herança. --- Um outro jeito bem simples de fazer o que você quer, é não fazendo restrições de invite ou expel das guildas, mas apenas IMPOSSIBILITANDO a entrada de membros de determinada guilda aos castelos, caso a guilda não atenda as condições de ter apenas 2 personagens de classes iguais. Isso você pode fazer com um simples comando de script que você poderá criar no script.c e uma simples consulta SQL para deixar que ela fique ativa apenas enquanto a WoE estiver acontecendo.
  15. Você não entendeu, um exemplo no seu script. getitem 7444,1; Trocar para: getitem 7444, rand(1,10);