Ferramentas / estratégia de ofuscação do .NET [fechado]

Meu produto possui vários componentes: ASP.NET, Windows Forms App e Windows Service. 95% ou mais do código está escrito em VB.NET.

Por motivos de propriedade intelectual, preciso ofuscar o código e, até agora, tenho usado uma versão do dotfuscator com mais de 5 anos. Estou pensando que é hora de mudar para uma ferramenta de nova geração. O que estou procurando é uma lista de requisitos que devo considerar ao procurar um novo ofuscador.

O que sei que devo procurar até agora:

• Serialização / desserialização . Na minha solução atual, eu simplesmente digo à ferramentapara não ofuscar nenhum membro dos dados da classe porque a dor de não poder carregar dados que anteriormente eram serializados é simplesmente muito grande.
• Integração com o Processo de Construção
• Trabalhando com o ASP.NET . No passado, eu achei isso problemático devido à alteração de nomes .dll (você costuma ter um por página) - que nem todas as ferramentas lidam bem.

De volta à ofuscação do .Net 1.1, era essencial: descompilar o código era fácil e era possível ir do assembly até o IL e o código C # e compilá-lo novamente com muito pouco esforço.

Agora, com o .Net 3.5, não tenho certeza. Tente descompilar um assembly 3.5; o que você recebe é um longo caminho desde a compilação.

Adicione as otimizações de 3.5 (muito melhores que 1.1) e a maneira como tipos anônimos, delegados e assim por diante são tratados pela reflexão (eles são um pesadelo para recompilar). Adicione expressões lambda, 'mágica' do compilador, como sintaxe Linq e var, e funções C # 2 como yield(o que resulta em novas classes com nomes ilegíveis). Seu código descompilado termina muito longe de ser compilável.

Uma equipe profissional com muito tempo ainda pode fazer a engenharia reversa novamente, mas o mesmo vale para qualquer código ofuscado. O código que eles obtiveram seria insustentável e provavelmente muito problemático.

Eu recomendaria assinar com chave seus assemblies (o que significa que se os hackers puderem recompilar um, eles precisam recompilar todos), mas não acho que a ofuscação valha a pena.

Tentamos vários ofuscadores. Nenhum deles funciona em um aplicativo cliente / servidor grande que usa comunicação remota. O problema é que o cliente e o servidor compartilham algumas DLLs, e não encontramos nenhum ofuscador que possa lidar com isso.

Tentamos DotFuscator Pro, SmartAssembly, XenoCode, Salamander e vários aplicativos pequenos cujos nomes me escapam.

Francamente, estou convencido de que a ofuscação é um grande truque.

Mesmo os problemas que ele aborda não são inteiramente um problema real. A única coisa que você realmente precisa proteger são cadeias de conexão, códigos de ativação, coisas sensíveis à segurança assim. Essa bobagem de que outra empresa vai fazer engenharia reversa de toda a sua base de código e criar um produto concorrente é algo do pesadelo de um gerente paranóico, não da realidade.

Eu sou 'Joelho profundo' nisto agora, tentando encontrar uma boa solução. Aqui estão as minhas impressões até agora.

Xenocode - Eu tenho uma licença antiga para o Xenocode2005 que costumava usar para ofuscar meus assemblies .net 2.0. Funcionou bem no XP e foi uma solução decente. Meu projeto atual é .net 3.5 e eu estou no Vista, o suporte me pediu para tentar, mas a versão de 2005 nem funciona no Vista (falhas), então eu e agora tenho que comprar o 'PostBuild2008' a um preço alto de $ 1900. Essa pode ser uma boa ferramenta, mas não vou descobrir. Muito caro.

Reactor.Net - Esse é um preço muito mais atraente e funcionou bem no meu Executável independente. O módulo Licenciamento também foi bom e teria me poupado muito esforço. Infelizmente, está faltando um recurso essencial e essa é a capacidade de excluir coisas da ofuscação. Isso torna impossível alcançar o resultado que eu precisava (mesclar várias montagens, ofuscar alguns, não ofuscar outros).

SmartAssembly - baixei o Eval para isso e funcionou perfeitamente. Consegui alcançar tudo o que queria e a Interface era de primeira classe. O preço ainda é um pouco alto.

