BRPI0614089A2

BRPI0614089A2 - método para evitar engenharia reversa de software, modificação não autorizada e interceptação de dados de tempo de execução

Info

Publication number: BRPI0614089A2
Application number: BRPI0614089-0A
Authority: BR
Inventors: Keren Asipov; Boris Asipov
Original assignee: Secured Dimensions Ltd
Priority date: 2005-08-06
Filing date: 2006-03-30
Publication date: 2011-03-09
Also published as: US8352929B2; US8938727B2; BRPI0614089A8; US20130125243A1; CN101300584B; RU2439669C2; RU2008104404A; WO2007017856A1; CN101300584A; US20100313188A1

Abstract

MéTODO PARA EVITAR ENGENHARIA REVERSA DE SOFTWARE, MODIFICAçãO NãO AUTORIZADA E INTERCEPTAçAO DE DADOS DE TEMPO DE EXECUçAO Um método para evitar a modificação desautorizada de um software ou modificação desautorizada de dados de tempo de execução. De acordo com esse método, um conversor, que é capaz de converter o software em um código de máquina generalizado é fornecido. O conversor é projetado de tal modo que não possa sofrer engenharia reversa, pelo uso de um processo de conversão que causa perda de dados. Um intérprete, cujo conhecimento de seu método de processo é mantido restrito, também é fornecido. O intérprete interpreta o código de máquina geral em um código de máquina específico, enquanto reconstrói os dados perdidos durante o processo de interpretação.

Description

"MÉTODO PARA EVITAR ENGENHARIA REVERSA DESOFTWARE, MODIFICAÇÃO NÃO AUTORIZADA E INTERCEPTAÇÃO DEDADOS DE TEMPO DE EXECUÇÃO"

CAMPO DA INVENÇÃO

A presente invenção refere-se ao campo de proteçãode software de computador. Mais particularmente, a invençãorefere-se a um método para proteger software de computadorcontra engenharia reversa, modificação não autorizada e in-terceptação de dados de tempo de execução.

ANTECEDENTES DA INVENÇÃO

Muitas tentativas têm sido feitas nos últimos anospara proteger software de computador original contra dupli-cação e distribuição em massa. Um dos métodos utilizados a-tualmente envolve a necessidade de uma licença ou uma chavede seqüência, que é entrada manualmente pelo cliente, duran-te instalação ou durante tempo de execução. Outro método po-pular para evitar uso duplicata de software envolve a ativa-ção do software após instalação. O processo de ativação re-quer que o software leia números seriais de ID de elementosde hardware no computador, como o número serial do processa-dor ou número serial do cartão gráfico. Após leitura dos nú-meros seriais de ID de hardware, os mesmos podem ser envia-dos juntamente com o número de ID de software através da In-ternet para o vendedor. 0 vendedor armazena os números de IDe envia um código de licença para o programa através da In-ternet. 0 software pode ser programado para cessar funciona-mento adequado sem um código de licença autenticado a partirdo vendedor. Nesse caso, se o software for ilegalmente copi-ado e instalado em um computador diferente, o software nãopode ser ativado uma vez que a licença do software já estáassociada ao hardware da primeira instalação e o código delicença pode ser enviado somente para o computador tendo osmesmos perfis de hardware armazenados pelo vendedor. Entre-tanto, esses métodos não evitam que uma parte não autorizadarealize engenharia reversa do código de software, modifiqueo mesmo para excluir essas ferramentas de proteção de soft-ware, e distribua em massa o software modificado.

Muitas ferramentas estão em uso atualmente paraengenharia reversa de software, como o dumper hexadecimal,que imprime ou exibe os números binários de um código desoftware em formato hexadecimal. Conhecendo os padrões debit que representam essas instruções, bem como os comprimen-tos de instruções, uma pessoa que deseja realizar engenhariareversa o software pode identificar certas porções de um có-digo para ver como funcionam, e então modificar as mesmas.

Outra ferramenta comum para engenharia reversa e modificaçãode código é o desassemblador. O desassemblador lê o códigobinário e então exibe cada instrução executável em um forma-to textual. Além disso, uma vez que o desassemblador não po-de dizer a diferença entre uma instrução executável e os da-dos utilizados pelo código, um depurador pode ser utilizado.

0 depurador permite que o desassemblador evite desassembla-gem as porções de dados de um código. Por exemplo, se o de-sassemblador ler um comando "ADD_INT8", que significa: "adi-cionar o número representado nos 8 bits seguintes", o depu-rador processa os 8 bits seguintes como a porção de dados docomando "ADD_INT8", e o próximo grupo de bits é processadocomo um comando novo. Entretanto, essas ferramentas se ba-seiam no conhecimento publicado de como o código de instru-ções é construido, onde as informações residem na memória,quais registros são utilizados, e como a pilha (uma armaze-nagem de dados utilizada para armazenar solicitações que ne-cessitam ser tratadas, na forma de uma lista de empurrar pa-ra baixo) é utilizada.

