Protegendo executável da engenharia reversa?

Estive pensando em como proteger meu código C / C ++ contra desmontagem e engenharia reversa. Normalmente eu nunca toleraria esse comportamento pessoalmente no meu código; no entanto, o protocolo atual em que estou trabalhando nunca deve ser inspecionado ou compreensível, para a segurança de várias pessoas.

Agora, este é um assunto novo para mim, e a Internet não é realmente uma ferramenta de prevenção contra engenharia reversa, mas descreve toneladas de informações sobre como fazer engenharia reversa

Algumas das coisas que pensei até agora são:

• Injeção de código (chamando funções fictícias antes e depois das chamadas reais de função)
• Erro de código (manipula a desmontagem do binário)

• Escrever minhas próprias rotinas de inicialização (mais difícil para os depuradores se ligarem)

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }

• Verificação de tempo de execução para depuradores (e forçar a saída se detectada)

• Função trampolins

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }

• Alocações e desalocações inúteis (a pilha muda muito)

• Chamadas fictícias inúteis e trampolins (toneladas de saltos na saída da desmontagem)
• Toneladas de fundição (para desmontagem ofuscada)

Quero dizer, essas são algumas das coisas em que pensei, mas todas podem ser contornadas e / ou descobertas por analistas de código, no prazo certo. Existe alguma outra alternativa que eu tenho?

O que Amber disse está exatamente certo. Você pode dificultar a engenharia reversa, mas nunca pode evitá-la. Você nunca deve confiar na "segurança" que se baseia na prevenção da engenharia reversa .

Dito isso, as melhores técnicas de engenharia anti-reversa que eu já vi focadas não em ofuscar o código, mas em quebrar as ferramentas que as pessoas geralmente usam para entender como o código funciona. Encontrar maneiras criativas de quebrar desmontadores, depuradores, etc. provavelmente será mais eficaz e também mais intelectualmente satisfatório do que apenas gerar resmas de códigos espaguetes horríveis. Isso não faz nada para bloquear um invasor determinado, mas aumenta a probabilidade de o J Random Cracker se afastar e trabalhar em algo mais fácil.

mas todos eles podem ser contornados e / ou descobertos por analistas de código no prazo certo.

Se você der às pessoas um programa que elas possam executar, elas também poderão fazer a engenharia reversa, com tempo suficiente. Essa é a natureza dos programas. Assim que o binário estiver disponível para alguém que queira decifrá-lo, não será possível impedir a engenharia reversa eventual. Afinal, o computador precisa ser capaz de decifrá-lo para executá-lo, e um humano é simplesmente um computador mais lento.

Safe Net Sentinel (anteriormente Aladdin). Advertências - a API é uma porcaria, a documentação é uma porcaria e as duas são ótimas em comparação com as ferramentas do SDK.

Eu uso o método de proteção de hardware ( Sentinel HASP HL ) há muitos anos. Requer um chaveiro USB proprietário que atue como a 'licença' do software. O SDK criptografa e ofusca os arquivos executáveis ​​e as bibliotecas e permite vincular diferentes recursos do aplicativo aos recursos gravados na chave. Sem uma chave USB fornecida e ativada pelo licenciante, o software não pode descriptografar e, portanto, não será executado. O Key ainda usa um protocolo de comunicação USB personalizado (fora do meu conhecimento, eu não sou um motorista de dispositivo) para dificultar a construção de uma chave virtual ou violar a comunicação entre o wrapper e a chave do tempo de execução. O SDK deles não é muito amigável para desenvolvedores e é bastante doloroso ao integrar a proteção adicional com um processo de compilação automatizado (mas possível).

Antes de implementarmos a proteção HASP HL, havia 7 piratas conhecidos que retiraram as 'proteções' do dotfuscator do produto. Adicionamos a proteção HASP ao mesmo tempo que uma grande atualização do software, que realiza alguns cálculos pesados ​​em vídeo em tempo real. O melhor que posso constatar de criação de perfil e benchmarking, a proteção HASP HL, só diminuiu os cálculos intensivos em cerca de 3%. Desde que o software foi lançado cerca de 5 anos atrás, nenhum novo pirata do produto foi encontrado. O software que ele protege está em alta demanda em seu segmento de mercado, e o cliente está ciente de vários concorrentes tentando ativamente fazer engenharia reversa (sem sucesso até agora). Sabemos que eles tentaram solicitar ajuda de alguns grupos na Rússia que anunciam um serviço para interromper a proteção de software,