Dotfuscator Pro - Não foi possível encontrar o preço no site. Atualmente em discussões para obter uma cotação. Parece ameaçador.

Confuser - um projeto de código aberto que funciona muito bem (para confundir pessoas, exatamente como o nome indica).

Nota: O ConfuserEx está "quebrado" de acordo com a Edição # 498 no repositório do GitHub.

Se você está procurando um gratuito, pode experimentar o DotObfuscator Community Edition que acompanha o Visual Studio ou o Eazfuscator.NET .

Desde 29 de junho de 2012 , o Eazfuscator.NET agora é comercial. A última versão gratuita disponível é 3.3.

Eu tenho usado smartassembly. Basicamente, você escolhe uma dll e ela retorna ofuscada. Parece funcionar bem e até agora não tive problemas. Muito, muito fácil de usar.

Eu tentei quase todos os ofuscadores no mercado e o SmartAssembly é o melhor na minha opinião.

Também uso o SmartAssembly. Eu achei o Ezrinz .Net Reactor muito melhor para mim em aplicativos .net. Ele ofusca, suporta o Mono, mescla montagens e também possui um módulo de licenciamento muito bom para criar uma versão de avaliação ou vincular a licença a uma máquina específica (muito fácil de implementar). O preço também é muito competitivo e, quando eu precisava de suporte, eles eram rápidos. Eziriz

Só para esclarecer, sou apenas um cliente que gosta do produto e não tem relação alguma com a empresa.

A resposta curta é que você não pode.

Existem várias ferramentas que dificultam a leitura do seu código - algumas das quais foram apontadas por outras respostas.

No entanto, tudo o que fazemos é dificultar a leitura - eles aumentam a quantidade de esforço necessária, isso é tudo. Geralmente, isso é suficiente para impedir leitores casuais, mas alguém que está determinado a cavar seu código sempre será capaz de fazê-lo.

Temos um aplicativo de várias camadas com uma interface asp.net e winform que também suporta comunicação remota. Não tive problemas com o uso de qualquer ofuscador, com exceção do tipo de criptografia que gera um carregador que pode ser problemático de todas as formas inesperadas e não vale a pena na minha opinião. Na verdade, meu conselho seria mais parecido com "Evite criptografar ofuscadores do tipo carregador, como a praga". :)

Na minha experiência, qualquer ofuscador funcionará bem em qualquer aspecto do .net, incluindo asp.net e remoting, você só precisa se familiarizar com as configurações e aprender até onde pode empurrá-lo em quais áreas do seu código. E reserve um tempo para tentar fazer engenharia reversa no que você obtém e ver como ele funciona com as várias configurações.

Usamos vários aplicativos ao longo dos anos e optamos pelo ofuscador Spices da 9rays.net porque o preço é justo, ele faz o trabalho e eles têm um bom suporte, embora não precisemos mais do suporte há anos, mas para ser sincero Eu não acho que realmente importe qual ofuscador você usa, os problemas e a curva de aprendizado são todos iguais, se você quiser que ele funcione corretamente com o remoting e o asp.net.

Como outros já mencionaram, tudo o que você realmente está fazendo é o equivalente a um cadeado, mantendo pessoas honestas de fora e / ou dificultando a recompilação de um aplicativo.

O licenciamento é geralmente a área principal da maioria das pessoas e você definitivamente deve usar algum tipo de sistema de certificado assinado digitalmente para licenciamento. Sua maior perda virá do compartilhamento ocasional de licenças, se você não tiver um sistema inteligente, as pessoas que quebram o sistema de licenciamento nunca comprariam.

É realmente fácil levar isso longe demais e ter um impacto negativo em seus clientes e em seus negócios, fazer o que é simples e razoável e não se preocupar com isso.

Nos últimos dois dias, experimentei o Dotfuscator Community Edition avançado (um download gratuito depois de registrar o CE básico que acompanha o Visual Studio).

