[Vamos debater] Não quero ser crackeado...

Nildo sua proposta é ótima, espero que todos do forum se empenhem em neste projeto.

Uma vez eu fiz gravar em um campo de uma tabela a primeira vez que o prog foi executado. Aí, na hora de executar, ele olhava a data e via se tinham 30 dias. Funciona bem se vc souber que o user não vai ter acesso ao BD... mas provavelmente há uma solução melhor.

Nào uso banco de dados.
Mas mesmo assim. Se o cara deletar o arquivo aí ferra tudo

Uai.. mas se o prog usa BD e ele deletar o BD... aí que ele não usa mais o prog mesmo hehehe...

hehe

Mas se ele reinstalasse o sistema, poderia continuar usando o programa.
Mas de qualquer maneira, meu programa nao usa BDs

Prezado Nildo.
Executo duas verificações para minhas versões trial.
1º = Continuo partidário em limitar o número de registros a serem gravados nas tabelas do BD, sempre projetando um número suficiente para que toda a funcionalidade do sistema seja verificada. Após o número limite de registros as tabelas passam a ser somente leitura;
2º = Por outro lado, uma segunda verificação também se torna necessária, pois, se o cliente demorar muito para analisar o sistema o mesmo vai expirar.
Na primeira execução o sistema verifica a existência de um determinado arquivo .DAT. Se não existir ele o cria no diretório especificado em projeto e grava a data da execução mais a diferença da data atual menos a data da primeira execução de forma encriptada.
Sempre que o sistema é aberto, ele lê o arquivo criado, lê a data atual, deduz uma da outra e acrescenta a diferença à data anteriormente gravada.
Quando esta diferença for superior a 30 (correspondente a 30 dias; por exemplo: 2710200331 = 27/10/2003 dif=31) as tabelas também se tornam somente leitura para a gravação de registros.
Não me refiro a propriedade somente leitura de arquivos, mas sim para a gravação de registros.
Este tem sido o procedimento que tenho utilizado. Ainda não quebraram.

Desta forma, eu poderia utilizar um monitorador de arquivos, e perceberia que o programa gera um .DAT lá. Se eu deletásse esse arquivo, o sistema acusaria que seria a primeira execução. Ou mesmo se eu instalá-lo novamente, acusaria como primeira execução, mesmo se a data já expirou.

Prezado amigo:
vc se apegou ao arquivo dat e a limitação de 30 dias, mas, e a limitação de registros, vc nada falou?
de outra forma, você é um desenvolvedor. vai habilitar seu sistema para usuários, certo?
se quiserem deletar o dat, e dai, mais que X registros no BD não gravarão.
OBS: vi em uma colocação sua neste forum que é um expert em delphi. como expert o que sugere então??
MMTOOR2003

Primeiro: O lance dos DBs nao vem ao caso. Já que estamos falando em uma maneira global. Pois meu programa por exemplo não utiliza DBs. Sobre a colocação, eu disse que entendo de Delphi, e estamos discutindo uma ´idéia´ de como pode ser feito esse sistema de travamento. Depois da idéia pronta, cabe a mim programá-la. E sobre a ´idéia´ global, seria um Trial para parar de funcionar depois de X dias. E não um DEMO cujo mesmo há limitações (no caso a limitação dos registros). Pois pretendo liberar acesso total a todas funcoes do meu programa, e não simplesmente travar algumas opções.

Ps.: Não estou tentando sugerir nada. stou tentando habilitar uma discussão sobre o assunto pois também estou interessado em sugestões. Como é uma discussão, todos temos o direito de contrariar algumas idéias. Estou atraz de sugestões, e não tentando passar as minhas.

Colocar um pouco de pimenta...


O dia que eu fizer um programa e os caras começarem a piratear...


UUUUUUúúúúú........Isto quer dizer que o meu programa é sencacional..

Por tanto, vou continuar criando meus programas com alguns BUG´s...Pois, assim, somente os usuários registrados poderão atualizar..

Ou será que á Microsoft faz coisa diferente ????



:lol:

Eu ainda sou a favor de versão limitada. Programas trial eu crackeio mole-mole, mamão com açucar.

É simplesmente sobre-humano criar algo infalível, [in]felizmente! :!:

Ataliba.

Uma solução simples é comparar da data corrente com a data do executável.

Outra é determinar via programa a data limite. Assim não gravamos em lugar nenhum. O cara pode utilizar mas vai ter que ficar voltando a data do computador.

Assim a validade não se refere a quantidade de utilização mas a uma data no futuro.

A solução do registro via email também é boa. Ninguem vai perder tempo craqueando um programa da gente.

Voce pode mandar o programa de vez-em-quando te mandar um email utilizando o smtp disponível, com o nome do usuário e a data de utilização. Assim vai saber se existe algum uso indevido.

Tem programas que somente rodam quando enxergam o seu site na internet. Mas estes são difíceis de vender.

Na verdade o negócio é liberar a cópia. Quanto mais gente utilizar melhor para vender as novas versões.

Este negócio de proteger muito acabou com a LOTUS.

Marconi

Só fazer um launcher para o programa: ele volta para uma data X e roda seu programa.

Só pra constar: se não fosse o software livre, o computador ainda dependaria de válvulas. O que seria de nós se Nicklaus Wirth, Edsger Dijkstra, Jean Ichbiah, David Huffman, Tony Hoare, Alan Turing, Alonzo Church, entre outros, tivessem patenteado suas descobertas, ou cobrado por elas? E Charles Darwin, Newton, Arquimedes?

Eu sei que esta não é uma questão de patente, mas os princípios são os mesmos. Além do mais, copyrights são respeitados.

Ataliba.

Boa noite.

Eu concordo com o que foi dito por todos. Mas tenho uma reflexão a fazer. Será que existe algo seguro de verdade? O nildo está rebatendo todas as idéias dos colegas dizendo que pode usar um monitorador de registro e um monitorador de arquivos, etc. Vc nem parou para pensar numa coisa. Se vc sabe fazer ( a trava ) outro tb vai sabe desfazer. É uma coisa lógica. Se vc é programador e sabe que caminhos tomar para criar uam trava, outro programador tb sabera como percorrer o caminho inverso.
Pelo que já vi em programação, o que realmente funciona é vc está sempre mudando a forma de verificação. Se vc usa o registro, não fique preocupado se alguem vai usar um monitorador de registro. Quantos usuários vc acha que têm o conhecimento e a ferramenta e vão saber monitorar direito e encontrar a chave do registro? Poucos usuários saberiam fazer. Alguns administradores de sistema e programadores vão saber como procurar e vão encontrar. Quando encontrarem, é hora de vc por exemplo, usar trava de arquivos ( pode deixar a primeira trava só para confundir ). Se descobrirem a trava de arquivos, crie outra. Esta é a forma ideal para ninguem usar seu programa sem autorização. Melhor ainda seria se vc conseguisse que cada trava adicionada, não atrapalhas-se a outra e todas pudessem co-existir juntas. Se não for possivel, retire algumas antigas e substitua por outras mais eficientes.
Espero ter ajudado.
Um abraço.

É tecnicamente *impossível* criar qualquer ´função´ q NÃO possa ser craqueada!

O q se deve procurar é criar mecanismos onde o esforço para ´craquear´ seja o maior possível em relação ao valor/ambiente de sua aplicação.

Mesmo os sistemas ´trial´ mais simples em geral não conseguem ser ´dissolvidos´ pela maioria dos ´usuários´ -- é preciso um programadorzinho ou um usuário mais ´esperto´ para conseguir driblar a rotina, sendo assim, vc terá evitado o FURTO de seu sistema na maior parte das vezes.

Existem diversas ferramentas no mercado (OpenSource, Freeware ou Comercial) que realmente tornam bastante difícil para o ´delinquente´ conseguir quebrar a segurança, de forma q é possível q muitos desistam -- isso não quer dizer q todos -- mas seu mercado já provavelmente estará assegurado.

Agora, existem outras alternativas mais eficazes para garantir seu mercado como:: oferecimentos de serviços associados ao sistema, suporte técnico eficiente, atualizações constantes, boa imagem/relacionamento com seu mercado alvo, etc.


T+

Só posso dizer uma coisa: Nada é 100¬ seguro, inquebrável ou intransponível. (Tudo bem, foram três coisas. :D )

Eu tenho muita boa vontade de liberar meus programas de graça. Mas o problema é que meu chefe quer receber por eles.

Olha moçada, do meu ponto de vista o melhor a fazer é dificultar ao máximo o trabalho dos crackers... na verdade nenhum sistema é inviolável... então o melhor a fazer é com q o cara pense bem se vale a pena se preocupar com o nosso sistema... eu mesmo criei um componente q verifica a cada vez q o aplicativo é usado a data q ele rodou pela primeira vez, a data q ele rodou pela última vez (evitando retorno da data do sistema), a quantidade de vezes q ele rodou e a data atual... todos esses dados são salvos no registro do sistema só q de forma encriptada... não tenha dúvidas, se alguem se dedicar um pouco quebra a minha segurança... mas a pergunta é: quem vai perder seu tempo com isso???

Bom Nildo.
Pelo que percebi vc quer a idéia dos colegas, certo. Entendi...

Evandro Massine: Tem muita, mas muita e muita gente por aí crackeando sistemas só para dizer: Eu fiz. Mas muita gente mesmo

mmtoor: Não exatamente a idéia. Quero muitas opiniões pra juntar tuda numa só e criar um componente pra isso. O que eu quero fazer é criar este componente e liberar seu fonte à todos aqui do forum. (Com o fonte seria seguro???).
Quero que esse componente quebre o meu galho e o de muitos que estejam interessados, sendo muito dificil de ser quebrado. É isso que eu proponho.

Prezado amigo:
O TTimeStop faz isso que quer. vc insere o componente, informa a data para expirar e pronto.
Seria algo assim?

Seria. Mas queria desenvolver algo que tivesse certeza que é um sistema duro de quebrar, e com uns recursos a mais que tenho em mente. Mas para isso cai no comesso da discução: Onde salvar alguma informação, que seria difívil de se ver, dificultando assim um cracker de crackear o sistema.

Prezado amigo ulbj05...
O pior é que isso é a realidade. Estou pensando em fazer algo assim:
Veja se vocês concordam, principalmente o MMTOOR:

Uma chave do registro, com varias informações inuteis que meu programa somente le mas nao faz nada (confundir o cara) do tipo: DataExpira, Registrado, Chave, etc. E que o nome dessa chave seria: {ANNBYCJ35-355HJKH-287HSHH} (como aqueles GUIDs do registro). Confundiria mais ainda. E alguma informação dentro dessa chave que diria que eu teria que ler outra chave para obter o valor de outra chave, e assim sucessivamente umas 5 vezes. Só que na verdade a informação util está na 3ª chave (das 5), que lá dentro teria todos os dados encriptografados, contendo a data de hoje, e uma anterior (cada vez que entra no sistema atualiza a data). Assim posso verificar se o cara alterou a data do sistema, se a data de hoje for menor que a anterior. Outra informação dizendo se o cara registrou ou não. Mas não seria um simples valor Boolean. Seria o número do HD do cara, criptografado (dessa maneira não funcionaria a mesma chave em outro computador). Eu leria esse valor, descriptografaria e verificarei se o número bate com o serial do HD do cara. Se bater então está registrado, senão não está. :wink:

E então? O que vocês acham dessa idéia?

Nildo, do jeito que explicou a idéia deu até um nó na cabeça. Realmente vai dificultar muito ser quebrado o sistema. Mas será que vale o esforço? E a manutenção? Vc sabe que dar manutenção em sistemas que utilizam o registro é um pé no s. Não seria melhor vc criar um componente que entre suas propriedades vc pudesse escolher em que chave seria gravada a informação?
Eu criei um componente para segurança de minhas aplicações. Ainda não quebraram ( o que não quer dizer que não venham a quebrar no futuro ). Nesta versão que o componente está, ele nem grava criptografado. Mas eu posso escolher em que chave eu vou gravar as informações. Escolho um nome bem estranho, de preferencia, parecido com os nomes do proprio windows, e gravo lá. Se eu souber que meus sistemas foram craqueados, simplesmente mudo o nome dachave e o nome dos valores numa próxima versão. A pessoa que craqueou, vai ter todo o trabalho novamente. Além de ser um saco, o cara ter que fazer o seu trabalho tudo de novo ( o delinquente ), vc ainda pode acrescentar um novo verificador, ou acrescentar novas chaves no registro, etc. O céu é o limite. Vc pode fazer o que quiser. Mas ainda acho mais fácil vc ter uma boa chave de segurança e continuar usando ela, mesmo se os delinquentes consigam entrar. Faça uma estimativa: se vc vender seu programa para umas 200 pessoas, quantas vão ter tempo, paciencia, conhecimento, ferramentas, para quebrar sua segurança? Uns 10¬? Todo negócio tem riscos. Se vc encontrar um negócio que não tenha riscos, vc tb não ganha nada. É aquele velho ditado: ´QUEM NÃO ARRISCA, NÃO PETISCA!!!´
A sua idéia é boa e trabalhosa. Se acha que vale o esforço, mãos a obra. Eu acho que uma simples chave no registro de nome bem dificil de adivinhar, já dificultaria muito para a maioria dos usuários. Se vc percebeu que sua chave simples foi eficiente para, por exemplo, 150 pessoas das 200 que vc vendeu, mantenha esta chave e acrescente uma outra um pouco mais complicada para pegar na rede os 50 deliquentes que estão teimando em quebrar sua segurança.
É isso. Que acha da idéia?
Um abraço.

