Estou desenvolvendo um aplicação desktop que ja esta praticamente pronta, mas não faço a minima ideia de como fazer um metodo para que o programa expire e so volte a rodar quando uma nova chave for inserida, alguem tem uma ideia q possa resolver este problema?
cara, esse é um assunto que perturba a cabeça de muitos programadores ao redor do mundo e acho que nao existe uma solução perfeita, tanto é que nem as empresas top (microsoft, adobe, corel) conseguem evitar que os seus produtos sejam pirateados. Mas o que você pode fazer é tentar complicar um pouco o trabalho de quem for atrás de quebrar os teus algoritmos. Você pode, por exemplo, ter um arquivo de licença e neste arquivo todo o conteúdo seria criptografado. Você pode usar recursos de criptografia que já vem no Java e usar chaves gigantes, mesmo que o tempo de processamento seja um pouco maior. Isso nao será um problema porque será processado apenas na hora de iniciar a aplicação. Neste arquivo então você teria, entre outras informações, a data de expiração do software e você faria a comparação. O problema é que o usuário pode voltar a data toda vez que inicia o teu software, ai complicou tudo. Uma vez eu fiz o seguinte com um software em que trabalhava, a gente colocava o nome do cliente dentro da licença, todo criptografado, entao se ele fosse distribuir cópia pra outra pessoa, todos os relatorios saíam com o nome do primeiro cliente. Tem gente que nao se incomoda com isso, mas de qualquer forma pega mal pra ele entregar relatorios com o nome de outra empresa.
mas depois de todo esse tempo, o que aprendi hoje é que esse tipo de bloqueio só dá trabalho e você nunca consegue fazer algo perfeito, entao a solução é deixar o software solto e colocar as tuas regras de uso e distribuição dentro de uma licença e/ou contrato. O cara que não cumprir, estará agindo contra a lei e sujeito às penalidades. Cabe a cada empresário então decidir como trabalhar. Outra coisa também é que um software sem suporte nao significa muita coisa e vc só vai dar suporte pra quem lhe paga.
Tem também aquela opção de hard keys, que voce liga na paralela e usb e valida por uma chave que tem dentro. Tem empresa especializada em fabricar esses equipamentos e eles te fornecem também o código pra trabalhar com ele.
se for algo simples…
utilize a boa e velha criptografia com serial…
pode nao ser eficaz contra outros programadores experientes… mas contra os usuarios “simples” vai funcionar sim…
e se a aplicação nao for “grande” , creio q ninguem vai kerer perder tempo achando um meio de burlar o programa…
a ideia do bosnic eh uma boa solução… faça o aplicativo com o nome do cara que “comprou” a licença…
isso vai evitar q outras pessoas que necessitam do programa para um trabalho sério copiem…
Por esse lado vc estão certos, mas o q eu quero nao é restringir invasao o tentativas de quebra, e sim que apos um tempo de uso o programa pare e so volte a rodar quando o cliente entrar em contato, pq o sistema q desenvolvi fica em um notebook assim se acabar o contrato e ele quiser sumir com o programa ele nao tem como ou pelomenos fica mais dificil
se for o caso…
eu iria gravar um “log criptografado” secreto dentro dos arquivos…
q iria registrar a primeira vez q ele acessar o programa…
ai vamos supor vc ker q ele use por 30 dias…
esse log iria fazer uma comparação toda vez q ele acessar o programa…
comparando a data da primeira vez q rodou e ver se não se passaram 30 dias…
mas ainda teria o problema do cara mudar o Dia no PC…
soh q ele teria q ficar preso nesses 30 dias… entende?
pois se por um acaso ele voltasse pro ano 1990…
o programa poderia travar de vez… percebendo q ele voltou a uma data de antes do primeiro registro…
Gente, Sei que esse tópico é bem antigo, já me “meti” em outros tópicos mais ainda não achei uma solução plausível para o meu problema. O que eu quero é limitar o uso de meu software após 7 ou 15 dias a partir da data da 1ª utilização. Essa data deverá ser gravada em um arquivo, em algum lugar bem escondido no PC do cliente e de preferência com uma extensão que ele não possa editar (não diretamente, como os arquivos .properties ou .conf ou qualquer outra extensão diferente de .txt ou .log, e toda vez que o cliente abrir o programa, deverá verificar esse arquivo e calcular a data limite de uso, informando ao usuário que ainda faltam x dias, e após expirar esse prazo, aparece uma mensagem informando que o tempo de teste acabou e o sistema não abre. Mas não sei como fazer para gravar esse arquivo e depois lê-lo de comparar as datas. Preciso de uma ajuda com isso! Alguém pode me dar um HELP!!! Meu sistema já está pronto e só estou preceisando disso para começar da divulgá-lo, pois não posso entregar o ouro na bandeja, deixando o programa completo nas mãos do cliente antes de efetivar a compra do mesmo.
Cara… Primeiro, tu vais definir a data inicial a partir da data da instalação ou do primeiro uso. De qualquer maneira tu vais criar um arquivo guardando essas informações.
Depois, toda vez que o programa iniciar, a classe principal vai tratar esse arquivo, ler as informações, e fazer a comparação das datas…
Caso passe a validação, continua a carregar o programa…
Caso passe a validação e você calculou que faltam alguns dias pra terminar a licença e queira mandar alguma msg pro cliente, é só chamar algum método…
Caso não passe a validação, envia uma mensagem e encerra a execução…
Acho que não tem mistério. Se você desenvolveu um sistema completo, essa implementação de validação de tempo de uso simples seria a menor das dores de cabeça…
E de qualquer maneira, essa validação offline não tem muita segurança contra usuários avançados…
Acho que “bolei” um mei mais fácil “criar” uma versão trial para meu software. Simplemente desabilitei um monte de recursos e limitei a quantidade de registros que podem ser gravados. Assim, não corro o risco do usuário alterar a data do sistema ou do arquivo gerado (se for um usuário avançado), pois a lógica está toda dentro das minhas classe, para burlar esses “impecilhos” teria que possuir algum conhecimento em programação (Java) e fazer engenharia reversa para descompilar minhas classe gerando assim os fontes e alterando as restrições! É muito trabalho!!!
Valeu ul1sses e galera do GUJ!!!
Cara… se vai distribuir o programa… e quer ter essa trava, talvez seja melhor você compilar para código nativo.
De uma olhada nesse cara:
http://www.excelsior-usa.com/pr20030428.html
Já testei e funcionou bem… mas no meu caso achei desnecessário pois perdia mta flexibilidade em ganho irrisório de performance… mas no seu caso… fica mais dificil descompilar…
Para isso o cara teria de usar um debugger a lá OllyDbg e encontrar a “trava” em código de máquina.
Desta forma você poderia deixar as travas dentro do programa, nem precisaria de arquivo para isso.
Eu fiz um método que até hoje funciona e nao achei alguem que pudesse quebrar (na verdade, ainda nao desafiei alguem)…
Bom, se a geral aninar tentar desvendar… eis o arquivo…
Depois eu posto como que eu fiz 
abraços
Na verdade minhas travas são coisas bem simples. Eu consulto o banco de dados
select count (*) from tabeladepois eu verifico se a qde de registros atingiu um certo limite
if(con.rs.getInt("count") < X){
// Execute ...
}else{
// Não Execute
}E já testei o programa e funcionou.
Desabilitei recursos como backup, a exclusão de arquivos (para impedir que pudessem burlar as travas) e alguns tipos de relatórios.
Tive que copiar a pasta do meu projeto completo para a área de edição do NetBeans, renomear a pasta para “xxxTrial”, editar as alterações no código e compilar novamente. Então, tenho as 2 versões do programa, cada uma na sua pasta.
d34d_d3v1l
Com certeza seu arquivo deve ser dificil de quebrar… só vi que ta criptografado mas não sei com o que…
O detalhe é que se me passar seu programa Java, mesmo usando ofuscador de código, descompilando ele conseguirei informações que me ajudarão a abrir o arquivo e até modificar o mesmo… a não ser que distribua juntamente uma VM com mudanças na parte de criptografia, mas eu tbem terei esta VM…
Neste caso passar para código nativo ajuda, pois é muito mais dificil entender assembly do que java…
Embora também seja possível quebrar (vcs já viram por acaso alguma coisa que ninguem conseguiu crackear???) mas obvio que acaba caindo no caso que não compensa…
descompilar java não é tão dificil assim… ta cheio de iniciante que sabe fazer!
Abs
[quote=jmmenezes]d34d_d3v1l
Com certeza seu arquivo deve ser dificil de quebrar… só vi que ta criptografado mas não sei com o que…
O detalhe é que se me passar seu programa Java, mesmo usando ofuscador de código, descompilando ele conseguirei informações que me ajudarão a abrir o arquivo e até modificar o mesmo… a não ser que distribua juntamente uma VM com mudanças na parte de criptografia, mas eu tbem terei esta VM…
Neste caso passar para código nativo ajuda, pois é muito mais dificil entender assembly do que java…
Embora também seja possível quebrar (vcs já viram por acaso alguma coisa que ninguem conseguiu crackear???) mas obvio que acaba caindo no caso que não compensa…
descompilar java não é tão dificil assim… ta cheio de iniciante que sabe fazer!
Abs[/quote]
É verdade…
Eu mesmo (noob como sou) ja descompilei alguns projetos em Java para dar uma olhada no fonte…
Sobre o arquivo, com certeza ele é quebrável…
Bom, nao tem nada de mais no código fonte da aplicação a respeito do arquivo…
Até mesmo por que todo o controle é feito no proprio arquivo 
E não estou usando criptografia…
Agora fiquei curioso…
A sua aplicação não lê esse arquivo???
esse run.bin é um arquivo executável???
EDIT:
$ file run.bin
é um arquivo zip…
la dentro tem um arquivo run… agora vamos ver o que é!
Cara…
esse seu run é uma serialização da classe model.Run
Com seu programa java (copia do class) com certeza é possível deserializar e modificar.
Também é possível modificar com um editor hexa.
Isso confirma o que falei anteriormente… só realmente não é criptografado. (abrir ele num editor hexa e nem vi que era zip)
Cracked!
Data de expiração no arquivo: Mon Jun 25 00:00:00 BRT 2012
package model;
import java.io.Serializable;
import java.util.Date;
public class Run implements Serializable {
private static final long serialVersionUID = -7665070546480459488L;
int contador;
int max;
Date dataAnterior;
Date dataExpiracao;
public int getContador() {
return contador;
}
public void setContador(int contador) {
this.contador = contador;
}
public int getMax() {
return max;
}
public void setMax(int max) {
this.max = max;
}
public Date getDataAnterior() {
return dataAnterior;
}
public void setDataAnterior(Date dataAnterior) {
this.dataAnterior = dataAnterior;
}
public Date getDataExpiracao() {
return dataExpiracao;
}
public void setDataExpiracao(Date dataExpiracao) {
this.dataExpiracao = dataExpiracao;
}
}Depois é só deserializar.
package main;
import java.io.FileInputStream;
import java.io.ObjectInputStream;
import model.Run;
public class Serial {
public static void main(String[] args) {
try {
FileInputStream arquivoRunDezipado = new FileInputStream("c:/temp/run.txt");
ObjectInputStream objetoSerializacao =
new ObjectInputStream(arquivoRunDezipado);
Run objeto = (Run) objetoSerializacao.readObject();
System.out.println(objeto.getDataExpiracao());
objetoSerializacao.close();
arquivoRunDezipado.close();
} catch( Exception e ){
e.printStackTrace( );
}
}
}Abs
[quote=jmmenezes]esse run.bin é um arquivo executável???
EDIT:
$ file run.bin
é um arquivo zip…
la dentro tem um arquivo run… agora vamos ver o que é![/quote]
aeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeewwww =]
ta quasee…
aeewww… desculpa n tinha visto… foi RAPIDO D+
KKkkkkkkkkkkk
Para quem se interessar como se chega na classe serializada a partir do arquivo binário, achei este link aqui que explica bem, mas é bem simples pois os atributos ficam abertos, olhando o arquivo já da para saber: