[Tiago Souza]

Seu software proprietário está livre da pirataria ou curiosos?!

Infelizmente, a pirataria é impulsionada por péssimas políticas de proteção de software. Veja nesse artigo algumas dicas de como proteger melhor o seu software e dificultar o trabalho dos crackers.

Se você é um desenvolvedor contratado por alguma empresa e cria sistemas específicos para cada cliente,pode ser que isto nunca seja uma preocupação muito séria, pois há poucas possibilidades do sistema ser de interesse de outra pessoa física ou jurídica com diferentes características operacionais (entenda como "o produto acabado" e não o código fonte).

Caso você esteja no mercado de softwares para o público em geral, seja bem-vindo ao clube dos programas pirateados.

Este artigo visa introduzir alguns conceitos de proteção de software para programadores (em geral), porém, antes de começarmos há uma coisa muito importante a ser dita:

Muitas empresas grandes liberam softwares com baixa proteção contra pirataria visando exatamente uma divulgação indireta do produto (eu ouvi, Windows?). É uma tática que dá certo em países onde há uma certa lei e consciência (além do dinheiro) por parte dos usuários com software, mas isto não se aplica ao Brasil. Um conselho: nunca faça uma proteção meia-boca do seu software ! Ninguém vai comprar aqui o seu produto se podem obtê-lo gratuitamente (p2p dita as regras) e a quantidade que comprarem não cobrirá os custo do desenvolvimento.

Você poderá distribuir o seu software para venda na prateleira ou via internet. Na venda via prateleira, lembre-se que é importante lembrar que ainda há casos que o cliente não tem internet, portanto, se você optar pela ativação de software mediante uma chave de registro, é imprescindível manter uma maneira dos clientes fazerem-a offline (por telefone, por exemplo). Mas há um porém: grande parte dos cracks / keygens consistem em inserir uma chave de registro offline, passando pela autenticação feita no servidor.

Isto acontece porque o servidor deve ter uma lista de chaves autorizadas, logo, uma chave gerada por keygen tem grandes chances de ser falsa, mas isso depende muito do algoritmo. Por outro lado, o desenvolvedor não pode inserir uma lista de seriais (ou contra-chaves) autorizados no software, porque se essa lista for obtida através de engenharia reversa, meu amigo, você nunca mais poderá identificar um cliente verdadeiro de um pirata.

É importante utilizar mais de uma proteção no seu software. Veja algumas dicas:

1) Nos casos aplicáveis, utilize um compactador de arquivos PE. NÃO utilize o UPX, pois este é facilmente descompactado. O bom dos compactadores PE é que o código hexadecimal geralmente fica embaralhado, dificultando a edição hexadecimal e edição dos recursos (resources);

2) Nunca utilize nomes óbvios ao criar funções de validação de serial. Por exemplo: ao invés de usar "validaSerial", use "fnctnvc" (FuNCTioN Valida Código, abreviada). Isto dificulta o trabalho de engenharia reversa;

3) Para validação, procure criar funções que servem para deixar o cracker perdido. Por exemplo, crie uma função "validaSerial", que passe um determinado valor para outra com o nome "isSerialValido" ou algo parecido. Chame-a na hora de fazer a verificação do serial. Isso leva o foco do cracker para essa função e não para a função "fnctnvc";

4) Bloqueie o uso do software se detectar algum debugger, como o SoftIce. Evite fazer essa verificação a cada 5 segundos, pois será um desperdício de processamento. Faça a verificação na inicialização do programa ou na hora de validar o serial. Cuidado com programas que monitoram o que é feito nos arquivos (como o Filemon).

5) Se você vender o software pela internet, considere implantar o sistema de chave / contra-chave. Você disponibiliza um demo para o cliente e, depois que ele comprar, você pede para ele passar a chave gerada pelo software (geralmente usando a versão do windows + criptografia + ID do HD) e, com isso, você gera uma contra-chave. Isso evita que um cara compre seu programa e distribua chaves para todo mundo. Importante lembrar que, se o usuário trocar de HD ou Windows, você terá que, de boa-fé, passar uma nova chave para o cliente, mesmo que ele esteja agindo de má-fé. Lógico, você não vai passar 20 chaves para o cliente em um período de 20 dias.

6) Para detectar que o usuário registrou o produto, procure utilizar o registro do Windows ou um arquivo escondido, ou ainda utilize os dois. Tente seguir a seguinte lógica:

Se o cliente usa produto demo, uma chave escondida no registro possui valor = chave encriptada.

Se o cliente usa o produto completo, altere o valor daquela chave escondida para = contra-chave + encriptação. Crie um arquivo no diretório do Windows com um conteúdo encriptado, para evitar que o cliente burle um possível sistema de 30 dias de uso.

7) Para sistemas que verificam o serial durante a instalação, desabilite a opção de instalação silenciosa (/silent geralmente). Pode parecer estranho, mas alguns instaladores não verificam o serial de o argumento /silent for passado. MUITO cuidado com descompactadores de instaladores.

8) Para sistemas que dão 30 dias ou "x" usos de limite, por mais óbvio que pareça, procure proteger bem os dados que indicam o uso / dias e, mesmo que não pareça ético, NUNCA exclua estes dados do seu registro.

9) Se seu software for crackeado, providencie um patch invisível. Por exemplo, você faz uma pequena melhoria no programa, porém uma grande melhoria no sistema de proteção. Procure atualizar regularmente seu software, sempre alterando alguma coisa na proteção.

10) Se utilizar autenticação pela internet, ao gerar os seriais, implante-os na lista (ou banco de dados) do servidor. Dessa forma, seriais que batem com o algoritmo, mas não estão autenticados no servidor serão bloqueados.

11) Se você pretende criar programas caríssimos (R$2000 pra cima), considere utilizar "Hardlocks", que são pequenos periféricos USB que devem ser plugados no computador para execução do software, pois é uma proteção BEM mais complicada para ser quebrada. Muito cuidado com emuladores destes periféricos.

12) Lembre-se: não existe maneira de proteger em 100% um sistema. O que você deve fazer é dificultar ao máximo para desencorajar os crackers. Se o seu software for bom, mais pessoas querem usar. Se mais pessoas querem usar, mais chances de crackers atenderem à demanda (geralmente, por renome).

13) Para banco de dados, utilize senha (principalmente em Banco de Dados "Access") e stored procedures, caso o bd suporte.

14) Se você implantar um ótimo sistema de proteção, mesmo que ele seja quebrado, você será visto (geralmente) com bons olhos pelos crackers, pois fez de tudo para proteger sua propriedade intelectual. Infelizmente, como já disse, não há nenhuma maneira de proteger 100% do seu software.


Autor: Rodolfo Andrade