BR112019011434A2 - autodepuração - Google Patents

Abstract

a presente invenção refere-se, de forma geral, a métodos, produtos de programas de computador e dispositivos para proteção de software. de acordo com a invenção, um método pode compreender associar um processo depurador a um processo de software. durante a execução do processo de software, operações relevantes para a funcionalidade do processo de código são realizadas dentro do processo depurador. como resultado, o processo depurador não pode ser substituído ou corrompido sem afetar a funcionalidade do processo de software. o processo de software pode, portanto, ser protegido de inspeção por técnicas de depuração maliciosas ou modificadas.

Description

“AUTODEPURAÇÃO” [001 ]O trabalho conducente à presente invenção recebeu financiamento do Seventh Framework Programme [União Européia] [Comunidade Européia de Energia Atômica] ([FP7/2007-2013] [FP7/2007-2011]) sob o contrato de subvenção n° 609734.

CAMPO [002]A presente invenção refere-se à segurança de software, particularmente, à proteção de software, tais como aplicativos ou bibliotecas, de ataques usando técnicas de depuração.

FUNDAMENTO [003]A depuração é o processo pelo qual erros no código podem ser identificados. Uma ferramenta para essa finalidade é o depurador, um tipo de utilitário que muitos sistemas operacionais permitem que seja pareado com o código a ser depurado. Quando uma exceção ou outro erro ocorre, isso é reportado ao depurador, que é capaz de inspecionar o código e identificar a origem desse problema.

[004]A capacidade de emparelhamento de um depurador com código tem sido utilizada por partes maliciosas, a fim de comprometer a segurança do código. Em particular, uma vez que um depurador é capaz de identificar o código de operação, ele pode ser uma fonte de vulnerabilidade.

[005]Foram desenvolvidas técnicas para tentar proteger o código contra esse ataque. Essas técnicas incluem tentativas de permitir que o código identifique quando um depurador ativo foi ilicitamente acoplado ao código. Outra abordagem é projetar o código para que ele mesmo inicialize um depurador quando executado (esse depurador pode ser denominado “autodepurador”). A maioria dos sistemas operacionais permitirá apenas que um único depurador seja emparelhado com um determinado processo, o que significa que o autodepurador ocupa o espaço que um depurador malicioso pode, de outra forma, desejar utilizar.

BREVE DESCRIÇÃO DOS DESENHOS

Petição 870190051970, de 03/06/2019, pág. 12/44

2/25 [006]A Figura 1 é uma ilustração esquemática das principais características de um processo de código prévio, e do acoplamento do processo de código e do processo de depuração da presente descrição;

[007]A Figura 2 é um fluxograma que mostra as etapas do tempo de execução de acordo com uma modalidade;

[008]A Figura 3 mostra aspectos primários da geração de binários de acordo com a presente invenção; e [009]A Figura 4 mostra uma infraestrutura de hardware para implementar uma modalidade preferida.

DESCRIÇÃO DETALHADA DOS DESENHOS [010]De forma geral, métodos para proteção da operação de código são providos. De acordo com a invenção, um método pode compreender inicializar um processo de código e inicializar um processo depurador associado ao processo de código. Durante a execução do processo de código, operações criticamente relevantes para a funcionalidade do processo de código podem ser realizadas dentro do processo depurador. Como resultado, o processo depurador não pode ser substituído ou corrompido sem afetar a funcionalidade do processo de código. O processo de código pode, portanto, ser protegido de inspeção por técnicas de depuração maliciosas ou modificadas.

[011]Neste contexto, “criticamente” pode ser entendido como significando que uma saída produzida por essas operações realizadas no processo depurador serve como entrada para a parte restante do processo de código, e que essa entrada é necessária para permitir que o processo de código gere sua saída correta dada a outra entrada do processo de código.

[012]Em alguns aspectos da invenção, um método para proteção de software é provido. O método pode compreender inicializar um processo de software e associar um processo depurador ao processo de software. O processo de código pode ser,

Petição 870190051970, de 03/06/2019, pág. 13/44

3/25 então, executado de forma que o processo depurador seja invocado pelo menos uma vez. Após a invocação, uma ou mais funções podem ser executadas dentro do processo depurador, essas funções tendo uma saída dependente de dados associados com o processo de software. Uma vez que a saída pode variar em dependência de dados associados com o processo de software (isto é, não predeterminado), a funcionalidade geral é apenas alcançada quando ambos o processo de software e o processo depurador estão funcionando corretamente. Isso não deixa espaço para interferência com o processo depurador para analisar o código.

[013]O processo de software desse aspecto pode ser considerado um processo “depurante”, pois toma o lugar do processo que está sendo depurado pelo depurador. O processo depurador pode ser inicializado quando o processo de software for inicializado ou posteriormente. Por exemplo, o processo depurador pode ser inicializado quando determinada funcionalidade (por exemplo, uma biblioteca) é carregada no processo de software. Em alguns exemplos, o processo de software utiliza a função fork para iniciar o processo depurador. Em outros exemplos, o processo depurador pode ser inicializado primeiro e, depois, utilizar a função fork para gerar o processo de software.

[014]Em algumas modalidades, a saída compreende uma saída de dados para uso pelo processo de software. Assim, a saída das funções dentro do processo depurador pode influenciar diretamente a operação posterior do processo de software, assim, acoplando firmemente os dois processos de forma que não seja fácil de romper. A saída da função no processo depurador compreende uma entrada de dados para o processo de software, a entrada de dados sendo crítica para a execução do processo de software.

[015]Em algumas modalidades, a saída de uma determinada função pode indicar múltiplos pontos de retorno dentro do processo de software para execução contínua. Assim, o ponto de retorno para pelo menos uma função é variável (em vez

Petição 870190051970, de 03/06/2019, pág. 14/44

4/25 de fixo). O fluxo de controle é, assim, variável de acordo com o comportamento do processo depurador e não pode ser prontamente inferido ou recriado.

[016]Em algumas modalidades, o processo depurador provê recursos de suporte de memória para permitir que as uma ou mais funções recuperem dados da memória dentro do espaço de endereço do processo de software. Assim, as funções relevantes ao programa podem ter a capacidade de processar dados como se fossem executados dentro do processo de software.

