CHAVE DE LIBERACAO DE SOFTWARE
olá Amigos.
como que voces fazem para vender seus programas e não ter que ir ate o usuario
para instalar e colocar a chave de liberação
gostaria de criar um formula para os usuários que usarem meu software
efetuar o registro do mesmo.
eu sei que existe o nslock15 que por sinal funciona blz
só que no meu caso a chave de registro deverar ser criada de acordo com
o numero de terminais que usarão o programa
tenho tres textBox:
txtEmpresa, txtCpf, txtquandeterminais
quero gerar a chave com base no conteudo destes tres textBox
obs: a quantidade de terminais pode chegar ate quinze terminais.
como que voces fazem para vender seus programas e não ter que ir ate o usuario
para instalar e colocar a chave de liberação
gostaria de criar um formula para os usuários que usarem meu software
efetuar o registro do mesmo.
eu sei que existe o nslock15 que por sinal funciona blz
só que no meu caso a chave de registro deverar ser criada de acordo com
o numero de terminais que usarão o programa
tenho tres textBox:
txtEmpresa, txtCpf, txtquandeterminais
quero gerar a chave com base no conteudo destes tres textBox
obs: a quantidade de terminais pode chegar ate quinze terminais.
Amigo, utilizo um sistemna bem prático e seguro baseado em criptografia do Serial do HD. Bem, se o HD não for clonado, funciona blz. Seria interessante você ler estas dicas abaixo. Em anexo segue uns arquivos de exemplo.
Lembre-se: Não existe sistema 100% seguro. No entanto existem algumas regrinhas básicas para quem quer fazer um sistema 99% seguro.
1. Nunca nomeie arquivos ou procedimentos com nomes que façam sentido, do tipo IsValidSerialNum ou CodRegOK.Se você usar funções para checagens, pelo menos coloque um trecho de código vital para o programa dentro de funções deste tipo. Se o cracker desabilitar a função, o programa gerará resultados incorretos;
2. Não avise o usuário assim que ocorrer uma violação. Faça com que o programa espere, talvez um dia ou dois (crackers odeiam estas surpresas);
3. Use checksums em DLLs e EXEs. Faça com que se chequem entre si. Não é perfeito mas dificulta muito o crack;
4. Introduza uma pausa de 1 a 2 segundos após a entrada de uma senha para que um cracking usando força bruta seja impraticável. Simples de ser feito, raramente usado;
5. Use a correção automática no seu software. Você sabe, como a correção de erros que os modems e os HDs usam. A tecnologia já existe há anos e ninguém a usa nos próprios softwares ? O melhor dessa história é que se o cracker usou um decompilador, ele pode estar olhando para uma listagem que perdeu a validade;
6. Faça um patch no seu próprio software. Mude seu código para que cada vez chame rotinas de validação diferentes. Vença-nos no nosso próprio jogo;
7. Guarde números seriais em locais improváveis, por exemplo como uma propriedade de um campo de uma base de dados;
8. Guarde números seriais em vários locais diferentes;
9. Não dependa da data do sistema. Obtenha a data de diversos arquivos, como SYSTEM.DAT, SYSTEM.DA0 e BOOTLOG.TXT e compare-as com a data do sistema. Exija que a data seja maior que a da última execução;
10. Não utilize strings literais que informem o usuário que tempo de uso expirou. Estas são as primeiras coisas procuradas. Gere strings dinâmicas ou use encriptação;
11. Inunde o cracker com falsas chamadas e strings "hard coded". Armadilhas são divertidas;
12. Não use uma função de validação. Cada vez que for necessário validar, escreva o código de validação dentro do processo atual. Isto apenas vai dar mais trabalho ao cracker;
13. Se usar chaves ou senhas "hard coded", faça com que tenham a aparência de código de programa ou de chamada de função (por exemplo, "73AF" ou "GetWindowText"). Isto funciona muito bem e causa confusão em alguns decompiladores;
14. Nunca utilize o registro do sistema "REGEDIT" para contabilizar o uso do software;
15. Utilize um bom compressor de executável (Minha sugestão é o ASPACK);
14. E, finalmente, nunca revele seus melhores segredos de proteção :-)
Fonte editada: http://www.numaboa.com.br/informatica/oiciliS/protect.php
Lembre-se: Não existe sistema 100% seguro. No entanto existem algumas regrinhas básicas para quem quer fazer um sistema 99% seguro.
1. Nunca nomeie arquivos ou procedimentos com nomes que façam sentido, do tipo IsValidSerialNum ou CodRegOK.Se você usar funções para checagens, pelo menos coloque um trecho de código vital para o programa dentro de funções deste tipo. Se o cracker desabilitar a função, o programa gerará resultados incorretos;
2. Não avise o usuário assim que ocorrer uma violação. Faça com que o programa espere, talvez um dia ou dois (crackers odeiam estas surpresas);
3. Use checksums em DLLs e EXEs. Faça com que se chequem entre si. Não é perfeito mas dificulta muito o crack;
4. Introduza uma pausa de 1 a 2 segundos após a entrada de uma senha para que um cracking usando força bruta seja impraticável. Simples de ser feito, raramente usado;
5. Use a correção automática no seu software. Você sabe, como a correção de erros que os modems e os HDs usam. A tecnologia já existe há anos e ninguém a usa nos próprios softwares ? O melhor dessa história é que se o cracker usou um decompilador, ele pode estar olhando para uma listagem que perdeu a validade;
6. Faça um patch no seu próprio software. Mude seu código para que cada vez chame rotinas de validação diferentes. Vença-nos no nosso próprio jogo;
7. Guarde números seriais em locais improváveis, por exemplo como uma propriedade de um campo de uma base de dados;
8. Guarde números seriais em vários locais diferentes;
9. Não dependa da data do sistema. Obtenha a data de diversos arquivos, como SYSTEM.DAT, SYSTEM.DA0 e BOOTLOG.TXT e compare-as com a data do sistema. Exija que a data seja maior que a da última execução;
10. Não utilize strings literais que informem o usuário que tempo de uso expirou. Estas são as primeiras coisas procuradas. Gere strings dinâmicas ou use encriptação;
11. Inunde o cracker com falsas chamadas e strings "hard coded". Armadilhas são divertidas;
12. Não use uma função de validação. Cada vez que for necessário validar, escreva o código de validação dentro do processo atual. Isto apenas vai dar mais trabalho ao cracker;
13. Se usar chaves ou senhas "hard coded", faça com que tenham a aparência de código de programa ou de chamada de função (por exemplo, "73AF" ou "GetWindowText"). Isto funciona muito bem e causa confusão em alguns decompiladores;
14. Nunca utilize o registro do sistema "REGEDIT" para contabilizar o uso do software;
15. Utilize um bom compressor de executável (Minha sugestão é o ASPACK);
14. E, finalmente, nunca revele seus melhores segredos de proteção :-)
Fonte editada: http://www.numaboa.com.br/informatica/oiciliS/protect.php
BOM DIA LIKA
Eu faço assim: uso um codigo de criptografia que usa chave. Então vc pode pegar a txtquandeterminais & txtcpf para usar como chave. Ainda precisa pegar o serial do Hd(como é em rede,ver outra coisa).Se for o Hd, é preciso retornar para vc o serial, então vc cria um arquivo txt com qualquer extensão(.lik por exemplo)e envia para a máquina do cliente. Neste arquivo vai ter o serial do Hd(ou outro parâmetro) criptografado. então ao iniciar o programa verifica se o serial do servidor é o mesmo do arquivo .lik que vc enviou. Se for abre o sistema.
Para isso cv tem que usar o FileSystemObjet e classe que cryptografia. Veja como usar esses arquivos aqui, no vbmania.
Eu faço assim: uso um codigo de criptografia que usa chave. Então vc pode pegar a txtquandeterminais & txtcpf para usar como chave. Ainda precisa pegar o serial do Hd(como é em rede,ver outra coisa).Se for o Hd, é preciso retornar para vc o serial, então vc cria um arquivo txt com qualquer extensão(.lik por exemplo)e envia para a máquina do cliente. Neste arquivo vai ter o serial do Hd(ou outro parâmetro) criptografado. então ao iniciar o programa verifica se o serial do servidor é o mesmo do arquivo .lik que vc enviou. Se for abre o sistema.
Para isso cv tem que usar o FileSystemObjet e classe que cryptografia. Veja como usar esses arquivos aqui, no vbmania.
Tópico encerrado , respostas não são mais permitidas