Recentemente, tentamos a solução de licença de software (HASP SL) em um projeto menor, que foi direto o suficiente para começar a funcionar se você já estiver familiarizado com o produto HL. Parece funcionar; não houve relatos de incidentes de pirataria, mas esse produto tem uma demanda muito menor.

Obviamente, nenhuma proteção pode ser perfeita. Se alguém estiver suficientemente motivado e tiver dinheiro sério para queimar, tenho certeza de que as proteções oferecidas pelo HASP podem ser contornadas.

Os melhores truques anti-desmontagem, em particular nos conjuntos de instruções de comprimento variável das palavras, estão no código do montador / máquina, não no C. Por exemplo

CLC
BCC over
.byte 0x09
over:

O desmontador precisa resolver o problema de que um destino de ramificação é o segundo byte em uma instrução de vários bytes. Um simulador de conjunto de instruções não terá nenhum problema. A ramificação para endereços computados, que você pode causar em C, também torna a desmontagem difícil ou impossível. O simulador do conjunto de instruções não terá nenhum problema. Usando um simulador para classificar os destinos das filiais, você pode ajudar no processo de desmontagem. O código compilado é relativamente limpo e fácil para um desmontador. Então, acho que é necessária alguma montagem.

Eu acho que foi perto do início do Zen of Assembly Language de Michael Abrash, onde ele mostrou um simples truque anti-desmontador e anti-depurador. O 8088/6 tinha uma fila de pré-busca, o que você fez foi ter uma instrução que modificasse a próxima instrução ou algumas adiante. Se passo único, você executou a instrução modificada, se o simulador do conjunto de instruções não simulou completamente o hardware, você executou a instrução modificada. No hardware real em execução normalmente, a instrução real já estaria na fila e o local da memória modificado não causaria danos desde que você não executasse essa sequência de instruções novamente. Você provavelmente ainda pode usar um truque como esse hoje, pois os processadores em pipeline buscam a próxima instrução. Ou, se você souber que o hardware possui um cache de dados e instruções separado, você poderá modificar um número de bytes à frente se alinhar esse código na linha de cache corretamente, o byte modificado não será gravado no cache de instruções, mas no cache de dados e um simulador de conjunto de instruções que não tivesse simuladores de cache adequados falharia ao executar corretamente. Acho que apenas soluções de software não vão muito longe.

Os itens acima são antigos e bem conhecidos, não sei o suficiente sobre as ferramentas atuais para saber se elas já funcionam com essas coisas. O código auto-modificável pode / irá desarmar o depurador, mas o humano pode / irá restringir o problema e, em seguida, ver o código auto-modificável e contorná-lo.

Antes, os hackers levavam cerca de 18 meses para descobrir algo, dvds por exemplo. Agora eles têm uma média de 2 dias a 2 semanas (se motivados) (blue ray, iphones, etc.). Isso significa para mim que, se passo mais do que alguns dias em segurança, provavelmente estou perdendo meu tempo. A única segurança real que você terá é através do hardware (por exemplo, suas instruções são criptografadas e apenas o núcleo do processador, dentro do chip, descriptografa antes da execução, de maneira que não possa expor as instruções descriptografadas). Isso pode comprar meses em vez de dias.

Leia também o livro de Kevin Mitnick, The Art of Deception. Uma pessoa assim pode pegar um telefone e pedir que você ou um colega de trabalho entregue os segredos ao sistema, pensando que é um gerente ou outro colega de trabalho ou engenheiro de hardware em outra parte da empresa. E sua segurança está destruída. Segurança não é tudo sobre gerenciamento de tecnologia, também é preciso gerenciar os humanos.