0 problema de engenharia reversa e modificação decódigo por usuários não autorizados é ainda mais evidente aolidar com linguagens de programação baseadas em intérprete,ao contrário de linguagens de programação baseadas em compi-lador. Uma descrição de linguagem de programação baseada emcompilador pode ser encontrada na figura 1, que ilustra ge-nericamente o processo de software da técnica anterior delinguagens de programação baseados em compilador, como C ouPascal. Quando um programador programa em uma linguagem dealto nivel utilizando um editor ou similar, as instruções deseu código 10, ou código de fonte, não podem ser lidas dire-tamente pelo hardware de computador. Portanto, o código defonte 10 tem de se submeter a um processo de tradução conhe-cido como compilação pelo compilador 11. 0 compilador 11compila código de fonte 10 em um Código de Máquina (MC) es-pecifico 12, o qual o hardware do computador é capaz de lere executar. Uma vez que o MC 12 é especificamente compiladopara uma certa plataforma, não pode ser transferido de umaplataforma para outra. Nas linguagens de programação basea-das em compilador o código de fonte 10 é compilado para cadaplataforma individualmente produzindo um MC especifico, di-ferente, 12 para cada plataforma. Um exemplo de plataformasdiferentes pode ser um PC baseado em Intel® com Windows® XPe Mac® OS X.

Uma descrição de linguagem de programação baseadaem intérprete pode ser encontrada na figura 2A que é um flu-xograma, genericamente ilustrando o processo de software datécnica anterior de linguagens de programação baseadas emintérprete, como JAVA. Similares às linguagens de programa-ção baseadas em compilador, as linguagens baseadas em intér-prete são gravadas em linguagem de alto nivel, utilizando umeditor ou similar, mencionado a seguir como declarações defonte 20. Entretanto, de acordo com essa abordagem, o compi-lador 21 traduz as declarações de fonte de alto nivel 20 pa-ra um Código de byte (BC) 22 que é um MC generalizado nãolimitado a uma certa plataforma. Não obstante, para executaro BC 22, um intérprete especifico 23 é necessário para tra-duzir BC 22 em MC especifico 24. 0 intérprete especifico 23é normalmente instalado juntamente com o sistema operacio-nal. A principal vantagem dessa abordagem é que BC 22 podeser distribuído para diferentes plataformas. Após BC 22 serexecutado em uma certa plataforma, o intérprete específico23 traduz somente uma instrução de BC 22 de cada vez, produ-zindo uma instrução de MC 24 específica para execução pelohardware de computador. Entretanto, uma vez que o método deintérprete de processamento é um conhecimento comum, é rela-tivamente fácil de ler, entender e modificar o BC 22 que éum conjunto de instruções para o intérprete 23. Um hackerpode comprar uma cópia legal de um código gravado no BC, de-cifrar suas instruções e apagar ou modificar algumas dasinstruções originais do BC. Após modificação do BC, o mesmopode ser copiado em massa e revendido.

Outro método utilizado por hackers é conhecido natécnica como "interceptação de dados de tempo de execução."Por interceptar e ler o fluxo de dados durante a execução deum programa legal pelo intérprete, o hacker pode simular oprocesso ao executar um programa ilegal.

Um método para evitar fácil entendimento e deci-fragem do comportamento de código utiliza criptografia docódigo, como descrito na US 2004/0015710. De acordo com essaabordagem, o código criptografado é vendido com uma chave dedecriptografia para decriptografar o código. Cada instruçãono código é primeiramente decriptografada e interpretada porum intérprete para execução pelo processador. Entretanto,após decriptografia de código, um hacker pode ler o códigodecriptografado para realizar engenharia reversa do códigooriginal. Além disso, o processo de decriptografia pode sermonitorado por um usuário para formular a chave de decripto-graf ia. Além disso, após decriptografia de código, o mesmo écarregado desprotegido na memória do computador e pode sercopiado a partir da mesma, também.

Outro método para evitar modificação de um códigode software é dividir o código em 2 partes, uma parte sensí-vel que compreende a proteção de código, e uma parte menossensível. A parte menos sensível do código é vendida ao usu-ário, como anteriormente, pronta para interpretação, ao pas-so que a parte sensível do código é armazenada em produtosde hardware, como smart-cards. A interpretação da parte sen-sível do código é feita em hardware, como uma leitora desmart-card, onde não pode ser monitorada ou lida. Entretan-to, em alguns dos casos, o hardware adicional pode ser caro,e redistribuição de atualizações de código geradas pelo pro-vedor é complicada.