Olá, senhores.

Espero que possam aperfeiçoar minha idéia ou, quem sabe, demonstrar que ela não é viável (sei que para um programador é difícil, mas vamos tentar sermos maduros e focar o objetivo deste tópico).

Imagino um conjunto de quatro coisas:[list=1:aca16dee44][*:aca16dee44]Inscrição no registro;
[*:aca16dee44]Arquivo criptografado com dados da instalação;
[*:aca16dee44]Um conjunto de ativação via Internet;
e...
[*:aca16dee44]Um algorítimo que preveja o que deveria estar escrito (nada de ocultismo, vou explicar).
[/list:o:aca16dee44]
O algorítimo verificaria vários pontos o tempo todo...[list:aca16dee44][*:aca16dee44]se a data do sistema é compatível com os arquivos temporários que estão sendo gerados pelo próprio Windows. Ou seja, arquivos com datas de 20/10 e data do sistema 10/10... há algo de errado: anote no arquivo criptografado um [b:aca16dee44]termo de desconfiança[/b:aca16dee44];
[*:aca16dee44]ao instalar, baseado na data e em parte do número do HD, criar um arquivo - quem sabe dando a impressão de que o sistema de registro estela ali - com um tamanho e conteúdo relacionado àqueles dados. Assim, em outra data, o tamanho do arquivo seria diferente... data nova, tamanho de arquivo diferente: há algo de errado: anote no arquivo criptografado um [b:aca16dee44]termo de desconfiança[/b:aca16dee44];
[*:aca16dee44]um último ID exclusivo: com os dados levantados, o software se comunica com um servidor para validar a instalação...
...caso não haja tal recurso disponível, o instalador cria um disquete com os dados necessários, o usuário vai até uma web-station e dispara o mini executável que se comunica com o servidor e grava no próprio disquete a liberação;
[*:aca16dee44]com a chave via IP ou com o disquete, a execussão do aplicativo é habilitada;
[*:aca16dee44]finalmente, com a utilização do programa, cria-se vários lançamentos relacionados com o tempo de uso, existência de arquivos em pastas do sistema, etc. Tudo isso auditável e registado. Quando uma execussão determinar que seu arquivo e registro não são compatíveis com o histórico gravado, saberá que alguém está tentando burlar o sistema de proteção, extendendo o prazo de uso ou anulando dados de um banco de dados com restrições, etc.
[/list:u:aca16dee44]
Parece um parto... à [i:aca16dee44]fórceps[/i:aca16dee44].
Alguém pode incluir, modificar ou simplificar a idéia? :roll:

Existem Meios mas nenhum é 100¬ seguro a questão é utilizar o menos falho, já vi alguns métodos que fazem uma escrita no própio exe através de resource é complexo...

Caro amigo haguen, podemos utilizar sua idéia. Mas temos que achar uma maneira de mudar algo via programação tipo o tag dos formulários ou seja comparando as datas do executavel e a data corrente calcularesmos a diferença e gravamos o tag do formulário sendo assim se o tag for igual a ´1´ por exemplo a nossa aplicação se fecha.

Vamos amadurecer a idéia ok.

Hangen e machado, eu já pensei em escrever no próprio EXE. De muito complicado num tem nada. Só que se o cara reinstalar (trocar o executável), pronto. Pode usar mais 30 dias.

ulbj05: O problema não é escrever em uma chave difícil de adivinhar. O maior problema é que existem vários programinhas que identificam toda vez que um programa lê uma chave do registro, alem de mostrar qem leu a chave. Assim não importa o nome da chave o programa sempre detecta qual ela leu. Por isso eu disse que da minha maniera leria umas 5 chaves e na verdade o que interessa está na 3ª e nao na 5ª.

Ildefonso: O problema é o mesmo do registro, exitem programas pra monitorar criação de arquivos. Se o cara simplesmente deletasse o arquivo contendo o [b:7aed828f8c]termo de desconfiança[/b:7aed828f8c], o sistema acusaria que estaria tudo bem quando na verdade não está.

Olá, novamente, Nildo.

O [b:030abac0ec]termo de desconfiança[/b:030abac0ec] fica em um arquivo e em registros necessários para o sistema... não podem ser apagados, porém, se editados, o algorítimo descobriria que ele não têm [u:030abac0ec]nexo[/u:030abac0ec] dentro de sua forma, e cancelaria o uso do sistema.

Reformatando o computador, o que incluiria alterar o número do HD, o rastreamento seria mais difícil. Porém, a simples exclusão dos dados, faria que uma nova instalação informasse um número conhecido de HD para o servidor Internet... [b:030abac0ec]termo de desconfiança!!![/b:030abac0ec]

Vamos continuar...

No próprio exe é impossível, ele é somente leitura quando executando.

Ataliba.

Dá pra fazer o seguinte....

Grave todas as informações referentes as datas de utilização e datas já utilizadas dentro de uma DLL usada pelo windows... assim seuj monitor de arquivos não detectará o arquivo e se detectar o usuário terá que deletar esta dll ai o windows bau bau...



soda limonada
balceiro@bol.com.br

Gostei da idéia, mas creio que se o usuário restaurar o sistema, ele recupera a dll original.

Ataliba.

É isso ae Ataliba. Se houver um upgrade na DLL, perderiamos ela.
Mas você está enganado referente à alterar o EXE. Eu tinha uma biblioteca que alterava o EXE, só que para fazer efeitos deveria reiniciar o executável. Mas essa tentativa não vem ao caso pois se o cara trocar o EXE ferra com tudo.

Ildefonso: Qualquer arquivo mesmo o de sistemas dá pra ser excluido. mas eu utilizaria sua idéia de definir como arquivo em uso para um método em que pensei.

Por favor, escreví esse texo e desejo que vocês vejam se a idéia é válida:

Ps.: Daria muito trabalho pra fazer, mas estou disposto a faze-lo, pois valeria a pena:

[b:4502d9f57c]--------------------------------------------------[/b:4502d9f57c]

O programador deve apenas informar um número, que é o que eu usarei como controle pra saber qual chave deverei pegar as informações do registro.

De acordo com esse número de 5 caracteres, eu geraria 7 GUIDs mais ou menos assim:
{208D2C60-3AEA-1069-A2D7-08002B30309D}

Salvaria as chaves em locais diferentes:
HKEY_CURRENT_USER\Software\Classes\CLSID\
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\
HKEY_LOCAL_MACHINE\Software\CLASSES\(umas contas com o número, 3 caracteres)\CLSID\
HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\
HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\
HKEY_USERS\.DEFAULT\Software\Classes\CLSID\
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\

- Para definir como sistema registrado:
Pegar o nº de serie do HD, fazer umas contas doidas, criptografar e quebrar ele em 7 strings diferentes. Salvar cada um desses strings em cada um dos 7 GUIDs.

- Para saber se o sistema está registrado:
Em cada uma dessas chaves teria um Valor que juntando todos os valores e descritografando retornaria um número, que fazendo as ´contas doidas´ no modo inverso retornaria um número. Se esse número fosse o número de série do HD dele então está registrado.

- Quando executar pela primeira vez (Não existir nenhuma GUID):
Criar todas as GUIDs conforme dito no inicio do texto, e em uma delas salvar (criptografado) a data do sistema. Este valor será fixo e será usado para sempre.

- Toda vez que executar o programa:
salvar em uma GUID diferente da que está a data de quando executou pela primeira vez, em um valor novo, a data do sistema (Terá uma chave nova para cada dia que executar o programa). E toda vez que iniciar o sistema vai me possibilitar checar se o cara voltou a data.

- Checar se o período de avaliação expirou:
Pegar a data em que executou pela primeira vez, e pegar a maior data entre as que já estão salvas. Se a diferença de dias entre elas for maior ou igual a 31 (no caso) então quer dizer que expirou.

- Checar se o cara tentou sacanear o programa:
Além de salvar tudo no registro, salvar em um arquivo encriptado na pasta c:\windows\system tudo o que foi feito no registro. Dae eu posso verificar se o cara altero algum valor ou deletou alguma chave.
Checar a existencia de todas as GUIDs. Se uma delas não existir então tentou ser crackeado.
Se o arquivo não existir, e existir pelo menos uma das GUIDs, então quer dizer que foi crackeado.

[b:4502d9f57c]--------------------------------------------[/b:4502d9f57c]

É cansativo de ler, mas me deu muito mais trabalho escreve-lo. Por favor digam se é boa a idéia. Obrigado!!!!

Achei muito bom, mas tenho uma dúvida, o que acontece se a pessoa precisar formatar a maquina?

A idéia é boa nildo. Porém muito trabalhosa e sugeita a erros pois, se algo de errado acontece no meio do processo o resultado pode ser um Bug dificil de encontrar, com diversas chaves no registro ( algumas completas e outras incompletas ) e arquivos espalhados pelo computador. Gostaria de ter uma idéia melhor mas, é como falei, segurança demais pode também ter um efeito negativo: as pessoas têm tanta dificuldade em executar seu programa que podem deixar de usa-lo. E como fica a performance do programa? Se vc fizer todas as contas malucas e ler arquivos do HD e chaves do registro, será que o programa não vai ficar meio lento na inicialização ( isso sem levar em conta que o programa pode estar usando bancos de dados e também terá de se conectar e inicializar variáveis ). Talvéz a melhor forma seja uma idéia que tive ao ler as mensagens dos colegas. Não é fácil implementar.
Um programa não aceita ser apagado enquanto estiver em execução. Quando o programa iniciar, se ele fosse capaz de criar uma cópia dele mesmo incluindo informações de data que estão no próprio exe, seria interessante. O programa pegaria o código binário dele acrescentaria umas informações sobre a data e salvaria por exemplo com um nome igual ao dele com o sufixo ´Copia´. Então o programa executaria um outro programa que tem por finalidade apenas apagar o programa atual e renomear o programa tirando o sufixo ´Copia´ e executando o programa novo. Apos o programa antigo ter iniciado este outro programa ele se auto-fecha. O outro programa apaga este programa antigo, renomeia o outro e executa. É simples de
Alguém pode melhorar esta idéia? Que acham dela?

falar e dificil de implementar mas, seria o mais seguro na minha opinião pois as informações estariam dentro do próprio exe. Se o usuário re-instala-se o aplicativo, então não funcionaria pois, logo na primeira execução ele pegaria a data de instalação ( que já viria de fábrica ) e acrescentaria a data do sistema e já faria o processo, apagando o exe e criando outro novo. Se a data do sistema for menor que a data de instalação, ele não prossegue com a execução.

Nildo

Tchê estava pensando aqui com as minhas teclinhas !!!! :lol: E me passou uma dica pela cabeça, vc disse que se colocar um arquivo .DAT dentro de uma pasta com a data poderia ser identificado. Mas se vc colocar na primeira execução do aplicativo a geração de ´N´ arquivos com a data em pastas padrões, algo como: ´\Windows\System´, na própria pasta ´\Windows´, dentre outras, e até oculto se for o caso, com nome distintos, e para garantir e atribuir mais uma validação, insere também no Registro do Windows. Esta verificação não ficaria tão pesada, e você teria varios pontos para se certificar que não estão usando indevidamente. E quando ele for executado novamente, verificar um a um e caso falte algum não recriar o arquivo e acusar o erro. Coloque criptografia para dar mais uma segurança. E coloque alguns dados antes e depois da data, para ter certeza que não foram adulterados.

:idea: Não sei se pode ser uma boa idéia, mas é uma tentativa válida. Um software que encontrei e não encontrei maneira de reinstalar, exatamente o que vc procura, é um do lloyds, um tal de Espião 3.0, desenvolvido em Delphi.

Bom, acho que era isto, espero ter ajudado. :wink:

Shaolin: É interessante. Mas os crackers facilmente descobririam quais arquivos meu programa gera. É só deletar esses arquivos e pronto. Sistema liberado.

ulbj05: Obrigado. Mas um sistema de segurança tem de ser o mais complexo possível. Se você e até mesmo eu achei complicado de entender o que eu mesmo tentei passar, imagina alguem que não tenha lido o texto pra entender como funciona? Poderia ser sujeito a erros. Só que se for bem feito, um erro durante o processo quer dizer que ocorreu uma tentativa de crackeamento, pois alguem provavelmente alterou alguma chave no registro. Em questão à demora, é realmente imperceptível a demora dele. Pois é extremamente rápido os processos. Só que eu encontrei uma maneira de burlar esse sistema: Deletando o arquivo e todas aquelas chaves do registro. Só que até ele descobrir quais são vai demorar uma eternidade. Até lá já mudarei o método de verificação!

