Pensando nisso, existem vários tipos diferentes de ofuscação. Vamos começar com a ofuscação do código fonte, que é uma completa perda de tempo; já é difícil de entender sem isso! Então, vamos nos concentrar na ofuscação do pacote de entrega, de como o código é entregue ao usuário.
Ofuscação menor
Ocultação menor existe para impedir que o usuário casual enfie os dedos e quebre as coisas facilmente. Ele não impede o hacker determinado, mas tem valor em ajudar a garantir que as coisas que você é solicitado a apoiar sejam o que realmente entregou. O nível de proteção necessário para esse tipo de coisa é realmente bastante baixo; o pacote de entrega simplesmente não deve parecer legível e editável (sem ferramentas especializadas) e isso é bom o suficiente.
A minificação de Javascript é um exemplo disso, embora não seja comercializada como tal. Ninguém em sã consciência gostaria de ler e editar um arquivo JS minificado, mesmo que seja tecnicamente possível fazê-lo se você for determinado / persistente o suficiente.
Da mesma forma com o fornecimento de aplicativos Java. Apenas o empacotamento do código em um JAR executável interromperá a maioria das tolices, mesmo tendo toda a força de um sinal educado de "Por favor, mantenha a grama" em um parque da cidade.
Mesmo ao fornecer código C ++, retirar os símbolos desnecessários do executável será suficiente para se qualificar como ofuscação menor. A chave é que é estranho ler o resultado como usuário, mas não é um problema executá-lo como um computador.
Ofuscação grave
Ocultação principal é manter o usuário determinado e conhecedor de fora. É também um jogo de perder total; se um computador pode executá-lo, uma pessoa pode separá-lo e descobrir o que faz. O mais próximo que você poderia chegar seria tornar o programa descriptografado a si mesmo continuamente, transformando o que ele faz ao mesmo tempo em algo completamente diferente do que ele faz em outro momento. Criar uma coisa dessas seria bastante difícil e ainda assim não manteria um hacker muito bom de fora (embora eles fiquem realmente irritados com você no final do mesmo, com a quantidade de esforço necessária para descriptografar todo esse código auto-modificável).
É muito melhor pensar em termos de outras soluções. Por exemplo, você pode manter as "jóias da coroa" do código nos servidores que você controla e apenas permitir chamadas de serviço, tornando o cliente uma oferta essencialmente gratuita, que é um front-end para os bits valiosos. Ou você pode seguir a rota mais contratual / legal e entregar os executáveis apenas às organizações que concordam formalmente em não mexer no seu código ou compensá-lo se o fizerem (para que seja algum tipo de NDA). O objetivo seria criar um forte incentivo para o hacker não invadir e para os usuários manterem o código longe de hackers não vinculados pelo contrato.
Mas você não deve assumir que seu código nunca pode ser quebrado. Com a virtualização, qualquer estado de execução de um programa pode ser examinado e rastreado, e qualquer coisa que tente derrotar isso (por exemplo, rastreamento de relógio para uma fonte de tempo externa) terá muito mais probabilidade de causar problemas para usuários legítimos do que hackers. (Veja o histórico do DRM para saber até mesmo os editores de informações muito determinados não conseguem manter seus sistemas seguros quando o código está nas mãos de seus oponentes.) É muito melhor se concentrar em realmente fazer felizes usuários legítimos. As perdas resultantes do crack ocasional não serão nada comparadas ao dinheiro extra trazido pela satisfação adequada dos clientes.