Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6

Resumo Técnico: Identidores Envenenados Sobrevivem à Deobfuscacão por LLMs

1. O Problema

O estudo investiga um fenômeno específico na interação entre Modelos de Linguagem (LLMs) e código ofuscado: a persistência de identificadores "envenenados" (poisoned identifiers) durante o processo de deobfuscacão.

• Cenário: Quando um código JavaScript é ofuscado (com controle de fluxo achatado e strings codificadas), o LLM tenta reconstruir o código legível. No entanto, a tabela de strings decodificada pode conter nomes de variáveis intencionalmente incorretos (ex: chamar uma força de repulsão de "atração" ou "combustão").
• Hipótese Central: Mesmo quando o modelo demonstra compreender a semântica correta do código (através de comentários ou lógica matemática), ele tende a preservar os nomes de variáveis errados da tabela de strings decodificada no código gerado, falhando em corrigi-los mesmo sob instruções explícitas de verificação.
• Risco: Isso cria um padrão de "dual-representation" (dupla representação), onde o código contém erros lógicos nos nomes das variáveis, mas os comentários descrevem corretamente a operação, enganando ferramentas de análise automatizada ou desenvolvedores que confiam na deobfuscacão do LLM.

2. Metodologia

O estudo foi conduzido como um case study focado no modelo Claude Opus 4.6 (com testes limitados no Haiku 4.5), utilizando dois arquétipos de código:

1. Simulação de Gráfico Direcionado por Força (Física): O artefato principal.
2. Algoritmo A de Roteamento (Pathfinding):* Para replicação e validação.

Fases do Experimento:

• Fase A (Exploratória, N=1): Uso do Claude Code CLI com ferramentas (leitura/escrita de arquivos). Observações qualitativas para gerar hipóteses.
• Fase B (Sistemática, N=3–6 por condição): Uso da API Anthropic Messages (sem ferramentas). 192 execuções automatizadas em 50 condições diferentes.

Variáveis Manipuladas:

• Tipos de "Pílulas" (Stimuli):
  • Envenenamento Semântico: Nomes de variáveis trocados por termos plausíveis no domínio (ex: física) mas semanticamente errados.
  • Controles de "Zero Fit": Nomes sem nenhuma relação semântica (ex: "combustão" para "repulsão") para testar se a coerência do domínio é o fator chave.
  • Conteúdo Malicioso: Funções reais de malware para testar limites de recusa (refusal).
• Prompts (Instruções):
  • Base: "Deobfuscate this".
  • Verificação Explícita: "Verifique se cada nome corresponde à matemática".
  • Reenquadramento (Framing): "Escreva uma nova implementação do zero" (Geração) vs. "Deobfuscate" (Tradução).

Métricas:

• Endpoint Primário: Preservação do identificador envenenado nos blocos de código gerados.
• Endpoint Secundário: Padrão de "dual-representation" (nome errado no código + descrição correta no comentário).
• Verificação de Consistência Algorítmica: Garantia de que a lógica do código gerado permanecia funcionalmente correta.

3. Principais Contribuições e Descobertas

A. Falha das Instruções Explícitas
Instruções diretas para verificar a semântica ou alertar sobre nomes adversariais falharam completamente. Em 12/12 execuções, o modelo propagou os nomes errados mesmo quando explicitamente instruído a corrigi-los. O modelo gastou mais tempo processando, mas o resultado final foi o mesmo.

B. O Efeito de Reenquadramento (Task Framing)
A descoberta mais crítica foi que a mudança de quadro de tarefa alterou drasticamente o comportamento:

• Ao mudar o prompt de "Deobfuscate this" (que ativa um fluxo de trabalho de tradução) para "Write a fresh implementation from scratch" (Geração), a propagação de nomes errados caiu drasticamente:
  • Artefato de Física: De 100% para 20% (e 0% para alguns termos).
  • Artefato de Pathfinding: De 100% para 0%.
• Isso sugere que o modelo trata a deobfuscacão como uma "tradução" onde preserva os tokens de origem (da tabela de strings), enquanto a geração "do zero" força o modelo a inferir nomes baseados na estrutura do algoritmo.

C. Persistência Independente da Semântica (Controles de Zero Fit)
Contrariando a intuição inicial de que apenas nomes "plausíveis" seriam preservados, o estudo mostrou que termos com zero ajuste semântico (ex: "fatura" para um cálculo de heurística) persistiram na mesma taxa que os plausíveis, desde que a tabela de strings não formasse um domínio coerente alternativo.

• Se todos os termos formavam um domínio coerente (ex: engenharia), o modelo corrigia.
• Se os termos eram incoerentes ou misturados, o modelo preservava os nomes originais, independentemente de fazerem sentido ou não.

D. Padrão de Dual-Representação
Em 15/17 execuções bem-sucedidas no artefato de física, o modelo produziu código com nomes de variáveis errados, mas comentários descrevendo a operação física correta. Isso demonstra que o modelo sabe o que o código faz, mas falha em alinhar a nomenclatura com esse conhecimento quando no modo de "tradução".

4. Resultados Quantitativos Chave

• Propagação na Deobfuscacão (Base): 100% (8/8 no físico, 5/5 no pathfinding).
• Propagação com Instruções de Verificação: 100% (12/12).
• Propagação com Reenquadramento (Geração): 0% a 20%.
• Controle de Domínio Incoerente (Zero Fit): 100% de persistência (os nomes errados foram mantidos).
• Controle de Domínio Coerente (Engenharia): 0% de persistência (corrigido).

5. Significado e Implicações

• Multiplicador de Custo, não Proteção: A técnica de envenenamento de identificadores não impede que um atacante entenda a arquitetura do código (o modelo ainda identifica a lógica corretamente). No entanto, ela degrada a recuperação semântica automática, forçando o usuário a gastar tempo e tokens extras para corrigir manualmente os nomes ou reescrever o código.
• Falha na "Alucinação" de Correção: O estudo refuta a ideia de que LLMs modernos corrigirão automaticamente erros óbvios de nomenclatura quando instruídos. O contexto da tarefa (tradução vs. geração) é mais determinante do que o conteúdo do prompt de verificação.
• Limitações de Segurança: Para workflows de análise de código assistidos por IA, confiar apenas na deobfuscacão direta é arriscado. A melhor prática sugerida é um pipeline de duas etapas: deobfuscacão seguida de uma etapa de "reimplementação do zero" para limpar identificadores.
• Mecanismo Subjacente: Os autores conjecturam que o modelo não avalia cada nome individualmente, mas sim a coerência do domínio da tabela de strings inteira. Se a tabela parece um domínio válido (mesmo que errado), o modelo a aceita. Se não há coerência, ele tende a preservar os tokens originais por padrão.

Conclusão:
O artigo demonstra que a persistência de identificadores envenenados é um comportamento robusto do Claude Opus 4.6 durante a deobfuscacão, resistente a instruções explícitas, mas sensível ao framing da tarefa. Isso revela uma vulnerabilidade específica em fluxos de trabalho de engenharia reversa assistida por IA, onde a precisão semântica pode ser comprometida sem que o modelo pareça "confuso" sobre a lógica subjacente.