PC Toledo

Há uma forte tendência entre os usuários para não pagar um software. Pessoas - mesmo "de bem" sempre buscam os gratuitos. Quem já não foi procurado por um amigo para "destravar" um programinha ótimo, mas que tem que pagar?

É lógico que não há proteção infalível, sempre encontram o meio de burlar a segurança. Mas deixar totalmente livre é que não dá.

A criatividade nesse caso, conta muito. Uma das armas é dificultar ao máximo, objetivando fazer o transgressor desistir do seu intento. Eu costumo usar trilhas falsas, intituladas de "aqui checa se o soft é genuíno", que não levam a nada, mas o malandro perde muito tempo...

O #SERIAL do HD, embora bem manjado, é uma segurança bem básica e muito usada. Também acrescento diversos pontos de confirmação distribuídos dentro do programa. No caso de alteração, vai falhar inexplicavelmente em algum outro ponto.

Com anos de experiência no ramo, alguém deve ter idéias excelentes, que acho que deveria compartilhar, talvez por e-mail para não entregar o ouro...

Algumas poderiam ser postadas aqui, para o aproveitamento de todos. Alguém se habilita?

Bom

Na sessão codigo fonte eu exenplifiquei com codigo completo o meu programa protetor de .EXE.

Como não foi possivel coloca-lo dentro do sistema pois em Harbour não foi possivel escrever internamente eu bolei meu registrador externo que é invocado caso o sistema nao encontre o NUMERO de liberação.

A técnica que usei é a do serial de formatação do HD para um rápido entendimento e que melhoras podem ser visualizadas no topico a seguir:

https://pctoledo.org/forum/viewtopic.php?t=5164

O resultado é que uma string sera gravada dentro do executável liberando assim o seu uso por mais tempo.

Quando usava o Blinker minha rotina ficava dentro do executável e quando expirava acionava a rotina de ativacao que recebia o codigo de liberação e gravava numa variavel interna.

Se voce usa o Blinker ele mesmo já pode prover técnicas muito boas como datas de expiração, tempo de uso, numero de execuções e compactação.

No caso do Harbour voce pode usar outros métodos e programas para incluir esta caracteristica. Se não me engano o Vagner Nunes conhece um compactador que funciona legal com Harbour.

Ainda na sessão codigo fonte ou fivewin eu coloquei uma rotina que permite usar a NSLOCK.OCX que produz uma boa proteção e permite voce gerar uma cadeia de liberação.

Quanto a este assunto iremos ficar anos debatendo pois sempre surge novos meios de dibra-los.

rochinha escreveu:
O resultado é que uma string sera gravada dentro do executável liberando assim o seu uso por mais tempo.

Caro Rochinha,

Não consegui encontrar o código a que você se referiu. Vou dar uma outra busca, mas, inicialmente, achei bem interessante a idéia de gravar dentro do executável, mas não me ocorreu nenhuma idéia de como isso pode ser feito.

Idéias a serem analisadas:

1. Softwares utilitários de disco conseguem ler o #SERIAL do disco. Esse número não muda com a formatação.

- Não sei como obter esse número, mas seria o número ideal para o controle. Só que no caso da troca do HD esse controle se tornaria sem efeito.

2. Com a gravação sendo feita dentro do executável, a idéia é solicitar dados do cliente e acrescentá-los à uma variável interna.

- Se o cliente formatar a máquina ou mesmo efetuar a troca do HD a checagem poderia ser feita atavés desses dados.

- Dados como CPF (que pode ser facilmente verificado) e RG, que geralmente há mais 'medo' do cliente em propagá-los poderiam ser exigidos durante a primeira instalação.

3. Existia um meio de ler a chave do Windows 98 que ficava em um arquivo. No XP não consegui saber se ele fica disponível. Também seria uma forma de agregar esse número à variável interna.

Acho que a melhor solução é apresentar a razão social do cliente em todas as telas e relatórios. Criptografe internamente no sistema.

Grings escreveu:Acho que a melhor solução é apresentar a razão social do cliente em todas as telas e relatórios. Criptografe internamente no sistema.

É sem dúvida uma forma de inibir o uso do software por outros. O fator criptografar é importante, para evitar a edição - já vi casos em que os dados do cliente são alterados através do Edit do MS-DOS, com o famoso /16...

Amiguinho

Me referi ao topico onde o Maligno explica melhor a falha que ocorre com o Serial de formatação do HD. Para mim ela serve pois só uma máquina poderá ter o sistema instalado, pois se seu cliente perder os dados ou formatar o hd tera de entrar em contato com voce. Se ele te paga manutenção voce mesmo vai até lá e instala eai por diante.

Lógico que não existe técnica de serialização que funcione pois se existisse a microsoft já teria usado. Ela bem que tentou no lançamento do XP com os 14 dias de amaciamento. Mas ai os crackers conseguiram dobrar a técnica.

Agora com o Vista esta tese de segurança em registro vem reforçada

Analise o codigo em
SEGURANCA - Modulo de registro de aplicativo com HDserial...

Aqui exemplifico o uso de NSLOCK.OCX:
Como proteger um programa? com boas participações.

Aqui tem uma função bem interessante importei de um codigo ASP de minha página de controle de senhas em meu site:
SEGURANCA - Funcao de geração de senha aleatória

