Protegendo executável da engenharia reversa?


210

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?


172
"no entanto, o protocolo atual em que estou trabalhando nunca deve ser inspecionado ou compreensível, para a segurança de várias pessoas". -- boa sorte com isso.
Âmbar

62
Você pode dificultar a engenharia reversa do seu aplicativo. Você não pode tornar isso impossível, contanto que o outro cara tenha uma parte substancial de seus pedaços nas mãos. Cuidado ao garantir total segurança, especialmente se houver vidas em risco - você não pode cumprir.
precisa

127
Se o seu computador pode entender o código, uma pessoa também.
Lightness Races em órbita

78
Crie o código Open Source, e ninguém fará engenharia reversa.
usuário desconhecido

28
"A segurança pela obscuridade nunca funcionou."
bot47

Respostas:


151

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.


14
Entendo isso e li alguns artigos sobre segurança do Skype explicados e tenho contemplado as mesmas idéias que o Skype já tentou como um método para não impedir, mas proteger meu protocolo. Algo que se provou digno o suficiente, dadas as circunstâncias óbvias do Skype.
Grafitemaster

8
O Skype é, na verdade, o primeiro exemplo que me veio à cabeça, então estou feliz que você já esteja pensando em emular os métodos deles.
Ricket 26/06

175

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.


113
+1. Leia os dias de glória da proteção contra cópias no Apple II, a guerra cada vez maior entre os ofuscadores e os crackers, os truques malucos com o motor de passo do disquete e as instruções não documentadas do 6502 e assim por diante ... durma, porque você não implementará algo quase tão elaborado e todos acabarão rachando.
Nemo

2
É mais fácil usar um simulador e obter melhor visibilidade do que tentar fazer engenharia reversa visualmente ou com um desmontador. Se a segurança não estiver embutida no hardware que você está usando, acho que o mundo está em média de dois dias a duas semanas para fazer a engenharia reversa e derrotar praticamente tudo o que sai. Se você demorar mais de dois dias para criar e implementar isso, você gastou muito tempo.
old_timer

5
O único DRM atualmente funcionando razoavelmente hoje é a combinação de uma chave e um servidor da Internet, verificando se apenas uma instância da chave está ativa por vez.
Thorbjørn Ravn Andersen

2
@Rotsor: O computador não consegue entender porque ainda não conseguimos reduzir esse tipo de inteligência a um algoritmo, não porque existe algum tipo de barreira física ou tecnológica. O humano pode entendê-lo porque ele pode fazer qualquer coisa que o computador possa (embora mais lento) , além da razão .
Adam Robinson

3
Nesse momento, alguém tentará fazer engenharia reversa do computador, a menos que esteja disponível apenas em um ambiente que você controla.
28612 Amber

41

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.


19
Nota do moderador: Os comentários nesta resposta foram removidos devido à digressão em ruído antagônico.
Tim Post

2
+1 por experiência, mas gostaria de repetir que não é perfeito. O Maya (suíte 3D) usou um dongle de hardware (não tenho certeza se era o HASP), o que não impediu os piratas por muito tempo. Quando há uma vontade há um caminho.
Robert Fraser

1
O AutoCAD usa um sistema semelhante, que foi quebrado várias vezes. O HASP e outros semelhantes manterão honestas as pessoas honestas e evitarão a pirataria casual. Se você estiver construindo o próximo produto de design de vários bilhões de dólares, sempre terá biscoitos para enfrentar. É tudo uma questão de retornos decrescentes - quantas horas de esforço vale a pena quebrar sua proteção de software versus apenas pagar por isso.
RyanR

6
Também quero entrar em contato com a perspectiva de alguém que usou o software seguro HASP. Os HASPs são um problema real para o usuário final . Eu lidei com um iButton de Dallas e um HASP de Aladdin, e ambos eram realmente bugs, e fiz com que o software parasse de funcionar aleatoriamente, exigindo desconectar e reconectar o HASP.
Fake Name