Pegue, por exemplo, o algoritmo AES . É um algoritmo muito, muito público e é MUITO seguro. Por quê? Duas razões: ele foi revisado por muitas pessoas inteligentes, e a parte "secreta" não é o algoritmo em si - a parte secreta é a chave que é uma das entradas para o algoritmo. É uma abordagem muito melhor projetar seu protocolo com um "segredo" gerado que está fora do seu código, em vez de torná-lo secreto. O código sempre pode ser interpretado, não importa o que você faça, e (idealmente) o segredo gerado só pode ser comprometido por uma abordagem massiva de força bruta ou por roubo.

Penso que uma pergunta interessante é " Por que você deseja ofuscar seu código?" Você quer dificultar que os invasores decifrem seus algoritmos? Para dificultar a localização de bugs exploráveis ​​no seu código? Você não precisaria ofuscar o código se o código não fosse quebrável em primeiro lugar. A raiz do problema é um software quebrável. Corrija a raiz do seu problema, não o ofusque.

Além disso, quanto mais confuso você criar seu código, mais difícil será para você encontrar erros de segurança. Sim, será difícil para hackers, mas você também precisa encontrar bugs. O código deve ser fácil de manter daqui a alguns anos, e mesmo o código claro bem escrito pode ser difícil de manter. Não faça pior.

Tornar o código difícil de realizar engenharia reversa é chamado ofuscação de código.

A maioria das técnicas mencionadas é bastante fácil de solucionar. Eles se concentram em adicionar algum código inútil. Mas o código inútil é fácil de detectar e remover, deixando você com um programa limpo.

Para uma ofuscação eficaz, você precisa tornar o comportamento do seu programa dependente dos bits inúteis que estão sendo executados. Por exemplo, em vez de fazer isso:

a = useless_computation();
a = 42;

faça isso:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Ou, em vez de fazer isso:

if (running_under_a_debugger()) abort();
a = 42;

Faça isso (onde running_under_a_debuggernão deve ser facilmente identificável como uma função que testa se o código está sendo executado em um depurador - ele deve misturar cálculos úteis com a detecção do depurador):

a = 42 - running_under_a_debugger();

Ofuscação eficaz não é algo que você possa fazer puramente na fase de compilação. Tudo o que o compilador pode fazer, um descompilador pode fazer. Claro, você pode aumentar a carga dos decompiladores, mas isso não vai muito longe. Técnicas eficazes de ofuscação, na medida em que existem, envolvem a escrita da fonte ofuscada a partir do dia 1. Faça seu código se auto-modificar. Disponha seu código com saltos computados, derivados de um grande número de entradas. Por exemplo, em vez de uma chamada simples

some_function();

faça isso, onde você sabe o layout exato esperado dos bits em some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

Se você está falando sério sobre ofuscação, adicione vários meses ao seu planejamento; ofuscação não sai barato. E considere que, de longe, a melhor maneira de evitar que as pessoas façam engenharia reversa do seu código é torná-lo inútil para que elas não se incomodem. É uma consideração econômica simples: eles realizarão engenharia reversa se o valor para eles for maior que o custo; mas aumentar o custo também aumenta muito o custo, então tente diminuir o valor para eles.

Agora que eu lhe disse que a ofuscação é difícil e cara, vou lhe dizer que não é para você de qualquer maneira . Você escreve

O protocolo atual em que estou trabalhando nunca deve ser inspecionado ou compreensível, para a segurança de várias pessoas

Isso levanta uma bandeira vermelha. É segurança pela obscuridade , que tem um histórico muito ruim. Se a segurança do protocolo depende de pessoas que não o conhecem, você já perdeu .

Leitura recomendada:

• A Bíblia de segurança: Engenharia de Segurança por Ross Anderson
• A Bíblia da ofuscação: software furtivo de Christian Collberg e Jasvir Nagra

Muitas vezes, o medo do seu produto sofrer engenharia reversa é equivocado. Sim, pode sofrer engenharia reversa; mas ficará tão famoso em um curto período de tempo que os hackers acharão que vale a pena reverter o engg. isto ? (esse trabalho não é uma atividade pequena para linhas de código substanciais).

Se ele realmente se tornar um ganhador de dinheiro, você deve ter coletado dinheiro suficiente para protegê-lo usando os meios legais, como patente e / ou direitos autorais .