[017]O processo depurador pode ser invocado quando um ponto de interrupção dentro do processo de código é alcançado. O processo depurador pode ser desassociado do processo de software quando o processo de software termina. O processo de software pode finalizar porque está completo ou por outro motivo (tal como quando abortado). Alternativamente, o processo depurador pode ser desassociado do processo de software quando a funcionalidade dentro do processo de software finalizar, em vez de esperar que o processo como um todo seja concluído.

[018]Em algumas modalidades, o processo de software implementa um executável, tal como um aplicativo. Em outras palavras, o processo de código implementa uma biblioteca.

[019]Em outro aspecto da invenção, é provido um método para geração de código protegido. Fragmentos de código dentro do código de objeto a serem migrados para um depurador podem ser identificados. O código binário pode, então, ser gerado, em que o código binário no tempo de execução faz com que um processo depurador se associe a um processo de software, os fragmentos de código identificados sendo executados dentro do processo depurador. O processo de software e o processo depurador podem “bifurcados (função fork)” a partir de um único processo. Por exemplo, o processo de software pode inicializar o processo depurador.

[020]A etapa de geração pode compreender incorporar código predefinido correspondente à funcionalidade de depurador genérica dentro do código binário. A

Petição 870190051970, de 03/06/2019, pág. 15/44

5/25 etapa de geração pode ser uma etapa de ligação incorporando alguns aspectos predefinidos do depurador, tais aspectos podem ser denominados de “minidepurador”. Assim, o depurador global inclui alguns aspectos genéricos, bem como alguns aspectos específicos para o código fonte em virtude da inclusão dos fragmentos de código identificados.

[021 ]O método pode compreender extrair do código-fonte uma ou mais anotações identificando fragmentos de código a serem migrados para um depurador. O código fonte é, então, compilado para gerar o código de objeto. O código binário pode, então, ser gerado a partir do código de objeto, com os fragmentos de código identificados sendo integrados com um depurador no código binário. Dessa forma, a geração de código binário pode ser a etapa de ligação, que inclui um elemento de reescrita para mover fragmentos identificados para outro local. Quando o código binário é então utilizado, um depurador é gerado compreendendo aspectos do código fonte original, o que pode ser pertinente para a funcionalidade do código fonte.

[022]Em algumas modalidades, o código binário compreende um primeiro arquivo de código binário correspondente ao código fonte, mas excluindo os fragmentos de código identificados, e um segundo arquivo de código binário correspondente ao depurador. Alternativamente, um único arquivo de código binário pode incorporar ambos o código fonte e o depurador.

[023]Outros aspectos da invenção referem-se a produtos de programa executáveis por computador que compreendem instruções executáveis por computador para realizar os métodos dos aspectos descritos acima. Os aspectos da invenção também podem se referir a dispositivos configurados para realizar os métodos dos aspectos descritos acima.

[024]Algumas modalidades específicas são agora descritas a título de ilustração com referência aos desenhos anexos, em que números de referência semelhantes se referem a características semelhantes.

Petição 870190051970, de 03/06/2019, pág. 16/44

6/25 [025]Através de técnicas de reescrita binária, a presente invenção pode migrar pedaços inteiros de funcionalidade do software original para um autodepurador. Isso oferece várias vantagens. Primeiramente, o comportamento de entrada-saída do autodepurador não é mais predeterminado: toda vez que o autodepurador intervém, ele executa uma funcionalidade diferente que não é predeterminada, mas que pode variar tanto quanto a funcionalidade em programas protegidos pode variar. Isso torna a proteção muito mais resistente à análise automatizada, desofuscação e desconstrução. Em segundo lugar, mesmo que o invasor possa descobrir o fluxo de controle e o fluxo de dados equivalente do programa original, torna-se muito mais difícil para um invasor desfazer a proteção e reconstruir o programa original. Em combinação, esses dois atributos tornam muito mais difícil para um invasor desassociar o autodepurador enquanto mantém um programa em funcionamento a ser rastreado ou depurado ao vivo.

PROJETO GERAL DE AUTODEPURADOR [026]A Figura 1 ilustra os conceitos básicos de um esquema de autodepuração de acordo com a presente invenção. Esta modalidade é direcionada ao Linux (e derivados, tais como Android), e os princípios também podem ser aplicados a outros ambientes, tais como Windows e OS X.

[027]À esquerda da Figura 1, um aplicativo original desprotegido é representado, incluindo um pequeno fragmento de gráfico de fluxo de controle. O código de montagem mostrado é (pseudo) código ARMv7. Esse aplicativo desprotegido é convertido em um aplicativo protegido que consiste em duas partes: uma depurante, que corresponde principalmente ao aplicativo original, como mostrado no meio da figura, e um depurador, como mostrado à direita. Além de alguns componentes novos injetados no depurante e no depurador, a principal diferença com o aplicativo original é que o fragmento gráfico de fluxo de controle foi migrado do aplicativo para o depurador. Esta modalidade particular suporta todos os fragmentos

Petição 870190051970, de 03/06/2019, pág. 17/44

7/25 de código de entrada única e saídas múltiplas que não contêm fluxo de controle interprocessual, tal como chamadas de função.

[028]A migração de tais fragmentos é mais do que simples cópia: referências de memória, tal como a instrução LDR, devem ser transformadas, pois no aplicativo protegido, o código migrado sendo executado no espaço de endereço do depurador pode preferencialmente acessar dados que ainda residem no espaço de endereço do depurante. Todos os componentes e transformações relevantes serão discutidos em mais detalhes nas seções posteriores.

[029]Os fragmentos migrados são preferencialmente críticos para a operação do aplicativo. Ou seja, a saída produzida por aquelas operações realizadas migradas para o processo depurador serve como entrada para a parte restante do processo de código, e essa entrada é necessária para permitir que o processo de código gere sua saída correta dada a outra entrada do processo de código. Esse requisito é fácil de perder na prática. Por exemplo, um programador típico pode considerar executar a inicialização de variáveis do processo de código no contexto do depurador. No entanto, em geral, não é suficiente executar a inicialização de variáveis a partir do processo de código no processo depurador, porque, na prática, nos processos em que isso acontece com muita frequência, a inicialização da variável (por exemplo, variáveis locais na entrada de uma função) é realizada como resultado de boas práticas de programação e para atender aos requisitos de definição de linguagem de programação fonte, sem que seja realmente necessário para o correto funcionamento do processo e para a geração de saídas corretas. Isso pode ser porque as variáveis simplesmente não são usadas nos percursos executados no processo de código ou porque os valores iniciais são sobrescritos antes que possam impactar a saída ou execução do processo de código.

