Prompt to Pwn: Automated Exploit Generation for Smart Contracts

Título: Prompt to Pwn: Geração Automatizada de Explorações para Contratos Inteligentes

Autores: ZeKe Xiao, Qin Wang, Yuekang Li, Shiping Chen (UNSW Sydney & CSIRO Data61)

1. Problema e Motivação

Os contratos inteligentes são fundamentais para a finança digital, mas sua imutabilidade pós-implantação torna qualquer falha crítica e permanente. Embora existam ferramentas de detecção de vulnerabilidades (como Slither, Mythril) e pesquisas recentes sobre o uso de Grandes Modelos de Linguagem (LLMs) para detectar falhas, há uma lacuna significativa no entendimento da capacidade dos LLMs de gerar explorações automatizadas (AEG - Automated Exploit Generation) de ponta a ponta.

A detecção de vulnerabilidades e a geração de explorações são tarefas distintas: a primeira localiza o problema, enquanto a segunda deve sintetizar um artefato executável (Proof-of-Concept ou PoC) que valide a exploração sob execução real. Com o acesso fácil a LLMs via API, existe o risco de que atacantes iniciantes ("script kiddies") possam utilizá-los para lançar ataques reais, causando perdas financeiras massivas (ex: o ataque à carteira multi-assinatura da Bybit em 2025).

2. Metodologia: O Framework ReX

Os autores propõem o ReX, um framework de ponta a ponta que integra a síntese de explorações baseada em LLMs com a pilha de testes Foundry (uma ferramenta de desenvolvimento e teste em Rust para Ethereum). O objetivo é automatizar a geração, compilação, execução e validação de explorações.

Fluxo de Trabalho do ReX (5 Passos):

1. Pré-processamento: Limpeza do contrato vulnerável (remoção de comentários e ruído) para focar a lógica central.
2. Geração de Script: O LLM gera dois scripts em Foundry: um contrato de exploração (para ativar o caminho vulnerável) e um contrato de teste (para validar o sucesso). O modelo é instruído a raciocinar passo a passo.
3. Otimização Opcional: Correção automática de erros comuns (ex: endereços Ethereum sem checksum EIP-55, falta de casts payable).
4. Compilação e Teste: Os scripts são compilados e testados localmente usando forge build e forge test.
5. Loop de Feedback Iterativo: Se a compilação ou teste falhar, os erros são enviados de volta ao LLM para correção e regeneração, repetindo-se até encontrar uma exploração válida ou atingir o limite de tentativas.

Datasets Utilizados:

• SmartBugs-Curated: Um benchmark clássico para testes controlados (contratos simples).
• Web3-AEG: Um novo dataset curado com 38+ casos reais de incidentes de alto impacto (2021-2025), contendo código fonte verificado e PoCs escritos por auditores humanos. Este é o primeiro dataset focado em avaliação automatizada de explorações em cenários reais.

Modelos Avaliados:
Cinco LLMs de ponta foram testados: GPT-4.1, Gemini 2.5 Pro, Claude Opus 4, DeepSeek-R1 e Qwen3-Plus.

Critério de Sucesso:
Uma exploração é considerada bem-sucedida se o código gerado compilar no Foundry e violar deterministicamente uma invariância de segurança de nível de classe (ex: aumento não autorizado de saldo, falha de controle de acesso, violação de restrições aritméticas) em um ambiente controlado (sandbox).

3. Principais Contribuições

1. Primeiro Estudo Empírico Sistemático: Avaliação unificada da capacidade de AEG de LLMs para contratos inteligentes, cobrindo tanto benchmarks quanto dados do mundo real.
2. Framework ReX: Implementação de um pipeline automatizado que conecta LLMs ao Foundry para validação executável.
3. Dataset Web3-AEG: Criação e disponibilização pública de um conjunto de dados com explorações reais de contratos vulneráveis, permitindo a reprodução e avaliação de generalização.
4. Análise de Fatores de Desempenho: Investigação detalhada sobre o que impulsiona o sucesso ou falha na geração de explorações (capacidade do modelo vs. complexidade do código).
5. Estratégias de Defesa: Proposição de técnicas de "hardening" específicas para dificultar a análise baseada em LLM.