IMHO, tome as precauções básicas que você vai tomar e solte-o. Se se tornar um ponto de engenharia reversa que significa que você fez um trabalho muito bom, você mesmo encontrará maneiras melhores de superá-lo. Boa sorte.

Leia http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Tenho certeza de que outros provavelmente também poderiam fornecer fontes melhores de por que a segurança pela obscuridade é uma coisa ruim.

Deveria ser totalmente possível, usando técnicas criptográficas modernas, ter o sistema aberto (não estou dizendo que deveria estar aberto, apenas o que poderia ser) e ainda ter segurança total, desde que o algoritmo criptográfico não funcione. tem um buraco (provavelmente não se você escolher um bom), suas chaves / senhas privadas permanecem privadas e você não tem brechas de segurança no seu código ( é com isso que você deve se preocupar).

Desde julho de 2013, há um interesse renovado na ofuscação criptograficamente robusta (na forma de Ofuscação indistinguível ), que parece ter provocado a pesquisa original de Amit Sahai .

• Sahai, Garg, Gentry, Halevi, Raykova, Waters, Ofuscação indistinguível de candidato e criptografia funcional para todos os circuitos (21 de julho de 2013).
• Sahai, Waters, como usar a ofuscação indistinguível: criptografia negável e muito mais .
• Sahai, Barak, Garg, Kalai, Paneth, Protegendo a Ofuscação Contra Ataques Algébricos (4 de fevereiro de 2014).

Você pode encontrar algumas informações destiladas neste artigo da Quanta Magazine e no artigo IEEE Spectrum .

Atualmente, a quantidade de recursos necessários para fazer uso dessa técnica a torna impraticável, mas o consenso é bastante otimista quanto ao futuro.

Digo isso muito casualmente, mas para todos os que costumam rejeitar instintivamente a tecnologia de ofuscação - isso é diferente. Se está provado que está realmente funcionando e se tornou prático, isso é realmente importante, e não apenas para ofuscação.

Para se informar, leia a literatura acadêmica sobre ofuscação de código . Christian Collberg, da Universidade do Arizona, é um estudioso respeitável nesse campo; Salil Vadhan, da Universidade de Harvard, também fez um bom trabalho.

Estou atrasado nesta literatura, mas a idéia essencial de que tenho conhecimento é que você não pode impedir que um invasor veja o código que você executará, mas você pode cercá-lo com código que não é executado e isso custa um tempo exponencial do invasor (usando as técnicas mais conhecidas) para descobrir quais fragmentos do seu código são executados e quais não são.

Há um artigo recente chamado " Ofuscação de programas e programas únicos ". Se você realmente leva a sério a proteção de seu aplicativo. O artigo em geral contorna os resultados teóricos da impossibilidade pelo uso de hardware simples e universal.

Se você não pode exigir hardware extra, também existe outro documento que fornece a ofuscação teoricamente a melhor possível " Na melhor ofuscação possível ", entre todos os programas com a mesma funcionalidade e o mesmo tamanho. No entanto, o artigo mostra que o melhor possível da teoria da informação implica um colapso da hierarquia polinomial.

Esses documentos devem fornecer pelo menos pistas bibliográficas suficientes para percorrer a literatura relacionada se esses resultados não funcionarem para suas necessidades.

Atualização: Uma nova noção de ofuscação, denominada ofuscação indistinguível, pode atenuar o resultado da impossibilidade (artigo)

Se alguém quiser gastar o tempo para reverter seu binário, não há absolutamente nada que você possa fazer para detê-lo. Você pode tornar se moderadamente mais difícil, mas é isso. Se você realmente deseja aprender sobre isso, obtenha uma cópia do http://www.hex-rays.com/idapro/ e desmonte alguns binários.

O fato de a CPU precisar executar o código é sua ruína. A CPU executa apenas o código da máquina ... e os programadores podem ler o código da máquina.

Dito isto ... você provavelmente tem um problema diferente que pode ser resolvido de outra maneira. O que você está tentando proteger? Dependendo do seu problema, você provavelmente poderá usar criptografia para proteger seu produto.

Para poder selecionar a opção correta, você deve pensar nos seguintes aspectos:

