proteção de software para pequenos fornecedores

Question

Este é um problema que todos nós temos que considerar em algum ponto.

Depois de muitos anos e muitas abordagens que tendem a concordar em geral com o staterment: "Para qualquer software protegido usado por mais de algumas centenas de pessoas, você pode encontrar uma versão rachada. Até agora, cada esquema de proteção pode ser adulterado." Será que o seu empregador impor o uso de software anti-pirataria?

Além disso, cada vez que eu postar sobre este assunto, alguém vai lembrar-me; "Primeiro de tudo, não importa que tipo de proteção que você vai empregar, um cracker verdadeiramente dedicado irá, no final, passar por todas as barreiras de proteção." Qual é o melhor valor para o dinheiro c protecção # código para um único desenvolvedor

Assim, não obstante estes dois amplamente verdadeiras renúncias, vamos falar sobre a "proteção"!

Eu ainda sinto que para aplicativos menores, que não são susceptíveis de warrent o tempo ea atenção de um biscoito qualificados, a proteção é um exercício interessante.

Parece óbvio que não importa o que você faz, se o cracker pode mudar o resultado de uma instrução IF (JMP) remendando a aplicação, então todas as senhas e dongles na ANRE mundo não vai ajudar.

Assim, a minha abordagem tem sido a ofuscar o código com virtualização usando produtos como: http://www.oreans.com/codevirtualizer.php Tenho sido muito feliz com este produto. Para meu conhecimento neve foi derrotado. Posso até comprimir o executável com PECompact Alguém tem experiência com ele?

Nada tinha, mas problemas com EXECryptor http://www.strongbit.com/news.asp Mesmo o site é uma dor de cabeça para uso. Os aplicativos compilados iria falhar ao fazer quaisquer chamadas WMI.

Esta abordagem permite-lhe rodear as secções menores de código com o ofuscamento e, assim, proteger a segurança verificando etc.

Eu uso a abordagem de autorização on-line, como a aplicação precisa de dados do servidor regularmente, de modo que não faz sentido para o usuário para usá-lo off-line por longos períodos. Por definição, o aplicativo é inútil naquele momento, mesmo se estiver rachada.

Assim, uma simples criptografado aperto de mão é muito bom. Eu apenas verificá-lo ocasionalmente, dentro da proteção ofuscação. Se o usuário instala o aplicativo em uma máquina diferente, um novo ID é carregado em cima do lançamento eo servidor desativa o velho ID e retorna uma nova autorização.

Eu também uso um hash do aplicativo compilado e verificá-lo no lançamento para ver se um único bit mudou, em seguida, abra o aplicativo como um arquivo (com um bloqueio de leitura) de dentro do aplicativo para evitar que alguém alterá-lo uma vez lançado .

Uma vez que todas as cordas estáticas são claramente visíveis no arquivo .exe, eu tento ser genérico com mensagens de erro e assim por diante. Você não vai encontrar a string "Falha na autorização" em qualquer lugar.

Para se proteger contra despejos de memória, eu uso uma técnica de texto ofuscação simples (como XOR cada personagem) Isso faz com que os dados de texto simples na memória mais difícil de distinguir de variáveis ??e assim por diante.

Então, claro, há AES para quaisquer dados que é muito sensível. Eu como modo de contador para o texto como esta resulta em não há sequências de repetição revelando dados subjacente, como uma sequência de espaços em branco.

Mas com todas estas técnicas, se o vetor chave ou de inicialização podem ser despejados a partir da memória, ou a instrução IF contornado, tudo é desperdiçado.

Eu costumo usar uma instrução switch em vez de uma instrução condicional. Então eu criar uma segunda função que é basicamente um beco sem saída em vez da função que realmente executa a tarefa desejada.

Outra idéia é pointe códigors com uma variável adicionado. A variável é o resultado da autorização (normalmente zero). Esta vontade inevitável levar a uma falha em algum ponto. Eu só uso isso como um último recurso depois de algumas autorizações de nível inferior falharam caso contrário os usuários reais podem encontrá-lo. Em seguida, a reputação do seu software é baixado.