4
Além disso, vale ressaltar que as medidas de segurança do HASP não são necessariamente mais seguras que a ofuscação do código - com certeza elas exigem uma metodologia diferente para a engenharia reversa, mas é muito possível revertê-las - Veja: flylogic.net/blog/?p=14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
Nome Falsificado

22

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.


1
Além disso, você não precisa ter acesso ao código fonte (ou mesmo código fonte desmontado) para encontrar uma falha de segurança. Pode ser por acidente ou usando o fato de que a maioria dos furos vem dos mesmos problemas no código (como estouros de buffer).
precisa saber é o seguinte

2
Existem grandes problemas com o código auto-modificável. A maioria dos sistemas operacionais / hardwares modernos não permite fazer isso sem privilégios muito altos, pode haver problemas de cache e o código não é seguro para threads.
Martin James

1
Com os modernos processadores x86, truques como esses geralmente prejudicam o desempenho. O uso do mesmo local de memória como parte de mais de uma instrução provavelmente tem um efeito semelhante a uma ramificação incorreta. O código de modificação automática faz com que o processador descarte as linhas de cache para manter a coerência entre os caches de instrução e de dados (se você executar o código modificado com muito mais frequência do que o modifica, ainda poderá ser uma vitória).
jilles

2
Eu me deparei com isso há 20 anos. Levamos quase meia hora para descobrir o que aconteceu. Não é muito bom se você precisar de mais proteção.
Bo Persson

1
"a instrução real já estaria na fila e a localização da memória modificada não causaria nenhum dano" Até que uma interrupção ocorra no meio, liberando o pipeline de instruções e fazendo com que o novo código fique visível. Agora sua ofuscação causou um bug para seus usuários legítimos.
Ben Voigt

21

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.


3
+1 para o senso comum: por que dificultar para si mesmo quando você pode criar um sistema melhor?
Necrolis

1
Como eu sempre digo, se você continuar do lado do servidor tudo, é mais seguro
liamzebedee

20

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:


1
@Gilles, essa é sua afirmação, que é muito forte, então o ônus da prova recai sobre você. No entanto, fornecerei um exemplo simples: 2+2pode ser simplificado pelo compilador para 4, mas o descompilador não pode trazê-lo de volta 2+2(e se realmente fosse 1+3?).
Rotsor 26/06

7
@Rotsor 4e 2+2são observacionalmente equivalentes; portanto, são iguais para esse fim, a saber, o que o programa está fazendo. Sim, é claro, o decompilador não pode reconstruir o código fonte, mas isso é irrelevante. Esta sessão de perguntas e respostas é sobre a reconstrução do comportamento (ou seja, o algoritmo e, mais precisamente, um protocolo).
Gilles 'SO- stop be evil'

1
Você não precisa fazer nada para reconstruir o comportamento. Você já tem o programa! O que você geralmente precisa é entender o protocolo e alterar algo nele (como substituir um 2 2+2por 3 ou substituir +por um *).
Rotsor

1
Se você considerar todos os programas equivalentes ao comportamento iguais, então sim, o compilador não poderá fazer nada porque realiza apenas uma transformação de identidade. O descompilador também é inútil, pois é uma transformação de identidade novamente. Caso contrário, no entanto 2+2-> 4é um exemplo válido de transformação irreversível realizada pelo compilador. Se torna a compreensão mais fácil ou mais difícil é um argumento separado.
Rotsor

2
@ Gilles Não posso estender sua analogia com a maçã porque não consigo imaginar uma maçã estruturalmente diferente, mas comportamentalmente equivalente. :)
Rotsor

13

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.


1
Quero dizer, essa é uma resposta viável e aplicável, mas a linha que você define entre proteção e receita de alguns milhões para que outras pessoas protejam seu produto para você é uma linha muito longa.
Grafitemaster

12

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).


2
Eu concordo com isso. Eu acho que você pode ter um problema conceitual ou de design. Existe um analógico com uma solução de par de chaves público-privado? Você nunca divulga a chave privada, ela permanece com o proprietário cujo cliente seguro a processa. Você pode manter o código seguro fora do computador e transmitir apenas os resultados ao usuário?
Dizzley