1. É provável que "novos usuários" não desejem pagar, mas usem o Seu software?
2. É provável que os clientes existentes precisem de mais licenças do que precisam?
3. Quanto os usuários em potencial estão dispostos a pagar?
4. Deseja conceder licenças por usuário / usuários simultâneos / estação de trabalho / empresa?
5. Seu software precisa de treinamento / personalização para ser útil?

Se a resposta à pergunta 5 for "sim", não se preocupe com cópias ilegais. Eles não seriam úteis de qualquer maneira.

Se a resposta da pergunta 1 for "sim", pense primeiro em preços (consulte a pergunta 3).

Se você responder às perguntas 2 "sim", um modelo de "pagamento por uso" poderá ser apropriado para você.

De acordo com a minha experiência, o pagamento por uso + personalização e treinamento são a melhor proteção para o seu software, porque:

• Novos usuários são atraídos pelo modelo de preços (pouco uso -> pouco pagamento)
• Quase não há "usuários anônimos", porque eles precisam de treinamento e personalização.
• Nenhuma restrição de software afasta os clientes em potencial.
• Existe um fluxo contínuo de dinheiro de clientes existentes.
• Você recebe feedback valioso para o desenvolvimento de seus clientes, devido a um relacionamento comercial de longo prazo.

Antes de pensar em introduzir DRM ou ofuscação, você pode pensar nesses pontos e se eles são aplicáveis ​​ao Seu software.

O código protegido em uma máquina virtual parecia impossível de fazer engenharia reversa no início. Themida Packer

Mas não é mais tão seguro. E não importa como você compacta seu código, você sempre pode fazer um despejo de memória em qualquer executável carregado e desmontá-lo com qualquer desmontador como o IDA Pro.

O IDA Pro também vem com um código de montagem bacana para o transformador de código-fonte C, embora o código gerado pareça mais uma bagunça matemática de ponteiro / endereço. Se você compará-lo com o original, poderá corrigir todos os erros e remover qualquer coisa.

Não há dados, você não pode proteger seu código contra desmontagem. O que você pode fazer é configurar o servidor para a lógica comercial e usar o serviço da web para fornecê-lo ao seu aplicativo. Obviamente, esse cenário nem sempre é possível.

Para evitar a engenharia reversa, você não deve fornecer o código aos usuários. Dito isto, recomendo o uso de um aplicativo on-line ... no entanto (já que você não deu contexto) que pode ser inútil para o seu.

Possivelmente, sua melhor alternativa ainda está usando a virtualização, o que introduz outro nível de indireção / ofuscação necessário para ser ignorado, mas como SSpoke disse em sua resposta , essa técnica também não é 100% segura.

O ponto é que você não obterá a proteção máxima, porque não existe, e se houver, não vai durar muito, o que significa que não era a proteção máxima em primeiro lugar.

Qualquer homem que monte, pode ser desmontado.

Geralmente é verdade que a desmontagem (adequada) costuma ser uma tarefa mais difícil (um pouco ou mais); portanto, seu oponente deve ser mais habilidoso , mas você pode assumir que sempre existe alguém com essa qualidade e é uma aposta segura.

Se você deseja proteger algo contra os ERs, deve conhecer pelo menos as técnicas comuns usadas pelos ERs.

Assim palavras

a internet não é realmente útil para prevenção contra engenharia reversa, mas descreve toneladas de informações sobre como fazer engenharia reversa

mostre sua atitude ruim. Não estou dizendo que, para usar ou incorporar proteção, você deve saber como quebrá-la, mas para usá-la sabiamente, deve conhecer suas fraquezas e armadilhas. Você deveria entender isso.

(Existem exemplos de software que usa proteção de maneira incorreta, tornando essa proteção praticamente inexistente. Para evitar falar vagamente, darei um exemplo brevemente descrito na internet: Oxford English Dictionary Second Edition no CD-ROM v4. Você pode ler sobre falha no uso do SecuROM na página a seguir: Oxford English Dictionary (OED) em CD-ROM em um ambiente Windows de 16, 32 ou 64 bits: instalação no disco rígido, bugs, macros de processamento de texto, rede, fontes e assim por diante )

Tudo leva tempo.