Que técnicas você usa?

(este não é um fio debater os méritos de implementar algo. Ele é projetado para aqueles que decidiram fazer algo)

Answer 1

Eu discordo xsl.

Nós protegemos o nosso código, não porque queremos proteger nossa receita -. Aceitarmos que aqueles que usaria se sem uma licença provavelmente nunca pagaria por ele de qualquer maneira

Em vez disso, nós fazemos isso para proteger o investimento nosso clientes têm feito em nosso software. Acreditamos que o uso do nosso software torna mais competative em seu lugar no mercado e que, se outras empresas têm acesso a ela sem pagar eles têm uma vantagem injusta -. Ou seja, eles se tornam como competative sem ter a sobrecarga do custo de licenciamento

Somos muito cuidadosos para assegurar que a protecção - que é cultivado em casa - é o mais discreto possível para os usuários válidos, e para este fim que nunca consideraria 'compra num' off the shelf solução que pode afetar isso.

Answer 2

Você não precisa de algumas centenas de usuários para obter o seu software rachado. I ficou irritado por ter meu shareware rachado tantas vezes, por isso, como um experimento I criou um programa chamado Magia caixa de texto (que era apenas um formulário com uma caixa de texto sobre ele) e lançou-o para shareware locais (que tinha seu próprio arquivo PAD e tudo ). Um dia depois, uma versão rachada da Magia Textbox estava disponível.

Esta experiência me fez praticamente desistir de tentar proteger o meu software com mais nada do que proteção contra cópia rudimentar.

Answer 3

Eu uso pessoalmente as técnicas de código discutido aqui . Esses truques têm o benefício de incomodar piratas sem tornar a vida mais difícil para seus usuários finais legítimos

Mas a questão mais interessante não é "o que", mas "por que". Antes de um fornecedor de software embarca neste tipo de exercício, é realmente importante para construir um modelo de ameaça. Por exemplo, as ameaças para um jogo de preço baixo B2C são totalmente diferentes aos de um aplicativo de alto valor B2B.

Patrick Mackenzie tem um bom ensaio onde discute algumas das ameaças , incluindo uma análise dos 4 tipos de cliente potencial. Eu recomendo fazer esta análise ameaça para o seu próprio aplicativo antes de fazer escolhas sobre como proteger seu modelo de negócio.

Answer 4

Eu tenho implementado hardware chaveamento (dongles) antes de mim, então eu não estou totalmente familiarizado com as questões. Na verdade, eu dei-lhe uma grande dose de pensamento. Eu não concordo com a lei de direitos autorais alguém violar, como seus biscoitos estão fazendo. Quem não quiser adquirir legalmente uma cópia do seu software deve fazer sem. Eu nunca violar direitos autorais de software mim. Dito isto ...

Eu realmente, realmente não gosto da palavra "proteger" usados ??aqui. A única coisa que você está tentando proteger é seu controle . Você está não proteger o software. O software é muito bem de qualquer forma, como são os seus usuários.

A razão que manter as pessoas de copiar e compartilhar o seu software é tal PITA profana é que prevenir tais atividades não é natural. Todo o conceito de um gira em torno de computador copiando dados, e é simples da natureza humana querer compartilhar coisas úteis. Você pode lutar contra estes fatos se você realmente insistir, mas será uma luta ao longo da vida. Deus não está fazendo os seres humanos de forma diferente, e eu não estou comprando um computador que não é possível copiar as coisas. Talvez seria melhor para encontrar uma forma de trabalho com computadores e pessoas, ao invés de lutar contra eles o tempo todo?

I, juntamente com a maioria dos desenvolvedores de software profissionais, sou empregado em tempo integral por uma empresa que software necessidades desenvolvido para que ele possa fazer o seu negócio, não para que ele possa ter um "produto de software" com a escassez artificial de "vender" para os usuários. Se eu escrever algo geralmente útil (que não é considerada uma "vantagem competitiva" aqui), podemos liberá-lo como Software Livre. Não é necessário qualquer "protecção".