Rodrigo_rcp: Se o cara formatar, paciencia. Somente com validação via internet não permitiria o uso mesmo depois de formatar. Mas nenhum programa fica travado mesmo depois de formatar.

Eu tenho utilizado um pouco de tudo isto, para além de não usar strings em sítios sensiveis nem enviar mensagens ´Thaaaaan!!´ ao usuário. Tudo silencioso, pessoal.

Um método que tenho desenvolvido com sucesso é mudar periodicamente os nomes das procedures e métodos de segurança.

Associo isto às últimas versões de software, o que torna impossível criar um padrão de crack. Quem quiser anda sempre atrás do rato (bacalhau... eheheh).

Outra maneira é criar procedures com nomes iguais a comandos assembler. É de arrancar os cabelos desvendar um código quando isto acontece.

Mais outra: colocar código ´lixo´ que não faz nada nem interfere com a velocidade dos programas, mas atrai amadores a desvendá-lo.

Gostei bacalhau!!!!
Como q voce muda periodicament o nome das procedures? ´via programação mesmo?

como assim, se eu desmontar um programa e achar

eu vou entender perfeitamente.

Ataliba.

É verdade

Só fazer um launcher para o programa: ele volta para uma data X e roda seu programa.[/quote:bdc4c8dde7]

Pois é exatamente o que eu disse.
Se for um programa onde a data é importante, como por exemplo Notas Fiscais, ele vai ter problemas.

Quanto a Lotus lançou a versão 3.2 do Lotus 123, cheia de travas e à prova de pirataria, os disquetes de instalação davam muitos problemas. Além disso cobravam para reativar créditos em disquetes cujos programas instalados se perdiam por causa de ´paus´ nos computadores.
E como davam ´Paus´ naquela época!!
Foi a gota d´água que faltava para a maioria abandonar o Lotus e partir para o Exel, que era fácil de piratear.
Hoje a maioria das pessoas que piratearam o Exel, utilizam uma versão comprada do Office 2000 ou XT. Valeu ou não valeu à pena para a MicroSoft.

Eu tenho a impressão que eles não estão nem aí para as cópias piratas que os desenvolvedores têm em casa. Graças a elas as empresas têm cópias legais, pois as pessoas só se sentem à vontade com o Office.

Marconi

marconi, você realmente tem razão. Só que meu programa não é um do tipo que todos devem ter em casa. Pelo menos as empresas serão obrigadas a ter uma cópia pois pelo que ví é o melhor do mercado (é programa de backup). Mas você pode perder muito dinheiro se todos crackearem seu sistema.

O problema está resolvido, grava-se as datas em uma DLL usada pelo windows...

crie uma variavel nesta DLL chamada já utilizado = true;

Se o usuário reinstalar o sistema, ele não conseguira recuperar a dll porque toda vez que o programa for iniciado ele checa se a variavel é igual a true se a resposta for sim o sistema checa se a data já não está expirada se estiver não executa o sistema.

E se a variavel utilizado não existir na dll o sistema vai para o procedimento de criar a mesma primeiramente para DEPOIS criar as variavés de data.

assim você terá sempre uma segurança em seus sistemas, não será possível fazer a recuperação da dll nem a exlusão, nem copiar de outro sistema operacional windows...

Ou seja seus sistema será INVIOLÁVEL.

Se alguém quiser contestar esta resposta por favor faça de forma coerente.

Soda Limonada
balceiro@bol.com.br

Acho que modificar DLLs ou EXEs do windows não seria uma idéia muito viável, já que estaria sujeito a corrupção dos arquivos. A idéia é boa, mas seria muito fácil do cracker identificar qual o arquivo que o programa modificou, então ele entraria na DLL por um editor de HEX e pronto. Eu acho que a idéia é boa, mas eu não posso sair por aí alterando as DLLs do windows. Vamos supor que o programa expirou. Então o cara atualiza as DLLs dele pelo utilitário de restauração do sistema. Pronto, o sistema estaria como Trial novamente.

Ataliba: Sua ultima ´*&@#&´ foi excluida uaehuaehuehauhaeuh :lol:

Me corrijam se eu estiver errado, mas parece que ninguém considerou a possibilidade de alguém mexer direto no exe, não é? Imaginem que um programador mesquinho e sem coração fez uma super ultra mega master rotina de verificação, mas aí eu simplesmente edito o programa e troco um je por um jne nos lugares certos, ou simplesmente tiro a tal rotina e pronto, nada de rotina chata que impeça o pobre usuário de usar o executável livremente..

Simples: Meu componente guardaria encriptado numa propriedade privada o tamanho do executável. Dae eu verificaria o tamanho do executável com o valor daquela variavel. Se for diferente então foi crackeado.

Agora se o tamanho continuar o mesmo, eu acho meio difícil o cara achar o lugar certo simplesmente vizualisando seu hexadecimal. Afinal eu teria várias propriedades inúteis só pra enganar esses caras

Mas você disse de tirar a rotina de verificação? Na hora de programação? Se for, é problema do programador por falta de ler o tao chamado LEIAME.TXT

Tirar depois que o programa foi compilado, no hex. Incluindo a tal rotina que verifica o tamanho do arquivo. Para achar o local correto em que se deve mexer e driblar propriedades e métodos inúteis, usa-se um debugger.

nada é 100¬ seguro. Esses metodos todos dariam muito e muito trabalho pro cracker. Por exemplo: Como ele vai adivinhar que existe tal método que verifica o tamanho do EXE, ou mesmo a data de modificação? Um dia ele descobre. mas até lá vai demorar

Não dá pra confiar no tamanho ou data do executável, mas no conteúdo dele sim. Tem um sistema que eu to loco pra quebrar, é aquela proteção de CDs nos jogos. O jogo mesmo fica no arquivo GAME.ICD, critografado, e o GAME.EXE verifica se há um CD original e caso haja, ele descriptografa e roda o GAME.ICD como um executável normal. No nosso caso, precisamos substituir o CD por outro meio que valide a originalidade do sistema.

Ataliba

Sabe como os caras burlam esse sistema?
No momento que o original.exe descriptografa o .ICD, entao os caras pegam esse arquivo descriptgrafado (que ele cria em algum lugar) e o substituem pelo original. Isso tudo por um programa de verificar criação de arquivos. Eles verificam onde q o original .EXE cria o novo .ICD

Não é a única maneira. Um arquivinho de 6 Kb, o loader, virtualmente coloca um CD original no teu drive. Só não seu ainda como funciona, tô seu meu PeViewer. O que eu sei(vi no Ctrl+Alt+Del) é que um *.tmp é executado.

Ataliba

Sorteia um método e implementa, afinal, nenhum é seguro, não sei pq existem pessoas que ainda insistem em discutir um assunto desses, todo mundo sabe que é impossível criar proteções seguras, mas todo mundo quer se exibir com sua rotininha mequetrefe que acabou de criar e acha que é o máximo. Deve-se analizar o sistema a ser protegido e ver por quanto tempo e contra quem ele deve ser protegido, daí ve-se qual o método mais adequado, afinal, contra algums usuários, uma mísera criptografia de 8bit já seria mais que suficiente, já com outros, 256 bits é brincadeira de criança...

Foi mal pessoal, não levem pelo lado pessoal, simplesmente ignorem...

Infelizmente essa é a realidade. Na verdade o maior desafio é conseguir ficar o maior tempo possível sem ser crackeado!

Eu faço o seguinte:

Crio um novo valor em uma chave com um Nome que não tem nada haver com o programa.
Depois os valores eu coloco um seguencia Hexadecimal que somados de 4 em 4 gera a data de expiração do software(A1FF 1FF4 BCDA D0D1F006) sendo que é dd mm aaaa.
E faço outro Valor no registro para saber que a data expirou, para que o usuario não volte a data do computador (MonthOne = On ou Off).

Estes valores do registros são criados assim que o programa roda a primeira vez. Não corre o risco de o usuario desinstalar e instalar novamente, porque o programa verifica se os valores no registro ja existe, se existir não cria novamente.

A idéia principal é essa, porem é extremamente fácil de desvendar.

Olá,

Só a título de informação: Existe no www.sourceforge.net uma coleção de componentes chamada turbopower onguard, que é toda voltada à proteção de executáveis.
Podem não ser perfeitos, mas já servem de ponto de partida para criação dos seus próprios (tem rotinas interessantes...).
Como são free e opensource, vale a pena dar uma olhada....

Barcelos
osbarcelos@hotmail.com

Obrigado!
Vou estar dando uma olhada

Tamos aí pra isso,

Abraço,
Barcelos

A melhor maneira de se proteger de craker é saber como eles pensam, tem site legal na internet que aborda o assunto http://www.numaboa.com/informatica/oiciliS/index.php um dos tópicos encontrados por lá segue abaixo:

Os famosos 14 mandamentos de Mark

1 Nunca nomeie arquivos ou procedimentos com nomes que façam sentido, do tipo IsValidSerialNum ou CodRegOK (dããããã!!!). 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 E, finalmente, nunca revele seus melhores segredos de proteção :-)

Fava:
Cara num sei nem como agradecer as dicas! Realmente me serão muito úteis, principalmente aquele link que você me passou.

Realmente, o item número 4 já está implementado em meu sistema. Depois que digita o serial, dou uma pausa de 5 segundos para falar se está correto ou não!

Essas dicas são preciosas, era justamente isso que eu queria. Obrigadao mesmo!!!

Nildo, dispõe.

Só não querendo ficar com créditos que não são meus, gostaria de frisar que estas dicas foram tiradas do site que indiquei, ou seja, não fui eu que escrevi. :?

Mas.... depois se você lembrar me manda uma cópia do seu componente... :oops:

Vou colcoar um tópico quando acabar
Valew mesmo

Olá a todos,

deixe-me falar como o meu componente funciona (ele é bem simples mesmo). A versão atual ainda não é para Trial, mas sim para liberar a execução do mesmo.

Primeiro ele verifica se existe u arquivo específo na pasta de instalação do programa (para que esconder?), caso não exista, ele recria-o e e abre uma tela pedido um código de liberação. Para obter tal código, o usuário tem que informar uma contra-chave para que, através dela, eu possa gerar um código de liberação para aquela cópia específica (no momento, utilizo o Serial do HD mas a identificação da aplicação). O usuário recebe a chave, informa ao sistema e pronto, está liberado. Se o usuário apagar o arquivo de ´controle´ o sistema não funciona, e tem que informar o códi do liberação de novo).

Agora para um implementar o ´TRIAL´ estou pensando em utilizar o mesmo esquema, só que, quando o usuário tentar abrir o sistema, ele vai checar o arquivo de controle, e caso o mesmo não exista, e vai pedir para que o usuário obtenha uma chave via internet (que será automático, o usuário apenas vai clicar um botão e o proprio sistema vai acessar uma URL passando algumas informações como: data da solicitação de liberação, serial do HD, e contra-chave para liberação). Essas informações ficarão guardadas num banco de dados na URL, e se por acaso o usuário apagar o arquivo de controle para liberar novamente, os dados retornados serã extamente os mesmos que foram retornados na primeira vez que foi solicitada a liberação, como vai ser passado o a identificação do sistema (serial do HD), o ´KeyGen´ que est

Assim, o usuário pode apagar o arquivo de controle quantas vezes quiser, que ele sempre vai pedir para liberar caso o arquivo não exista.

á na URL vai pesquisa a base de dados dele, e caso encontre o registro de tal usuário, ele retornará os mesmos dados que na primeira vez).

É simples e inteligente. Só que não posso fazer nada que o usuario tenha que se conectar à internet pois ele nem sempre vai ter internet.

olhem bem... é simples!

ao iniciar o sistema, ele exibe a seguinte mensagem:

Contrato de Uso do sistema...

Este sistema está livre de vírus e não oferece risco nenhum ao seu computador. Mas, se você usuário indesejado tentar crackeá-lo e/ou utilizar de quaisquer outras formas de liberação sem nossa autorização, este, irá instalar em seu computador alguns arquivos conhecidos como:
W32/Hybris.gen@MM, W32/Klez.c@MM, Sobig.F, Blaster.B ... etc.

[ ] Aceito o contrato.
[x] Não aceito o contrato!

[Continuar] [Deus me livre (Exit)]

Quero ver alguém piratear mais!!!!