8

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 .

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.


7

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.


7

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)


6

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.


6

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.


Muito bons conselhos (e eu upvoted), mas ele realmente não adress esta questão em particular
MAWG diz Reintegrar Monica

5

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.


5

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.


8
bem dito, a única maneira de evitar que as pessoas desmontem seu código é nunca permitir que elas tenham acesso físico a ele, o que significa oferecer seu aplicativo exclusivamente como um SAAS, receber solicitações de clientes remotos e devolver os dados processados. Coloque o servidor em uma sala trancada em um bunker subterrâneo cercado por uma vala de jacaré e arame farpado eletrizado de 5m de altura, no qual você joga a chave fora antes de cobrir tudo por 10m de concreto armado e depois espere não se esqueça de instalar toneladas de sistemas de software para evitar invasões na rede.
Jwenting

6
Espero nunca obter o contrato para manter seus servidores
Colin Pickard

5

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.


esta é a solução real ... ou seja, coloque suas joias da coroa em seu próprio servidor em sua própria máquina VPS e exponha apenas chamadas de API para este servidor a partir do cliente (navegador ou cliente da API)
Scott Stensland -

5

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.


4

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.


2
seu primeiro ponto não faz sentido; o código otimizado elimina a sujeira; isso facilita a reversão (falo por experiência própria). seu ponto de partida também é uma perda de tempo, e o engenheiro reverso que vale a pena saber como fazer o ponto de interrupção do acesso à memória. é por isso que provavelmente é melhor não projetar você mesmo um sistema, mas nós bibliotecas de terceiros que ainda precisam ser 'quebradas', porque é provável que dure um pouco mais do que qualquer coisa que um 'novato' possa criar ...
Necrolis

Como parece que eu não sei nada sobre o assunto, talvez eu deva recorrer a um profissional como você para atender às minhas necessidades de desenvolvimento de software, em vez de escrever qualquer código sozinho.
Olof Forshell

4

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.


3

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!


7
1. Seu exemplo não é relevante aqui; os dois programas que você mostra são comportamentalmente equivalentes, e essa pergunta é sobre descobrir o comportamento de um programa, não reconstruindo seu código fonte (o que, obviamente, é impossível). 2. Este artigo é um trabalho teórico; é impossível escrever o ofuscador perfeito, mas também é impossível escrever o descompilador perfeito (pelas mesmas razões que é impossível escrever o analisador de programa perfeito). Na prática, é uma corrida armamentista: quem pode escrever o melhor (des) ofuscador.
Gilles 'SO- stop be evil'

1
@Gilles, o resultado da desofuscação (correta) sempre será comportamentalmente equivalente ao código ofuscado. Não vejo como isso prejudica a importância do problema.
Rotsor

Além disso, sobre corrida armamentista: não se trata de quem investe mais na pesquisa, mas de quem está certo. As provas matemáticas corretas não dão errado só porque alguém quer muito.
Rotsor 26/06

1
Ok, talvez você esteja certo sobre a corrida armamentista na prática. Eu acho que não entendi bem este. :) Espero que seja possível algum tipo de ofuscação criptograficamente segura.
Rotsor

Para um caso interessante de ofuscação, tente cartões inteligentes, onde o problema é que o invasor tem acesso físico (ofuscação de caixa branca). Parte da resposta é limitar o acesso por meios físicos (o invasor não pode ler as chaves secretas diretamente); mas a ofuscação de software também desempenha um papel importante, principalmente para fazer ataques como o DPA não fornecer resultados úteis. Não tenho uma boa referência para oferecer, desculpe. Os exemplos na minha resposta são vagamente inspirados nas técnicas usadas nesse domínio.
Gilles 'SO- stop be evil'

3

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


3

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/


2

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!


4
Você leu a pergunta? Eu nunca pedi métodos sobre como proteger da pirataria. O aplicativo será gratuito, é o protocolo subjacente usado que precisa ser protegido devido à natureza da segurança.
Grafitemaster

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.