[030]No tempo de execução, a operação deste aplicativo protegido é o seguinte. Primeiramente, o depurante é inicializado na etapa s21, como se fosse o

Petição 870190051970, de 03/06/2019, pág. 18/44

8/25 aplicativo original. Um inicializador recém-injetado, em seguida, utiliza a função fork em um novo processo para o depurador, em que o inicializador do depurador imediatamente se associa ao processo depurante. Assim, o processo depurador é inicializado e associado ao processo depurante na etapa s22.

[031]Quando, posteriormente, durante a execução do programa, o ponto de entrada do fragmento de código migrado é alcançado, um fluxo de controle possível no aplicativo segue as setas na Figura 1. No aplicativo/depurante, a instrução de indução da exceção é executada e causa uma exceção na etapa s23 (rotulado como 1 na Figura 1). O depurador é notificado desta exceção e a manipula em seu ciclo depurador na etapa s24 (rotulado como 2 na Figura 1). Entre outros, o código neste ciclo é responsável por pesquisar e carregar o estado de processo do depurante, procurar o fragmento de código migrado correspondente e transferir o controle para o ponto de entrada daquele fragmento na etapa s25 (rotulado como 3 na Figura 1). Como dito, nesse fragmento, os acessos de memória não podem ser realizados como estão. Então, eles são substituídos por invocações 4 de funções de suporte à memória 5 que acessam a memória no espaço de endereço do depurante na etapa s26. Quando um ponto de saída 6 é eventualmente alcançado no fragmento de código migrado, o controle é transferido para o ponto correspondente no ciclo depurador 7 na etapa s27, que atualiza o estado do depurante com os dados computados no depurador na etapa s28, e os 8 controles são transferidos de volta para o depurante na etapa s29. Para fragmentos de código com múltiplas saídas, tal como o exemplo na figura, o controle pode ser transferido de volta para múltiplos pontos de continuação no depurante. A este respeito, o depurador da presente revelação se comporta de maneira mais complexa do que os autodepuradores existentes, que implementam um mapeamento um-para-um entre transferências de fluxo de controle de avanço e retrocesso entre depurante e depurador.

[032]Eventualmente, quando o aplicativo sair, os finalizadores embutidos

Petição 870190051970, de 03/06/2019, pág. 19/44

9/25 realizarão as operações de desassociação necessárias.

[033]É importante observar que esse esquema não pode ser implementado apenas para proteger executáveis (ou seja, binários com uma função principal e ponto de entrada), mas também para proteger bibliotecas compartilhadas. Assim como os executáveis, as bibliotecas podem conter inicializadores e finalizadores que são executados quando são carregados ou descarregados pelo carregador de OS. Nesse momento, todas as funções de fork, associação e desassociação necessárias podem ser executadas também.

[034]Embora a descrição a seguir se refira principalmente à proteção de aplicativos, implicitamente, o ensinamento aplica igualmente aplicativos e bibliotecas. Um aspecto que é particularmente relevante para as bibliotecas é a necessidade de uma adequada inicialização e finalização do depurador. Isso é necessário porque não é incomum que as bibliotecas sejam carregadas e descarregadas várias vezes dentro de uma única execução de um programa. Por exemplo, o carregamento e o descarregamento repetitivos acontecem com frequência para plug-ins de reprodutores de mídia e navegadores. Além disso, enquanto os principais programas consistem em apenas uma cadeia quando são inicializados, eles podem consistir em múltiplas cadeias quando as bibliotecas são carregadas e descarregadas.

SUPORTE DE FERRAMENTAS [035]A Figura 3 apresenta um possível fluxo de ferramenta conceituai.

Anotações do Código Fonte [036]Para determinar os fragmentos de código a serem migrados para o depurador, existe um número de opções. Uma delas, apresentada na figura - e também a que foi utilizada em nossa implementação - é anotar o código fonte na etapa s31 com pragmas, comentários ou quaisquer outras formas de anotações que marquem os inícios e fins das regiões de código a serem migrados para o processo depurador. Um simples grep é suficiente para extrair anotações e seus números de

Petição 870190051970, de 03/06/2019, pág. 20/44

10/25 linha e armazenar essas informações em um arquivo de anotações na etapa s32.

[037]Opções alternativas seriam listar os procedimentos ou arquivos de código fonte a serem protegidos ou coletar traços ou perfis para selecionar fragmentos interessantes de forma semiautomática.

[038]A esse respeito, é importante notar que os fragmentos a serem migrados para o depurador não devem necessariamente ser fragmentos muito quentes. Para obter uma forte adesão entre o depurante e o depurador, basta levantar exceções com relativa frequência, mas isso não precisa estar nos percursos de código mais quentes. Outras considerações para a seleção de fragmentos serão detalhadas abaixo. Uma vez que cada exceção levantada introduzirá uma quantidade significativa de informações complementares (mudança de contexto, muitas chamadas ptrace...), é importante minimizar seu número sem comprometer o nível de proteção.

Compiladores e Ferramentas Padrão [039]Para que a abordagem de autodepuração divulgada seja implementada, qualquer compilador “padrão” pode ser usado na etapa s33. A técnica não impõe nenhuma restrição no código gerado pelo compilador. Em avaliações experimentais, ambos o GCC e o LLVM foram utilizados, nos quais não houve necessidade de adaptação ou ajuste da geração de código.

[040]Um requisito, entretanto, é que o compilador e os utilitários binários (o assembler e o linker) forneçam ao reescritor do tempo de conexão (link-time) informações de realocação e símbolo suficientemente precisas. Isso é necessário para permitir que análises e transformações de código de tempo de conexão confiáveis e conservadoras implementem todo o esquema de autodepuração, incluindo a migração e a transformação dos fragmentos de código selecionados. Fornecer informações suficientemente precisas é certamente possível para as ferramentas comumente usadas. Os compiladores proprietários da ARM, por exemplo, fazem isso há muito tempo, e para as GNU binutils, GCC e LLVM, correções