Se você é novo no assunto e não tem meses ou anos para se interessar por assuntos de ER, escolha as soluções disponíveis feitas por outras pessoas. O problema aqui é óbvio, eles já estão lá, então você já sabe que eles não são 100% seguros, mas criar sua própria nova proteção lhe daria apenas uma falsa sensação de estar protegido, a menos que você conheça realmente o estado da arte em engenharia reversa e proteção (mas você não faz, pelo menos neste momento).

O objetivo da proteção de software é assustar iniciantes, impedir REs comuns e colocar um sorriso no rosto de ER experiente após sua jornada (espero que seja interessante) até o centro do seu aplicativo.

Nas conversas sobre negócios, você pode dizer que é tudo sobre atrasar a concorrência, na medida do possível.

(Dê uma olhada na bela apresentação Silver Needle no Skype de Philippe Biondi e Fabrice Desclaux mostrada no Black Hat 2006).

Você está ciente de que há muita coisa sobre ER por aí, então comece a ler. :)

Como falei sobre virtualização, vou dar um link para um exemplo de tópico do EXETOOLS FORUM : Melhor protetor de software: Themida ou Enigma Protector? . Pode ajudar um pouco em pesquisas adicionais.

Eu não acho que nenhum código seja intransponível, mas as recompensas precisam ser ótimas para alguém querer tentar.

Dito isto, há coisas que você deve fazer, como:

• Use o nível de otimização mais alto possível (a engenharia reversa não se trata apenas de obter a sequência de montagem, mas também de entender o código e transportá-lo para uma linguagem de nível superior, como C). Código altamente otimizado pode ser um b --- h a seguir.
• Torne as estruturas densas por não ter tipos de dados maiores que o necessário. Reorganize os membros da estrutura entre liberações de código oficiais. Campos de bits reorganizados em estruturas também são algo que você pode usar.
• Você pode verificar a presença de certos valores que não devem ser alterados (uma mensagem de direitos autorais é um exemplo). Se um vetor de byte contiver "vwxyz", você poderá ter outro vetor de byte contendo "abcde" e comparar as diferenças. A função que faz isso não deve passar ponteiros para os vetores, mas usar ponteiros externos definidos em outros módulos como (código pseudo-C) "char * p1 = & string1 [539];" e "char p2 = & string2 [-11731];". Dessa forma, não haverá ponteiros apontando exatamente para as duas strings. No código de comparação, você compara para " (p1-539 + i) - * (p2 + 11731 + i) == algum valor". O cracker acha que é seguro alterar a string1 porque ninguém parece fazer referência a ela. Enterre o teste em algum lugar inesperado.

Tente hackear o código do assembly para ver o que é fácil e o que é difícil de fazer. Devem surgir idéias com as quais você pode experimentar para dificultar a engenharia reversa do código e tornar a depuração mais difícil.

Como muitos já disseram: Em uma CPU comum, você não pode impedi-los de fazer, basta atrasá-los. Como meu antigo professor de criptografia me disse: Você não precisa de criptografia perfeita, a quebra do código deve ser apenas mais cara do que o ganho. O mesmo vale para a sua ofuscação.

Mas três notas adicionais:

1. É possível tornar a engenharia reversa impossível, MAS (e isso é muito, mas muito grande), você não pode fazê-lo em uma CPU convencional. Eu também desenvolvi muito o hardware, e frequentemente o FPGA é usado. Por exemplo, o Virtex 5 FX possui uma CPU PowerPC, e você pode usar a APU para implementar os próprios códigos de operação da CPU em seu hardware. Você pode usar esse recurso para descriptografar realmente as incstuções do PowerPC, que não são acessíveis pelo software externo ou por outro software, ou mesmo executar o comando no hardware. Como o FPGA incorporou a criptografia AES para seu fluxo de bits de configuração, não foi possível fazer engenharia reversa (exceto se alguém conseguir quebrar o AES, mas acho que temos outros problemas ...). Dessa forma, os fornecedores de IP de hardware também protegem seu trabalho.

2. Você fala do protocolo. Você não diz que tipo de protocolo é esse, mas quando é um protocolo de rede, você deve pelo menos protegê-lo contra o sniffing da rede. Isso você pode realmente fazer por criptografia. Mas se você deseja proteger a criptografia / descriptografia de um proprietário do software, você está de volta à ofuscação.