Eu acho que a razão pela qual mais pessoas não usam ofuscação como opção padrão é que é um sério problema em comparação com o risco. Em projetos de teste menores, pude executar o código ofuscado com muito esforço. A implantação de um projeto simples via ClickOnce era problemática, mas viável após a assinatura manual dos manifestos com o mage. O único problema foi que, por erro, o rastreamento da pilha voltou ofuscado e o CE não possui um desobfuscador ou clarificador empacotado.

Tentei ofuscar um projeto real baseado em VSTO no Excel, com integração com o Virtual Earth, muitas chamadas de serviço da web e um contêiner do IOC e muito reflexo. Era impossível.

Se a ofuscação é realmente um requisito crítico, você deve projetar seu aplicativo com isso em mente desde o início, testando as construções ofuscadas à medida que avança. Caso contrário, se for um projeto bastante complexo, você acabará sofrendo bastante.

O Ofuscador de criptografia aborda todas as suas preocupações e cenários. Isto :

1. Exclui automaticamente tipos / membros da ofuscação com base em regras. Tipos / campos serializados são um deles.
2. Ele pode ser integrado ao processo de compilação usando o MSBUild.
3. Oferece suporte a projetos ASP.Net.

Recentemente, tentei canalizar a saída de um ofuscador gratuito para outro ofuscador gratuito - o Dotfuscator CE e o novo ofuscador Babel no CodePlex. Mais detalhes no meu blog .

Quanto à serialização, movi esse código para uma DLL diferente e a incluí no projeto. Eu raciocinei que não havia nenhum segredo lá que não estivesse no XML, então não precisava de ofuscação. Se houver algum código sério nessas classes, o uso de classes parciais no assembly principal deve cobri-lo.

Você deve usar o que for mais barato e mais conhecido para sua plataforma e chamá-lo por dia. A ofuscação de idiomas de alto nível é um problema difícil, porque os fluxos de opcode da VM não sofrem dos dois maiores problemas que os fluxos de opcode nativos apresentam: identificação de função / método e alias de registro.

O que você deve saber sobre a reversão de bytecode é que já é prática padrão para os testadores de segurança revisar o código X86 direto e encontrar vulnerabilidades nele. No X86 bruto, você não pode necessariamente encontrar funções válidas, muito menos rastrear uma variável local durante uma chamada de função. Em quase nenhuma circunstância, os inversores de código nativo têm acesso a nomes de funções e variáveis ​​- a menos que estejam revisando o código da Microsoft, para o qual a MSFT fornece essas informações ao público.

"Dotfuscation" funciona principalmente por função de codificação e nomes de variáveis. Provavelmente é melhor fazer isso do que publicar código com informações no nível de depuração, onde o Reflector está literalmente desistindo do seu código-fonte. Mas qualquer coisa que você faça além disso provavelmente terá retornos decrescentes.

Não tive problemas com o Smartassembly.

Você pode usar o "Dotfuscator Community Edition" - ele vem por padrão no Visual Studio 2008 Professional. Você pode ler sobre isso em:

http://msdn.microsoft.com/en-us/library/ms227240%28VS.80%29.aspx
http://www.preemptive.com/dotfuscator.html

A versão "Profissional" do produto custa dinheiro, mas é melhor.

Você realmente precisa do seu código ofuscado? Geralmente, há muito pouco problema com o seu aplicativo ser descompilado, a menos que seja usado para fins de segurança. Se você está preocupado com as pessoas "roubando" seu código, não fique; a grande maioria das pessoas que analisam seu código será para fins de aprendizado. De qualquer forma, não existe uma estratégia de ofuscação totalmente eficaz para o .NET - alguém com habilidade suficiente sempre será capaz de descompilar / alterar seu aplicativo.

Evite o reator. É completamente inútil (e sim, eu paguei por uma licença). O Xenocode foi o melhor que encontrei e comprei uma licença também. O apoio foi muito bom, mas eu não precisava muito, pois funcionava. Eu testei todos os ofuscadores que pude encontrar e minha conclusão é que o xenocode foi de longe o mais robusto e fez o melhor trabalho (também a possibilidade de pós-processar o seu .NET exe em um exe nativo que eu não via em nenhum outro lugar).