Answer 5

De alguns dos links:

O conceito Tentei explicar é o que eu chamo de “crack spread”. Não importa que uma rachadura (ou keygen, serial ou pirateado, ou qualquer outro) existe para a sua aplicação. O que importa é quantas pessoas têm acesso à rachadura.

Onde / quando para verificar o número de série: I verificar uma vez na inicialização. Um monte de gente dizer “Check-in todos os tipos de locais”, para tornar mais difícil para alguém para quebrar descascando para fora o cheque. Se você quiser ser particularmente desagradável para o biscoito, o check-in todos os tipos de lugares usando o código embutido (ie NÃO exteriorizar tudo em SerialNumberVerifier.class) e, se possível faça-o multi-threaded e difícil de reconhecer quando ele falhar , também. Mas isso só torna mais difícil fazer o crack, não impossível, e lembre-se seu objetivo geralmente não é derrotar o cracker. Derrotar o cracker não faz de você uma quantidade apreciável de dinheiro. Você só precisa derrotar o usuário casual na maioria dos casos, e o usuário casual não tem acesso a um depurador nem sabe como usar um.

Se você estiver indo para o telefone de casa, você deve ser telefonar para casa com suas informações de usuário e aceitar o número de série como a saída do roteiro de seu servidor, não telefonar para casa com o número de série e aceitar um boolean, etc, como a resultado. ou seja, você deve fazer a injeção chave, não verificação da chave. verificação da chave tem de acontecer em última análise, dentro do aplicativo, que é por criptografia de chave pública é a melhor maneira de fazê-lo. A razão é que a ligação à Internet também está nas mãos do adversário :) Está a uma mudança arquivo hosts longe de um break-uma vez, break-em todos os lugares explorar se o seu software está apenas esperando para ler um booleano fora da Internet.

Não faça um “interessante” ou proteção “desafiador”. Muitos biscoitos rachar para o desafio intelectual sozinho. Faça sua proteção duro de roer, mas tão chato quanto possível.

Existem algumas rachaduras que buscam padrões de bytes em busca do lugar para patch. Eles geralmente não são derrotados por uma recompilação, mas se o seu .EXE é embalado (por ASProtect, Armadillo, etc) este tipo de rachaduras deve primeiro descompactar o exe .. e se você usar um bom packer como ASProtect, o cracker será capaz de desempacotar o EXE manualmente utilizando um nível de montagem depurador tais como SoftICE, mas não será capaz de criar uma ferramenta que extrai o .EXE automaticamente (para aplicar os adesivos byte depois).

Answer 6

XSL, que é um ponto muito de vista estreito com muitos construído em assumtions.

Parece-me óbvio que qualquer aplicativo que se baseia em entregar algo a partir de um servidor sob o seu controle deve ser capaz de fazer um bom trabalho de descobrir o nosso que tem uma conta válida!

Eu também da crença de que atualizações regulares (ou seja, um aplicativo recém-compilado com código em locais diferentes) sou fará vesrions rachadas rapidamente obsoletos. Se seus comunica app com um servidor, o lançamento de um processo secundário para substituir o executável principal cada semana é um pedaço de bolo.

Então, sim, nada é uncrackable, mas com algum projeto intrínseca inteligente, torna-se um ponto discutível. O único fator que é significativo é quanto tempo são os biscoitos dispostos a gastar com ele, e quanto esforço são os seus potenciais clientes dispostos a exercer na tentativa de encontrar o produto de seus esforços em uma base semanal ou mesmo diariamente!

Eu suspeito que, se seu aplicativo fornece uma valiosa função útil, então eles vão estar dispostos a pagar um preço justo por ele. Se não, produtos competitivos vai entrar no mercado e seu problme apenas resolvido em si.

Answer 7

Eu tenho usado .NET Reactor no passado com bons resultados - http://www.eziriz.com/

O que eu gostei sobre este produto é que ele não exige que você para ofuscar o código para ter boa proteção.