Aqui a dica de um amigo exemplificando sua técnica:
Trava mensal do sistema liberando com senha mutante

Não podemos deixar de lembrar da técnica do arquivo BLABLABLA.SYS dentro do diretório do Windows, muito manjada mas que funciona.

E a técnica de segurança dos aplicativos gerados pelo Gas DOS.

Bom, o negócio rende...

diogenes_varela escreveu:inicialmente, achei bem interessante a idéia de gravar dentro do executável, mas não me ocorreu nenhuma idéia de como isso pode ser feito.

É uma técnica relativamente simples. Você inclui no executável uma função de segurança, com uma variável qualquer, que conterá uma string de identificação, que seja única em todo o programa. Junto a ela um espaço adicional, se necessário, talvez para armazenar os dados da empresa licenciada, por exemplo.
Com um editor hexadecimal, basta você procurar pela sua string original e por cima dela, ou mesmo após ela, no espaço reservado, você insere a sua string de controle, que essa função irá manipular e assim, validar a execução do programa.
É possível até mesmo "enxertar" código executável dentro de uma função. Mas isso depende de código ASM.
Desvantagem: se você usar o modo de compressão do BLinker, sua string será também compactada e não será mais possível encontrá-la.

[]'s
Maligno
http://www.buzinello.com/prg

Uma das técnicas que eu uso é de gravar uma chave de identificação dentro de um arquivo...Digamos "xyzabcdefg", aí vocês vão dizer mas isso é o que já foi dito, a diferença é que eu gravo em um arquivo do próprio Windows, exemplos : SORT.EXE, APPEND.EXE, COMP.EXE, VMMREG32.DLL

Daí o sistema verifica no inicio do sistema se existe a chave gravada, geralmente faço isso em mais de um arquivo. Essa técnica tb pode ser usada para gravar a última data de uso do sistema e ou a quantidade de execuções do programa.

Óbviamente que se o cliente reinstalar o windows o sistema precisará ser liberado novamente, mas juntamente com as outras soluções apresentadas torna-se um forte bloqueio.

Até logo.

Marcelo

Maligno escreveu:
Com um editor hexadecimal, basta você procurar pela sua string original e por cima dela, ou mesmo após ela, no espaço reservado, você insere a sua string de controle, que essa função irá manipular e assim, validar a execução do programa.

Amigo Maligno,

Só não entendi como isso poderia funcionar durante a instalação, na máquina do cliente, como isso poderia ser possível? Ou não foi isso que você sugeriu?

diogenes_varela escreveu:Só não entendi como isso poderia funcionar durante a instalação, na máquina do cliente, como isso poderia ser possível? Ou não foi isso que você sugeriu?

Neste caso você tanto poderia entregar um programa já preparado, como poderia gravá-lo no momento da instalação. Mas neste caso, claro, você não poderia abrir um editor hexa na cara do cliente. Até pegaria mal. Você teria de usar um programa de "enxerto" que poderia, por exemplo, ler um arquivo contendo os dados criptografados. Para quem aluga programas é uma alternativa. O cliente paga a mensalidade, você envia o arquivo de validação e ele apenas executa o utilitário. Já fiz algo semelhante no passado. Funcionava muito bem.

[]'s
Maligno
http://www.buzinello.com/prg

Amiguinho

Juntando as dicas do Maligno e a rotina que propuz logo acima é mais ou menos isto

Voce tem uma variavel em seu programa:
Voce entrega o executável para o cliente instalar e executar. Seu sistema ira testar o conteudo desta variavel e se ela contiver HDHDHDHDDDMMYYYY voce invoce o programa que produz o registro.

Este programa abre o sistema, faz uma varredura nele buscando por HDHDHDHDDDMMYYYY, se achar ele grava então o serial do HD e uma data de expiracao, tipo 3 meses, ficando mais ou menos assim: 2E6F87B401042007.

A função de checagem de seu sistema sempre fará as leituras trazendo como possibilidade os retornos, numero do serial do HD, data de expiração. Se o serial não bater retorna MAQUINA INVALIDA, se a data estiver ultrapassada retorna FORA DE DATA ou se a string estiver ainda com HDHDHDHDDDMMYYYY retorna NAO REGISTRADO.

Se voce não for usar um programinha externo para REGISTRAR o sistema use então um arquivo que voce envia via email para o cliente e que será jogado no diretorio do sistema. Seu sistema ao entrar sempre ira abrir este arquivo e verificar a autenticidade de seu conteudo com a liberação grafada dentro de seu sistema e atualiza-la automaticamente.

Depois de liberado o arquivo deve ser reescrito com zeros para evitar sua releitura.

PRESISO PROTEGER UM HD E MEMORIA FLESH COMO EU FASO O SISTEMA GUE EU USO E MSDOS

Amiguinho

O funcionamento de um HD em memória flash é identico ao disco rigido, recebe formatação, nome de volumes, etc.

Mas este tipo de memória por ser volátil não tem muita segurança a não ser que voce analise o manual da memória ou do adaptador para verificar se existe algum meio de proteger o conteudo para um formato read-only.

Amigos, tô achando essa mensagem acima bem suspeita, com erros de português propositais!