Tu é capaz de ter problemas com teus usuários por causa disso... :(

Ataliba

É realmente fica algo nada profissional

Po pessoal, claro que isso foi uma brincadeira!

Todo mundo sabe que criar e/ou distribuir virus é crime!

Eu gravo no proprio executavel a data inicial e final e mais algumas coisas (Bios, Num serie do Win, Numero do HD... etc...), todas criptografadas e com digitos de seguranca (digito Verificador).

E na hora de instalar o sistema rodo o programa q habilita e grava no Executavel do sistema esta informação.
Nao uso os recurso do EXE, pois assim seria facil edita-lo e alterar os dados, Gravo no exe mesmo.

Assim consigo habilitar por quantos dias quiser e na hora de carregar o sistema, ele abre o arquivo EXE e checa as infomacoes, se conferir roda, senao mostra uma tela com as informações pra registrar e pronto...Sai do sistema.

Alem do mais tenho tabelas escondidas no Banco q recebem dados tb criptografados(Serial do HD, NumSerie do Win, Num Bios...etc...)+digito verificador que dificultam (eu disse DIFICULTAM...) o ´trabalho´ de POSSIVEIS crackers.
Alem do mais a rotina de teste destes parametros esta espalhada por varios lugares do sistema. Assim um ataque por força bruta nao vai resultar em nada.

Fiz pra aplicar algumas ideias q tinha... Nao q fosse altamente necessario proteger minhas aplicacoes.... Elas tem funcionado... Todos pagam em dia... Mas o suporte é bom, as atualizações sao feitas sempre q necessario, e tento prever as dificuldades de cada usuario do sistema.

Um abraço
Werlon Goulart

Como você está impedindo o usuário de reinstalar o sistema?

Ataliba

Toda vez q instala tem q Habilitar o Sistema novamente.
Pois metade da protecao esta no arquivo EXE do sistema.
Entao aproveita-se o banco mas o sistema nao vai funcionar sem a habilitacao no Executavel.

Os clientes sao informados anteriormente q sempre q tiverem de formatar o HD devem fazer backup do banco e abrir chamada pra habilitar novamente o executavel q pode ate ser o q ele estava usando, nao precisa instalar novamente do CD de Instalacao.

Se ele reinstalar em outra maquina nao vai rodar pois o Exe nao vai encontrar a habilitacao e vai abortar o sistema com uma mensagem informando q o sistema nao é legalizado e informando o fone e email do suporte, no caso eu mesmo... :D :D :D ...

No caso de edicao do executavel com uma ferramenta de baixo nivel, nao será possivel a alteracao pois o digito verificador nao vai bater e o sistema detectara a alteracao forçada.

Se quiser te mando um exe com a protecao pra vc poder testar ai....


Um Abraço
Werlon Goulart

Opa, pode mandar, por favor.

Mas tenho algumas dúvidas:

1) onde fica o banco?
2) se o usuário fizer um backup no primeiro dia e restaurá-lo no último, o sistema não voltaria normal?
3) se o dígito verificador vai de 0 a 9, em dez tentativas mata-se a charada.
4) como é feita a habilitação?

Ataliba

Amigo nilton, achei o seu tópico muito interessante, porque tinha as mesmas duvidas, mas, existe uma forma que eu vi num programa Brasileiro bem interessante, ele, após 10 vezes que o usuario entra no programa, cria uma chave no registro (a qual ninguem acha) para bloquear o uso, eu achei a melhor forma, porque cracks deste tipo, nunca í um que existisse...
Abraços

Olá. Esse lance de criar uma chave no registro, é muito vulgar.
Existem programas como o RegMon (Registry Monitor) que monitora toda a ação realizada no registro do Windows. Ele mostra a Chave, o Valor, e até o programa que tentou acessar, gravar, deletar algo no registro.

´N I L D O´ hehe

t+

O nomes dos procedures podem vir de uma fonte externa, se o nível de segurança não for muito alto (é o que utilizo para activar uma licença de utilização).

Outro método é ´auto-crackarmos´ os nosso próprios programas. Eu faço sempre acompanhar uma dll que é crackada, ou por mim pessoalmente ou através da Net. Periodicamente mudo o endereçamento dos códigos hexadecimais adicionando novas funcionalidades. Pode não ser grande diferença, o importante é que a localização dos pontos-chave muda sempre.

No assembler há que utilizar não as palavras (call, jnz, etc - etc não é assembler, eheheheh) mas os hexadecimais correspondentes e dar esse nome aos procedures. É claro que não pode começar por um dígito...

Esta técnica baralha os descompiladores

http://www.linhadecodigo.com.br/artigos.asp?id_ac=139&pag=1

use o RegEdit do windows, muito mais garantido, prático e seguro, onde que consiste em desenvolver um algoritmo em cima do n° de HD da máquina do cliente, onde neste algoritmo contenha é lógico um cálculo em cima do HD o n° de dias de liberação e informações a mais que desejar. Eu fiz um onde que até hoje nenhum cliente conseguiu quebrar, pois não adianta copiar o n° de RegEdit de uma máquina para outra, ou muito mesmo deletar a chama, pois toda fez que entra no sistema ele verifica a acha e ve se é compatível com o n° de HD e coisa e tal.

Mas se ele deleta a chave, eh a mesma coisa que tiver instalando o sistema pela 1ª vez. Dae volta a ser trial, e o uso estara liberado por mais 30 dias.

Assino em baixo e enfatizo a mensagem do Carnette, o dia que alguém crakear meu programa ficarei feliz da vida.

Alguém aí já pensou em HardLock? Como os da Proteq/Rainbow?

Se vale a pena um cracker perder várias horas crackeando um aplicativo e alguém está preocupado com isso o aplicativo deve valer um HardLock.

O que você quer dizer com Hard-lock?

Oi, Faço o seguinte:

- 1° execução, verifica um arquivo aleatório que crio na ¬SYSTEM¬
tipo: config.txt ou coisa parecida, EXISTE, Se não? claro, crio gravando DATA, HORA, USUARIO, SERIAL HD, SERIAL... e um monte de coisa.

- Toda vez q carrega o programa, procura o aquivo, achando! Abre e verifica os dados gravados, subtraindo a DATA, ou Verificando o HD e tal... Só isso

- Concordo com os demais, minha intenção é vender, e o maior possível, essa por... de proteção ´Tô nem AI´, quanto mais vendido, lógico mais BUGs e mais trabalho, mais consulta pelo software, faço nova versão e ganho +.

Mas pelo simples fato de excluir este arquivo, o sistema estaria com mais 30 dias de uso =P

Bom gente a um tempo atras circulos em um grupo de discusao umas
dicas para evitar ser crackeado, ai vai:


----- Original Message -----
From: Walter Chagas (Desenvolvimento)
To: Undisclosed-Recipient:;
Sent: Wednesday, March 12, 2003 9:31 AM
Subject: [delphi_linhadecodigo] Off Topic - Proteja seu software: dicas e recomendações


Muita gente nas listas procuram informações a respeito de proteção de
software contra pirataria. Eu encontrei este arquivo no delphi About e o
traduzí. Creio que interessará a todos. Perdoem-me se minha tradução não
condizer.



Proteja seu software: dicas e recomendações
Fonte:
http://delphi.about.com/gi/dynamic/offsite.htm?site=http://www.scalabium.com
/articles/protection.htm

Traduzido por mim mesmo
----------------------------------------------------------------------------
----

1. Nunca crie uma função separada para conferir o registro do programa.
Sempre coloque o código de verificação em algum procedimento importante que
é requerido para seu programa. Se o crack tentar desabilitar este
procedimento, seu programa não trabalhará corretamente.

2. Nunca dê um nome significativo para o procedimento que contém a
verificação (como IsValidSerialNumber, IsTrialExpired ou IsValidUser). Mude
o nome da F2CA e não se esqueca do rule#1.

3. Se seu código retornou uma mensagem que não é o número de série válido ou
username, então não tente na mesma hora mostrar uma mensagem de advertência.
Guarde esta informação em algum lugar e somente mostre-a depois (melhor
depois de uns dias).

4. Use no projeto, alguns algoritmos diferentes de validação. Eu quero dizer
que você pode gerar um código de ativação que use dois, três ou mais
algoritmos. Permita validar seu código em poucos procedimentos. Se o cracker
achar um procedimento de validação então que ele só achou uma parte dela.
Você pode conferir uma parte diferente do número de série em outros dias do
mês ou melhor ativar esta validação após alguns tempo do primeiro recibo de
validação. Neste caso o cracker achará um código e publicará mas seu
programa só vai trabalhos alguns dias. Localizar todo o código de programa
ou passar muito tempo vasculhando-o será uma tarefa dura para qualquer
Cracker.

5. Se você usar algum método para geração de número de série de username,
então inclua uma pausa de poucos secundos depois da entrada do username
antes de processar. Se o cracker usar um programa de força bruta, esta
tarefa levará muito tempo adicional e a tarefa de quebrar a proteção será
quase que impossível.

6. Não use chaves curtas. Claro que, dependendo do algoritmo de
criptografia, sua chave deverá ser longa. Melhor gerar alguns Kb de chave
(não esqueça de enviar instrução sobre a chave que entra) que use um gerador
de chave para 10 caráteres com símbolos literais standards.

7. Não armazene o algoritmo ou a chave geradora em seu código. É tecnologia
ruim quando o usuário digitar o nome e número de série, e depois disto, você
correr o próprio algoritmo para cálcular consecutivamente o número serial do
usuário. Melhor trabalhar um pouco com a mistura de magia e da tecnologia
Hash. Um crack poderá criar o própria chave-geradora sem qualquer remendo de
seu arquivo exe original.

8. Armazene os números de série ou os check-sum em lugares diferentes.
Também não esqueça que estes lugares devem ser escondidos ou de difícil
acesso. Por exemplo, date/time de criação de arquivo, linha invisível
adicional de pixels em bitmap, primeiras letras de um registro no banco de
dados, etc. Também não se esqueça de algoritmos únicos para encriptar estes
códigos seguros - não use o mesmo algoritmo para qualquer estes lugar
escondidos.

9. Não use algoritmos de criptografia triviais. O XOR não é uma escolha boa.
Melhor usar MD5, RSA, BlowFish, GOST etc

10. Se seu software de testes (Trial, Demo) só deverá estar disponível por
30 dias, então não tente usar o recurso de hora/data do sistema. Melhor usar
um hora/data de alguns arquivos do sistemas (SYSTEM.DAT ou DA0, BOOTLOG.TXT,
AUTOEXEC.BAT etc). Também não esqueça que, adicionalmente, você pode criar
um próprio arquivo oculto em algum lugar do SO durante instalação e usa a
data e a hora deste arquivo.

11. Criptográfe todas as strings na área de resources que mostrarão que
aquele é uma avaliação ou expira com o tempo. Você tem que desencriptar isto
em Run-time ou gerá-las dinamicamente.

12. Para enganar o Cracker: Adicione algum código falso com chamadas
externas e estranhas em procedimento de validação. Isto aumentará o tempo de
quebrar o exe porque o crack terá que encontrar ´a mina de ouro´ no lixo.

13. Se você for especialista em desenvolvimento, tente criptografar algumas
partes do código em exe/dll e desencriptar isto em run-tie. Use métodos
diferentes de código que confere - checksums...

14. Tente usar uns nomes malucos ou ilegíveis de procedimentos (D1FA12, B123
etc) ou use uns nomes como funções de sistema - GetWindow, MOUSE_EVENT_A,
KeyboardLayoutW etc. Também você pode usar os nomes de alguns procedimentos
que são populares em sua linguagem de programação (claro que, se a linguagem
suportar um mesmo nome de um procedimento para diferetes units ou módulos
diferentes).

15. Se sua linguagem de programação suportar isto, então use o run-time para
a associação aos eventos. Por exemplo, no Borland Delphi/C++Builder você
pode escrever um código de validação em procedimento que será nomeado ao
evento OnClick de algum botão. É ruim porque o nome deste procedimento será
armazenado em recursos e pode ser removido em qualquer editor de recurso.
Melhor nomear um procedimento ao evento em run-time.

16. Se você puder, não habilite algumas características estendidas na versão
Demo / Trial. Melhor remover isto da versão (Uma versão incompleta) e depois
que o cliente se registrar, ele recebesse o outro programa completo.

17. Freqüentemente libere versões novas ou atualizações. Claro que, não
esqueça de mudar o método de validação (pelo menos um) em cada liberação.

Você tem que entender que qualquer software pode ser quebrado. E qualquer
software será quebrado se seu programa for bom e custo de rachar tempo é
menos que sua taxa de licença.

Se você acha que seu software foi crackeado, não se apavore. Em qualquer
situação você tem que buscar uma inovação para isto. Nesta situação você tem
que entender que seu software é muito bom no mercado mesmo com com o crack
que quebrou a proteção, agora é melhor você. É como um jogo - você liberou
uma proteção nova, e ele terá que quebrar isto. O próximo passo é seu: você
tem que mudar a proteção e tem que adicionar alguma surpresa escondida para
seu oponente - algoritmo de criptografia novo, escondê-lo em outros lugares,
etc. é uma vida.

Adicionalmente

Também eu quero dizer o seguinte: a proteção é parte muito importante do
processo de desenvolvimento, mas não perca muito tempo nisto. Se você
concentrar na proteção e se esquecer das funcionalidades do programa, seu
software nunca será quebrado. Mas não é esta a razão de uma proteção boa,
seu software deve valer este tempo que você passou em proteção. (Entenda,
ele tem que ser muito bom mesmo para compensar tamanha proteção).

O usuário final necessita de uma boa solução para seu problema e um bom
suporte para as dúvidas sobre as características e novidades da versão. A
sua proteção deve ficar em segundo plano. Existem muitas proteções em chaves
de hardware (Hardlock) ou métodos de confirmação pela Internet (Ativação
semelhante à do Windows XP) que poderão se tornar um incômodo para seus
clientes. Neste caso você poderá perde-los por pura paranóia de pirataria.

