Como impedir que outras pessoas usem meu assembly .Net?

Eu tenho um assembly que deve não ser usado por qualquer aplicativo que não seja o executável designado. Por favor me dê algumas instruções para fazer isso.

0
adicionado editado
Visualizações: 1
adicionado o autor Darren Kopp, fonte

13 Respostas

100% completamente impossível sem saltar através de alguns aros.

Uma das vantagens de usar o .NET é a capacidade de usar a reflexão, carregar uma montagem e inspecioná-la, chamar métodos dinamicamente, etc. Isso é o que possibilita a interoperabilidade entre VB.NET e F #.

No entanto, como seu código está em um assembly gerenciado, isso significa que qualquer pessoa pode adicionar uma referência ao seu código e invocar seus métodos públicos ou carregá-lo usando reflexão e chamar métodos privados . Mesmo que você ofusque seu código, as pessoas ainda poderão usar reflexão e invocar seu código. No entanto, uma vez que todos os nomes serão mascarados, fazer qualquer coisa é proibitivamente difícil.

Se você precisar enviar seu código .NET de uma maneira que impeça outras pessoas de executá-lo, você poderá usar seu binário NGEN (compilá-lo para x86) e enviar esses binários.

Eu não sei os detalhes da sua situação, mas a ofuscação deve ser boa o suficiente.

0
adicionado
Sim, você pode carregar dinamicamente uma DLL não gerenciada e executá-la também - no entanto, você precisa saber: o endereço de memória do código, o número/tipo de parâmetros, como controlar esses parâmetros etc. Chamando códigos não gerenciados para fazer coisas é praticamente impossível sem ter a fonte.
adicionado o autor Chris Smith, fonte
Eu não tenho certeza de como isso vai me ajudar ... se é um assembly .net ou um assembly nativo, qualquer um deve ser capaz de carregá-lo corretamente.
adicionado o autor cathy, fonte

Exija apenas um código de acesso para ser enviado usando uma chamada de função e, se ele não tiver sido autorizado, nada funcionará, como .setAuthorizeCode ('123456') e, em cada local que possa ser usado, verifique se authorizeCode! = 123456 em seguida, lançar erro ou simplesmente sair ... Não soa como uma boa resposta para reutilização, mas esse é exatamente o ponto.

A única vez que isso poderia ser usado é por você e quando você codificar o código de autorização no programa.

Apenas um pensamento, poderia ser o que você está procurando ou poderia inspirá-lo para algo melhor.

0
adicionado

Não tenho certeza se esse é um caminho disponível para você, mas talvez você possa hospedar o assembly usando serviços da Web do WCF ou ASP.NET e usar algum tipo de esquema de autenticação (LDAP, pares de chaves pública/rpiva, etc.) para garantir somente clientes permitidos se conectam. Isso manteria sua montagem fisicamente fora das mãos de qualquer outra pessoa e você pode controlar quem se conecta a ela. Apenas um pensamento.

0
adicionado

Você pode usar ofuscação.

Isso vai virar:

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);

Em algo ilegível como:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);

Outros ainda poderão usar sua montagem, mas será difícil fazer qualquer coisa sensata.

0
adicionado

Você pode assinar o assembly e o executável com a mesma chave e, em seguida, colocar uma verificação no construtor das classes que deseja proteger:

public class NotForAnyoneElse {
  public NotForAnyoneElse() {
    if (typeof(NotForAnyoneElse).Assembly.GetName().GetPublicKeyToken() != Assembly.GetEntryAssembly().GetName().GetPublicKeyToken()) {
      throw new SomeException(...);
    }
  }
}
0
adicionado
Eu só consegui fazer isso funcionar depois de converter os tokens em uma string, por exemplo BitConverter.ToString (typeof (NotForAnyoneElse) .Assembly.GetN & zwnj; ame (). GetPublicKeyTo & zwnj; ken ())
adicionado o autor JohnZaj, fonte
Eu acho que a opção InternalsVisibleTo mencionada abaixo é melhor. É a mesma coisa que esta resposta, sem a codificação. Você precisa assinar os assemblies para que o InternalsVisibleTo funcione. Com ambas as técnicas, outros usuários podem ver os métodos e chamá-los usando reflexão; mas ambas as técnicas falharão se o assembly de chamada não tiver a mesma chave.
adicionado o autor Rob Kraft, fonte

