Dominando o Endurecimento de Aplicações: Uma Análise Detalhada da Ofuscação

Ofuscações e você

Segurança do aplicativo já é um conhecimento conhecido. Todos sabem que precisam disso, e os atacantes sabem como burlar as proteções básicas; lançar um aplicativo desprotegido simplesmente não é uma opção. Todas as proteções robustas têm duas partes: prevenção por análise estática e detecção dinâmica de ataques. A análise estática é uma ferramenta poderosa que oferece aos atacantes uma visão única dos detalhes de implementação específicos do aplicativo. Ela expõe as partes mais vulneráveis ​​de um aplicativo, ajudando a acelerar um ataque ou a roubar propriedade intelectual valiosa da empresa. O código-fonte, assim como os dados, ofuscação é uma parte importante de qualquer proteção contra análise estática. Aqui estão algumas maneiras pelas quais o código e os dados podem ser transformados para dificultar a ação de agentes maliciosos. Quanto mais trabalho eles tiverem que fazer, mais difícil será para eles se protegerem. safer nosso mundo pode ser.

Privatize sua proteção

Embora os aplicativos não devam ser distribuídos sem alguma forma de ofuscação, nem todas as ofuscações são iguais. Dois componentes cruciais para qualquer ofuscação robusta são IP privado e aleatoriedade. Os ofuscadores de código aberto atualmente disponíveis podem ser tão úteis para atacantes quanto para desenvolvedores de aplicativos. O nível de proteção fornecido por esses ofuscadores de código aberto não é suficiente para proteger com segurança aplicativos de nível empresarial. Ofuscações eficazes precisam transformar o código-fonte em algo ilegível para humanos e irreversível para ferramentas de ataque automatizadas. Técnicas de ofuscação publicamente disponíveis funcionam como uma espécie de Pedra de Roseta para derrotá-las. O uso de técnicas de ofuscação personalizadas e não publicamente acessíveis impede que Timmy Turner reverta a ofuscação de um aplicativo usando suas Fadas de IA Generativa. Combine esses algoritmos privados com aleatoriedade inerente para garantir que nenhum ser humano, ou LLM (Limited Liability Machinery), consiga desvendar a ofuscação.

PRNG contra-ataca

Os atacantes podem obter muitas informações comparando diferentes versões do mesmo aplicativo. Ter ofuscação alterada entre as versões do aplicativo é absolutamente necessário. A maioria dos mecanismos de pseudoaleatoriedade usa uma semente para forçar a previsibilidade, mantendo a aleatoriedade inerente, e com a ofuscação não é diferente. Simplesmente incrementar ou decrementar um valor de semente impactará drasticamente a ofuscação aplicada a um aplicativo de entrada. Isso proporciona reprodutibilidade quando necessário, mas força os atacantes a recomeçarem do zero ao fazer engenharia reversa de um aplicativo após o lançamento de uma nova versão. É como se o atacante limpasse metade da entrada da garagem, fizesse uma pausa para tomar um chocolate quente e voltasse para encontrar neve fresca. Uma segurança robusta se concentra em evitar o desperdício de tempo. engenharia reversa Tempo, e um cenário em constante mudança, é uma das melhores maneiras de desperdiçar o tempo deles.

Ofuscação Ofuscando Ofuscações

Conceitualmente, a ofuscação é o oposto da otimização. Assim como os compiladores geralmente têm várias etapas de otimização, nós temos várias etapas de ofuscação. Isso significa que aplicamos ofuscação às ofuscações que acabaram de ser adicionadas. O resultado é extremamente difícil de ler.

Instruções simples como `add` ou `mov` podem rapidamente se transformar em cinquenta ou centenas de instruções. A ofuscação adequada de pares `adrp add` pode dizimar a capacidade de uma ferramenta automatizada (como o Ghidra ou o IDA) de resolver o fluxo de controle do programa. Ofuscações aparentemente pequenas podem tornar quase impossível para um atacante encontrar o início, o fim ou o meio da chamada da função `acceptUserCredentials`. Centenas de ofuscações compostas e variadas deixam os potenciais atacantes tentando descobrir como o código sequer é executado com sucesso.

Balance, gire, configure

Nem todas as chamadas de método ou função são sensíveis em uma aplicação, e algumas chamadas de método ou função podem ser extremamente críticas para o desempenho. Embora aplicar ofuscação uniformemente em toda a aplicação ainda seja significativamente melhor do que nada, essa estratégia pode ter um impacto considerável no desempenho em tempo de execução. Dar aos engenheiros de segurança a capacidade de ofuscar fortemente as chamadas sensíveis, enquanto ofuscam levemente as chamadas que exigem alto desempenho, faz parte do fornecimento de uma ferramenta de proteção de classe mundial. Quaisquer proteções dinâmicas (Guards) injetadas na aplicação exigem tanta ofuscação quanto o código-fonte subjacente. Aplicar as mesmas técnicas de ofuscação de alta segurança a esses guards ativos ajuda a mantê-los protegidos e em execução, além de dificultar os esforços dos invasores para identificá-los e removê-los. A configurabilidade é crucial para qualquer organização focada em segurança, e as ferramentas de proteção precisam mudar tão rapidamente quanto a direção da empresa. Como mencionado anteriormente, algumas ofuscações são construídas de forma diferente. Aqui estão alguns conceitos que qualquer mecanismo de ofuscação sério oferece e como ele pode impedir o tráfego aéreo não autorizado.

Fluxo de Controle Computado