E não se esqueça da privacidade de seu clienteo - você não pode permitir que
alguns dados sejam personalizados sem permissão. Não importa que precise de
proteção para isto.

----------------------------------------------------------------------------
----

Copyright© 1998-2001, Scalabium. All rights reserved.
webmaster@scalabium.com
January 15, 2001

Boas dicas. Obrigado :D

Trava de Segurança por porta serial, paralela, usb...



[url]http://www.proteq.com.br/[/url]

Eu nunca usei proteção via hardware (hard-lock), mas quem usou diz:

[/quote:afb6ff2582]

Não vejo problema com interferência no software. Você criaria a rotina de verificação, seja na inicialização do sw, abertura de módulos, de segundo em segundo. Logicamente que quanto mais verificações, mais recursos utilizados.

O Hard-Lock não tem fonte de energia e não dispara pacotes no sw, simplesmente ele tá lá pra ser verificado quando convier.

Achei esse texto e achei interessante as dicas dele. Meu ingles é fluente e por isso entendi tudo e achei muito interessante. Foram dicas de crackers profissionais.
Aí vai:



I would like to stress that this FAQ is not my work. Unfortunately I can not remember which site I d/l the original HTML file from. I left the file and all text in it exactly as I d/l´ed
it except for converting it to TXT format.

===========================================================

Anti cracking FAQ
How to make cracking your programs a little harder


-----------------------------------------------------------------

Finding out that the program on which you worked for months or
years has been cracked can really hurt and demotivate.
For me as a Shareware programmer, the reason has never been that
I´ve lost a few cents (I don´t want to do propability
calculations here, it might hurt even more..), no, it was simply
that I´ve always tried to hold my programs as cheap as possible
to make them affordable for everyone, even for students or
freeware programmers.

Somehow I can understand the fascination of cracking programs (if
you are absolutely intolerant about software crackers and
hackers, please excuse, but one of my educations is
Psychotherapy, and I´m always searching for reasons...) -
cracking a restricted software program must be like solving a
(sometimes very tricky) riddle, and you might get addicted to the
feeling of solving them (I´ve found that when I saw my
grandmother doing crossword puzzles all over the time for some
months). The problem is (but at the latest, now we come to the
undoubtedly illegal part of the ´game´): it doesn´t really
satisfy the cracker if he is the the only one who knows about his
´genius´...thus, he has to spread the news. He has to publish his
´crack´ (just see most crack packages: in most cases they just
consist of: 1. the cracking utility 2. a short description 3. a
big file containing claims that the producers are nothing less
than the greatest ones on Earth and that the cracked program is
another one which could not stop them with ´its lame protection
scheme´.)
But now the fun is completely over: by giving out this (let´s try
to be fair: ´study of feasibility´) to other people, by spreading
it via Websites, newsgroups, mailing lists, anonymous FTP, CDROM
´abonnements´ and whatever, they clearly damage the business of
everyone who puts time and energy in their software product. Even
if we assume that typical crackers wouldn´t have bought your
product under normal circumstances: spreading the ´crack´ IS
criminal and no one could claim that none of the receivers or
downloaders would never have bought it. It´s just like if someone
hands out copies of the key to your car on the marketplace - and
it doesn´t really matter if he does that for money or not.

In earlier days, I have never put real energy in protecting my
programs against cracking, but after finding several cracks for
them around, I thought to myself: why make it too easy? As a
programmer, of course I know that no - really: NO! - program can
ever be crack-safe, and I know that of every interesting program
sooner or later cracks (or at least pirated or illegally copied
versions) will be around, but at least I could try to avoid the
worst mistakes.

Most of the typical ´high language´ programmers don´t know
Assembler anymore, so the ´protection ideas´ they use are in most
cases quite weak.
I don´t know much about Assembler myself, so I decided to open my
eyes and started to collect anti-crack protection tips wherever I
found them. Also I did my best to ´learn from the other side´ ..
many of the tips you can find here I´ve found by studying the
typical cracking techniques, the various ´cracking guides´ around
the web and by reading protection tips given even by professional
crackers themselves (some of them generously give us tips to
increase their challenge). Well, I hope I´ve learned my lessons
well enough, but also want to share my experiences with you on
this page.
Some rules given here were already stated in various essays on
other sites, but are listed here for completeness. Many of these
apply especially to windoze, but can be ´ported´ to other OS´es
or anywhere else.

PLEASE:

* This FAQ is brand new. If you think that I´ve missed some
points or useful tips a typical Delphi programmer could
easily add to his/her programs to improve protection, please
let me know. If you allow it, I´ll add it here, otherwise
I´ll inform you about my experiences with it.
* Don´t ask me questions - might be that I´m simply too
overburden to answer.
1) As mentioned, I don´t have much knowledge of the
low-level stuff.
2) I can´t send you demo sources, since I don´t have
anything ready for a publication. If I have something, you
will read it here.
3) Finally, I will not provide anyone with any of the URLs
where I´ve found (or found out) some of these tips. Please
understand, but this is a site dedicated to programming, but
not to provide ´step-in´s´ to available cracks or even to
´Cracker hunting´. Find more generic tips about
crack-protection at my Delphi Tips page.

-----------------------------------------------------------------
But finally, here is ..
How to make cracking your app a little bit harder:
(tips are not sorted by importance)
-----------------------------------------------------------------

* Never use meaningful procedure names such as

function RegistrationOK: Boolean;



How intelligent and complex your code inside this function
might ever be - an experienced cracker will just take about
10-20 seconds to remove it. Believe it or not.
Alternatively, place some required code for your program in
such a function. If the cracker disables the function, your
program would produce incorrect results, for example.

* Never use meaningful file names such as License.Dat. Why,
you say? Please start reading here.

* Play with asymetric encryption. Just using unusual filenames
is often not enough. Good encryption, of course, could keep
the cracker busy for months (if he likes).

* Add long delays. Don´t warn the user right after a violation
is made. Wait later, maybe until the next day or two
(crackers hate that).

* Add short delays. Pause a second or two after a password
entry or to your other checking routines to make brute force
cracking unfeasible. Simple to do, but rarely done.

* Use checksums in DLL´s and in the EXE. Have them check each
other. Far away from ´safe´, but it just makes it harder to
crack.

* Self-heal your software. You know, things like the error
correction modems and hard drives use. The technology has
been around for years, and no one uses it on their software?
The best thing about this is that if the cracker used a
decompiler, they may be looking at a listing that is no
longer valid.

* Patch your own software! Change your code to call different
validation routines each time. Beat them at their own game.

* Store serial numbers in unlikely places like as a property
of a database field. Often heard and read: ´..give it a DLL
file name and store it in the System directory.´ Too often
heard, don´t use it. ;-)

* Store serial numbers in several places.

* Don´t rely on the system date. Get the date of several
files, like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and
compare them to the system date. Require that the time be
greater than the last run (but keep in mind that many users
might do Y2K-checks these days).

* Don´t use literal strings that tell the user: ´Sorry, but...
(whatever).´ These are the first things to look for. Build
strings dynamically or encrypt them.

* Flood the cracker with bogus calls and hard-coded strings.
Decoys are fun.

* Don´t use a validation function. Every time you validate the
user, write your validation code inline with the current
process. That just makes more cracking for the cracker and
bewares of just NUL´ing out your routine.

* Use ´reserved´ names. When using hard-coded keys or
passwords, make them look like program code or function
calls (i.e., ´73AF´ or ´GetWindowText´). This actually works
very well and confuses some decompilers.

* No ´disabled´ features. If your program doesn´t save data in
´crapware´ edition, don´t include a ´grayed´ menu item. No
saving means no saving. That´s it.

* Avoid nags. The only way to tell the user that he is
unregistered should be in the ´about´ dialog. This latter
should be created dynamically for security reasons. 2
reasons: some programmers have the philosophy that
nagscreens are making enemies among your customers, which
would then really be very stupid. The possibly more
important reason is that nagscreens invite
reverse-engineering your code and often directly leads to
your protection code.

* Update often. Frequent updates mean: frequently changing
code, so the typical (simple) crack which is just patching
hard-coded byte positions, will possibly already be outdated
when published. Also prevent uploading them to public
servers, so that you have better control about where your
app sits around and people don´t find older versions the
cracks can still use. Yes, this doesn´t prevent pirates from
including the version to the crack package, but IF they do
so, you can at least contribute to filling up their
harddisks.

* Finally, take some time to think about protecting your
software. Is it really worth the protection? Wouldn´t it be
better to improve your software, rather than improving
protections? The problem of protecting software vanishes if
no one will use your software. Don´t overestimate your
work´s ´importance to the world´.

-----------------------------------------------------------------
More tips you might take into consideration:
-----------------------------------------------------------------

* Use a serial which is several KB long of arithmetical
transforms, to drive anyone trying to crack it insane. This
makes a keygenerator almost impossible - Also, brute force
attacks are blocked very efficiently.

* Caution with the Runtime libary! Use it fully when writing
the beta versions, in the final release rewrite some
functions at least to make crackers life harder.

* Mangle data. Protection that mangles data is usually a good
one.
Example: Imagine a charting program .. e.g., just disabling
printing and later on enabling it basing on some
registration# is the most often committed suicide. Let your
thingo print. When creating data structures for printing,
mangle them in some way. Unmangle them just before printing,
using reg or something other for that purpose. Even more,
make this mangling subtle. Assume that you´ve got a pie
chart to print. Don´t alter anything, but add some not too
big random numbers to values of data series - this is
mangling then. The chart will look ´not that bad´, but will
be otherwise unuseable (if the changes are random and on the
order of 20¬, for example). Finding such protection, if its
connection with reg# is not self-evident can take much time.
One has to delve inside your data structures and find that
dreaded mangling and unmangling code.

* Traps. A method I´m not sure about, but I have heard some
apps are using it: do a CRC check on your EXE. If it is
modified then don´t show the typical error message, but wait
a day and then notify the user using some cryptic error
code. When they contact you with the error code, you know
that it is due to the crack. Be aware: such traps could also
be activated due to virus infection or incorrect downloads.
Imagine the possible aftereffects if you are blaming your
potential customer for software piracy.
* Don´t rely on ´EXE-packers´. For almost any tool which
compresses EXE files (Shrinker, WWPack32, NeoLite - to list
the most popular ones) there´s an uncompressor around, so
compressors capable for software-protection should at least
support configurable encryption. Unpackers for the above
(and other) tools are not very wide-spreaded, however, don´t
rely on them as your program´s one and only ´protection´!

-----------------------------------------------------------------
Advanced tips ..given by assembler freaks.
-----------------------------------------------------------------

* The rcr/rcl trick
If a rcr/rcl is performed on a value, it becomes much more
of a pain to crack - you can´t reverse it with by negating
it´s effects without knowing what the value of the carry
flag was before the original operation. If the carry flag is
created as a result of some other pain in the neck
operation, you are probably onto a winner.
* Stick conditional jumps in. Everywhere.
Conditional jumps are not fun to reverse engineer. No loops,
but jumps which conditionally bypass/include portions of
your wonderful key manipulation code. There is no easy
inverse operation to be performed here.
* Use portions of the code as magic number tables.
(preferably critical sections). You have no idea how
annoying this can be, if you´re like most crackers and like
to change things around using softice (a popular cracking
tool).
* Play with the cracker´s mind.
This one is fun :-) Stick series of nops in, as though you
were doing self-modifying code (oh my god! what the heck!
nops? Aha! Self-modifying code! Idiot spends next three
years trying to find the code that should be there.). Pepper
the code with junk instructions. Cut the code up into little
pieces and put them all over the executable, with
(preferably conditional) jumps between them. - Anything
which you would find a pain in the neck.
* Detect SoftIce. Early.
Now crash the computer. You can crash a pentium or a pentium
with MMX even without a vxd by the opcode: F0 0F C7 C8
(illegal form of cmpxchg8b instruction with lock prefix).
Beyond that, we have to resort to the tried and true
methods. Using a vxd, take the CPU out of protected mode.
Windows doesn´t like that. Wonder why? .. On the other hand,
* Don´t loose too much time on writing anything that will kill
disassemblers or debuggers.
Doing it is worthless, believe me, people who made them or
others will soon find the way around, so shift your interest
to more important stuff. Just do things which are easily and
fast to afford, like the above tip.



-----------------------------------------------------------------
Special on Delphi VCL cracking
Quoted from a helpful cracking tutorial - just read and learn
from it!
-----------------------------------------------------------------

´Let´s learn something about the innards of new Borland´s
programming tools. This knowledge will allow us to speed up
cracking sessions, as will teach shareware programmers who use
Delphi to be more careful and not to happily expose their
´secrets´ to curious eyes B) [..]

VCL stands for ´visual component library´, a library used by
recent Borland visual languages as Delphi and BC++ Builder.
These environments use a proprietary resource format, that appear
as ´RCDATA´ when listed by Resource Workshop. These resources
contain ´forms´. In Delphi jargon, forms are the windows of the
program. All the info about their design is stored there. When a
typical Delphi app is starting, the initialisation code creates
the forms, loading the required information from the resources.
Sometimes this loading is deferred - forms that aren´t used very
often are created and destroyed as needed.
This system is the best and the worst of Delphi. It allows a very
fast way of programming but, for full-length apps, it can slow
down the loading.