Você deve conseguir fazer tudo internamente no escopo e, em seguida, usar o InternalsVisibleTo Atributo para conceder somente aquele assembly acesso aos métodos internos.

0
adicionado
pode bater a reflexão?
adicionado o autor cathy, fonte

The Code Access Security attribute that @Charles Graham mentions is StrongNameIdentityPermissionAttribute

0
adicionado
desse link - no .NET Framework versão 2.0 e posterior, as demandas por permissões de identidade são ineficazes se o assembly de chamada tiver confiança total.
adicionado o autor cathy, fonte

No .Net 2.0 ou melhor, faça tudo interno e, em seguida, use Friend Assemblies

http://msdn.microsoft.com/pt-br/library/0tke9fxk.aspx

Isso não irá parar a reflexão. Eu quero incorporar algumas das informações abaixo. Se você realmente precisa impedir que alguém ligue, provavelmente a melhor solução é:

  1. ILMerge o arquivo .exe e .dll
  2. ofuscar o arquivo .exe final

Você também pode verificar a pilha de chamadas e obter a montagem para cada chamador e certificar-se de que todas elas estejam assinadas com a mesma chave da montagem.

0
adicionado
Isso vai bater a reflexão?
adicionado o autor cathy, fonte
Não, para vencer a reflexão, você precisa ofuscar.
adicionado o autor Rick Minerich, fonte

Você pode ser capaz de definir isso nas políticas de segurança de acesso ao código no assembly.

0
adicionado

Como algumas pessoas mencionaram, use o atributo InternalsVisibleTo e marque tudo como interno. Isto, obviamente, não protege contra a reflexão.

One thing that hasnt been mentioned is to ilmerge your assemblies into your main .exe/.dll/whatever, this will up the barrier for entry a bit (people won't be able to see your assemby sitting on its own asking to be referenced), but wont stop the reflection route..

ATUALIZAÇÃO: Além disso, o IIRC, ilmerge tem um recurso onde pode automaticamente internalizar os conjuntos mesclados, o que significa que você não precisa usar internalsVisibleTo em tudo

0
adicionado
ironicamente, esse mesmo conjunto está sendo carregado sob demanda usando reflexão. Eu acho que não há maneira infalível de evitar isso.
adicionado o autor cathy, fonte

Você também pode procurar usar o compactador e compactador Netz .

Isso leva seus assemblies e seu arquivo .exe e os empacota em um único executável para que eles não fiquem visíveis para o mundo externo sem um pouco de pesquisa.

Meu palpite é que isso é suficiente para impedir o acesso da maioria dos programadores .net.

Um grande benefício da abordagem .netz é que ela não exige que você altere seu código. Outro benefício é que isso realmente simplifica o processo de instalação.

0
adicionado

Se o assembly era um serviço da web, por exemplo, você poderia garantir que o executável designado passasse um valor secreto na mensagem SOAP.

0
adicionado

Parece que você está procurando por uma ferramenta de proteção ou ofuscação. Embora não exista uma solução, a ferramenta de proteção que eu recomendo é smartassembly . Algumas alternativas são Salamandra Obfuscator , dotfuscator e Xenocode .

Infelizmente, se você der seus bytes para alguém para ser lido ... se eles tiverem tempo e esforço suficientes, eles poderão encontrar uma forma de carregar e chamar seu código. Para responder preventivamente a um comentário, vejo você perguntar com frequência: Salamander impedirá que seu código seja carregado diretamente na ferramenta Reflector, mas eu tive experiências melhores (ou seja: mais confiáveis) com o smartassembly.

Espero que isto ajude. :)

0
adicionado