Petição 870190051970, de 03/06/2019, pág. 21/44

11/25 muito simples são suficientes para evitar que essas ferramentas executem um relaxamento de símbolos excessivamente agressivo e simplificação da realocação, e para forçá-las a inserir símbolos de mapeamento para marcar dados no código. Esses requisitos foram documentados antes, e demonstrou-se que eles são suficientes para executar uma reescrita de código confiável e conservadora de tempo de conexão tão complexa e não convencional quanto as versões CISC (x86) e RISC (ARMv7) do núcleo Linux e bibliotecas C, que são cheios de códigos de conjunto manualmente escritos.

[041]Uma grande parte genérica do depurador - o “minidepurador” - pode ser pré-compilado com o compilador padrão e, então, simplesmente conectado ao aplicativo a ser protegido. Outras partes, tais como os prólogos e epílogos do ciclo de depuração para cada um dos fragmentos migrados, são gerados pelo reescritor do tempo de conexão, pois são customizados para seus fragmentos específicos.

[042]Para permitir que o reescritor do tempo de conexão identifique os fragmentos que foram anotados no código fonte, basta passar a informação do número da linha extraída dos arquivos de código fonte, e permitir que os compiladores gerem arquivos de objeto com informações de depuração. Essa informação de depuração, então, mapeia todos os endereços no código binário para os números de linha fonte, que o reescritor pode conectar aos números de linha das anotações.

Binários, Bibliotecas e Processos [043]O reescritor de tempo de conexão tem duas opções para gerar um aplicativo protegido na etapa s35. Uma primeira opção é gerar dois binários, um para o aplicativo/depurante, e um para o depurador. Do ponto de vista de segurança, isso pode ser preferível, pois a semântica do aplicativo e sua implementação são distribuídas por vários binários, o que provavelmente dificulta ainda mais para um invasor desfazer a proteção, ou seja, corrigir o depurante no aplicativo original. Esta opção introduz uma sobrecarga de tempo de execução adicional, no entanto, uma vez

Petição 870190051970, de 03/06/2019, pág. 22/44

12/25 que o inicializar do depurador também requer o carregamento do segundo binário.

[044]A opção alternativa - usada nos exemplos adicionais abaixo - é incorporar todo o código de depurante e todo o código do depurador em um binário. Nesse caso, a simples função fork será suficiente para inicializar o depurador. Se não, e até que ponto, isso facilita ataques contra a proteção fornecida pela autodepuração, é uma questão de pesquisa aberta.

IMPLEMENTAÇÃO

Inicialização e Finalização [045]Uma rotina de inicialização extra pode ser adicionada a um binário protegido. Essa rotina é invocada assim que o binário for carregado (porque é atribuída uma alta prioridade), após o que todas as outras rotinas listadas na seção .init do binário são executadas.

[046]Essa rotina de inicialização invoca a função fork(), criando assim dois processos chamados pai e filho. Quando a rotina de inicialização é concluída, o processo pai continuará a execução, geralmente invocando a próxima rotina de inicialização.

[047]Existem duas opções para atribuir os papéis de depurador e depurante: após a função fork, o processo filho se associa ao processo pai, ou vice-versa. No primeiro caso, o filho se torna o depurador e o pai se torna o depurante, no último caso, os papéis são obviamente invertidos.

[048]A primeira opção é preferida. O processo pai (isto é, depurante) continua sendo o processo principal do aplicativo e mantém o mesmo ID de processo (PID). Isso facilita a execução contínua de todos os aplicativos externos e canais de comunicação entre processos que dependem do PID original, por exemplo, porque foram configurados antes do carregamento e função fork de uma biblioteca protegida.

[049] Esse esquema vem com seus próprios problemas, no entanto. Como já mencionado, as bibliotecas compartilhadas podem ser carregadas e descarregadas

Petição 870190051970, de 03/06/2019, pág. 23/44

13/25 (usando dlopen() e dlcloseQ) a qualquer momento durante a execução de um programa. Existe, portanto, o problema potencial que uma biblioteca compartilhada protegida pode ser descarregada e carregada novamente, enquanto o depurador originalmente carregado e “bifurcado” ainda não terminou sua inicialização. Isso pode resultar na existência simultânea de dois processos depurador, ambos tentando (e um falhando em) se associar ao depurante. Para evitar essa situação, bloqueamos a execução da cadeia que chamou dlopen(). Então, até esse momento, essa cadeia não pode invocar dlclose() usando o identificador que obteve com dlopen() e também não pode passar o identificador para outra cadeia. Um ciclo infinito na rotina de inicialização do depurante impede que a cadeia de carregamento saia da rotina de inicialização antes que o depurador permita que ela prossiga.

[050]A rotina de inicialização também instala um finalizador no depurante. Esse finalizador não faz muito. Na saída do programa (ou quando a biblioteca compartilhada é descarregada), ele simplesmente informa o minidepurador sobre este fato levantando um sinal SIGUSR1, fazendo com que o minidepurador se desassocie de todas as cadeias do depurante e desligue o processo depurador.

Suporte a Multiencadeamento [051]Associar o depurador não é trivial, em especial, no caso de bibliotecas compartilhadas protegidas. Quando uma biblioteca é carregada, o aplicativo pode consistir em várias cadeias. Apenas uma delas executará a rotina de inicialização do depurante durante sua chamada para dlopen. Isso é bom, já que apenas uma função fork será executada, mas também apresenta a desvantagem de que apenas uma cadeia entrará no ciclo infinito mencionado na seção anterior. As outras cadeias no processo depurante continuarão sendo executadas, e podem criar novos encadeamentos em qualquer ponto durante a execução da rotina de inicialização do depurante ou da rotina de inicialização do depurador. Para garantir uma proteção adequada, o depurador deve se associar a cada cadeia no processo depurante como

Petição 870190051970, de 03/06/2019, pág. 24/44