Os atacantes podem obter bastante informação sobre uma aplicação apenas observando o fluxo de chamadas de função ao longo da aplicação. Para combater isso, nossas técnicas de ofuscação utilizam algo chamado Fluxo de Controle Computado. O Fluxo de Controle Computado impede que os descompiladores conectem chamadas de função e referências a rótulos ao ponto de entrada principal da aplicação. É uma parte crucial de qualquer proteção de alto nível. Quando um descompilador analisa um binário, ver como uma função chama outra geralmente é trivial. Considere, por exemplo, instruções como: `b.eq 0x10055bc42` e `bl 0x100abcdef`. Um descompilador sabe exatamente o que reside nesses endereços de memória virtual. No caso das duas instruções anteriores, trata-se de rótulos dentro de uma função ou da própria chamada de função. Qualquer descompilador competente irá gerar uma teia complexa de chamadas de função interligadas, mostrando um caminho de execução claro por toda a aplicação. Combine isso com outros truques básicos, como verificar onde no código assembly uma mensagem de "login bem-sucedido" é usada, e torna-se trivial para um atacante identificar código explorável. O Fluxo de Controle Computado é um conjunto de operações matemáticas injetadas antes de chamadas óbvias de fluxo de controle. Essas operações matemáticas impedem que um descompilador saiba o Endereço Virtual Relativo exato para o qual o salto está sendo feito, destruindo sua capacidade de gerar um gráfico de fluxo de controle.

Achatamento do fluxo de controle

O Fluxo de Controle Computado (CFF) já é um pesadelo para os descompiladores; seria uma pena se o piorássemos. Outra estratégia para sabotar o fluxo de controle lógico é o Achatamento do Fluxo de Controle (CFF). Existem várias formas de CFF, mas uma adicionada recentemente (chamada Nexus) revitaliza essa técnica crucial de ofuscação. Todos nós já escrevemos um jogo de xadrez na função `main`, mas e se estivéssemos escrevendo um aplicativo completo de nível de produção em uma única instrução `switch` autorreferencial? O Nexus faz exatamente isso, priorizando o desempenho em tempo de execução. Há uma infinidade de informações disponíveis sobre CFF, sua importância e como funciona. É impossível subestimar o quão difícil essa técnica de ofuscação torna a vida dos atacantes, e nenhum aplicativo deve sair do ambiente de testes sem ela.

C hopup

Nenhum conjunto de facas de aço inoxidável estaria completo sem uma tesoura de aço inoxidável correspondente, e o Chopup complementa a ofuscação do fluxo de controle de maneira muito semelhante. Os formatos de arquivo binário geralmente são compactados para economizar espaço em disco. Isso significa que a maioria das chamadas de função relacionadas ficam bem próximas umas das outras. Como resultado, um binário desmontado tende a agrupar funções relacionadas e quase sempre as apresenta como um bloco contíguo. Isso é muito fácil de ler e nos irrita bastante. O Chopup muda isso. Não há restrição técnica em um binário que exija que as chamadas de função sejam contíguas na memória, e uma boa tesoura (com um pouco de cola flexível) pode deixar um binário funcionando como esperado, mas forçar os atacantes a vasculharem cada canto do binário em busca de fluxo de controle lógico.

mgDaea e Reparo

Embora ofuscar o fluxo de código em si seja uma camada crucial de proteção, ofuscar os dados subjacentes da aplicação é igualmente necessário. Danificar e reparar são o Caótico Maligno e o Legal Benigno das proteções contra análise estática, e quase sempre andam de mãos dadas. Danificar um dado, ou mesmo, em alguns casos, um trecho de código, e repará-lo imediatamente antes de ser lido ou executado torna a análise estática praticamente impossível. Danificar transforma os dados especificados em algo que parece ser memória inválida. Quando esses mesmos dados são expostos a uma chamada de reparo, eles são revertidos à sua forma original, muitas vezes pouco antes de serem usados. Esses dados podem então ser danificados novamente após saírem do escopo e não serão usados ​​até a próxima chamada da função. A chave da API pode ser inicialmente “1#&at0d$*nd@@z” no binário, mas fique tranquilo, ela será corrigida antes de ser usada.

Renomeação de Símbolos

Mesmo com ofuscação de código-fonte e de dados, ainda restam nomes de símbolos no código-fonte compilado. Por exemplo, um símbolo para uma função como "acceptContinuousPayment" pode facilmente fornecer um link direto para a implementação dessa função. Uma vez encontrado, é trivial alterar o código assembly e acessar recursos premium sem pagar. A renomeação completa de símbolos oculta os artefatos restantes e não deixa nada para os atacantes explorarem. Remover quaisquer dicas ou pistas sobre funcionalidades sensíveis em um binário protegido pode forçar os atacantes a desistirem completamente da análise estática.

O Fim

Esses são apenas exemplos de como práticas e metodologias robustas de ofuscação se apresentam, e a lista não é exaustiva. Deixar um aplicativo desprotegido em produção concede a qualquer pessoa visibilidade completa do IP exclusivo e oferece a qualquer atacante acesso irrestrito à lógica de negócios. Com a ascensão meteórica da IA ​​generativa e dos copilotos de código-fonte, tornou-se infinitamente mais fácil para as pessoas escreverem código e, para algumas, até mesmo fazerem engenharia reversa. Um compromisso de toda a organização com a implementação de soluções de segurança robustas é o único caminho viável em um ambiente tão dinâmico. Não deixe que o trabalho árduo de seus desenvolvedores seja perdido sem essa proteção.

 

Leia a opinião da IDC sobre a importância de ofuscação e anti-adulteração como parte do seu DevSecOps prática.