3. Torne seu programa imperdoável / irrecuperável. Tente usar algum tipo de detecção de depuração e aplique-a, por exemplo, em alguma fórmula ou para adicionar um conteúdo de registro de depuração a uma constante mágica. É muito mais difícil se o seu programa estiver no modo de depuração, se estiver sendo executado normalmente, mas fizer uma computação, operação ou outra incorreta completa. Por exemplo, eu conheço alguns jogos ecológicos que tiveram uma proteção contra cópias realmente desagradável (sei que você não deseja proteção contra cópia, mas é semelhante): a versão roubada alterou os recursos minerados após 30 minutos de jogo e, de repente, você conseguiu apenas um recurso. O pirata apenas o quebrou (ou seja, fez engenharia reversa) - verificou se estava rodando e a volia a liberou. Tais pequenas mudanças de comportamento são muito difíceis de detectar, esp. se eles não aparecerem instantaneamente para detecção, mas apenas atrasados.

Então, finalmente, eu sugeriria: Estimar qual é o ganho das pessoas que fazem engenharia reversa do seu software, traduza isso em algum tempo (por exemplo, usando o salário mais barato da Índia) e faça a engenharia reversa de modo que o tempo custe que seja maior.

Ao contrário do que a maioria das pessoas diz, com base em sua intuição e experiência pessoal, não creio que a ofuscação do programa com segurança criptográfica seja impossível em geral.

Este é um exemplo de uma declaração de programa perfeitamente ofuscada para demonstrar meu argumento:

printf("1677741794\n");

Nunca se pode imaginar que o que realmente faz é

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

Há um artigo interessante sobre esse assunto, que prova alguns resultados impossíveis. É chamado de "Na (Im) possibilidade de Ofuscar Programas" .

Embora o artigo prove que a ofuscação que torna o programa não distinguível da função que implementa é impossível, a ofuscação definida de uma maneira mais fraca ainda pode ser possível!

A segurança através da obscuridade não funciona, como foi demonstrado por pessoas muito mais inteligentes do que nós dois. Se você deve proteger o protocolo de comunicação de seus clientes, é moralmente obrigado a usar o melhor código que é aberto e examinado por especialistas.

Isso é para a situação em que as pessoas podem inspecionar o código. Se seu aplicativo for executado em um microprocessador incorporado, você poderá escolher um que possua um recurso de vedação, o que torna impossível inspecionar o código ou observar mais do que parâmetros triviais, como o uso atual enquanto ele é executado. (É, exceto pelas técnicas de invasão de hardware, que você desmonta cuidadosamente o chip e usa equipamentos avançados para inspecionar correntes em transistores individuais.)

Eu sou o autor de um montador de engenharia reversa para o x86. Se você estiver pronto para uma surpresa fria, envie-me o resultado de seus melhores esforços. (Entre em contato comigo através dos meus sites.) Poucos que vi nas respostas apresentariam um obstáculo substancial para mim. Se você quiser ver como o código sofisticado de engenharia reversa funciona, você deve realmente estudar sites com desafios de engenharia reversa.

Sua pergunta pode ser esclarecida. Como você espera manter um protocolo em segredo se o código do computador é passível de engenharia reversa? Se o meu protocolo fosse enviar uma mensagem criptografada RSA (mesmo chave pública), o que você ganha mantendo o protocolo em segredo? Para todos os efeitos práticos, um inspetor seria confrontado com uma sequência de bits aleatórios.

Groetjes Albert

As técnicas tradicionais de engenharia reversa dependem da capacidade de um agente inteligente usar um desmontador para responder a perguntas sobre o código. Se você quer uma segurança forte, deve fazer o que provavelmente impede o agente de obter essas respostas.

Você pode fazer isso contando com o Halting Program ("o programa X pára?"), Que em geral não pode ser resolvido. A adição de programas difíceis de raciocinar no seu programa dificulta o seu raciocínio. É mais fácil construir esses programas do que separá-los. Você também pode adicionar código ao programa que tem vários graus de dificuldade para raciocinar; um grande candidato é o programa de raciocínio sobre aliases ("indicadores").