14/25 parte de sua inicialização. Para garantir que o depurador não perca nenhuma cadeia criada no depurante, entretanto, foram utilizados o diretório /proc/[pid]/task, que contém uma entrada para cada cadeia de um processo. O processo depurador se associa a todas as cadeias, iterando sobre as entradas neste diretório, e mantendo a iteração até que nenhuma nova entrada seja encontrada. Após a associação à cadeia, que acontece por meio de uma requisição PTRACE_ATTACH, a cadeia também é interrompida (e o depurador é notificado desse evento pelo OS), o que significa que não pode mais gerar novas cadeias a partir de então. Assim, para qualquer programa que gera um número finito de cadeias, assegura-se que o procedimento iterative para se associar a todas as cadeias seja encerrado. Uma vez que todos as cadeias tenham sido associadas, o ciclo infinito no depurante é finalizado e suas cadeias interrompidas podem continuar. Quando cadeias adicionais são criadas posteriormente durante a execução do programa, o depurador é automaticamente associado a elas pelo OS, e recebe um sinal de que toda a contabilidade necessária pode ser executada.

Fluxo de Controle [052]Transformar o fluxo de controle em e fora dos fragmentos de código migrados consiste em várias partes. Foram discutidos o levantamento de exceções para notificar o depurador, a transferência do ID informando o depurador de qual fragmento deve ser executado e os prólogos e epílogos customizados que são adicionados a cada fragmento de código.

Levantamento de Exceções [053]A notificação real do depurador pode acontecer através de qualquer instrução que faça com que uma exceção seja levantada. Em nossa implementação, foi utilizado um ponto de interrupção de software (isto é, uma instrução BKPT em ARMv7) para fins de simplificação. Outras exceções menos óbvias podem, obviamente, ser usadas, tais como as causadas por instruções ilegais ou indefinidas. Quando tais instruções são alcançadas através de fluxo de controle direto (ramificação

Petição 870190051970, de 03/06/2019, pág. 25/44

15/25 direta ou percurso de queda), elas podem facilmente ser detectadas estaticamente. Mas quando transferências de fluxo de controle indireto são usadas para saltar para os dados nas seções de código, e os bits de dados correspondem a uma instrução ilegal ou indefinida, a detecção estática pode se tornar muito mais difícil. Da mesma forma, instruções legais que lançam exceções apenas quando seus operandos são “inválidos” podem ser usadas para ocultar o objetivo das instruções. Tais instruções incluem divisão por zero, acessos de memória inválidos (isto é, uma falha de segmentação), ou a desreferência de um ponteiro inválido (resultando em um erro de barramento).

Transferência de IDs [054]A cadeia é chamada no depurante, que gera uma exceção na cadeia solicitante, pois está essencialmente solicitando ao depurador que execute algum fragmento de código.

[055]O depurador, após ser notificado sobre a requisição pelo OS, precisa descobrir qual fragmento executar. Para permitir isso, o depurante pode passar um ID do fragmento de várias maneiras. Uma opção é simplesmente usar o endereço da instrução de indução da exceção como um ID. Outra opção é passar o ID colocandoo em um registrador fixo logo antes de levantar a exceção ou em uma localização de memória fixa. Em nossa implementação, usamos a última opção. Como várias cadeias no depurante podem solicitar um fragmento diferente simultaneamente, a localização da memória não pode ser uma localização global. Em vez disso, precisa ser a localização da cadeia. Como cada cadeia tem sua própria pilha, optamos por passar o ID do fragmento pela parte superior da pilha da cadeia solicitante.

[056]Dependendo do tipo de instrução usada para levantar a exceção, outros métodos também podem ser previstos. Por exemplo, o operando divisor de uma instrução de divisão (por zero) podería ser usado para passar o ID também.

Prólogos e Epílogos

Petição 870190051970, de 03/06/2019, pág. 26/44

16/25 [057]O ciclo depurador no minidepurador é responsável por pesquisar e carregar o estado do programa do depurante antes de um fragmento ser executado, e por transferi-lo de volta após sua execução. A funcionalidade ptrace padrão é usada para fazer isso.

[058]Para cada fragmento de código migrado, o ciclo de depuração também contém um prólogo e um epílogo personalizados a serem executados antes e depois do fragmento de código responsável. O prólogo carrega os valores necessários da estrutura em registros, o epílogo grava os valores necessários de volta na estrutura. O prólogo é customizado no sentido de que ele só carrega os registros que são realmente usados no fragmento (os chamados registros live-in). O epílogo apenas armazena os valores que são live-out (isto é, que serão consumidos no depurante) e que foram substituídos no fragmento de código.

Acessos à Memória [059]Para cada operação de carga ou armazenamento em um fragmento de código migrado, é necessário um acesso à memória do depurante. Existem várias opções para implementar tais acessos. A primeira é simplesmente usar a funcionalidade ptrace: o depurador pode executar requisições PTRACE_PEEKDATA e PTRACE_POKEDATA para ler e escrever no espaço de endereço do depurante. Neste caso, por palavra a ser lida ou escrita, uma chamada de sistema ptrace é necessária, o que resulta em uma sobrecarga significativa. Algumas versões recentes do Linux suportam acessos mais amplos, mas ainda não estão disponíveis em todos os lugares, tal como no Android.

[060]A segunda opção é abrir o arquivo /proc/[pid]/mem do depurante no depurador e, então, simplesmente ler ou escrever neste arquivo. Isso é mais fácil de implementar, e dados mais amplos podem ser lidos ou gravados com uma única chamada de sistema, então, muitas vezes, esse método é mais rápido. Escrever em outro /proc/[pid]/mem do processo não é suportado em todas as versões dos núcleos

Petição 870190051970, de 03/06/2019, pág. 27/44

17/25

Linux/Android, no entanto, em nosso protótipo, as solicitações de escrita ainda são implementadas com a primeira opção.

[061]Uma terceira opção se baseia na segunda: se o binário-reescritor puder determinar quais páginas de memória serão acessadas em um fragmento de código migrado, o ciclo de depuração pode realmente copiar essas páginas para o espaço de endereço do depurador usando a opção 2. O fragmento no depurador, em seguida, simplesmente executa operações de carga e armazenamento regulares para acessar as páginas copiadas e, após o fragmento ser executado, as páginas atualizadas são copiadas de volta para o depurante. Esta opção pode ser mais rápida se, por exemplo, o fragmento de código contiver um ciclo para acessar um buffer na pilha. Os experimentos realizados para comparar a terceira opção com as duas opções anteriores revelaram que essa técnica pode valer a pena para apenas 8 acessos à memória. Não foi implementado um suporte confiável para isso em nosso protótipo, no entanto: uma análise conservadora de tempo de conexão para determinar quais páginas serão acessadas por um fragmento de código permanece um trabalho futuro neste momento.

