Obfusk8: Biblioteca de Ofuscação Baseada em C++17

Obfusk8 é uma biblioteca leve, somente de cabeçalho, em C++17, projetada para aprimorar significativamente a ofuscação de suas aplicações, tornando a engenharia reversa um desafio substancialmente maior. Ela alcança isso por meio de um conjunto diversificado de técnicas em tempo de compilação e execução, com o objetivo de proteger a lógica e os dados do seu código.

---

Índice

1. Principais Estratégias de Ofuscação
2. Dependências
3. Visualização
4. Perfil de Análise e Detecção do Mecanismo
5. Características Estruturais e Forenses
6. Uso
7. Compilação
8. Demonstração
9. Contribuição e Feedback

---

Principais Estratégias de Ofuscação

1. Encapsulamento da Função main (Macro _main)

O ponto de entrada da sua aplicação (main) é transformado em um mecanismo de ofuscação complexo e multicamadas:

• Execução em Máquina Virtual (VM) (Conceitual): Antes que o código real do main_body seja executado, uma mini-VM (CPU simulada) executa uma sequência de instruções "criptografadas". Isso oculta o verdadeiro ponto de entrada e as operações iniciais. O estado da VM (registradores, contador de programa, chave de despacho) é inicializado com valores aleatórios em tempo de execução.
• Achatamento de Fluxo de Controle Indireto (ICFF): Os loops críticos dentro da macro _main (tanto no prólogo quanto no epílogo) são transformados em máquinas de estado intricadas. O fluxo de controle não é direto, mas determinado por variáveis de estado fortemente "criptografadas". As chaves de codificação/decodificação dessas variáveis de estado são dinâmicas, derivadas do estado da VM, contadores de loop, aleatoriedade em tempo de compilação (como __COUNTER__, __LINE__, __TIME__) e uma semente opaca global. Isso torna a análise estática do fluxo de controle excepcionalmente difícil.
  • Dois mecanismos ICFF distintos (obf_icff_ns_dcff e obf_icff_ns_epd) são usados com lógica de transição de estado e geração de chaves diferentes, complicando ainda mais a análise.
• Fluxo de Controle Falso (macros OBF_BOGUS_FLOW_*): Numerosos padrões de salto enganosos e estruturas condicionais convolutas são injetados ao longo de _main. Eles usam declarações goto combinadas com predicados opacos (condições que sempre avaliam para verdadeiro ou falso, mas são computacionalmente caras ou difíceis de determinar estaticamente). Isso cria um labirinto de caminhos falsos para desmontadores e decompiladores.
  • Inclui OBF_BOGUS_FLOW_LABYRINTH, OBF_BOGUS_FLOW_GRID, OBF_BOGUS_FLOW_SCRAMBLE, OBF_BOGUS_FLOW_WEAVER, OBF_BOGUS_FLOW_CASCADE e OBF_BOGUS_FLOW_CYCLONE para gerar fluxos falsos diversos e complexos.
• Truques Anti-Análise e Anti-Debug (macro Runtime, SEH):
  • Exceções Forçadas e SEH: O Tratamento Estruturado de Exceções (SEH) é usado para criar caminhos que envolvem exceções forçadas. Os blocos __except podem alterar o estado do programa, dificultando o acompanhamento se o depurador ignorar exceções.
  • Verificações de Depurador (Conceitual): A macro Runtime contém condições que, se atendidas (devido a estados específicos da VM ou temporização), podem acionar __debugbreak() ou lançar exceções, projetadas para atrapalhar sessões de depuração.

2. Mecanismo de ISA Virtual (obf_vm_engine)

Um componente central da ofuscação da macro _main:

• Simulação de Mini-CPU Personalizada: Simula uma CPU com registradores voláteis (r0, r1, r2), um contador de programa (pc) e uma dispatch_key. Ela executa "instruções" personalizadas (handlers).
• Instruções Ofuscadas: Os handlers de instrução da VM executam operações fortemente disfarçadas usando Aritmética Booleana Mista (MBA) e manipulações bit a bit. Os handlers incluem aritmética, lógica bit a bit, mutilação de chaves, sequências de lixo, atualizações condicionais, simulação de memória e mutilação de PC.
• Despacho Dinâmico: A seleção do próximo handler de instrução da VM é randomizada por meio de múltiplos mecanismos de despacho:
  • Despacho baseado em registrador (reg_dispatch_idx).
  • Despacho baseado em tabela de memória (tabela de ponteiros de função embaralhada get_mem_dispatch_table).
  • Despacho misto (mixed_dispatch_idx). A dispatch_key é constantemente mutada, tornando a sequência de handlers executados altamente imprevisível.
• Mutação da Tabela de Handlers: A tabela de handlers de instrução da VM (vm_handler_table) é ela própria mutada em tempo de execução dentro do prólogo e epílogo de _main, obscurecendo ainda mais o comportamento da VM.

3. Criptografia de Strings em Tempo de Compilação (OBFUSCATE_STRING de AES8.hpp)

• Strings Ocultas: Criptografa todos os literais de string em tempo de compilação usando uma cifra AES modificada.
• Chaves Dinâmicas: As chaves de criptografia são únicas por instância de string, derivadas do conteúdo da string, localização do arquivo (__FILE__, __LINE__) e tempo de compilação (__DATE__, __TIME__).
• Descriptografia Just-In-Time: As strings são descriptografadas na pilha somente quando acessadas em tempo de execução, minimizando seu tempo de vida em texto puro na memória.
• (Opcional) Seções PE Iscas: Pode armazenar strings criptografadas em seções PE personalizadas projetadas para imitar assinaturas comuns de empacotadores, potencialmente enganando analistas (recurso específico do MSVC em AES8.hpp).

4. Chamadas Stealthy a APIs do Windows (STEALTH_API_OBFSTR / STEALTH_API_OBF de Resolve8.hpp)

• Ofuscação da IAT: Evita deixar entradas diretas e facilmente identificáveis para APIs do Windows na Tabela de Endereços de Importação (IAT).
• Resolução Baseada no PEB: Encontra dinamicamente os endereços base das DLLs carregadas e os endereços das funções de API analisando diretamente as estruturas de dados do Bloco de Parâmetros do Processo (PEB) em tempo de execução. Isso contorna as funções padrão GetModuleHandle e GetProcAddress para a resolução inicial se elas próprias ainda não tiverem sido resolvidas por esse mecanismo.
• Nomes com Hash: Usa hash em tempo de compilação (algoritmo personalizado CT_HASH) de nomes de DLLs e APIs para buscas. Isso impede que nomes de DLLs e APIs em texto puro apareçam nos dados relacionados a importações ou nas tabelas de strings do binário ao usar essas macros.

5. Mecanismo de Syscall Indireto (K8_SYSCALL)

Obfusk8 agora integra um mecanismo de Syscall Indireto de última geração para contornar Hooks em Modo de Usuário (EDRs/AVs) e verificações de análise estática.

• Resolução "The Sorting Hat": Em vez de ler a seção .text da ntdll.dll (que geralmente é hookada ou monitorada), o mecanismo analisa o Diretório de Exportação. Ele filtra funções que começam com Zw, ordena-as por endereço de memória e deduz o Número de Chamada do Sistema (SSN) com base em seu índice. Isso permite a resolução do SSN sem nunca tocar em código executável.
• Execução de Gadget Lateral: O mecanismo não contém a instrução syscall (0F 05) em seu próprio binário. Em vez disso, ele localiza um gadget syscall; ret válido dentro da memória da ntdll.dll em tempo de execução. Pilhas de Chamada Limpas: Um thunk personalizado é alocado e salta para o gadget da ntdll. Para o kernel do SO e os sensores de segurança, a chamada de sistema parece se originar legitimamente da ntdll.dll, mantendo uma pilha de chamada limpa.
• Uso: Simplesmente use K8_SYSCALL("ZwOpenProcess", ...) em vez de NtOpenProcess.