Collberg et al. Têm um artigo ("Fabricando construções opacas baratas, resilientes e furtivas") que discute esses tópicos e define uma variedade de predicados "opacos" que podem dificultar muito o raciocínio sobre o código:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

Não vi os métodos específicos de Collberg aplicados ao código de produção, especialmente ao código-fonte C ou C ++.

O ofuscador DashO Java parece usar idéias semelhantes. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

PRIMEIRA COISA PARA LEMBRAR SOBRE OCULTAR SEU CÓDIGO : Nem todo o seu código precisa estar oculto.

O OBJETIVO FINAL : Meu objetivo final para a maioria dos programas de software é a capacidade de vender licenças diferentes que ativam e desativam recursos específicos dos meus programas.

MELHOR TÉCNICA : Acho que construir em um sistema de ganchos e filtros como o WordPress oferece, é o melhor método absoluto ao tentar confundir seus oponentes. Isso permite criptografar determinadas associações de gatilhos sem criptografar o código.

O motivo para fazer isso é porque você deseja criptografar a menor quantidade de código possível.

CONHEÇA SEUS CRACKERS : Saiba o seguinte: o principal motivo para decifrar códigos não é por causa da distribuição maliciosa de licenças, é porque NECESSÁRIO alterar seu código e eles realmente NÃO precisam distribuir cópias gratuitas.

INTRODUÇÃO : Separe a pequena quantidade de código que você vai criptografar, o restante do código deve tentar ser compactado em UM arquivo para aumentar a complexidade e a compreensão.

PREPARANDO A CRIPTOGRAFIA : Você criptografará em camadas com o meu sistema, também será um procedimento muito complexo, então crie outro programa que será responsável pelo processo de criptografia.

PASSO UM : Ofusque usar nomes base64 para tudo. Uma vez feito, base64 o código ofuscado e salve-o em um arquivo temporário que posteriormente será usado para descriptografar e executar esse código. Faz sentido?

Repito, já que você fará isso de novo e de novo. Você irá criar uma string base64 e salvá-la em outro arquivo como uma variável que será descriptografada e renderizada.

PASSO DOIS : Você vai ler este arquivo temporário como uma string e ofuscar ele, então base64 e salvá-lo em um segundo arquivo temporário que será usado para descriptografar e renderizá-lo para o usuário final.

PASSO TRÊS : Repita o passo dois quantas vezes quiser. Depois de fazer isso funcionar corretamente, sem erros de descriptografia, você começará a construir minas terrestres para seus oponentes.

TERRA MINA UM : Você vai querer manter o fato de estar sendo notificado em segredo absoluto. Portanto, crie um cracker, tente o sistema de correio de aviso de segurança para a camada 2. Isso será acionado, informando os detalhes sobre o seu oponente se algo der errado.

TERRA MINA DOIS : Dependências. Você não quer que seu oponente possa executar a camada um, sem as camadas 3, 4 ou 5, ou mesmo o programa real para o qual foi projetado. Portanto, certifique-se de que na camada um você inclua algum tipo de script de morte que será ativado se o programa não estiver presente ou nas outras camadas.

Tenho certeza que você pode criar suas próprias minas terrestres, se divertir com isso.

O QUE LEMBRAR : Você pode realmente criptografar seu código em vez de base64'ing-lo. Dessa forma, uma simples base64 não descriptografará o programa.

RECOMPENSA : Lembre-se de que isso pode realmente ser um relacionamento simbiótico entre você e seu oponente. Eu sempre coloco um comentário dentro da camada um, o comentário parabeniza o cracker e fornece a ele um código promocional para usar para receber uma recompensa em dinheiro de você.

Faça a recompensa em dinheiro significativa, sem preconceitos envolvidos. Eu normalmente digo algo como $ 500. Se seu cara é o primeiro a decifrar o código, pague o dinheiro e se torne amigo dele. Se ele é seu amigo, ele não distribuirá seu software. Pergunte a ele como ele fez isso e como você pode melhorar!

BOA SORTE!

Alguém já tentou o CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Ou Themida: http://www.oreans.com/themida_features.php ?

Mais tarde, parece mais promissor.