[062]Uma quarta opção potencial é adaptar o depurante, por exemplo, fornecendo uma biblioteca de gerenciamento de memória de heap customizada (malloc, free...) de forma que toda a memória alocada (ou pelo menos o heap) seja alocada como memória compartilhada entre o depurante e os processos depuradores. Então, os fragmentos de código no depurador podem acessar os dados diretamente. Obviamente, os fragmentos ainda precisam ser reescritos para incluir uma tradução de endereços entre os dois espaços de endereço, mas provavelmente a sobrecarga desta opção pode ser muito menor do que a sobrecarga das outras opções. A implementação desta opção e sua avaliação continuam a ser trabalho futuro neste momento.

[063]Em relação à segurança, as diferentes opções provavelmente também

Petição 870190051970, de 03/06/2019, pág. 28/44

18/25 terão um impacto diferente, no sentido de que irão impactar a dificuldade de um invasor de fazer engenharia reversa da semântica original do programa e desconstruir a versão de autodepuração em um equivalente do programa original.

Combinação da Autodepuração com Outras Proteções [064] Para fornecer uma forte proteção a softwares contra ataques MATE, técnicas adicionais de proteção podem ser empregadas. Por exemplo, no topo da autodepuração, ofuscação para evitar a análise estática pode ser empregada, juntamente com técnicas antiadulteração para evitar todos os tipos de ataques.

[065]Por exemplo, o reescritor binário que implementa a abordagem de autodepuração também pode aplicar um número de outras proteções, tais como um ou mais de:

- Ofuscações de fluxo de controle: as conhecidas ofuscações de predicados opacos, achatamento de fluxo de controle e funções de ramificação;

- Randomização de layout de código: durante o layout de código, o código de todas as funções é misturado e o layout é randomizado;

- Mobilidade de código: uma técnica na qual os fragmentos de código são removidos do binário estático e somente baixados, como o chamado código móvel, para a aplicação no tempo de execução;

- Proteções de código: implementações on-line e off-line de técnicas nas quais os hashes são computados sobre o código no espaço de endereço de processo para verificar se o código não foi alterado.

- Integridade de fluxo de controle: uma técnica leve na qual os endereços de retorno são verificados para evitar que funções internas sejam invocadas a partir de código externo.

- Virtualização de conjunto de instruções: uma técnica com a qual o código nativo é traduzido para bytecode que é interpretado por uma máquina virtual incorporada em vez de executado nativamente.

Petição 870190051970, de 03/06/2019, pág. 29/44

19/25 [066]Combinar a técnica de autodepuração com todas essas proteções não representa nenhum problema na prática. No reescritor de tempo de conexão, não é difícil determinar uma boa ordem para realizar todas as transformações para todas as proteções, e evitar que múltiplas técnicas sejam aplicadas nos mesmos fragmentos de código quando essas técnicas não compõem de fato. Por exemplo, o código móvel é realocado para locais aleatórios. Lidar com todas as proteções corretamente requer alguma contabilidade, mas nada complexo.

[067]Quanto ao comportamento em tempo de execução, as técnicas também são compostas. Múltiplas técnicas requerem inicializadores e finalizadores, mas no processo depurador, não desejamos executar os inicializadores das demais proteções, pois esse processo depurante deve ser apenas um depurador, e não outro cliente para mobilidade de código ou qualquer outra técnica. Para evitar que os outros inicializadores sejam executados, os inicializadores do autodepurador recebem a prioridade mais alta. Eles são executados primeiramente quando um binário ou biblioteca é carregado, e a rotina de inicialização do depurador implementa de fato tanto o inicializador real, quanto o ciclo de depuração. A rotina, portanto, nunca termina (ou seja, desde que o finalizador não seja invocado) e, portanto, o controle nunca é transferido para os outros inicializadores que possam estar presentes no binário.

AVALIAÇÃO

Plataforma de Avaliação [068]Uma implementação do autodepurador visa as plataformas ARMv7. Concretamente, essa implementação teve como alvo e avaliou extensivamente a implementação no Linux 3.15 e Android (não enraizado) 4.3+4.4. Confirmou-se ainda que as técnicas também funcionam nas versões mais recentes do Linux (4.7) e Android (7.0), e que é realmente o caso.

[069]O hardware de teste consistiu em placas de vários desenvolvedores.

Petição 870190051970, de 03/06/2019, pág. 30/44

20/25

Para o Linux, uma Panda Board foi usada com um processador OMAP4 Texas Instruments de núcleo único, uma Arndale Board com um processador Samsung Exynos de núcleo duplo, e uma placa Lite Nitrogen6X/SABRE da Boundary Devices com um processador Freescale i.MX6q de núcleo único. A última placa também foi usada para as versões Android.

[070]Na cadeia de ferramentas, foram utilizados GCC 4.8, LLVM 3.4 e GNU binutils 2.23. O código foi compilado com os seguintes sinalizadores: - Os march=armv7-a -marm -mfloat-abi=softfp -mfpu=neon -msoft-float.

Casos de uso [071 ]O esquema de autodepuração demonstrou funcionar em vários casos de uso. Por exemplo, em um cenário de gerenciamento de direitos digitais, as seguintes considerações práticas foram encontradas.

[072]Este caso de uso consistiu em dois plug-ins, escritos em C e C ++, para a estrutura de mídia do Android e a estrutura de DRM do Android. Essas bibliotecas são necessárias para obter acesso a filmes criptografados e descriptografá-los. Um aplicativo de vídeo programado em Java é usado como GUI para acessar os vídeos. Esse aplicativo se comunica com as estruturas de mediaserver e DRM do Android, informando as estruturas do fornecedor de quais plug-ins ele precisa. Sob demanda, essas estruturas carregam os plug-ins. Concretamente, esses servidores são os processos de mediaserver e drmserver executados no Android.

