none
Protegendo DLLs RRS feed

  • Pergunta

  • Pessoal,

    Alguém sabe a técnica de proteger uma DLL contra uso indevido?

    Encontrei várias dicas na WEB utilizando CAS - Code Access Security, utilizando chave prublica/privada para assinar e proteger DLLs.

    Porém, TODOS os exemplos que encontrei são incompletos e a maioria não funciona,  pois falta sempre alguma coisa q não sei o que é. E tem mais um agravante, os exemplos na maioria é para VS2003 e não para VS2005 que aparentemente é diferente.

    Como não tenho conhecimento prévio do assunto não consigo decifrar  o que é preciso fazer.

    Pois bem, vamos ao resumo do que consegui até o momento, espero que alguém que entenda do assunto possa me ajudar, e desde de já agradeço.

    --> Meu objetivo:

    Proteger minhas DLLs pra evitar que outras pessoas não autorizadas possam utiliza-las.

    --> Método para proteger:

    Assinar minhas DLLs e meus aplicativos com um conjunto de chaves publica/privada. Desta forma, eu posso chamar minhas DLLs sem restrições, mas, caso alguém queira utilizar minhas DLLs terá de ter um aplicativo (chamador) assinado com minha chave, que não vou passar claro ;-)

    --> Procedimento

    1. Criar um conjunto de chaves utilizando o seguinte comando do prompt do VS:

    ** Este passo funciona.

    sn - k chave.snk

    2. Assinar minha aplicação e DLL adicionando o seguinte item ao assemblyInfo.vb da aplicação e da DLL :

    ** Este passo funciona

    <assembly:Assemblykeyfile("c:\projeto\chave.snk")>

    3. Descobrir a chave publica contida no arquivo chave.snk:

    ** Aqui aparece um problema, toda documentação que encontrei informa que devo usar o comando "sn -tp chave.snk" para visualizar a chave pública, porém este comando dá o seguinte erro "Failed to convert key to token". Em um forum americano encontrei uma solução e foi a que adotei, e devo fazer em 2 comandos:

    sn -p chave.snk chavepub.snk 

    sn -tp chavepub.snk 

    O resultado é algo deste tipo:

    Public key is
    00240000048000009400000006020000002400005253413100040000010001002d84fd878122c7
    b01191c83c6b35aa12a729989cfb3054d1cc08fd7a8b60b650ba35008048a6f4da014ccc54583a
    9f71cc32a44cb8321fa8b0ebf55e988dcea8f089bc6425949a154612a0e71cae2d78df7de66e3d
    9d53c6cfa0c84dc8a0767aee142a9f752bd34274d5c0409c8975fceba2664df5dab01c9dd485b0
    7f0ede9f

    Public key token is dea3e7825a88aa9f

     

    4. Inserir nas classes da DLL um atributo que cause restrição desejada:

    <System.Security.Permissions.StrongNameIdentityPermission(Security.Permissions.SecurityAction.LinkDemand, PublicKey:= _

    "00240000048000009400000006020000002400005253413100040000010001002d84fd878122c7" + _

    "b01191c83c6b35aa12a729989cfb3054d1cc08fd7a8b60b650ba35008048a6f4da014ccc54583a" + _

    "9f71cc32a44cb8321fa8b0ebf55e988dcea8f089bc6425949a154612a0e71cae2d78df7de66e3d" + _

    "9d53c6cfa0c84dc8a0767aee142a9f752bd34274d5c0409c8975fceba2664df5dab01c9dd485b0" + _

    "7f0ede9f")> _

    Public Class UserControl1

    ...

    End Class

     

    5. Fiz tudo isso, mas não funciona.

    - Criei uma DLL com um user control dentro. Assinei a DLL com minha chave.snk, coloquei a atributo de restrição na classe que gera o user control (como descrito acima.)

    - Criei uma aplicação e assinei com minha chave.snk, chamei a DLL e carreguei o user control sem nenhum problema.

    - Criei outra aplicação e não assinei, chamei a DLL e carreguei o user control sem nenhum problema também.

    A proteção não funcionou!

     

    6. Alguém, por favor, pode me dizer o fiz de errado?? Ou se está tudo errado??

    Desde já agradeço pela ajuda! Obrigado.

     

    quarta-feira, 19 de julho de 2006 16:51