Um método para evitar modificação de um código desoftware é descrito em um artigo por Enriquillo Valdez e Mo-ti Yung "DISSECT: Distribution for SECurity Tool" (G.I. Da-vida e Y. rankel (Eds.): ISC 2001, LNCS 2200, pág. 125-143,2001. Springer-Verlag Berlin Heidelberg 2001). 0 método su-gere a divisão do código em 2 partes, uma parte sensível euma parte menos sensível. A parte menos sensível do código évendida ao usuário, como anteriormente, pronta para inter-pretação, ao passo que a parte sensível do código é armaze-nada em um servidor seguro. A interpretação da parte sensí-vel do código é feita em um servidor seguro, onde não podeser monitorada ou lida. Entretanto, essa abordagem requer amanutenção de um contato direto com o servidor designado pa-ra executar o código.

Portanto, é um objetivo da presente invenção for-necer um método barato para evitar engenharia reversa desoftware, modificação não autorizada, e interceptação de da-dos de tempo de execução.

É outro objetivo da presente invenção fornecer ummétodo para evitar modificação não autorizada de software,sem necessitar de hardware adicional.É ainda outro objetivo da presente invenção forne-cer um método que, por um lado, evite qualquer modificaçãopor um usuário não autorizado e por outro lado, permite mo-dificação e atualização pelo vendedor.

Outros objetivos e vantagens da invenção tornar-se-ão evidentes à medida que a descrição prossegue.

Sumário da invenção

A presente invenção é dirigida a um método paraevitar a modificação desautorizada de um software ou modifi-cação desautorizada de dados de tempo de execução. É forne-cido um conversor, capaz de converter o software em um códi-go de máquina generalizado que não pode sofrer engenhariareversa, pelo uso de um processo de conversão que cause per-da de dados e um intérprete que pode ser compilado por umCLR. O conhecimento do método de processo de intérprete émantido restrito. O código de máquina geral é interpretadopelo intérprete em uma máquina especifica.