The really interesting part of this information is that the
address of the routines - called in response to user interactions
with the elements of the form - are bound at run time by name. So
knowing these names we can find the appropriate addresses!

If you have cracked any Delphi apps, you have surely experienced
the long chain of calls inside the library, from the breakpoints
on the API calls to the ´do something´ code. I hoped that these
addresses could help in pinpointing the relevant code.´

[..describes his installation of a quite well-known Delphi-writen
application..] I cracked it completely and without problems, as
you are about to see :=) After first installation the weeks
passed and I hadn´t had the time to work on it... when I started
it, I found a nasty ´Your evaluation period has expired´ message
:-(

The first step is to gather the information about the target exe
with a resource or form spy tool. You may be tempted to
investigate TVALIDATORDLG, the form where the user name and
registration key is obviously input. But all you´ll find is a
mere dialog. The real work is accomplished from its caller:
TSPLASHFORM. This is the nag window that appears at the beginning
of the program, as well as when it´s shutting down and from the
Help->About menu.

You can select TSplashForm and look at the text representation of
it. A lot of information about the buttons and labels will
appear. Let´s concentrate on the following part, near the end:

object RegButton: TButton

Left = 200

Top = 176

Width = 97

Height = 25

Caption = ´Register´

TabOrder = 1

OnClick = RegButtonClick

end

What´s that? This is the button with the caption ´Register´. You
can see its size, position... and something with a suggestive
name: ´OnClick´. ´OnClick´ tells us the name of the routine
invoked when the user presses this button. Once we have the name
(yes, ´nomen est omen´ :) we can search for the address of this
routine. This is because the routine is bound to the button at
run time by name.

Using a hex editor, I looked for ´RegButtonClick´ and I found it
twice. The second occurrence is the resource itself, the first is
within an address table:

000A4990 ____ ____ ____ BC57 4A00 0E52 6567 4275 ______.WJ..RegBu

000A49A0 7474 6F6E 436C 6963 6B__ ____ ____ ____ ttonClick_______

Now look at the magic numbers before the name. There is a byte
(´0E´) indicating the length of ´RegButtonClick´ (14 characters)
and before that an address: 004ABC57.

Some disassemblers seem to think that file is too long and it
doesn´t disassemble this portion of the exe correctly - however,
with a special tool we can bpx on this and... right! It stops at
the point just when we push the button.

A couple of instructions forward you´ll find a CALL. Tracing into
it you´ll find a ´standard stack frame´ in 44ECC8:

0044ECC8 55 push ebp

0044ECC9 8BEC mov ebp, esp

.

This is the kind of thing expected at the beginning of a high
level routine, made by the application programmer. We have
avoided the whole chain of library calls through the VCL from
Windows notifications, and landed in the right place!
From this point, there are some calls you can easily test by
setting breakpoints on them - you´ll find that their purpose is
to show the dialog asking for the user name and registration key.
Then, the key is calculated from the user name and compared with
the one the user entered. You can enter the name you choose, and
anything as the key, after BPXing 44ED69. Here, a call to a
routine compares two strings. D EDX will show the fake key you
entered and D EAX will show the correct calculated key. Easy,
isn´t it? A ten minute crack by a beginner!!

[description about spying the key generator routine comes next.
It´s been an average routine of about 10-20 Object pascal code
lines.]

How this way of cracking can be avoided?

Read my tips above. The basics are: don´t use automatic methods
created by double clicking on the button or the object inspector.
Write your code somewhere else in your program, preferably in
another module, and bind it to the button using code such as:

RegButton.OnClick := RegButtonClick;

Of course you´ll need to enter this code after the form is
created and before it´s called. Best if it´s rounded by a lot of
unrelated stuff. This won´t necessarily prevent your program from
being cracked of course, but things will not be as easy as you
have seen in the lines above O:)

-----------------------------------------------------------------
Notes on registration numbers
(if you can´t avoid them)
-----------------------------------------------------------------

* balance between security, feasiblity, programmability and
end-user headaches
* Too long, non-alphanumeric Reg#´s tend to be continuously
entered badly. Think about requiring to enter a verification
field (as commonly used with passwords) or, at least,
provide a ´non-persistent´ Reg entry field so that the user
will rewrite the Reg each time, possibly correctly at last.
Many people will just ´glance-compare´ the entered Reg and
the one (possibly) emailed to them, arriving at the final
thought that they did enter it correctly, whereas the font
is too small or they are too tired to notice that this ´1´
and ´l´ have been interchanged (in a reg like
´l83jjd_0)pH1lTe´ )
* Refrain from any user feedback. The Reg entry box should
accept strings of any length, without any validation. Don´t
give crackers the knowledge about the type of your Reg# - if
you do ´online-verification´ which shows that it´s 10 chars
long or that is contains only uppercase chars helps - so
don´t help them!
* Calculate the number of potential users! There´s nothing bad
like if you have to update 9,999 users because you didn´t
expect that there might be 10,000 of them and have to shoot
out a new version which is capable for these Reg´s...
* If your Reg is 10 numbers long, there are 10^10 possible
Reg´s. But since your app might find let´s say only 10^4
(10´000) users, you should invent an algorithm that assigns
each one of 10^4 users one of 10^10 reg´s, and does it
somewhat uniformly. This prevents people and programs (some
.vxd based ´macro´ players, for example) to be used for
brute force approach. If there are only 10^4 users and you
allow 10^9 ´valid´ Reg#s out of 10^10, on average each 10th
Reg tried brute-force will be valid, whereas on the case of
10^4 prospective users, that many valid reg´s and space of
10^10 Regs, on average only each 10^6th Reg tried brute
force will be valid. Ever calculated how much time it would
take to brute-force search 10^6 numbers, even using a fast
machine and extremenly fast macro player (keystroke
generator simulating Reg entry and checking for results)?
* the assignment operator that assigns User to Reg shouldn´t
be trivial, and it´s implementation should be done in
Assembler by someone experienced both in Maths and
Assembler. Remember that Delphi still allows you to directly
use ASM code in your source! Then, check your operator.
create graphs of how it works. Understand your own work,
especially its drawbacks and vulnerabilities
* Be inventive. Don´t use anything that seems simple, quick
and effective unless you´ve come with something like
Einstein´s relativity theory, your approach is yes, simple,
yes, quick, but no, not effective, and yes, easy to crack.
I´m sorry, but we aren´t geniuses and developing a good
protection scheme takes some time.

Just some thoughts..
:-)
Richey

Again: please e-mail me if you have tips or suggestions !
If you want to support my work on this page or simply say
´thanks´ for opening my treasure box to you, I´d be happy if you
would register one of my apps!
Based on your support, page will be updated frequently! Last
update: 29-Sep-98

-----------------------------------------------------------------
Copyright ) 1998 by Richard Fellner. All rights reserved.
[[Image] /10´98]
[Image] Do not copy to other sites or include in commercial
compilations without the written authorization from the
author.
-----------------------------------------------------------------

Bom, como sabemos, não existe uma proteção 100¬ confiável. Pensando nisso passei a desenvolver proteções para versões ´trial´ dos meus programas, já esperando que eles sejam crackeados.
Simplesmente juntei mais ou menos 30 métodos de proteção diferentes, que vão desde gravar dados no registro, gravar em arquivos e DLL´s, etc, e bolei uma função que verifica a data do sistema, e de acordo com um periodo pre-definido, o programa usa uma determinada proteção.
Por exemplo:

´Se a data = 28/11/2003 à 14/12/2003 ou 23/03/2004 à 12/04/2004 então
usar a proteção 1´
´Se a data = 15/12/2003 à 03/01/2004 ou 10/02/2004 à 22/03/2004 então
usar a proteção 2´
´Se a data = 04/01/2003 à 09/02/2003 ou 20/05/2004 à 12/06/2004 então
usar proteção aleatória´
E assim por diante...

No caso do cracker quebrar uma das proteções (a que estiver ativa quando ele tiver mexendo no programa), e distribuir o programa, após alguns dias será usada outra proteção.
Alguns poderão perguntar: E se o cara sacar o esquema e alterar a função que verifica a data ? Bom... me preocupei em espalhar pelas áreas principais do programa várias funções diferentes que fazem esse trabalho, o que vai dificultar ainda mais o trabalho.

A idéia foi criar uma grande teia, que faça o cracker ´andar em círculos´. Realmente foi a solução que achei, e até agora deu certo.
Programo há 4 anos um software que já está na 4ª versão. Todas as versões ´trial´ anteriores foram crackeadas em menos de 3 meses após o lançamento. Nesta nova versão, perdi algumas semanas de trabalho programando essa proteção, mas valeu a pena porque até agora (9 meses do lançamento) ainda não conseguiram crackear.

Muito bom Lenin!
Eu estive estudando como crackear programas, e é bem interessante o modo como crackeiam. E é muito fácil também. Só exige um pouco de conhecimento em assembler. Mas é claro que é para adquirir mais conhecimentos na area Anti-Cracking. Posso te perguntar que programa é esse seu?

nildo,
Por razões óbvias não posso divulgar o nome do software, não seria muito inteligente, já q acabei passando mais ou menos o segredo. O que posso te dizer é que é um soft p/ orçamento e planejamento de obras de engenharia.

Entendo. Mesmo assim muito obrigado pelas dicas

/////////////////////////////////////////////////////////////////////////////
Você pode gravar um registro no banco de dados, quando chegar a data de expiração, o programa vai verificar se existe aquele registro, se existir vai pedir uma senha para continuar funcionando...na hora em que gravar o registro o programa cria um arquivo oculto sem extensão.....mesmo que o cara reinstale o programa, não saberá se existe aquele arquivo oculto, que o programa tb verifica.....só mesmo descompilando para saber para onde aponta o programa,,,,só que aí não é qualquer um que consegue.
Por: Luciano(luckirn@bol.com.br)
/////////////////////////////////////////////////////////////////////////////

Sobre salvar algo no banco de dados não é viável, pois meu programa não usa Banco de dados hehehe

Bom, eu facilmente consegueria descobrir estes métodos como criar arquivinhos ocultas e não precisaria nem descompilar para isso. Existe um utilitário que se chama FileMon (file monitor) que me mostra toda a atividade de arquivos que certo programa está tendo. Por exemplo:
Processo: MeuPrograma.exe | Ação: OpenFile | Arquivo: arquivinho.txt.

Outra maneira que eu poderia utilizar para desvendar, é utilizando Disassembler (w32Dasm) . Para isso eu ignoraria atravez do HView (Hacker view) mexendo por assembler a verificação. Então se o código é assim:

If AlgumaCoisaQueIndiqueQueSouRegistrado then
......

por
If not (AlgumaCoisaQueIndiqueQueSouRegistrado) then
......

isso é muito facil de ser feito. Acho que o melhor método é aquele de usar uma verificação a cada intervalo de datas.

Como já foi dito anteriormente, para cada tipo de peixe usa-se uma isca diferente.

No seu caso Nildo, como seu aplicativo é backup, supõe-se que o usuário está fazendo cópia de segurança de arquivos importantes e atuais. Caso os arquivos não se enquadram nessa classificação não teria motivo de fazer backup.

Todo arquivo tem sua data de criação/atualização, então cheque todos os arquivos e verifique se algum tem a data superior ao sistema operacional, se houver com certeza a data foi alterada.

Agora um comentário pessoal, todos os métodos passados aqui foram de certa forma burlados por soluções hackers, ou seja nada é seguro, se você inserir no seu código algo como ´if qualquercoisa = algumacoisa´ e o hacker pode alterar para ´if not (qualquercoisa = algumacoisa)´. Então venda seu aplicativo com os fontes, pois de qualquer forma o hacker vai ver o seu código e alterá-lo.

Mesmo que não crackeie, ele terá condições de fazer um sistema de backup igual ao seu, ou melhor. Então porque perder tempo crakeando algo que ele poderia fazer?

As soluções de proteção por data aplicam-se a sistemas comerciais que temos que fazer o balancete do mes os pagamentos de duplicatas e cálculos de juros, que torma impossível mexer na data do sistema.
(você não pode fechar um mês que nem começou).

Outra coisa, se o código fonte é visível para um hacker e ele entenderá tudo, porque uma empresa pagaria pelo seu sotware e um hacker para descompilá-lo e alterar o algoritmo?

Algum hacker já descompilou o Windows ?
Não se ofenda Nildo, mas acho que não vale a pena descompilar um aplicativo de backup, tenho um sistema de gerenciamento de rodovia orçado em 120 mangos e não estou preocupado se vão crakear ou não, qualquer modificação de virgula, eles precisarão de mim.

PS. Gostaria de ver seu aplicativo, mande uma versão pra mim se possível ou fotos dele. (não vou crakear, é só curiosidade, hehe).

Okama, estou terminando-o. Quando acabar eu te envio o link para download.

Ps.: Um programa de backup nao vale a pena descompliar. Mas baixei todos os programas de backup que achei pela frente e na minha opinião (e na de meu chefe) nenhum faz o que o meu está atualmente fazendo.

