Resumo Técnico: CrackMeBench

Declaração do Problema

Os benchmarks atuais para agentes de modelos de linguagem focam predominantemente na síntese de código-fonte (por exemplo, HumanEval, SWE-bench) ou no desempenho amplo em captura de bandeira (CTF) de cibersegurança (por exemplo, CyberSecEval, Cybench). No entanto, a engenharia reversa de binários permanece subespecificada no contexto de agentes autônomos. Especificamente, há uma falta de avaliação precisa sobre se um agente, dado apenas um executável compilado, consegue recuperar a lógica de validação e produzir uma entrada válida (senha, serial, artefato ou gerador de chaves) aceita por aquele programa.

A engenharia reversa de binários exige capacidades distintas em comparação com a codificação em nível de fonte: os agentes devem triar formatos de arquivo, raciocinar sobre código desprovido de símbolos ou com poucos símbolos, determinar a confiabilidade da saída de descompiladores, formular hipóteses dinamicamente e inverter transformações não projetadas para legibilidade. Diferentemente da reparação de código-fonte, os agentes não podem confiar em nomes semânticos ou testes de repositório; diferentemente de CTFs amplos, o objetivo pode ser estreitado para um problema de validação determinístico.

Metodologia: CrackMeBench

Os autores introduzem o CrackMeBench, um benchmark projetado para avaliar agentes de modelos de linguagem em tarefas de engenharia reversa no estilo educacional CrackMe. O framework é construído em torno de um modelo de avaliação de oráculo executável, onde o sucesso é definido pela aceitação de uma solução candidata pelo programa, e não pela plausibilidade de uma explicação textual.

Design do Benchmark e Inventário de Tarefas

O benchmark v0 consiste em 20 tarefas divididas em dois conjuntos:

1. Calibração Pública (8 tarefas): Binários higienizados de desafios educacionais CrackMe públicos (por exemplo, Enigma CrackMe, SirCrackaLot). Estes servem como verificações de validade externa, mas são tratados como dados de calibração devido à possível vazamento de soluções em relatos públicos.
2. Pontuação Principal Gerada (12 tarefas): Tarefas construídas a partir de templates semeados em C, Rust e Go. Estas são ainda divididas em:
   • Núcleo (6 tarefas): Focam na recuperação literal, codificações reversíveis, restrições aritméticas, geradores de chaves simples e anti-debugging benigno.
   • Difícil (6 tarefas): Introduzem predicados opacos, validadores descriptografados em tempo de execução, artefatos criptográficos simplificados, raciocínio de checksum e ruído de tempo de execução proveniente de Rust/Go.

Ambiente de Execução e Protocolo

• Sandbox: Os agentes operam em um contêiner Docker Linux sem rede.
• Sistema de Arquivos:
  • /task (Somente Leitura): Contém o binário do desafio, metadados e materiais públicos.
  • /work (Leitura e Escrita): O diretório de trabalho do agente para scripts e submissões.
  • /harness (Somente Leitura): Contém comandos auxiliares (list_tools, submit) e o manifesto de ferramentas.
• Acesso a Ferramentas: A lista exata de ferramentas instaladas (triagem estática, desmontagem, depuração, execução simbólica e ferramentas de compilação) é explicitamente injetada no prompt via um manifesto JSON, prevenindo a dependência de priores do modelo.
• Esquema de Submissão: Os agentes devem submeter um objeto JSON especificando uma password, um caminho de artifact ou um caminho de script keygen.
  • Para tarefas keygen, o script submetido é executado contra nomes de usuário ocultos para verificar a generalização, prevenindo soluções codificadas manualmente.
• Pontuação: Um oráculo privado fora do espaço de trabalho do agente valida as submissões contra o binário original. As métricas incluem pass@1 e pass@3 (sucesso dentro de 1 ou 3 tentativas), tempo decorrido, uso de tokens e rastros de comandos.

Configuração de Avaliação

A avaliação v0 testou três modelos com um orçamento de tempo de 5 minutos e um máximo de três submissões pontuadas por tarefa:

• GPT-5.5 (via Azure OpenAI)
• Claude Opus 4.7
• Kimi K2

Resultados Principais

A avaliação destaca um gradiente de desempenho acentuado baseado na dificuldade da tarefa e na capacidade do modelo:

Tarefas Geradas (Pontuação Principal):

• GPT-5.5: Alcançou 92% de pass@3 (11/12 tarefas). Resolveu todas as 6 tarefas de núcleo e 5/6 tarefas difíceis (falhando apenas na tarefa de serial Rust).
• Claude Opus 4.7: Alcançou 58% de pass@3 (7/12 tarefas). Resolveu 5/6 tarefas de núcleo e 2/6 tarefas difíceis.
• Kimi K2: Alcançou 42% de pass@3 (5/12 tarefas). Resolveu 4/6 tarefas de núcleo e apenas 1/6 tarefas difíceis.

Tarefas de Calibração Pública:
O desempenho caiu significativamente em todos os modelos no conjunto público, provavelmente devido a ruído de implementação mais rico e convenções desconhecidas:

• GPT-5.5: 3/8 (38%)
• Claude Opus 4.7: 2/8 (25%)
• Kimi K2: 1/8 (12%)

Observações Qualitativas:

• Lacunas Operacionais vs. Semânticas: O modo de falha primário para modelos de menor ranking não foi necessariamente uma falta de compreensão semântica, mas uma ineficiência operacional. O GPT-5.5 converteu mais frequentemente constantes recuperadas em scripts de validação e submeteu rapidamente. Outros modelos frequentemente gastaram o orçamento de tempo em exploração estática ampla ou triagem de ruído de tempo de execução sem produzir um candidato verificável.
• Sobreajuste: Os agentes às vezes identificaram locais de validação, mas falharam em inverter-los ou sobreajustaram-se a exemplos visíveis em tarefas de keygen, um comportamento detectado especificamente pelo oráculo de nome de usuário oculto.
• Uso de Ferramentas: O manifesto explícito de ferramentas e as saídas de comandos higienizadas (removendo sequências ANSI) foram críticos para manter uma interface consistente e prevenir a explosão de contexto.

Significado e Alegações

O artigo afirma que o CrackMeBench estabelece um ambiente de teste reproduzível para medir a transição de agentes do raciocínio em código-fonte para a análise autônoma de binários. Seu significado reside em:

1. Enquadramento de Oráculo Executável: Desloca a métrica de avaliação de "prosa plausível" para "sucesso executável", reduzindo ambiguidades e forçando os agentes a produzir artefatos generalizáveis (senhas, geradores de chaves) em vez de apenas descrições.
2. Escopo Controlado: Ao restringir o escopo a programas educacionais e construídos com propósito, sem acesso à rede, o benchmark isola o comportamento de engenharia reversa sem recompensar capacidades ofensivas (análise de malware, contornação de DRM).
3. Análise Granular de Falhas: O framework fornece rótulos de falha estruturados (por exemplo, "encontrou-verificação-mas-não-inverso", "falha na configuração simbólica") e rastros detalhados, permitindo um diagnóstico preciso das limitações dos agentes.
4. Linha de Base de Benchmarking: Os resultados demonstram que, embora os agentes atuais possam resolver muitas tarefas controladas de engenharia reversa, eles permanecem fracos em desafios públicos e semelhantes ao mundo real, indicando um caminho claro para melhorias futuras na análise autônoma de binários.

Os autores enfatizam que o CrackMeBench não é uma ferramenta para segurança ofensiva, mas um passo metodológico rumo à compreensão de como os agentes podem analisar autonomamente binários compilados em um ambiente seguro e auditável.