4. Resultados Chave

Desempenho dos Modelos

• Gemini 2.5 Pro obteve o melhor desempenho geral (67,3% de taxa de sucesso no benchmark), seguido por GPT-4.1 (58,1%) e Claude Opus 4 (63,3%). Modelos como DeepSeek-R1 e Qwen3-Plus tiveram desempenho inferior.
• Vulnerabilidades Simples vs. Complexas: Os LLMs têm alta eficácia em vulnerabilidades de contrato único com padrões fixos (ex: overflow aritmético, randomness previsível).
• Limitação em Ataques Cruzados: Os modelos falham consistentemente em cenários que exigem coordenação entre múltiplos contratos ou exploração de inconsistências de estado em protocolos DeFi complexos.
• Impacto do Loop de Feedback: A iteração (reparação automática de erros) aumentou drasticamente a taxa de sucesso (ex: de 27% para 58% no geral), indicando que os modelos frequentemente têm o plano lógico correto, mas falham em detalhes sintáticos ou semânticos.

Fatores que Influenciam o Sucesso (RQ2)

• Capacidade Intrínseca do Modelo: É o fator determinante. Contratos complexos não são necessariamente mais difíceis de explorar do que contratos simples se o padrão de vulnerabilidade for reconhecível.
• Tipo de Vulnerabilidade: Aritmética e DoS são mais fáceis; Front-running e controle de acesso complexo são mais difíceis.
• Engenharia de Prompt: Tem impacto limitado. Otimizações de prompt ajudam na estabilidade, mas não compensam a falta de compreensão semântica profunda do modelo.

Defesas (RQ3)

O estudo testou estratégias de defesa contra AEG:

• Divisão de Código (Externalização): Separar a lógica em múltiplos contratos força o LLM a raciocinar sobre interações cruzadas, onde ele é fraco.
• Complexidade Estrutural: O uso de herança profunda e interfaces abstratas confunde a análise semântica do LLM.
• Vulnerabilidades Isca (Decoys): Inserir padrões sintáticos que parecem vulneráveis, mas não são, aumenta a taxa de erro do LLM.
• Construções de Baixo Nível: O uso de inline assembly ou Yul reduz a capacidade do LLM de sintetizar explorações válidas.
• Resultado: Defesas individuais têm impacto limitado, mas uma combinação de técnicas reduziu a taxa de sucesso dos LLMs para cerca de 37-43%. No entanto, vulnerabilidades como Bad Randomness e Time Manipulation permaneceram suscetíveis mesmo com hardening.

5. Significado e Conclusão

O estudo revela que os LLMs de ponta já possuem capacidade suficiente para gerar explorações funcionais (PoCs) para uma subclasse significativa de vulnerabilidades de contratos inteligentes, especialmente aquelas localizadas em um único contrato. Isso representa uma ameaça real, pois democratiza o acesso a ataques automatizados.

No entanto, os LLMs ainda não alcançam o nível de especialistas humanos em ataques complexos de múltiplos contratos (DeFi). O sucesso da exploração depende mais da capacidade de raciocínio do modelo do que da complexidade do código alvo.

Implicações:

1. Defesa Assimétrica: As defesas devem focar em aumentar o custo de análise para LLMs (ex: quebrar padrões sintáticos, exigir raciocínio multi-contrato), em vez de apenas tentar corrigir bugs.
2. Avaliação Realista: A segurança de contratos não deve ser avaliada apenas por detectores estáticos, mas por pipelines de geração de explorações executáveis.
3. Limitações: O estudo assume acesso ao código fonte e não considera condições de rede real (MEV, dinâmicas de gás), focando na viabilidade técnica em ambiente controlado.

Em suma, o trabalho estabelece um novo padrão para avaliar a segurança de contratos inteligentes na era da IA, demonstrando que, embora os LLMs sejam ferramentas poderosas para atacantes, suas limitações atuais podem ser exploradas para criar defesas mais robustas.