[073]Durante os experimentos e desenvolvimento, foram observadas diversas características que tornam este caso de uso um perfeito teste de resistência para essa técnica. Primeiramente, o mediaserver é multiencadeado, e cria e elimina novas cadeia o tempo todo. Em segundo lugar, as bibliotecas de plug-ins são carregadas e descarregadas com frequência. Às vezes, o descarregamento é iniciado antes mesmo da inicialização da biblioteca ser concluída. Em terceiro lugar, assim que o processo falha, uma nova instância é inicializada. Às vezes, isso permite que o reprodutor de

Petição 870190051970, de 03/06/2019, pág. 31/44

21/25 video Java continue a funcionar ininterruptamente, às vezes, isso não acontece. Isso torna a depuração da implementação da nossa técnica ainda mais complexa do que já é para aplicações simples. Em quarto lugar, o mediaserver e o drmserver estão envolvidos em frequentes comunicações entre processos. No entanto, a implementação efetiva foi alcançada com base nos princípios descritos acima.

[074]As técnicas podem ser aplicadas em muitos outros cenários de casos de uso. Por exemplo, no mobile banking ou em qualquer outro cenário em que a segurança seja desejável. A Figura 4 ilustra um diagrama de blocos de uma implementação de um dispositivo de computação 400 dentro do qual um conjunto de instruções, para fazer com que o dispositivo de computação execute qualquer uma das mais das metodologias discutidas aqui, pode ser executado. Em implementações alternativas, o dispositivo de computação pode ser conectado (por exemplo, em rede) a outras máquinas em uma Rede de Área Local (LAN), uma intranet, uma extranet ou a Internet. O dispositivo de computação pode operar na capacidade de um servidor ou uma máquina cliente em um ambiente de rede cliente-servidor, ou como uma máquina de mesmo nível em um ambiente de rede ponto a ponto (ou distribuído). O dispositivo de computação pode ser um computador pessoal (PC), um tablet, uma settop box (STB), um Assistente Pessoal Digital (PDA), um telefone celular, um dispositivo da Web, um servidor, um roteador de rede, comutador ou ponte, ou qualquer máquina capaz de executar um conjunto de instruções (sequenciais ou não) que especifiquem as ações a serem tomadas por aquela máquina. Além disso, embora apenas um único dispositivo de computação seja ilustrado, o termo “dispositivo de computação” deve também incluir qualquer coleção de máquinas (por exemplo, computadores) que individualmente ou conjuntamente executem um conjunto (ou múltiplos conjuntos) de instruções para realizar qualquer uma ou mais das metodologias discutidas aqui.

[075]O dispositivo de computação exemplificativo 400 inclui um dispositivo de

Petição 870190051970, de 03/06/2019, pág. 32/44

22/25 processamento 402, uma memória principal 404 (por exemplo, memória somente de leitura (ROM), memória flash, memória de acesso aleatório dinâmica (DRAM), tal como DRAM sincrona (SDRAM) ou DRAM Rambus (RDRAM) etc.), uma memória estática 406 (por exemplo, memória flash, memória estática de acesso aleatório (SRAM) etc.) e uma memória secundária (por exemplo, um dispositivo de armazenamento de dados 418), que se comunicam entre si através de um barramento 430.

[076]O dispositivo de processamento 402 representa um ou mais processadores de propósito geral, tal como um microprocessador, unidade de processamento central, ou semelhantes. Mais particularmente, o dispositivo de processamento 402 pode ser um microprocessador de computação de conjunto de instruções complexo (CISC), microprocessador de computação de conjunto de instruções reduzido (RISC), microprocessador de palavra de instrução muito longa VLIW, processador implementando outros conjuntos de instruções, ou processadores implementando uma combinação de conjuntos de instruções. O dispositivo de processamento 402 pode também ser um ou mais dispositivos de processamento de propósito especial, tal como um circuito integrado de aplicação específica (ASIC), uma matriz de portas programáveis em campo (FPGA), um processador de sinal digital (DSP), processador de rede ou semelhantes. O dispositivo de processamento 402 é configurado para executar a lógica de processamento (instruções 422) para realizar as etapas de trabalho discutidas aqui.

[077]O dispositivo de computação 400 pode ainda incluir um dispositivo de interface de rede 408. O dispositivo de computação 400 também pode incluir uma unidade de exibição de vídeo 410 (por exemplo, um visor de cristal líquido (LCD) ou um tubo de raios catódicos (CRT)), um dispositivo de entrada alfanumérico 412 (por exemplo, um teclado ou tela sensível ao toque), um dispositivo de controle de cursor 414 (por exemplo, um mouse ou tela sensível ao toque), e um dispositivo de áudio

Petição 870190051970, de 03/06/2019, pág. 33/44

23/25

416 (por exemplo, um alto-falante).

[078]O dispositivo de armazenamento de dados 418 pode incluir um ou mais meios de armazenamento legíveis por máquina (ou, mais especificamente, um ou mais meios de armazenamento legíveis por computador não transitórios) 428 nos quais são armazenados um ou mais conjuntos de instruções 422 que incorporam qualquer uma ou mais das metodologias ou funções descritas aqui. As instruções 422 também podem residir, completamente ou pelo menos parcialmente, dentro da memória principal 404 e/ou dentro do dispositivo de processamento 402 durante a execução do mesmo pelo sistema de computador 400, na memória principal 404 e o dispositivo de processamento 402 também constituindo o meio de armazenamento legível por computador.

[079]Os vários métodos descritos acima podem ser implementados por um programa de computador. O programa de computador pode incluir código de computador organizado para instruir um computador a executar as funções de um ou mais dos vários métodos descritos acima. O programa de computador e/ou o código para execução de tais métodos podem ser fornecidos a um aparelho, tal como um computador, em um ou mais meios legíveis por computador ou, de forma mais geral, um produto de programa de computador. O meio legível por computador pode ser transitório ou não transitório. Um ou mais meios legíveis por computador poderíam ser, por exemplo, um sistema eletrônico, magnético, óptico, eletromagnético, infravermelho ou semicondutor, ou um meio de propagação para transmissão de dados, por exemplo, para baixar o código pela Internet. Alternativamente, os um ou mais meios legíveis por computador poderíam assumir a forma de um ou mais meios legíveis por computador físicos, tais como memória de estado sólido ou semicondutor, fita magnética, um disquete de computador removível, uma memória de acesso aleatório (RAM), uma memória somente de leitura (ROM), um disco magnético rígido, e um disco óptico, tal como um CD-ROM, CD-R/W ou DVD.