Existem duas diferenças principais entre reator e xenocódigo. O primeiro é que o Xenocode realmente funciona. A segunda é que a velocidade de execução de suas montagens não é diferente. Com o reator, foi cerca de 6 milhões de vezes mais lento. Também tive a impressão de que o reator era uma operação de um homem.

Eu achei o Agile.Net uma proteção muito boa para o seu. Net Assembly porque ele oferece não apenas ofuscação, mas também criptografia. Faça o download de uma trilha gratuita.
http://secureteam.net/NET-Code-Protection.aspx http://secureteam.net/downloads.aspx

Venho ofuscando código no mesmo aplicativo desde .Net 1, e tem sido uma grande dor de cabeça do ponto de vista de manutenção. Como você mencionou, o problema de serialização pode ser evitado, mas é realmente fácil cometer um erro e ofuscar algo que você não queria ofuscar. É fácil interromper a compilação ou alterar o padrão de ofuscação e não conseguir abrir arquivos antigos. Além disso, pode ser difícil descobrir o que deu errado e onde.

Nossa escolha foi o Xenocode e, se eu fizesse a escolha novamente hoje, preferiria não ofuscar o código ou usar o Dotfuscator.

Aqui está um documento da própria Microsoft. Espero que ajude ..., é de 2003, mas ainda pode ser relevante.

Estamos usando o SmartAssembly em nosso cliente Windows. Funciona muito bem.

Adiciona alguns problemas extras também. A impressão dos nomes das suas classes em arquivos de log / exceções deve ser ocultada. E, claro, não pode criar uma classe a partir do nome. Portanto, é uma boa ideia dar uma olhada no seu cliente e ver quais problemas você pode obter ofuscando.

Tudo depende da linguagem de programação que você usa. Leia o artigo: Código ofuscado

a maneira gratuita seria usar o dotfuscator de dentro do visual studio; caso contrário, você teria que comprar um ofuscador como o Postbuild ( http://www.xenocode.com/Landing/Obfuscation.aspx )

Eu tive que usar uma proteção de ofuscação / recurso no meu rpoject mais recente e achei o Crypto Obfuscator como uma ferramenta agradável e simples de usar. O problema de serialização é apenas uma questão de configurações nesta ferramenta.

Existe uma boa versão de código aberto chamada Obfuscar. Parece funcionar bem. Tipos, propriedades, campos, métodos podem ser excluídos. O original está aqui: https://code.google.com/p/obfuscar/ , mas como parece não estar mais atualizado

Você também pode procurar novas tecnologias de proteção de código, como Metaforic e ViLabs, e novas tecnologias de proteção de cópia de software, como ByteShield . Divulgação: Eu trabalho para o ByteShield.

Eu também uso montagem inteligente. No entanto, não sei como funciona para um aplicativo da web. No entanto, gostaria de ressaltar que, se seu aplicativo usa proteção do tipo shareware, verifique se não verifica uma licença com retorno booleano. é muito fácil byte crack. http://blogs.compdj.com/post/Binary-hack-a-NET-executable.aspx

O SmartAssembly é ótimo, fui usado na maioria dos meus projetos

Eu tentei a versão demo do Eziriz .... gostei. Mas nunca trouxe o software.

Ofuscar não é uma proteção real.

Se você possui um arquivo .NET Exe, existe uma solução MUITO melhor .

Eu uso Themida e posso dizer que funciona muito bem.

A única desvantagem do Themida é que ele não pode proteger as DLLs do .NET. (Ele também protege o código C ++ no Exe e nas DLLs)

Themida é de longe mais barato do que os obfuscators aqui mencionados e é o melhor anti pirataria de proteção no mercado. Ele cria uma máquina virtual na qual partes críticas do seu código são executadas e executa vários threads que detectam manipulação ou pontos de interrupção definidos por um cracker. Ele converte o .NET Exe em algo que o Reflector nem sequer reconhece como um assembly .NET.

Por favor, leia a descrição detalhada em seu site: http://www.oreans.com/themida_features.php

Eu tentei um produto chamado Rummage e ele faz um bom trabalho em dar-lhe algum controle ... Embora falte muitas coisas que Eziriz oferece, mas o preço para Rummage é bom demais ...