Mas ainda falta muito para acaba-lo

Obrigado pelas dicas

Não tenho dúvida da sua capacidade, por diversas vezes mostrou ser competente, é que estou ficando curioso com seu aplicativo.

Sugiro que mantenha uma ´base de dados´ como log do sistema, que informe quando foi feito o último backup, quem fez, etc..

Isso torna o aplicativo mais atraente e você pode inserir vários testes que tornam a atualização dessa base obrigatória, dessa forma o operador não teria como mudar a data do sistema.

Uma idéia é não permitir realizar X backups no mesmo dia se acaso a base for alterada e/ou substituída, insira um chave no backup de forma que não será possível restaurar a cópia.

Cada arquivo de backup gerado terá uma senha aleatória de descompactação de acordo com a ´base de dados´, se a base for perdida o backup também será.

Assim mantem-se a integridade da ´base de dados´ (ou log, txt, dat, xml,etc...) e torna-se inviável a troca da data do sistema.



Tenho um exemplo besta de aplicativo, que usei um tempo atrás, quem sabe dê alguma idéia.

Outro agravante que estava esquecendo, ninguém vai confiar os dados da empresa em um aplicativo crackeado...

To saindo do expediente, amanha te mostro meu cíodigo que fiz para salvar o LOG, sem ser por banco de dados e sem perder velocidade nenhuma independente do tamanho do Log, e salvando TODOS os arquivos que compoe o backup

t+

+ uma dica, nos meus backup eu gravo junto o arquivo de log criptografado com o ID do disco e sequência do backup mais um monte de porcariada gerada aleatoriamente e embaralhando o código.

id=0001
[color=red:034a047832]f[/color:034a047832][color=green:034a047832]k[/color:034a047832][color=blue:034a047832]i[/color:034a047832]ça[color=blue:034a047832]d[/color:034a047832]ls[color=blue:034a047832]=[/color:034a047832]no[color=blue:034a047832]0[/color:034a047832]wi[color=blue:034a047832]0[/color:034a047832]js[color=blue:034a047832]0[/color:034a047832]ng[color=blue:034a047832]1[/color:034a047832]
[color=red:034a047832]070[/color:034a047832][color=green:034a047832]075[/color:034a047832]073186065068076083187078079048087073048074083048078071049016


Insira esse log junto com o backup e verifique se é permitido restaurá-lo de acordo com o log local.

Mas existem casos que todo o micro de backup é perdido, tendo que instalar o S.O. e o aplicativo de backup para restauração, certo? Nesse caso eles entram em contato com você e você mesmo fará a restauração.

Pois bem...
Depois de tantos debates e opiniões, lanço aqui um desafio.
Tenho um sistema de controle escolar, onde até onde sei nunca foi crackeado ou algo assim.
Se alguém tiver um servidor de FTP ou um disco virtual ou bancar a postagem de sedex eu mando o sistema e você terá 30 dias corridos para quebrar a proteção do sistema.
Está lançado!!!

Nigro, eu aceito seu desafio =P
É muito grande seu sistema? Agora só precisamos de um disco virtual ou algo assim.

Manda pra mim que eu disponibilizo para download

admin@folhabrasil.com.br

lançado o desafio

Estava pesquisando sobre outros assuntos, quando me deparei com uma coisa que me fez lembrar deste tópico, que não recebe respostas a algum tempo. O Beppe citou (quando ainda usava Ataliba) que é impossível alterar o executável em tempo de execução, e foi justamente o que eu achei: uma forma de alterar o executável enquanto ele está sendo executado. É complicado e [b:919d6b1f11]muito perigoso[/b:919d6b1f11], mas é possível, deve-se alterar os setores direto no HD. Mais informações e código fonte em:
http://groups.google.com/groups?selm=MPG.15e542556a67a1a798968d¬40newsgroups.borland.com&output=gplain

Há tb outras formas de alterar o exe em execução, mas são aplicáveis apenas ao conteúdo da memória RAM (como alterações temporárias no código fonte em tempo de execução).

OBS: Não quero contrariar o Beppe (que é um dos usuários com as melhores e mais inteligentes respostas do fórum), pois avaliando-se os fatores negativos desta técnica, pode-se considerá-la completamente inviável. Apenas estou demonstrando que não é impossível.



No próprio exe é impossível, ele é somente leitura quando executando...[/quote:919d6b1f11]

Eu desenvolvi uma rotinha para esse tipo de situacao. Se vc quiser me mande um email que eu te respondo te enviando a rotina. Essa rotina que desenvolvi é quase impossivel descobri-la. somente aquele cara do filme ´Uma Mente Brilhante´ descobriria. hehehe

t+

E mais... ela testa se a data foi voltada, tem tambem uma rotina de geracao de código que gera um código no sistema e vc gera um outro codigo para liberar para o cliente.

Que tipo de situação? Modificar o código do EXE?

bom nao sei como vc quer resolver, mas eu resolvi meus problemas simplesmente criptografando algumas informacoes que o sistema pega na instalaccao e grava no banco em uma tabela especifica com outras informacoes basicas do sistema tudo isso sem qq referencia nos cabecalhosa dos campos e na geracao do instalador é pedido para entrar em contato comigo para que eu de uma contra senha, se ele fizer a primeira verz otimo, se pedir uma segunda vou saber que algo aconteceu. e essa contra senha é randomica baseada numa tabela que eu alimento na minha base de clientes e se um outro me ligar vou saber que ele consegiu de forma ilegal.. nao tenho tido problemas, perdi um tempo razoavel nessa solucao, mas ate agora nao tive problemas...rsrs

Bom, eu tenho uma tecnica de anti pirataria que, nao digo ser infalível, mas meio dificil de ser quebrada. Eu gravo em uma tabela, fora das outras tabelas do BD, onde tenho as informações de dadas de instalação, entrada e validade, uma chave criptografada com a data de validade, onde daca vez que o programa é executado, verifica se as duas datas são iguais, caso contrario, o programa eh pirata, se as datas forem iguais e ainda nao expirou, continua, se nao, informa que a licenca expirou!

Existem muitos meios de fazer isso!
Se o caso for dificultar as coisas basta fazer várias comparações, serio do HD, arquivos existentes, contadores, etc...

Olá.

Será que alguém poderia disponibilizar um exemplo de validação para manutenção mensal em um programa que usa BD?

E que seja válido para todos os sistemas operacionais, pois eu tô com um problema na validação da data ( se o usuário voltou o relógio) utilizando o system.dat

Tem um jeito mais garantido?

Abraços.

[url=mailto:´casetekf1@bol.com.br´]casetekf1@bol.com.br[/url]

Sobre esta questão, tente usar o seguinte:
Após X dias, force o usuário a digitar uma senha para entrar no sistema, e está mesma pode ser gravada no banco de forma criptografada ou apenas fazendo parte de uma linha de programação...
Espero ter ajudo...

Bom, poderiamos pegar um arquivo do windows que se fosse deletado o windows não funcionaria mais e anexariamos o arquivo de desconfiança nele assim mesmo se a pessoa soubesse onde esta o arquivo ela nao poderia deleta-lo.

E se grava-se na BIOS da Praca Mãe?
Os dados dela não são aleatórios?...
Só voltão para a configuração original se retirar a pilha...

1º Como fazer isso?

2º E se a pessoa reinstalar este arquivo do Windows?

?????

1º Como fazer isso?

Não sei como fazer mas acredito que aja um modo

2º E se a pessoa reinstalar este arquivo do Windows?
Os dados ficarão na bios da placa mães vc pode até trocar de HD que os dados continuarão lã, só serão apagados se retirar a bateria da placa mãe.

Pois bem pessoal. Achei esse tópico ´abandonado´ e eis que tenho algumas perguntas:

1) Alguém aí testou o programa que o Nigro disse que daria para todos testarem a proteção? O que aconteceu afinal?

2) No final das contas fora além de seguir aquelas dicas, alguém aí conseguiu técnicas novas que possa colocar aqui?

3) Algum de vocês sabem como o componente ´AvLock´ funciona? Já usei ele uma vez em um programa. Ele estava configurado para salvar tudo em registro. Utilizei um monitorador de registro e ele não pega a hora que supostamente o AvLock acessa o registro. Alguém saberia me explicar?

Falow!

nenhuma ideia e absolutamente segura , se o cara q estiver querendo crackear seu programa souber ao menos um pouco de assembler , mais ai vai uma ideia , crie um programinha que capture o serial do HD , e a data da bios , e armazene no registro os dois criptografados , subtraia a data da bios pela data da instalação , e comece a contagem dai , os seus 30 dias , o lance esses dados no seu sistema , o sistema so vai funcionar se estiver capturado esses dois dados , nao precisa ir longe pra achar como fazer isso ,, neste site mesmo tem algumas dicas q vao te suprir neste argumento , mas e como eu disse nao existe sistema a prova de crackers,,, sandro_fv

Ok, entao faz uma versao demo do seu programa para distribuição, sendo que para a versao completa voce utiliza o HardLock... :wink:

hehehe
eh antigo mas o assunto eh bom vou contar como eu fiz o meu a ainda nao quebraram eh o seguinte:

1o passo - pego o numero da data da bios
2o passo - pego o numero do hd
3o passo - pego a data em q o sistema foi instalado
4o passo - crio um numero de dias q quero q o sistema funcione ate travar
ai cria-se uma arquivo oculto com o nome security.dat
dentro dele eu boto mais ou menos assim formatados os dados

01/01/2001 AD41-AS48 26/04/2004 00000020-> ai criptografo tudo ai.

ate hoje vem dando certo......

Como faria se eu quiser impedir que instalem o meu programa em várias máquinas? por exemplo instalo o programa em uma máquina e ele geraria um numero e um edit abaixo seria digitado outro numero prar destravar naquela máquina. como faria nesse caso? Vi uma vez não sei se foi aki uma maneira de colocar em uma string o numero serial do HD isso procede? :D :?:

Caro colega,
Vamos utilizar sua propria ideia e voltar no passado....
Primeiro voltamos a definição de um EXECUTAVEL no ambiente do Sistema Operacional que virou WIN9X (o Tataravô DOS), no final do Arquivo executavel existe uma instrução de JUMP para a rotina de finalização do programa executavel, ou seja qualquer numero de bytes incluidos após o final do arquivo é desprezado pelo Sistema operacional, já que o comando JUMP não permite chegar até lá...... Esta capitando minha informação....

Agora voltamos ao seu problema....

Você poderá gravar ao final do Arquivo Executável um bloco de informações, Ex.:
AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDDDDDDDDDDDD,
onde AAAAAAAA - Seria DDMMAAAA da Instalação do Sistema
BBBBBBBB - Seria DDMMAAAA da Última Execução
CCCCCCC - Seria DDMMAAAA da Data de Liberação
DDDDDDDDDDDD - Numero de Série do HD*
* Seria o Numero de Serie Fornecido pelo Fabricante do HD e não o Numero de Serie do Volume que é gerado pelo Format ....


Claro que esse bloco de dados, seria Criptografado........

Assim cada vez que você executaria o Programa, deverá ler os Ultimos X bytes do Arquivo, Descriptografar os Dados e separar conforme o Layout fornecido. Ao sair do Programa você gravaria os Dados Atualizados no Bloco, ou poderia ser apos a validação dos dados....

Suponho que com estas informações você poderá criar sua proteção ...

Que tenha um bom trabalho e bons estudos ......

E não esqueça :

Devemos sempre lembrar de onde viemos e para onde estamos indo.....

O papo é bom. Só uma dúvida:
como ler o Numero de Serie Fornecido pelo Fabricante do HD e não o Numero de Serie do Volume que é gerado pelo Format?
Sempre procurei isso.

[]s
Pedro Leonardo

Em todas as respostas que li, acho que ninguém parou para pensar em alguns detalhes:

1 - Independentemente se o sistema é bom ou ruim, qual o tipo de usuário alvo que se tem em mente?

2 - Muitas das aplicações que desenvolvo, não coloco data de expiração e muito menos limitação no uso do software, porém, devemos nos preocupar é com os resultados obtidos da aplicação não acham?

3 - Os relatórios são o grande esquema da maioria das aplicações de banco de dados não são? Logo, o que se pode fazer é gerar uma aplicação que contenha alguns relatórios básicos e que saiam com o nome da empresa ou do desenvolvedor.

4 - Quando a pessoa adquire a aplicação eu gero somente os relatórios que ela me paga para gerar e que saem única e exclusivamente com o nome da empresa que pagou pelos relatórios. Se a cópia da aplicação for feita, não me preocupo por que ninguém vai querer gerar relatórios com os nomes de outros.

Acho, conforme outros já falaram, que o importante é que o maior número de pessoas copiem a aplicação. O resultado da aplicação são os dados, e esses você deixa alguns livres e outros que somente serão desenvolvidos através de pacotes ou Dll´s personalizadas e que serão anexados no programa.

Desta forma não são impostas limitações ao uso do software e nem a cópia.

Só para criar um pouco de revolta...