Petição 870190051970, de 03/06/2019, pág. 34/44

24/25 [080]Em uma implementação, os módulos, componentes e outros recursos aqui descritos (por exemplo, unidade de controle 410 em relação à Figura 4) podem ser implementados como componentes discretos ou integrados na funcionalidade de componentes de hardware, tais como ASICS, FPGAs, DSPs ou dispositivos similares como parte de um servidor de individualização.

[081 ]Um “componente de hardware” é um componente físico tangível (por exemplo, não transitório) (por exemplo, um conjunto de um ou mais processadores) capaz de executar determinadas operações e pode ser configurado ou disposto de determinada maneira física. Um componente de hardware pode incluir lógica ou circuitos dedicados que são permanentemente configurados para executar determinadas operações. Um componente de hardware pode ser ou pode incluir um processador de propósito especial, tal como uma FPGA (matriz de portas programáveis em campo) ou um ASIC. Um componente de hardware também pode incluir circuito ou lógica programável que é temporariamente configurado por software para executar determinadas operações.

[082]Assim, a expressão “componente de hardware” deve ser entendida como abrangendo uma entidade tangível que pode ser fisicamente construída, permanentemente configurada (por exemplo, com fio) ou temporariamente configurada (por exemplo, programada) para operar de determinada maneira ou para executar determinadas operações descritas aqui.

[083]Além disso, os módulos e componentes podem ser implementados como firmware ou circuitos funcionais dentro de dispositivos de hardware. Além disso, os módulos e componentes podem ser implementados em qualquer combinação de dispositivos de hardware e componentes de software, ou somente software (por exemplo, código armazenado ou de outra forma incorporado em um meio legível por máquina ou em um meio de transmissão).

[084]Salvo especificamente indicado de outra forma, como é evidente na

Petição 870190051970, de 03/06/2019, pág. 35/44

25/25 discussão a seguir, é apreciado que, ao longo da descrição, discussões utilizando termos como “receber”, “determinar”, “comparar”, “habilitar”, “manter”, “identificar” “substituir” ou semelhantes referem-se às ações e processos de um sistema de computador, ou dispositivo de computação eletrônica semelhante, que manipula e transforma dados representados como quantidades físicas (eletrônicas) nos registros do sistema de computador e memórias em outros dados similarmente representados como quantidades físicas dentro dos registros ou memórias do sistema de computador, ou outros dispositivos de armazenamento, transmissão ou exibição de informações.

[085]Entende-se que a descrição acima pretende ser ilustrativa, e não restritiva. Muitas outras implementações serão evidentes para os versados na técnica quando da leitura e compreensão da descrição acima. Embora a presente invenção tenha sido descrita com referência a exemplos específicos de implementações, será reconhecido que a invenção não é limitada às implementações descritas, mas pode ser praticada com modificação e alteração dentro do espírito e escopo das reivindicações anexas. Por conseguinte, a especificação e os desenhos devem ser considerados em um sentido ilustrativo, em vez de um sentido restritivo. O escopo da invenção deve, portanto, ser determinado com referência às reivindicações anexas, juntamente com o escopo completo de equivalentes a que tais reivindicações têm direito.

Claims (15)

1. Método para proteção de software, CARACTERIZADO pelo fato de que compreende:

inicializar um processo de software;

associar um processo depurador ao processo de software;

executar o processo de software de forma que o processo depurador seja invocado pelo menos uma vez;

executar uma ou mais funções dentro do processo depurador em resposta à invocação do processo depurador, as uma ou mais funções tendo uma saída dependente de dados associados com o processo de software.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que a saída compreende uma saída de dados para uso pelo processo de software.

3. Método, de acordo com a reivindicação 1 ou reivindicação 2, CARACTERIZADO pelo fato de que a saída de uma determinada função pode indicar múltiplos pontos de retorno dentro do processo de software para execução contínua.

4. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que o processo depurador provê recursos de suporte de memória para permitir que as uma ou mais funções recuperem dados da memória dentro do espaço de endereço do processo de software.

5. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que o processo depurador é invocado quando um ponto de interrupção dentro do processo de software é alcançado.

6. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que ainda compreende desassociar o processo depurador do processo de software quando o processo de software está completo.

7. Método, de acordo com qualquer uma das reivindicações anteriores, CARACTERIZADO pelo fato de que o processo de software implementa um

Petição 870190051970, de 03/06/2019, pág. 37/44

2/3 executável, tal como um aplicativo.

8. Método, de acordo com qualquer uma das reivindicações 1 a 6, CARACTERIZADO pelo fato de que o processo de software implementa uma biblioteca.

9. Produto de programa executável por computador, CARACTERIZADO pelo fato de que compreende código executável por computador para realizar o método de acordo com qualquer uma das reivindicações anteriores.

10. Dispositivo, CARACTERIZADO pelo fato de que é configurado para realizar o método de acordo com qualquer uma das reivindicações 1 a 8.

11. Método de geração de código protegido, CARACTERIZADO pelo fato de que compreende:

identificar fragmentos de código dentro de código de objeto a serem migrados para um depurador;

gerar código binário que, no tempo de execução, faz com que um processo depurador se associe a um processo de software, os fragmentos de código identificados sendo executados dentro do processo depurador.

12. Método, de acordo com a reivindicação 11, CARACTERIZADO pelo fato de que a etapa de geração compreende incorporar código predefinido correspondente à funcionalidade de depurador genérica dentro do código binário.

13. Método, de acordo com a reivindicação 11 ou reivindicação 12, CARACTERIZADO pelo fato de que o código binário compreende um primeiro arquivo de código binário correspondente ao código fonte, mas excluindo os fragmentos de código identificados e um segundo arquivo de código binário correspondente ao depurador.

14. Produto de programa executável por computador, CARACTERIZADO pelo fato de que compreende código executável por computador para realizar o método de acordo com qualquer uma das reivindicações 11 a 13.

Petição 870190051970, de 03/06/2019, pág. 38/44

3/3

15. Dispositivo, CARACTERIZADO pelo fato de que é configurado para realizar o método de acordo com qualquer uma das reivindicações 11 a 13.