comecei agora a ter essa necessidade, e queria saber o q pode ser feito a respeito desse assunto…
estou com a ideia de ler o numero serial do disco rigido ou algo desse tipo…
o q vcs sugerem???
- Um bom advogado
- Use outra linguagem
- Um “dongle” (Exemplo: http://www.safenet-inc.com/products/sentinel/hardware_keys.asp )
O número serial do disco rígido é fácil de obter (basta um “dir”) mas mais fácil ainda de mudar.
VolumeID v2.0
Acho que a situação não é tão caótica assim a ponto de mudar de linguagem, vc pode gerar uma chave, criptografa-la e guardar no banco de dados, e sempre que sua aplicação levantar ela confere a chave, considerando é claro, que sua base de dados tenha uma senha própria, e não use a senha do root. Bom, agora, se vc quiser gastar, a solução da chave por hardware também é interessante.
Rodrigo.
Nesse caso, também precisaria usar uma conexão criptografada entre o banco de dados e a aplicação. Além disso, precisaria dar um jeito de alterar a chave a cada distribuição do software.
Mas isso ainda não resolve o problema. Já ouviu falar no cavaj?
Ele descompila código java, tornando realmente fácil você quebrar esse tipo de segurança.
Como o Thingol falou, nesse caso, é melhor usar uma outra linguagem, preferencialmente compilada.
[quote=rdantas][quote=“thingol”]
- Um bom advogado
- Use outra linguagem
- Um “dongle” (Exemplo: http://www.safenet-inc.com/products/sentinel/hardware_keys.asp )
[/quote]
Acho que a situação não é tão caótica assim a ponto de mudar de linguagem, vc pode gerar uma chave, criptografa-la e guardar no banco de dados, e sempre que sua aplicação levantar ela confere a chave, considerando é claro, que sua base de dados tenha uma senha própria, e não use a senha do root. Bom, agora, se vc quiser gastar, a solução da chave por hardware também é interessante.
Rodrigo.[/quote]
Mas descompilando o codigo (Decompiler) teria a senha do banco, e acessando o banco tenho a chave… toda criptografia ou logica para esconder a chave ou senha é complicada uma vez que a pessoa tem acesso ao codigo… tambem não vejo uma saída para o problema, veja tem um post meu sobre isso em que não achei uma solução convincente:
http://www.guj.com.br/posts/list/80116.java
Se alguem tiver alguma experiencia, as informações serão de total aproveito!
Grato
Pense se é possível mudar o foco da sua aplicação.
Em vez de criptografia, token, etc. Pense em ou deixar a sua aplicação no seu servidor ou pelo menos parte dela no seu servidor, daí o controle é bem fácil.
Ou melhor ainda, estude o modelo de negócio do software livre, é possível sim gerar receita para vc e deixar o seu software livre (imune a pirataria :lol: ) http://www.viamais.net/blog/?p=138
Boa sorte.
[quote=pyro]Pense se é possível mudar o foco da sua aplicação.
Em vez de criptografia, token, etc. Pense em ou deixar a sua aplicação no seu servidor ou pelo menos parte dela no seu servidor, daí o controle é bem fácil.
Ou melhor ainda, estude o modelo de negócio do software livre, é possível sim gerar receita para vc e deixar o seu software livre (imune a pirataria :lol: ) http://www.viamais.net/blog/?p=138
Boa sorte.[/quote]
Não estou querendo ser critico, gostaria de uma solução se é que existe para esses casos, mas distribuindo no seu servidor ou usando algum tipo de rede externa ao do servidor que roda aplicação seria facil, mas pra resumir imagine uma aplicação de repente que roda em um cd, ou na maquina local sem internet, assim como citei no meu post não vejo como fazer uma seguranção a não ser soluções de esconder ao maximo e embaralhar suas senhas no meio do codigo mas tudo soluções que com tempo e pasciência alguem recuperaria…
Bacana esse link, concordo com texto mas em alguns casos precisamos esconder senha ou informações sigilosas, não digo nem do codigo como seu texto enviado referencia… sou a favor tambem do software livre!
Bom, aqui usamos a solução de segurança através de hardware, como alguém já mencionou. Usamos o famoso PROTEQ (www.proteq.com.br).
Se trata de uma pecinha (os antigos são paralelos, os atuais são USB) que fica conectada no servidor. Nesse pequeno hardware contém uma identificação dizendo que a peça pertence a nossa empresa e tb todas as informações necessárias pra se saber qual sistema o cliente pode acessar, etc, inclusive a quantia de terminais que podem acessar o sistema.
A coisa é simples, o kra pode copiar seu programa pra qq lugar, só que sem ter o PROTEQ o sistema não funciona, ele só “roda” se identificar o proteq com nossa identificação e pegar as informações que mencionei acima.
Não tem como o kra comprar outro proteq e por no lugar, o sistema reconhece nossa identificação, e só nós gravamos ele com nossa identificação. Uma vez “formatado” pra nossa empresa (ou seja, gravada nossa identificação nele) só é possível desgravar ou gravar novamente mandando pro fornecedor de proteqs.
Vcs devem pensar: Ok! Tudo lindo, mas e se o kra descompilar o fonte do programa e inibir a verificação do proteq?
Difícil… o sistema funcionaria de forma “manca” já que em muitos lugares as informações coletadas do proteq são usadas, ele depende das informações do proteq pra funcionar. Além disso, distribuímos o sistema em versão executável (não em .jar), então fica mais difícil de descompilar (se é que é possível).
[quote=RenataFA]Bom, aqui usamos a solução de segurança através de hardware, como alguém já mencionou. Usamos o famoso PROTEQ (www.proteq.com.br).
Se trata de uma pecinha (os antigos são paralelos, os atuais são USB) que fica conectada no servidor. Nesse pequeno hardware contém uma identificação dizendo que a peça pertence a nossa empresa e tb todas as informações necessárias pra se saber qual sistema o cliente pode acessar, etc, inclusive a quantia de terminais que podem acessar o sistema.
A coisa é simples, o kra pode copiar seu programa pra qq lugar, só que sem ter o PROTEQ o sistema não funciona, ele só “roda” se identificar o proteq com nossa identificação e pegar as informações que mencionei acima.
Não tem como o kra comprar outro proteq e por no lugar, o sistema reconhece nossa identificação, e só nós gravamos ele com nossa identificação. Uma vez “formatado” pra nossa empresa (ou seja, gravada nossa identificação nele) só é possível desgravar ou gravar novamente mandando pro fornecedor de proteqs.
Vcs devem pensar: Ok! Tudo lindo, mas e se o kra descompilar o fonte do programa e inibir a verificação do proteq?
Difícil… o sistema funcionaria de forma “manca” já que em muitos lugares as informações coletadas do proteq são usadas, ele depende das informações do proteq pra funcionar. Além disso, distribuímos o sistema em versão executável (não em .jar), então fica mais difícil de descompilar (se é que é possível).[/quote]
Bacana essa solução! Ja vi um desse no microsiga, tem idéia do custo dele + - (chute até mesmo porque varia de terminais e tal…)
Com descompilação de fontes e substituição dinâmica de classes, nem o protec resolve.
Se o cara tiver um pouco de determinação, ele pode fazer com que suas classes que lêem informações do protec, imprimam essas mesmas informações.
Tudo depende contra quem você quer se prevenir.
Agora, uma reflexão:
Quem fica com o maior inconveniente desses sistemas anti-cópia?
O pirata, que vai pegar um software já descompilado e modificado?
Ou o cliente, que tem o stress de guardar um hardware (isso sem falar no estresse ainda maior se ele perde-lo), digitar seriais, e que teve a preocupação de pagar pelo seu software?
Infelizmente, medidas como essa afetam mais quem paga pelo software, do que quem não paga. Então, considere com carinho a possibilidade de não ser paranóico com o assunto, e incluir como medida de segurança o mínimo, apenas para barrar o “pirata casual”. Ou, opte pelo software livre e ganhe com outros canais de distribuição.
no momento nao busco uma solução tao complexa…
queria mesmo impedir apenas q os meus clientes, que geralmente sao comerciantes, nao conseguissem simplesmente copiar a pasta do sistema e o bando para outra maquina e rodar…
portanto acho q a solucao de ler o serial, criptografar e guardar no banco, ja resolveria meu problema…
se alguem tiver um exemplo eu agradeço!
(exemplo da leitura do serial)
[quote=Maniezo]
Bacana essa solução! Ja vi um desse no microsiga, tem idéia do custo dele + - (chute até mesmo porque varia de terminais e tal…)[/quote]
Poxa, desculpe, não trabalho na parte comercial da empresa (obviamente) e por isso não sei te dizer o preço. Acho que uns 100,00… sei lá, não deve sair disso. Mas é algo que já está embutido no preço do software, o cliente nem liga.
Claro que se seu cliente for MUITO pequeno ele não vai aceitar. Mas no nosso caso, os clientes não se importam com isso.
E é usado um por estabelecimento, não um por terminal. Fica no servidor da aplicação. Temos até gravação da peça on-line. O cliente não tem problemas qto a isso, é seguro pra ele, é seguro pra nós. Diferente do que mencionaram, não é um monte de seriais, nada do gênero. Liberamos qual deve ser o conteúdo do proteq dele, e pela internet ele apenas pluga a peça na máquina e clica num botão gravar. Coisa básica…rs…
[quote=lauronolasco]no momento nao busco uma solução tao complexa…
queria mesmo impedir apenas q os meus clientes, que geralmente sao comerciantes, nao conseguissem simplesmente copiar a pasta do sistema e o bando para outra maquina e rodar…
portanto acho q a solucao de ler o serial, criptografar e guardar no banco, ja resolveria meu problema…
se alguem tiver um exemplo eu agradeço!
(exemplo da leitura do serial)[/quote]
consigo fazer com o RunTime, lendo a saída…
tem outra forma?
e pra linux?? o mesmo ‘dir’ funciona?
[quote=RenataFA]
Difícil… o sistema funcionaria de forma “manca” já que em muitos lugares as informações coletadas do proteq são usadas, ele depende das informações do proteq pra funcionar.[/quote]
Eu me lembro de uma versão do Autocad que necessitava de um hardware desses (ainda nos tempos do DOS!); apareceu uma versão pirateada por aí que estava com as proteções removidas.
O problema dessa versão pirateada, é claro, é que algumas das informações necessárias para fazer os cálculos estavam no hardware, e se você fosse fazer um desenho com o Autocad ele ficava ligeiramente errado, ou seja, a versão pirateada era inútil.
Da mesma forma o sistema da Renata deve usar alguns truques do tipo “a alíquota de ICMS é X% mas essa informação está guardada no Proteq; se não achar o Proteq, calcule com Y% em alguns lugares apenas, para não ficar muito óbvio”.
pessoal… nao querendo ser chato…
vcs estao levemente fugindo do meu objetivo…
:lol:
queria um exemplo de leitura do serial do disco em java, que sirva tanto pra windows qnto pra linux…
Eu sei que para pegar o número de série do fabricante para o disco rígido você pode usar o seguinte comando, mas como root:
lshw -xml -class disk | grep serial
(pode ser que o lshw não esteja instalado no seu Linux “por default”).
Por exemplo, no caso de um HD Seagate:
<serial>3LC2GX9Y</serial>
ou no caso de um HD Western Digital:
<serial>WD-WMAK05950074</serial>
tentei isso aqui…
public static void main(String[] args) {
String saida = "";
String comando = "dir";// + ip;
try {
Runtime r = Runtime.getRuntime();
Process p = r.exec(comando);
BufferedReader in = new BufferedReader(new
InputStreamReader(p.getInputStream()));
String inputLine;
while ((inputLine = in.readLine()) != null) {
System.out.println(inputLine);
saida += inputLine;
}
in.close();
}//try
catch (IOException e) {
System.out.println(e);
}
}mas nao funciona… é como o Iniciar -> Executar…
nao executa comandos… so consegue abrir arquivos existentes… como o ‘ping’
?
Você precisa executar “cmd /c dir”, não “dir”. É que o “dir” é um comando do “cmd.exe”, não um executável separado.