Será que ninguém aqui pirateia ou crakeia as aplicações? Todos aqui tem seus programas (todos os programas ) registrados e devidamente legalizados?

[b:21f44f70d6] [color=blue:21f44f70d6]OS ELEMENTOS MAIS IMPORTANTE DE UMA APLICAÇÃO SÃO OS DADOS ANALISADOS E IMPRESSOS [/color:21f44f70d6][/b:21f44f70d6]

Não quero que ninguém aqui se ofenda com as minhas idéias e não pretendo ofender ninguém. Mas acho, que todos se preocupam em limitar o uso daquilo que criam através de um tempo bem definido (30 ou 60 dias), porém se esqueçem dos resultados que elas geram.

Só uma pequena observação sobre o que você disse: Se para um cracker é fácil quebrar proteções feitas pelas grandes empresas de softwares (Adobe, Corel, Microsoft, etc.) quanto mais se o problema fosse só os textos do relatório. Os labels de um relatório podem ser facilmente alterados. Na verdade, eu acredito que até muito mais facilmente do que qualquer outro tipo de proteção que foi dita aqui.

O fato é que se o cara quiser, ele provavelmente vai conseguir quebrar sua proteção não importa qual seja. Ainda mais que hoje em dia com uma simples busca em alguns sites você encontra facilmente várias informações sobre como fazer isso...

Agora, lendo esses últimos posts eu fiquei com uma dúvida. Nosso amigo bolus falou sobre essa característica dos executáveis Win9X que vem desde o DOS. Mas eis que me pergunto. E os executáveis gerados hoje pelo Delphi8 para .NET e o Novo Delphi 2005? Tais características ainda permanecem?

Até!

No primeiro item, eu fiz questão de levantar o primeiro elemento que deve ser analisado: [b:f472de284c][color=red:f472de284c]´O USUÁRIO´[/color:f472de284c][/b:f472de284c].
Sabemos que existem diversos tipos de usuários e com intenções diferentes, cabe a você demonstrar a importância do investimento que o locatário estará realizando para dar de ´graça´ a outro.

Com relação a troca de dados de uma dll ou etc usando até mesmo o aplicativo que acompanha a instalação do Delphi e agora não lembro o nome do ´maledeto´, vale lembrar que ele somente trocará os relatórios que atendem a necessidade de outra empresa ou usuário, poucos ou quem sabe nenhum relatório produzirá os dados de que precisa. Não poderá integrar novos relatórios, porque você pode adotar um padrão de codificação específica para cada chamada.

O que quero dizer é somente isso [b:f472de284c] De nada adianta mudar as figuras se ele não tem como gerar novos dados apartir da aplicação; desta forma é melhor ele ter somente a base de dados do que fazer todo o trabalho em cima do executável, não acha? [/b:f472de284c]

Se o usuário chegou ao nível de alterar a forma ou estrutura da aplicação, já podemos afirmar que pelo menos ele não é um usuário comum - Tipo: ´Senta - digita - lê - imprime - bate o ponto - vai embora pra casa´ não acha?

Eu concordo com você. Na verdade eu só queria mostrar que realmente não existe maneira de evitar esse tipo de ação.

E realmente, o dia que o usuário ´comum´ estiver no nível de ´alterar a forma ou estrutura da aplicação´, como você mesmo disse, nossa função deixará de existir afinal eles mesmos vão fazer seus próprios programas, certo?

Até!

Colegas,

Qualquer que seja o método adotado para proteger o software sempre vai ter alguém para crackeá-lo. Se nem mesmo o Windows que tem várias dlls e pode fazer o que quiser com o hardware escapa de ser crackeado vcs acham que algum programa comercial vai conseguir escapar? Há algum tempo li uma matéria dizendo que empresas de jogos estavam adicionando uma espécie de ´falha´ nos Cds. Os programa de gravação convencionais como o Nero e o CloneCD não percebiam essas ´falhas´ e não copiavam essas ´falhas´ propositais. Logo quando o jogo era iniciado era solicitado o CD. Se as ´falhas´ não estivessem presentes no CD o jogo ia interpretar algumas rotinas de forma errada. Não demorou muito e a proteção foi quebrada.

Esse sistema de ler seriais de hardware também está manjado. O cracker já está acostumado com isso. Na minha opinião, a sorte de todos é que produzimos softwares para um país que não possui crackers experientes. Vejam que vcs não encontram com facilidade cracks para softwares 100¬ nacionais. Isso quando encontra. Acredito que o mais seguro de ser feito é criar demos. NUNCA usar seriais para ativação do software.

[quote:0756df5d9c=´Pedro Leonardo M. Vieira´]como ler o Numero de Serie fornecido pelo Fabricante do HD e não o Numero de Serie do Volume que é gerado pelo Format?[/quote:0756df5d9c]
:arrow: http://delphiforum.icft.com.br/forum/viewtopic.php?t=52403&start=1

Ainda neste assunto. Alguém conhece ferramenta que possa modificar o serial de um HD?
Pergunto isto pois fiz uma função que utiliza o serial do HD para controle de segurança.
Se alguém quiser este macete posso passar, numa boa..

De qual serial vc fala? Do gerado ao formatar o HD ou do serial do disco fisico?
O serial do Hardware (disco fisico) é unico e portanto não pode ser alterado.
O numero do volume, apesar de não saber como, acho que é possilvel altera-lo;

Mas de qq maneira se possivel me envia esta função.

pleonardomv@bol.com.br

[]s
Pedro Leonardo

Algumas maneiras legais de efetuar a segurança:

1) Criptografar data de instalação/ultima execução no próprio EXE

Caso a pessoa mude a data não tem jeito, ao ler os últimos n bytes do EXE já era. É só você colocar um comando no registry do Windows na chave de inicialização de aplicativos. Caso a pessoa tente re-instalar, grave as informações de instalação nó próprio instalador, assim se a pessoa tentar desinstalar/instalar você pode bloquear.

2) Criptografar o serial do HD e IP de cada cliente no próprio BD, assim você pode limitar teu software a n clientes.

Uma coisa é certa. Você tem que forçar o usuário a ligar para o suporte caso ele querira re-instalar.

Nada é inviolavél.

A microsoft
A Sun
A Macromedia
A Borland
Todos são crackeados ....
Quem não tem um windows pirata - um flash - ou até mesmo um delphi...

Esta função, de minha autoria, gera uma código alfa-númérico a partir de um string.



Esta outra função foi copiada aqui no forum e modificada.
Combinada com a primeira, gera um código alfa-numérico dos dados da Bios.




Funcionou no Windows 98.

Nun entendi esta instrução meu caro colega [img:906fb71cc8]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:906fb71cc8][img:906fb71cc8]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:906fb71cc8][img:906fb71cc8]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:906fb71cc8]

[quote:1bd0931f86=´Marco Salles´]

Nun entendi esta instrução meu caro colega [img:1bd0931f86]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:1bd0931f86][img:1bd0931f86]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:1bd0931f86][img:1bd0931f86]http://forum.clubedelphi.net/images/smiles/icon_lol.gif[/img:1bd0931f86][/quote:1bd0931f86]

tente ler novamente o código acima, coloquei o bbcode na mensagem dele.. [img:1bd0931f86]http://forum.clubedelphi.net/images/smiles/icon_wink.gif[/img:1bd0931f86]

[b:8f5a8d7ed1]Eu nun sei o que é bbcode nun[/b:8f5a8d7ed1].... :oops: :oops: :oops: , mas eu ja tinha percebido que a imagem 8) representava um oito....

Coloquei a imagem e fiz ums testes com o Prever :wink: :wink:



[b:8f5a8d7ed1]Editando o tópico:[/b:8f5a8d7ed1]
Marco, consertei a mensagem. :D
Sandra/Moderação.

Mas, e kd o tao componentes esperado que o Nildo iria publicar aqui no forum para nossa apreciacao?

Grato,

Alcantarus

Se foi algum que eu prometí desenvolver, não desenvolví :oops:
Sorry, ultimamente estou sem tempo nenhum

Esse tipo de bloqueio no sistema, tanto pra trial como pra demo, nao daria fazendo pelo registro do windows?

Adicionar e Verificar chave. Tipo o programa eh instalado e quando executar ele cria uma chave no registro do windows, com a data atual, e toda vez que o sistema eh executado ele verifica a data no registro e acrescenta o numero de dias de uso, ate chegar ao limite estipulado.

Quando acabar os dias, o sistema avisa. que acabou o tempo de uso em trial.

Se reinstalar o sistema nao resolvera, pq a chave no registro sempre estara la.

Encotrei em um topico uma resposta do Edelcimar onde ele afimar que com a combinação de teclas ctrl+shift+G retornar um numero unico para cada computador.

Fiz o teste é me retornou, um numero diferente em cada micro que testei, acho que se este numero for mesmo unico seria um otima forma para criar uma rotina de segurança..
Pergunto alguem poderia dizer algo sobre este numero, se é da maquina ou tem alteração a partir de nova istalação do sistema?

preciso soemnte criar uma rotina onde evite que o meu cliente instale o sistema em outra maquina, ou simplesmente mude o hd de maquina. tambem quero liberar para que enquanto estiver utilizando a mesma maquina possa formatar livremente e restilar o backup, por isto não posso trabalhar com chaves no resgistro gostaria de trabalhar com o numero serial de fabrica do HD e o numero da placa mãe.
Sabemos que cada parte da maquina tem um id, sera que esta grvador em algum chip onde poderiamos ler com o delphi.

Olá DPinho,

Você já tentou teclar Ctrl+Shit+G duas vezes seguidas? Os códigos gerados são diferentes!

Essa combinação de teclas é um atalho do Delphi para criar um GUID (´Globally Unique Identifier´), que é um padrão de número pseudo-randômico que vai de 0 a 2^128. A faixa é tão grande que a probabilidade de gerar um segundo número idêntico é mínima.

Para gerar uma senha segura, [url=http://www.singularsistemas.com.br/blog/2006/09/06/senhas-seguras-com-safepasswd/]recomendo[/url] o site gratuito [url]http://www.safepasswd.com/[/url].

Eu não vi seu já foi mencionado isso nesse tópico ainda, mas como solução profissional para proteger aplicações em Delphi, o [url=http://sourceforge.net/projects/tplockbox/]TurboPower LockBox[/url] é o ideal. Era um produto comercial da TurboPower, que acabou sendo publicado como open-source gratuito depois que a companhia fechou as portas.

Um abraço,

Esse número é gerado a partir do endereço físico da placa de rede da máquina e da data/hora (se não me engano, o algoritmo que gera o número é padronizado). Numa mesma máquina você gerar número diferentes a cada instante; acredito que esse identificador não seja muito útil para um esquema de proteção, uma vez que não há como reproduzi-lo nem como deduzir quais valores deram origem a ele. Normalmente é usado em situações onde você deseja ter um identificador único.

Obrigado a todos pelas respostas, fiz dow do componente turbo power, mas estou precisando de algum para gerar um chave de liberação, algo que eu possa utilizar o serial do hd mais algo da bios, consigo recuperar as informações da bios e o serial do hd, mas não sei como implementar e tenho certa urgencia
Tenho um cliente que esta tentando instalar o meu sistema em todas as maquinas sem pagar a licença, utilizo uma chave no registro e dados no banco, mas ele esta reclamando que toda vez que formata a maquina tem que me chamar para liberar o sistemas. esta exigindo um cd com esta liberdade.
Mas se eu liberar ele pode trocar o hd de maquina e continuar a utuilizar o sistema, quero força ele a não troca a maquina, mas deixar ele livre para formatar o hd todas vez que quizsr
Por favor me ajude nesta
preferencia componente free, sou programador autonomo... rsss

LockBox faz exatamente isso e é gratuito. É só ler os manuais.

curiosidade a parte , foi postado no forum , uma função pelo vinivus2k.
Parece que ela lia o Seria do Hd e não do volume. Por acaso o DPinho, chegou a ver esta função????

[quote:2da51263ad=´Marco Salles´]curiosidade a parte , foi postado no forum , uma função pelo vinivus2k.
Parece que ela lia o Seria do Hd e não do volume. Por acaso o DPinho, chegou a ver esta função????[/quote:2da51263ad]

sim, vi e estou utilizando a rotina que funciona perfeitamente
tambem estou utilizando uma rotina para ler as informaçõe da bios.
so que imagina o seguinte: vou ler o serial do hd, mas meu cliente resolve colocar o hd em outro micro, ou se vou ler a bios e o hd tem que ser formatado
preciso de algo que utilize informções da bios e do hd assim forço ele a não utilizar em outra maquina, mas preciso deixar ele livre para formatar e troca o sistema operacional na hora que ele quizer e so retornar o backup
o problema é que as informações da bios são muitas e não estou sabendo como selecionar o mais importante para gerar um chave ele me informaria esta chave e eu retornaria um contra-chave para ele utilizar toda vez que fosse reinstalar o sistema

outra duvida: se eu gravar todas as informações da bios em um dll e mandar pra ele, dai o sistema leria a dll antes de carregar e se fosse hd diferente ou bios diferente ele entraria em modo de demo

me ajude nesta, ta dificil fazer