Respostas

  • Não confundamos bananas com laranjas.

    Dotfuscator embaralha o assembly, mas não modifica seu comportamento em termos de segurança.

     

    "In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case."

     

    Veja bem, isso tem um motivo: Se você disse que seu assembly é full trust, você está passando por cima de todas as permissões possíveis.

    Daí temos duas opções:

    1-Tirar o full trust

    2-Usar reflection no código e investigar a identidade do assembly que faz a chamada.

    ;)

    segunda-feira, 22 de janeiro de 2007 07:06

Todas as Respostas

  • Eu também quero saber como posso proteger as DLL's?

    Não obtive sucesso em minhas buscas, se alguém souber, eu agradeço.

    Obrigado.

    sexta-feira, 1 de setembro de 2006 19:40
  • Eu também estou nesse barco !!! Por favor, se alguém encontrar por favor me enviem um e-mail...
    biogenoma99@hotmail.com

    valeu

    quinta-feira, 9 de novembro de 2006 16:03
  • Podem dar uma olhada.

    Acho que é isso que querem.

    http://www.remotesoft.com/salamander/obfuscator.html

    Abs

    Diogo Gomes

    quinta-feira, 9 de novembro de 2006 16:11
  • Olá Pessoal..

    veja se isso não resolve o problema de vc's... É uma ferramenta chamada de Dotfuscator.

    http://www.devaspnet.com.br/colunas2/coluna0501.aspx



    Espero ter ajudado, se caso sim, por favor, marque-a como tal.!
    terça-feira, 5 de dezembro de 2006 23:57
  • Estou com o mesmo problema.

    Até onde sei, o "DOTFUSCATOR" embaralha o código, dificultando a engenharia reversa (me corrijam se estiver errado), mas o que queremos é prevenir o acesso indevido. Não adianta nada o código fonte estar protegido se qualquer um que conheça os parâmetros pode usar a bilioteca.

    Usando o StrongNameIdentityPermission também não adianta, pois qualquer um que tenha acesso "Full Trusted" pode usar a assembly livremente. Pelas minhas pesquisas, o ASP.NET 2.0 simplesmente não permite este tipo de proteção.

    Aceito outras sugestões.

    quinta-feira, 18 de janeiro de 2007 13:46
  • Não confundamos bananas com laranjas.

    Dotfuscator embaralha o assembly, mas não modifica seu comportamento em termos de segurança.

     

    "In the .NET Framework versions 1.0 and 1.1, demands on the identity permissions are effective, even when the calling assembly is fully trusted. That is, although the calling assembly has full trust, a demand for an identity permission fails if the assembly does not meet the demanded criteria. In the .NET Framework version 2.0, demands for identity permissions are ineffective if the calling assembly has full trust. This assures consistency for all permissions, eliminating the treatment of identity permissions as a special case."

     

    Veja bem, isso tem um motivo: Se você disse que seu assembly é full trust, você está passando por cima de todas as permissões possíveis.

    Daí temos duas opções:

    1-Tirar o full trust

    2-Usar reflection no código e investigar a identidade do assembly que faz a chamada.

    ;)

    segunda-feira, 22 de janeiro de 2007 07:06
  •  

    Caro Mateus,

     

    Obrigado pela resposta e atenção. E desculpe pelo desabafo a seguir.

     

    Mas eu desisti de proteger meus projetos simplesmente pela extrema falta de documentação e suporte em relação a esse assunto.

     

    Esse assunto sobre 'como proteger DLLs' eu encontro em dezenas de fóruns e NUNCA encontrei uma resposta realmente funcional. Só existe teoria e NENHUM exemplo prático. Parece tabu falar sobre proteção, pois até hoje ninguém foi capaz de dar um exemplo de como isso funciona...

     

    Enfim estou aqui de volta a esse assunto, pois o que eu temia aconteceu! Estão usando minhas DLLs sem minha permissão.

     

    Peço, por gentileza, que me de as dicas para conseguir proteger uma DLL contra o uso não autorizado.

     

    (Utilizo VB 2005)

     

    Vamos as dúvidas:

    - Você fala em tirar o 'full trust', mas eu não consegui achar onde fazer isso. O único lugar que encontrei essa opção é na configuração de segurança do Click-Once, mas eu não estou utilizando Click-Once. Tem outro lugar?

     

    - Usar reflection e investigar a identidade... como faço isso?  

     

    Desde já agradeço pela ajuda.

     

    Caso você conheça algum livro ou site que tenha um 'passo-passo'  (que funcione  )de como implementar esse tipo de segurança, ficaria muito agradecido pela dica.

     

    Grato.

     

    sexta-feira, 1 de junho de 2007 14:39
  • Fulltrust é uma configuração na sua máquina. Ferramentas adminstrativas, .Net Framework Configuration, my computer, runtime security policy. Por default, tudo que roda local tem full trust a menos que você mude.

     

     

    Para saber quem chamou seu assembly você pode fazer assim:

     

    System.Reflection.Assembly.GetCallingAssembly().FullName

     

    Ou você pode pegar assim, se quiser saber qual o executável que começou toda a conversa até chegar no seu assembly:

     

    System.Reflection.Assembly.GetEntryAssembly().FullName

     

      Por esse caminho você pode pegar o nome do assembly, sua chave, versão e até saber em que diretório ele está rodando.

     

    Livro passo a passo eu não sei te falar, mas tem alguns cursos Microsoft interessantes nessa parte de segurança de aplicações...

    quarta-feira, 6 de junho de 2007 01:37
  • Muito obrigado Mateus pela resposta.

     

    Vou fazer alguns testes com suas dicas, e agora que algumas coisas ficaram mais claras vai ficar mais fácil procurar documentação a respeito.

    Vou tb entrar em contato com a MS para ver que tipo de curso é mais interessante sobre esse assunto.

     

    Valeu! ;-)

     

    segunda-feira, 11 de junho de 2007 01:10
  • Galera,

    Existe um livro que trata somento de segurança de DLL's, o nome desse livro é Programming .NET Security.

    Segue algumas partes do índice do livro:

    Part I:  Fundamentals
    Chapter 1.  Security Fundamentals
    Section 1.1.  The Need for Security
    Section 1.2.  Roles in Security
    Section 1.3.  Understanding Software Security
    Section 1.4.  End-to-End Security

    Chapter 2.  Assemblies
    Section 2.1.  Assemblies Explained
    Section 2.2.  Creating Assemblies
    Section 2.3.  Shared Assemblies
    Section 2.4.  Strong Names
    Section 2.5.  Publisher Certificates
    Section 2.6.  Decompiling Explained

     Chapter 3.  Application Domains
    Section 3.1.  Application Domains Explained

     Chapter 4.  The Lifetime of a Secure Application
    Section 4.1.  Designing a Secure .NET Application
    Section 4.2.  Developing a Secure .NET Application
    Section 4.3.  Security Testing a .NET Application
    Section 4.4.  Deploying a .NET Application
    Section 4.5.  Executing a .NET Application
    Section 4.6.  Monitoring a .NET Application

     

    Part II:  .NET Security
    Chapter 5.  Introduction to Runtime Security
    Section 5.1.  Runtime Security Explained
    Section 5.2.  Introducing Role-Based Security
    Section 5.3.  Introducing Code-Access Security
    Section 5.4.  Introducing Isolated Storage

    Chapter 6.  Evidence and Code Identity
    Section 6.1.  Evidence Explained
    Section 6.2.  Programming Evidence
    Section 6.3.  Extending the .NET Framework

    Chapter 7.  Permissions
    Section 7.1.  Permissions Explained
    Section 7.2.  Programming Code-Access Security
    Section 7.3.  Extending the .NET Framework

    Chapter 8.  Security Policy
    Section 8.1.  Security Policy Explained
    Section 8.2.  Programming Security Policy
    Section 8.3.  Extending the .NET Framework

    Chapter 9.  Administering Code-Access Security
    Section 9.1.  Default Security Policy
    Section 9.2.  Inspecting Declarative Security Statements
    Section 9.3.  Using the .NET Framework Configuration Tool
    Section 9.4.  Using the Code-Access Security Policy Tool

    Chapter 10.  Role-Based Security
    Section 10.1.  Role-Based Security Explained
    Section 10.2.  Programming Role-Based Security

    Chapter 11.  Isolated Storage
    Section 11.1.  Isolated Storage Explained
    Section 11.2.  Programming Isolated Storage
    Section 11.3.  Administering Isolated Storage

     

    Part III:  .NET Cryptography

    Chapter 12.  Introduction to Cryptography
    Section 12.1.  Cryptography Explained
    Section 12.2.  Cryptography Is Key Management
    Section 12.3.  Cryptographic Attacks

    Chapter 13.  Hashing Algorithms
    Section 13.1.  Hashing Algorithms Explained
    Section 13.2.  Programming Hashing Algorithms
    Section 13.3.  Keyed Hashing Algorithms Explained
    Section 13.4.  Programming Keyed Hashing Algorithms
    Section 13.5.  Extending the .NET Framework

    Chapter 14.  Symmetric Encryption
    Section 14.1.  Encryption Revisited
    Section 14.2.  Symmetric Encryption Explained
    Section 14.3.  Programming Symmetrical Encryption
    Section 14.4.  Extending the .NET Framework

    Chapter 15.  Asymmetric Encryption
    Section 15.1.  Asymmetric Encryption Explained
    Section 15.2.  Programming Asymmetrical Encryption
    Section 15.3.  Extending the .NET Framework

    Chapter 16.  Digital Signatures
    Section 16.1.  Digital Signatures Explained
    Section 16.2.  Programming Digital Signatures
    Section 16.3.  Programming XML Signatures
    Section 16.4.  Extending the .NET Framework

    Chapter 17.  Cryptographic Keys
    Section 17.1.  Cryptographic Keys Explained
    Section 17.2.  Programming Cryptographic Keys
    Section 17.3.  Extending the .NET Framework

    caso alguém queira o PDF do livro pode entrar em contato pelo e-mail leandro_lopez12@yahoo.com.br

    Espero ter ajudado.
    terça-feira, 9 de março de 2010 02:41
  • Como retirar o full trust de um assembly .NET?

    Sds.,

    Rubem Rocha
    Manaus, AM


    Sds., Rubem Rocha MCP, MCPD Manaus - AM
    sábado, 16 de julho de 2011 00:42
  • Você configura no Visual Studio o nivel de segurança do seu assembly.

    Project -> Properties -> Security


    Quem sabe um dia os DataSets se extinguirão?
    terça-feira, 19 de julho de 2011 11:24
  • Você pode me passar um guia passo-a-passo de como fazer isso?
    Sds., Rubem Rocha MCP, MCPD Manaus - AM
    sexta-feira, 22 de julho de 2011 16:41
  • Como o Mateus Veloso falou, os ofuscadores de código fazem com que quando você usa uma ferramenta para descompilar o código, o nome das variaveis fique diferente. Por exemplo se vc usar o .Net reflector, as variaveis vão aparecer como a, b, c, porém isso não garante que eles não vao olhar e copiar o seu código.

    Já quando você assina um assembly, e usa apenas assemblies assinados em seu projeto, isso garante que o programa só ira rodar se vc utilizar aquele assembly, com aquela assinatura. Por exemplo se alguma pessoa mal intencionada tentar modificar alguma dll sua, e compilar novamente e jogar no diretorio de sua aplicação, a aplicação vai lançar uma exceção pois a assinatura da dll, não é a mesma. Por isso é muito importante assinar todas as suas dlls do projeto. Você faz isso nas propriedades do projeto, na Aba Signing -> Sign the Assembly, é bem simples de se fazer.

    E por terceiro, o Full trust, Medium trust se refere as permissões que o seu programa necessita do sistema operacional, em full trust, significa que o seu programa pode fazer o que quiser. Essas configurações podem mudar de maquina para maquina, pois se vc configurar que apenas assemblies assinados, rodam em Full trust na sua maquina, vc terá que assinar o seu assembly para que ele rode na maquina do cliente.

    É mais ou menos isso.


    Quem sabe um dia os DataSets se extinguirão?
    terça-feira, 26 de julho de 2011 18:54