Como posso criar uma chave de produto para meu aplicativo C #?
Preciso criar uma chave de produto (ou licença) que atualizo anualmente. Além disso, preciso criar um para versões de teste.
Relacionado:
Como posso criar uma chave de produto para meu aplicativo C #?
Preciso criar uma chave de produto (ou licença) que atualizo anualmente. Além disso, preciso criar um para versões de teste.
Relacionado:
Respostas:
Você pode fazer algo como criar um registro que contenha os dados que deseja autenticar no aplicativo. Isso pode incluir o que você quiser - por exemplo, recursos do programa para habilitar, data de expiração, nome do usuário (se você quiser vinculá-lo a um usuário). Em seguida, criptografe-o usando algum algoritmo de criptografia com uma chave fixa ou faça um hash. Depois, basta verificar no seu programa. Uma forma de distribuir o arquivo de licença (no Windows) é fornecê-lo como um arquivo que atualiza o registro (evita que o usuário tenha que digitá-lo).
Porém, tenha cuidado com a falsa sensação de segurança - mais cedo ou mais tarde alguém simplesmente corrigirá seu programa para pular essa verificação e distribuir a versão corrigida. Ou, eles vão trabalhar em uma chave que passa em todas as verificações e distribuí-la, ou atrasar o relógio, etc. Não importa o quão complicado você faça seu esquema, qualquer coisa que você fizer para isso acabará por ser segurança através da obscuridade e eles sempre serão ser capaz de fazer isso. Mesmo se não puderem, alguém o fará e distribuirá a versão hackeada. O mesmo se aplica mesmo se você fornecer um dongle - se alguém quiser, eles também podem remendar o cheque. Assinar digitalmente seu código não ajudará, eles podem remover a assinatura ou renunciar a ela.
Você pode complicar um pouco as coisas usando técnicas para evitar que o programa seja executado em um depurador, etc., mas mesmo isso não é à prova de balas. Portanto, você deve dificultar o suficiente para que um usuário honesto não se esqueça de pagar. Também tenha muito cuidado para que seu esquema não se torne obstrutivo para os usuários pagantes - é melhor ter algumas cópias roubadas do que os clientes pagantes não poderem usar o que pagaram.
Outra opção é ter uma verificação online - basta fornecer ao usuário um ID exclusivo e verificar online quais recursos esse ID deve ter e armazená-lo em cache por algum período. Todas as mesmas advertências se aplicam - as pessoas podem contornar qualquer coisa assim.
Considere também os custos de suporte de ter que lidar com usuários que esqueceram sua chave, etc.
editar: Eu só quero adicionar, não invista muito tempo nisso ou pense que de alguma forma seu esquema complicado será diferente e indecifrável. Não vai e não pode durar enquanto as pessoas controlarem o hardware e o sistema operacional em que seu programa é executado. Os desenvolvedores têm tentado criar esquemas cada vez mais complexos para isso, pensando que, se desenvolverem seu próprio sistema para isso, ele será conhecido apenas por eles e, portanto, 'mais seguro'. Mas é realmente o equivalente em programação de tentar construir uma máquina de movimento perpétuo. :-)
Em quem você confia?
Sempre considerei essa área crítica demais para confiar em terceiros para gerenciar a segurança de tempo de execução de seu aplicativo. Depois que esse componente é quebrado para um aplicativo, ele é quebrado para todos os aplicativos. Aconteceu com a Discreet em cinco minutos quando eles lançaram uma solução de licença de terceiros para o 3ds Max anos atrás ... Bons tempos!
Sério, considere lançar o seu próprio para ter controle total sobre seu algoritmo. Se você fizer isso, considere o uso de componentes em sua chave ao longo das linhas de:
Em seguida, faça uma verificação total deles e adicione qualquer criptografia (reversível) que você quiser para torná-la mais difícil de quebrar.
Para fazer uma chave de licença de teste, basta definir os valores para os valores acima que se traduzem como "modo de teste".
E como este é provavelmente o código mais importante em seu aplicativo / empresa, além de / em vez de ofuscação, considere colocar as rotinas de descriptografia em um arquivo DLL nativo e simplesmente P / Invoke nele.
Várias empresas para as quais trabalhei adotaram abordagens generalizadas para isso com grande sucesso. Ou talvez os produtos não valiam a pena quebrar;)
Se você estiver perguntando sobre as chaves que você pode digitar, como as chaves de produto do Windows, elas são baseadas em algumas verificações. Se você está falando sobre as chaves que devem ser copiadas e coladas, elas são baseadas em uma assinatura digital (criptografia de chave privada).
Uma lógica de chave de produto simples pode ser começar dizendo que a chave de produto consiste em quatro grupos de 5 dígitos, como abcde-fghij-kljmo-pqrst , e então ir para especificar relacionamentos internos como f + k + p devem ser iguais a, significando os primeiros dígitos de 2 , 3 e 4 grupos devem totalizar a. Isso significa que 8xxxx-2xxxx-4xxxx-2xxxx é válido, então é 8xxxx-1xxxx-0xxxx-7xxxx. Claro, haveria outras relações também, incluindo relações complexas como, se o segundo dígito do primeiro grupo for ímpar, então o último dígito do último grupo também deveria ser ímpar. Dessa forma, haveria geradores de chaves de produto e a verificação das chaves de produto seria simplesmente verificar se ela atende a todas as regras.
A criptografia é normalmente a sequência de informações sobre a licença criptografada usando uma chave privada (== assinada digitalmente) e convertida em Base64 . A chave pública é distribuída com o aplicativo. Quando a string Base64 chega, ela é verificada (== descriptografada) pela chave pública e, se considerada válida, o produto é ativado.
Quer seja trivial ou difícil de decifrar, não tenho certeza se realmente faz muita diferença.
A probabilidade de seu aplicativo ser crackeado é muito mais proporcional à sua utilidade do que à força do manuseio da chave do produto.
Pessoalmente, acho que existem duas classes de usuários. Aqueles que pagam. Aqueles que não o fazem. Aqueles que o fizerem provavelmente o farão mesmo com a proteção mais trivial. Aqueles que não o fizerem vão esperar por um crack ou procurar outro lugar. De qualquer forma, você não receberá mais dinheiro.
Tenho que admitir que faria algo bastante insano.
Quando eles encontrarem e removerem o LicenseCheck, será divertido quando o DLL começar a apresentar falhas de segmentação .
Existe a opção Licenciamento e Proteção de Software Microsoft (SLP). Depois de ler sobre isso, eu realmente gostaria de poder usá-lo.
Gosto muito da ideia de bloquear partes do código com base na licença. Coisas interessantes e o mais seguro para .NET. Leitura interessante mesmo que você não use!
Os Serviços de Licenciamento e Proteção de Software Microsoft® (SLP) são um serviço de ativação de software que permite que fornecedores de software independentes (ISVs) adotem termos de licenciamento flexíveis para seus clientes. O Microsoft SLP Services emprega um método de proteção exclusivo que ajuda a proteger seu aplicativo e informações de licenciamento, permitindo que você entre no mercado mais rapidamente e, ao mesmo tempo, aumente a conformidade do cliente.
Observação: esta é a única maneira de lançar um produto com código confidencial (como um algoritmo valioso).
Outra boa ferramenta barata para chaves de produto e ativações é um produto chamado InstallKey. Dê uma olhada em www.lomacons.com
Um método simples é usar um Globally Unique Identifier (GUID). GUIDs geralmente são armazenados como valores de 128 bits e são comumente exibidos como 32 dígitos hexadecimais com grupos separados por hifens, como {21EC2020-3AEA-4069-A2DD-08002B30309D}.
Use o seguinte código em C # por System.Guid.NewGuid().
getKey = System.Guid.NewGuid().ToString().Substring(0, 8).ToUpper(); //Will generate a random 8 digit hexadecimal string.
_key = Convert.ToString(Regex.Replace(getKey, ".{4}", "$0/")); // And use this to separate every four digits with a "/".Espero que ajude.
O truque é ter um algoritmo que só você conheça (de forma que possa ser decodificado na outra extremidade).
Existem coisas simples como, "Escolha um número primo e adicione um número mágico a ele"
Opções mais complicadas, como o uso de criptografia assimétrica de um conjunto de dados binários (que pode incluir um identificador único, números de versão, etc.) e distribuir os dados criptografados como a chave.
Pode ser também vale a pena ler as respostas para esta pergunta , bem
Existem algumas ferramentas e APIs disponíveis para isso. No entanto, acho que você não encontrará um de graça;)
Existe, por exemplo, o pacote OLicense: http://www.olicense.de/index.php?lang=en
Você pode verificar LicenseSpot . Ele fornece:
Vou pegar carona na ótima resposta de @frankodwyer e me aprofundar um pouco mais no licenciamento online. Sou o fundador da Keygen , uma API REST de licenciamento desenvolvida para desenvolvedores.
Uma vez que você mencionou o desejo de 2 "tipos" de licenças para o seu aplicativo, ou seja, uma "versão completa" e uma "versão de teste", podemos simplificar isso e usar um modelo de licença de recurso onde você licencia recursos específicos do seu aplicativo (neste caso, há um conjunto de recursos "completo" e um conjunto de recursos de "teste").
Para começar, poderíamos criar 2 tipos de licença (chamados de políticas no Keygen) e sempre que um usuário registrar uma conta, você pode gerar uma licença de "teste" para ele começar (a licença "teste" implementa nossa política de recursos de "teste") , que você pode usar para fazer várias verificações dentro do aplicativo, por exemplo, o usuário pode usar Trial-Feature-A e Trial-Feature-B .
E, com base nisso, sempre que um usuário comprar seu aplicativo (seja usando PayPal, Stripe, etc.), você pode gerar uma licença implementando a política de recursos "completa" e associá-la à conta do usuário . Agora, em seu aplicativo, você pode verificar se o usuário tem uma licença "completa" que pode fazer Pro-Feature-X e Pro-Feature-Y (fazendo algo comouser.HasLicenseFor(FEATURE_POLICY_ID) ).
Mencionei permitir que seus usuários criem contas de usuário - o que quero dizer com isso? Eu falei sobre isso em detalhes em algumas outras respostas , mas um rápido resumo do motivo pelo qual acho que esta é uma maneira superior de autenticar e identificar seus usuários:
Claro, se você não quiser lidar com contas de usuário e quiser que seus usuários insiram as chaves de licença, tudo bem (e a Keygen também oferece suporte para fazer isso ). Estou apenas oferecendo outra maneira de lidar com esse aspecto do licenciamento e, com sorte, fornecer uma UX agradável para seus clientes.
Por fim, como você também mencionou que deseja atualizar essas licenças anualmente, pode definir uma duração em suas políticas para que as licenças "completas" expirem após um ano e as licenças de "teste" durem, digamos, 2 semanas, exigindo que seus usuários comprem um novo licença após a expiração.
Eu poderia me aprofundar mais, associando máquinas a usuários e coisas assim, mas pensei em tentar manter esta resposta curta e me concentrar em simplesmente licenciar recursos para seus usuários.
Verifique esta resposta: https://stackoverflow.com/a/38598174/1275924
A ideia é usar Cryptolens como servidor de licença. Aqui está um exemplo passo a passo (em C # e VB.NET). Também anexei um snippet de código para verificação de chave abaixo (em C #):
var licenseKey = "GEBNC-WZZJD-VJIHG-GCMVD";
var RSAPubKey = "{enter the RSA Public key here}";
var auth = "{access token with permission to access the activate method}";
var result = Key.Activate(token: auth, parameters: new ActivateModel()
{
Key = licenseKey,
ProductId = 3349,
Sign = true,
MachineCode = Helpers.GetMachineCode()
});
if (result == null || result.Result == ResultType.Error ||
!result.LicenseKey.HasValidSignature(RSAPubKey).IsValid())
{
// an error occurred or the key is invalid or it cannot be activated
// (eg. the limit of activated devices was achieved)
Console.WriteLine("The license does not work.");
}
else
{
// everything went fine if we are here!
Console.WriteLine("The license is valid!");
}
Console.ReadLine();