O software pode ser uma linguagem de alto nível(por exemplo, Java, Visual, J#, J#, C#, ou VB.NET ou umalinguagem baseada em compilador, por exemplo, C++, VB, ouPascal), como uma linguagem baseada em intérprete, e podeser dividido de tal modo que somente parte do software éconvertida com o conversor e interpretada pelo intérprete.

A perda de dados durante conversão pode ser a re-moção de metadados de estrutura de código ou a conversão deinstruções em outras instruções que seu operando(s) corres-pondente (s) é determinado durante tempo de execução.

Breve descrição dos desenhosNos desenhos:

A figura 1 é um fluxograma ilustrando genericamen-te o processo de software da técnica anterior de linguagensde programação baseadas em compilador;

A figura 2a é um fluxograma ilustrando generica-mente o processo de software da técnica anterior de lingua-gens de programação baseadas em intérprete;

A figura 2b é um fluxograma ilustrando generica-mente o processo de software da técnica anterior de lingua-gens de programação baseadas em intérprete, principalmenteJAVA;

A figura 3 é um fluxograma ilustrando genericamen-te o processo de software da técnica anterior de linguagensde programação de . NET, como Visual J#;

A figura 4 é um fluxograma ilustrando genericamen-te a implementação da invenção de acordo com uma das modalidades;

A figura 5 é um diagrama de blocos ilustrando umadas modalidades da invenção;

A figura 6 é um fluxograma ilustrando genericamen-te a implementação da invenção de acordo com outra modalida-de da invenção; e

A figura 7 é um fluxograma ilustrando genericamen-te a implementação da invenção de acordo com uma das modali-dades, para linguagens de programação baseadas em compilador.

Descrição detalhada das modalidades preferidas

Para fins de brevidade, os seguintes termos sãodefinidos explicitamente:

- Uma plataforma é o sistema operacional do compu-tador que é construído no conjunto de instruções para o pro-cessador de computador, o hardware que executa operações ló-gicas e gerencia movimento de dados no computador.

- Código de máquina (MC) é o código que pode serlido e executado diretamente pelo processador do computador.

- Código de máquina específica é o código que podeser somente lido e executado por uma plataforma específica,ou um número de plataformas especificadas.

- Código de máquina generalizado é o código quenão é limitado a uma plataforma específica.

- um compilador converte um conjunto de instruçõesem um código de máquina.

Descrição de processos bem conhecidos

A figura 2b é um fluxograma ilustrando generica-mente o processo de software da técnica anterior de lingua-gens de programação baseadas em intérprete, como JAVA. Simi-lar às linguagens de programação baseadas em compilador, aslinguagens baseadas em intérprete são gravadas em linguagemde alto nível, utilizando um editor ou similar, mencionado aseguir como declarações de fonte 200. De acordo com essa a-bordagem, o compilador 210 traduz as declarações de fonte dealto nível 200 em um Código de Byte (BC) 220, que é um MCgeneralizado que não é limitado a uma certa plataforma. Nãoobstante, para executar o BC 220, um intérprete específico230 é necessário para traduzir BC 220 em um MC específico240. O intérprete específico 230 é normalmente instaladojuntamente com o sistema operacional. A principal vantagemdessa abordagem é que BC 220 pode ser distribuído para pla-taformas diferentes. Após BC 220 ser executado em uma certaplataforma, o intérprete específico 230 traduz um comando deBC de cada vez, desse modo produzindo um comando MC especí-fico para o hardware de computador executar. Ao lidar comSun Microsystems® Java, BC 220 é denominado Código de ByteJava e o intérprete 230 é denominado uma Máquina Virtual(VM). Em alguns casos, a VM vem junto com um compiladorJust-in-time 250 e é utilizado opcionalmente. 0 compiladorJust-in-time 250 compila BC de Java 220 em um MC específico260 como se o programa tivesse sido compilado inicialmentepara aquele programa específico. Nos dois casos de VM 230 ecompilador Just-in-time 250, o hardware de computador lê seuMC específico pretendido. Entretanto, uma vez que o intér-prete 230 traduz um comando de BC 220 de cada vez duranteexecução, pode rodar mais lento no computador.

A VM Java, que opera como um intérprete entre BCJava e um MC específico, é individual para cada plataforma.

Após VM Java ter sido fornecido para uma plataforma, qual-quer BC Java compilado pode ser rodado naquela plataforma.Portanto, quando um usuário tiver uma VM Java instalada emseu computador, ele pode adquirir qualquer programa em BCJava, e executar o mesmo em seu computador. Quando um pro-gramador programa em Java e compila o programa em um BC Ja-va, ele pode distribuir o BC Java amplamente para qualquerusuário, visto que o BC Java é compatível para todas as pla-taformas populares. A VM Java é responsável por alocar memó-ria, definir registros, empilhar, heap de "lixo", e área demétodo (área de método de uma VM Java é uma área lógica dememória que armazena todas as informações sobre os tiposcarregados), para a execução de programa.

A figura 3 é um fluxograma ilustrando genericamen-te o processo de software da técnica anterior de programarlinguagens que são projetadas para rodar em Microsoft®NET,como Visual J#. Dito em termos gerais, o ambiente .NET per-mite o uso de recursos da Web em vez dos recursos de compu-tador para vários serviços. J# Visual ou J# permite que osprogramadores programem em linguagem "similar à Java" e ro-dem o programa em .NET. As declarações de fonte 300, grava-das em linguagem de alto nivel Visual J#, são compiladas pe-lo compilador 310 em Linguagem Intermediária Microsoft(MSIL) 320, que é um MC geral que não é limitado a uma pla-taforma especifica. O MSIL 320 é equivalente ao BC Java 220em suas funções, e o BC Java 220 pode até mesmo ser conver-tido facilmente em MSIL 320. Similar ao processo descritoacima, o MSIL 320 é convertido em um MC especifico 340 uti-lizando Tempo de execução de Linguagem comum (CLR) 330, queé equivalente à função de JAVA VM 230. Como entendido, ou-tras linguagens de programação .NET como C# e VB.NET sãosubmetidas a um processo similar a partir de declarações defontes 300 para MSIL 320 para MC especifico 340.

Deve ser observado que as alocações de memória doVM e CLR descritos são amplamente, conhecidas pelos hackers,como a definição dos registros, pilha, heap de "lixo", e á-rea de método do programa. Utilizando essa informação, ohacker pode entender quais comandos do BC Java ou MSIL sereferem à exigência de licença e modificar esses comandos.

Um metadado .NET Na estrutura .NET da Microsoftdescreve o código CIL (Linguagem Intermediária comum) .NET.

Um compilador de linguagem .NET gerará os metadados e arma-zenará esses na montagem contendo o CIL. Os metadados des-crevem todas as classes e membros de classe que são defini-dos na montagem, e as classes e membros de classe que a mon-tagem atual chamará a partir de outra montagem. Os metadadospara um método contêm a descrição completa do método, inclu-indo a classe (e a montagem que contém a classe), o tipo deretorno e todos os parâmetros de método. Quando o CLR execu-ta CIL, verifica que os metadados do método chamado são i-guais aos metadados que são armazenados no método que chama.

Isso assegura que um método possa somente ser chamado exata-mente com o número certo de parâmetros e exatamente os tiposcertos de parâmetros. Portanto, em ambientes como .NET e Ja-va é mais fácil realizar engenharia reversa do código vistoque o código e metadados são fornecidos juntos como parte dopacote redistribuivel. Os metadados são necessários paracompilação Just-in-time de código para a plataforma alvo.

Entretanto, em linguagens baseadas em compilador como C++,os metadados são abandonados durante a compilação e estágiosde link e não são redistribuídos para usuários finais.

Descrição geral da invenção

A essência da invenção é um intérprete, cujos mé-todos de operação e alocações de memória são não publicados.0 novo intérprete não revelado ou "Secret VM", é mencionadoa seguir como SVM. Cada SVM é emparelhado com um conversorcorrelacionado, ou em outras palavras, cada SVM pode somenteinterpretar um código que foi produzido por um conversorcorrelacionado. Portanto, cada vendedor de software originalque requer proteção de software pode adquirir um par corre-lacionado, exclusivo de conversor e SVM. Os métodos de ope-ração, como codificação de instrução ou alocações de memó-ria, podem variar entre SVMs diferentes.

A figura 4 ilustra uma implementação da invenção,de acordo com uma das modalidades, onde as declarações defonte 400 são gravadas em linguagem de programação de altonivel de .NET. O compilador 410 compila declarações de fonte400 em MSIL 420 como descrito na técnica anterior. Nesseponto, o conversor 421 é utilizado para converter MSIL 420em uma Linguagem de Máquina Virtual Secreta (SVML) 422. ASVML 422 é um MC geral, não limitado a uma certa plataforma.

Entretanto, os comandos da SVML 422 são diferentes dos co-mandos de MCs gerais conhecidos como os comandos de BC Javaou MSIL 420. Portanto, a decifragem da SVML 422 é excepcio-nalmente complicada, uma vez que não existe desassembladorou depurador conhecido para SVML 422. A SVML 422 pode serdistribuída juntamente com a SVM correspondente 423. A SVM423 é compilada no computador designado utilizando o CLR lo-cal 430 para adicionar os dados referentes à plataforma es-pecífica do computador designado. Uma vez que a SVM 423 de-sempenha como intérprete, compreende não somente novos dadospara interpretar SVML 422, como também dados referentes aoperfil de plataforma a partir de CLR 430. Desse modo, quandoSVML 422 é executado no computador designado, SVM 423 inter-preta cada comando para o hardware para execução. Uma vezque o método de processamento da SVM 423 é desconhecido, umhacker achará difícil entender e modificar o código, ou ten-tar interceptar os dados durante tempo de execução.

Descrição geral dos atributos propostos do conversor

Um dos atributos designados do conversor envolve aprodução de programas de SVML diferentes para a mesma entra-da de MSIL (de outro modo conhecida como "morphing de códi-go"). O morphing de código se baseia em uma redundância noconjunto de instruções de SVML, por exemplo, a instrução SUBpode ser substituída por instruções ADD e NEG. Esse atributoé principalmente eficaz para evitar tentativas de comparar oconjunto de instruções de MSIL com o conjunto de instruçõesde SVML equivalente. Esse atributo se baseia em uma redun-dância no conjunto de instruções de SVML, por exemplo, ainstrução SUB pode ser substituída por instruções NEG e ADD.

I. Outro atributo designado do conversor é a pos-sibilidade de codificação dinâmica de instruções, signifi-cando a alteração de padrão de bit correspondente, ou códigode uma certa instrução. Ao contrário da MSIL, onde se esperaque as mesmas instruções sejam codificadas similarmente, emSVML a mesma instrução pode aparecer em códigos diferentes.

Por exemplo, a instrução pode ser codificada com seu endere-ço como mostrado nas seguintes tabelas:

<table>table see original document page 15</column></row><table><table>table see original document page 16</column></row><table>

Portanto, mesmo se um hacker pudesse tentar encon-trar padrões de repetição em um código SVML para deduzirinstruções comuns, ele considerará mais complicado do queassumido.

II. O atributo projetado principal do conversor éa causa de perda de dados durante conversão por tornar oprocesso de conversão praticamente irreversível. Um exemplode perda de dados é a remoção de metadados de estrutura decódigo, como declarações de método, uma vez que em .NET nãoé necessário quando um método é chamado somente por outrosmétodos transformados. O exemplo adicional de perda de dadosé o seguinte: um conjunto de instruções amplamente conhecidocompreende as seguintes instruções: ADD_INT8, ADD_INT16, eADD_INT32. Essas instruções instruem o processador a somaros números 8, 16 ou 32 bits de acordo. Durante o processo deconversão, utilizando o conversor exclusivo, todas essasinstruções são convertidas em instruções abertas "ADD". 0tipo de operando e número de bits, que deve ser somado (8,16 ou 32) é determinado durante tempo de execução. Portanto,a compilação reversa é impossível sem conhecer o número parasomar na instrução "ADD". Uma vez que o processo de conver-são é irreversível, o código não pode ser convertido de vol-ta em um formato BC Java/MSIL padrão, e portanto não podeser descompilado, desassemblado, depurado ou modificado uti-lizando ferramentas padrão.

Exemplo de arquitetura SVM e conjunto de instru-ções SVML correspondente

A figura 5 é um diagrama de blocos ilustrando umexemplo de arquitetura SVM, de acordo com uma das modalida-des. A Unidade de Lógica aritmética 500 executa as operaçõeslógicas em registros de operando 510 e 520, e armazena o re-sultado no registro 530. O registro de transferência de da-dos 560 é utilizado para transferir dados entre registros eBancos de memória 540 e 550. Bancos de memória 540 e 550 sãoutilizados para armazenar variáveis locais e parâmetros demétodo. O registro seletor de banco 570 armazena o número deBanco de memória em uso.

Um exemplo de um subconjunto de instruções de SVMLe seu significado:

<table>table see original document page 17</column></row><table><table>table see original document page 18</column></row><table>

Comparação entre um código de MC geral e código deSVML

Para fins de brevidade um exemplo não limitador émostrado aqui abaixo comparando um código de programa demontagem do MC geral da técnica anterior com aquele da SVML.Nos dois casos, a tarefa dada exigiu processamento da equa-ção 4+3-1.

Um código de programa de MC geral processando aequação 4+3-1:

LDC 4LDC 3ADDLDC 1SUB

Um código de programa de SVML processando á equa-ção 4+3-1:

SETMBANK1 - seleciona o banco de memória 1MEM2TRANSFER 23 - carrega "4", uma constante arma-zenada no endereço de memória 23

TRANSFER2OPl - mover o valor "4" para o registrode operando 1

MEM2TRANSFER 45 - carrega "3", uma constante arma-zenada no endereço de memória 45

TRANSFER20P2 - mover o valor "3" para o registrode operando 2

ADD - somar conteúdo dos registros de operando 1 e 2

RESULT2TRANSFER - mover o resultado "7" para o re-gistro de transferência

TRANSFER20P1 -mover o valor "7" para o registro deoperando 1

MEM2TRANSFER 12 - Carregar "1", uma constante ar-mazenada no endereço de memória 12

TRANSFER20P2 -mover o valor "1" para o registro deoperando 2

SUB - subtrair o conteúdo do operando 2 do operando 1

RESULT2TRANSFER - mover o resultado para o regis-tro de transferência

TRANSFER2MEM 1 - armazenar o resultado no endereçode memória 1

Como mostrado no código de programa acima, os ope-randos processados (4, 3 e 1) nunca são representados expli-citamente nas instruções. Um hacker que tenta engenhariareversa no programa não pode deduzir do presente conjunto deinstruções quais são os valores de operandos na equação,visto que cada valor é lido da memória durante tempo de exe-cução.

Modalidades adicionais da invenção

Em uma das modalidades, cada vendedor é equipadocom seu próprio par de conversor e SVM. Portanto, conhecer ométodo de processo de um SVM não revela o método de processode outras SVMs.

O método proposto pela presente invenção pode serutilizado com qualquer linguagem baseada em intérprete. Porexemplo, para J# de .NET a SVM é compilada pelo CLR, paraJAVA a SVM é compilada pela VM, e assim por diante. A inven-ção proposta pode ser utilizada para qualquer software querseja uma linguagem de alto nivel como C# ou VB.NET, um códi-go de software, um código de fonte ou um código de máquina.

A figura 6 ilustra um exemplo de outra modalidadeda invenção, onde as declarações de fonte 500 são gravadasem linguagem de alto nivel, como Visual J#. O compilador 410compila declarações de fonte 400 em MSIL 420 como descritoanteriormente. Entretanto, antes da conversão, as instruçõesda MSIL 420 são divididas em dois grupos, instruções sensi-veis, que podem incluir as exigências de licença, e instru-ções insensíveis. As instruções sensíveis são convertidaspelo conversor 421 em SVML 422, ao passo que as instruçõesinsensíveis não são convertidas. O MC geral 425, ou progra-ma, que consiste em uma parte MSIL e uma parte SVML, podeser distribuído juntamente com a SVM correspondente 423 paraqualquer plataforma popular. Para executar o programa, SVM423 é compilado por CLR 430 na plataforma designada. Duranteexecução, cada instrução é examinada em relação à compatibi-lidade com MSIL 420 ou SVML 422. As instruções de MSIL 420são interpretadas diretamente por CLR 430, ao passo que asinstruções de SVML 422 são interpretadas por SVM 423.

A figura 7 ilustra uma implementação da invenção,de acordo com uma das modalidades, para linguagens de pro-gramação baseadas em compilador. Como descrito nos antece-dentes, o código de fonte 700 é compilado pelo compilador710 em MC específico 720. O MC específico 720 é convertidoutilizando um conversor designado 721 em uma SVML 722, ondea SVML 722 é dependente de plataforma, ou em outras palavrasé um MC específico. A SVML 722 é distribuída com uma SVM 723projetada para a plataforma específica da SVML 722. Uma vezque a SVM distribuída 723 já é especificada para uma plata-forma designada, não requer compilação no computador desig-nado. Portanto, a SVM 723 é capaz de traduzir a SVML 722 emMC específico 740, para o hardware do computador designado.

Em outra modalidade para linguagens de programaçãobaseadas em compilador, somente as instruções sensíveis sãoconvertidas pelo conversor 721 em SVML 722. A SVML 722 édistribuída com a SVM 723 e as instruções restantes de MCespecífico 720. Durante execução a SVM 723 executa as ins-truções da SVML 722.

Embora algumas modalidades da invenção tenham sidodescritas como ilustração, será evidente que a invenção podeser colocada em prática com muitas modificações, variações eadaptações, e com o uso de inúmeros equivalentes ou soluçõesalternativas que estão compreendidas no escopo das pessoasversadas na técnica, sem se afastar do espírito da invençãoou exceder o escopo das reivindicações.

Claims

1. Método para evitar a modificação desautorizadade um software ou modificação desautorizada de dados de tem-po de execução, CARACTERIZADO por compreender as etapas de:a. fornecer um conversor, capaz de converter osoftware em um código de máquina generalizado, que não podesofrer engenharia reversa, utilizando um processo de conver-são qtrk causa perda de dados eb. fornecer um intérprete, cujo conhecido de seumétodo de processo é mantido restrito,c. interpretar, pelo intérprete, o código de má-quina geral em um código de máquina especifico enquanto re-constrói os dados perdidos durante o processo de interpretação.

2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o intérprete é compilado porum CLR.

3. Método, de acordo com a reivindicação 1 ou 2,CARACTERIZADO pelo fato de que o software é dividido de talmodo que somente parte do software é convertida com o con-versor e interpretada pelo intérprete.

4. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o software é uma linguagem dealto nivel.

5. Método, de acordo com a reivindicação 4,CARACTERIZADO pelo fato de que a linguagem de alto nivel éuma linguagem baseada em intérprete.

6. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que a linguagem de alto nível po-de ser qualquer uma das seguintes: Java, Visual J#, J#, C#,ou VB.NET.

7. Método, de acordo com a reivindicação 4,CARACTERIZADO pelo fato de que a linguagem de alto nível éuma linguagem baseada em compilador.

8. Método, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que a linguagem de alto nível po-de ser qualquer uma das seguintes: C++, VB ou Pascal.

9. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a perda de dados durante con-versão é a remoção de metadados de estrutura de código.

10. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a perda de dados durante con-versão é a conversão de instruções em outras instruções asquais seu(s) operando(s) correspondente(s) são determinadosdurante tempo de execução.

11. Método para evitar a descompilação e modifica-ção de tempo de execução de um código de software .NET/CLIutilizando ferramentas que se baseiam em metadados .NET/CLI,CARACTERIZADO por compreender:a. fornecer um conversor, capaz de converter o có-digo de software .NET/CLI em um código de máquina geral, on-de a conversão envolve perda de dados de metadados .NET/CLI;b. fornecer um novo intérprete capaz de interpretaro código de máquina geral sem exigir metadados .NET/CLI, on-de o novo intérprete é implementado como componente de soft-ware baseado em .NET/CLI para manter o mesmo nível de porta-bilidade que o código de software .NET/CLI; ec. interpretar o código de máquina geral em um có-digo de máquina especifico, pelo intérprete.

12. Método, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que o software é dividido de talmodo que somente parte do software seja convertida com oconversor e interpretada pelo novo intérprete.

13. Método para evitar violação de um mecanismo deexecução de termos de licença de software em um ambiente.NET/CLI, de acordo com a reivindicação 11, CARACTERIZADOpelo fato de que as ferramentas de descompilação e modifica-ção que se baseiam em metadados .NET/CLI se tornam inutili-záveis após aplicar o método.

14. Método, de acordo com a reivindicação 11, paracriptografar um código .NET/CLI enquanto supera a ausênciade suporte de criptografia/decriptografia de código em .NETCLR pela execução de uma decriptografia parcial para a fun-ção atualmente executada, CARACTERIZADO por compreender:a. aplicar um processo de criptografia simétricona representação de código de máquina geral de cada funçãoconvertida; eb. decriptografar cada função de código de máquinageral antes da execução pelo novo intérprete.

15. Método, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que a chave de processo de crip-tografia simétrica é entregue ao usuário do software separa-damente, desse modo tornando impossível a execução desauto-rizada de software.

16. Método, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que implementações diferentes donovo intérprete são fornecidas para vendedores de software,onde o novo intérprete é formado pela escolha de um subcon-junto completo de instruções a partir de um conjunto de ins-truções redundantes, e por gerar dinamicamente um conversore a montagem .NET/CLI da implementação do novo intérpreteutilizando .NET Framework System.CodeDom API, Sys-tem. Ref lection. Emit API, ou geração de código de fonte delinguagem .NET direta.

17. Método, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que as implementações diferentesdo novo intérprete são fornecidas a vendedores de software,pela aplicação de processo de obscurecimento com diferentesesquemas de renomear metadados na mesma implementação.NET/CLI de base do novo intérprete, para fazer com que osmetadados pareçam diferentes em ferramentas de descompila-ção.

18. Método, de acordo com as reivindicações 16 ou-17, CARACTERIZADO pelo fato de que o novo intérprete é for-mado escolhendo um subconjunto de instruções completo a par-tir de um conjunto de instruções redundantes, e gerando di-namicamente um conversor e montagem .NET/CLI de implementa-ção de intérprete novo utilizando .NET Framework Sys-tem.CodeDom API, System.Reflection.Emit API, ou geração decódigo de fonte de linguagem .NET direta, e pela aplicaçãode processo de obscurecimento com diferentes esquemas de re-nomear metadados na mesma implementação de .NET/CLI de basedo novo intérprete, fazendo com que os metadados pareçam di-ferentes em ferramentas de descompilação.

19. Método para evitar a descompilação e modifica-ção de tempo de execução de código de software Java utili-zando ferramentas que se baseiam em metadados de classe Ja-va, CARACTERIZADO por compreender:a. fornecer um conversor capaz de converter o có-digo de software Java em um código de máquina geral, onde aconversão envolve perda de dados de metadados Java;b. fornecer um novo intérprete capaz de interpre-tar o código de máquina geral sem exigir metadados de classeJava, onde o novo intérprete é implementado com componentede software baseado em Java para manter o mesmo nivel deportabilidade que o software de código de software Java; ec. interpretar, pelo intérprete, o código de má-quina geral em um código de máquina especifico.

20. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que o software é dividido de talmodo que somente parte do software seja convertida com oconversor e interpretada pelo novo intérprete.

21. Método para evitar a violação de um mecanismode execução de termos de licença de software em um ambienteJava, de acordo com a reivindicação 11, CARACTERIZADO pelofato de que as ferramentas de descompilação e modificaçãoque se baseiam em metadados .NET/CLI se tornam inutilizáveisapós aplicar o método.

22. Método, de acordo com a reivindicação 19, paracriptografar um código Java enquanto supera ausência de su-porte de criptografia/decriptografia de código em Java VMpela execução de uma decriptografia parcial para a funçãoatualmente executada, CARACTERIZADO por compreender:a. aplicar um processo de criptografia simétricona representação de código de máquina geral de cada funçãoconvertida; eb. decriptografar cada função de código de máquinageral antes da execução pelo novo intérprete.

23. Método, de acordo com a reivindicação 22,CARACTERIZADO pelo fato de que a chave de processo de crip-tografia simétrica é fornecida ao usuário de software sepa-radamente, para tornar impossível execução desautorizada desoftware.

24. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que implementações diferentes donovo intérprete são fornecidas a vendedores de software, on-de o novo intérprete é formado escolhendo um subconjunto deinstruções completo a partir de um conjunto de instruçõesredundantes, e gerando um conversor e implementação de in-térprete novo.

25. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que as diferentes implementaçõesdo novo intérprete são fornecidas a vendedores de software,por aplicação do processo de obscurecimento com diferentesesquemas de renomear metadados na mesma implementação Javade base do novo intérprete, para fazer com que os metadadospareçam diferentes em ferramentas de descompilação.

26. Método, de acordo com as reivindicações 24 ou-25, CARACTERIZADO pelo fato de que o novo intérprete é for-mado escolhendo um subconjunto de instruções completo a par-tir de um conjunto de instruções redundantes, e por gerardinamicamente um conversor e implementação de intérprete no-vo, e aplicar processo de obscurecimento com diferentes es-quemas de renomear metadados na mesma implementação de basedo novo intérprete, para fazer com que os metadados pareçamdiferentes em ferramentas de descompilação.

27. Método, de acordo com a reivindicação 11,CARACTERIZADO pelo fato de que o uso de ferramentas de ins-trumentação que se baseiam em metadados .NET/CLI para violarum mecanismo de execução de termos de licença de software éevitado pelo uso de arquitetura de intérprete novo para exe-cutar chamadas entre métodos convertidos.

28. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que o uso de ferramentas de ins-trumentação que se baseiam em metadados de classe Java paraviolar um mecanismo de execução de termos de licença desoftware é evitado pelo uso de arquitetura de intérprete no-vo para executar chamadas entre métodos convertidos.