Como fazer engenharia reversa de qualquer coisa com Opus 5.5?

Para fazer engenharia reversa de qualquer coisa com o Opus 5.5, conecte o modelo a um motor de desmontagem por meio do REA e depois trabalhe por etapas: roteie o alvo, mapeie-o, descompile as funções mais movimentadas, peça ao Opus para nomeá-las e explicá-las, escreva uma especificação somente de comportamento e reconstrua a partir dessa especificação em um contexto separado. Ajuste o nível de esforço para cada etapa e comprove a reconstrução com testes de paridade.

Experimente o Apidog hoje

Essa é a versão resumida de um guia que viralizou no X. Em 12 de outubro de 2026, o builder Movez publicou um curso de 11 passos sobre engenharia reversa com o Claude Opus 5.5. Ele passou de 1 milhão de visualizações e 2.800 favoritos. Este artigo confronta as alegações do curso com as fontes, corrige dois detalhes de benchmark e acrescenta o passo que a maioria dos guias pula: testar a API com a qual o alvo se comunica.

Use isso apenas em software que você possui ou está autorizado a examinar. O README do REA limita a ferramenta a “pesquisa lícita, educação, interoperabilidade, preservação de software e análise de software que você possui ou está autorizado a examinar”.

Por que o Opus 5.5 precisa de uma ferramenta para ler um binário

O Opus 5.5 lê e escreve texto; ele não consegue carregar sozinho um arquivo Mach-O ou ELF. O REA é um servidor MCP que fica entre o seu agente e um motor de análise (Hopper, Ghidra ou IDA para código nativo), executa a análise localmente e retorna os achados com suas evidências: endereços, pseudocódigo, strings e pontos de chamada. O modelo lê esses achados e faz a próxima pergunta.

O REA ultrapassou 393.000 estrelas no GitHub em 27 de outubro de 2026, contra cerca de 115.000 em 12 de outubro. Cobrimos o que é o REA e como ele funciona e um ciclo de seis passos para reconstruir uma funcionalidade de um app quando ele começou a viralizar. Este guia foca no lado do modelo: os prompts, as configurações de esforço e os limites.

Passo 1: Instale o REA e escreva as regras da casa

O REA exige Node.js 22.23.4 ou superior na linha 22 (24.22.1+ ou 26.12.1+ também funcionam), além do npm. A versão atual no npm é a 6.8.0. Registre-o com o seu agente:

npx rea-agents setup
npm install --global rea-agents
rea --help

O setup mostra uma prévia das alterações de configuração, faz backup do que altera e oferece suporte a Claude Code, Codex, Cursor, Gemini CLI e Grok Build. A análise nativa exige Hopper, Ghidra ou IDA; a inspeção de JavaScript, Electron e .NET não exige motor.

Depois, dê ao agente as regras da casa. O bloco CLAUDE.md do curso é a melhor parte da thread:

# Reverse-engineering house rules
- Only analyze targets I own or am authorized to examine. State the basis once.
- Tag every claim: observation, inference, or unknown.
- Cite the evidence: address, bytes, pseudocode or call site.
- Start with the smallest overview. Expand only on a concrete gap.
- Separate static facts from runtime facts.
- Build from behavior and public specs, never from copied code or assets.
- Every recovered behavior needs a passing test before "done".

Passo 2: Escolha um nível de esforço para cada etapa

O Opus 5.5 oferece cinco níveis de esforço: low, medium, high, xhigh e max. Segundo a documentação de esforço da Anthropic, o Opus 5.5 usa medium por padrão, enquanto xhigh é voltado a execuções agênticas longas e max remove todos os limites de gasto de tokens. Você o define com output_config.effort na API, ou pela configuração de esforço do seu agente.

A divisão proposta pelo curso é um ponto de partida razoável, não uma regra medida:

Etapa	Esforço sugerido	Por quê
Roteamento, reconhecimento, navegação	medium	Principalmente chamadas de ferramentas e listagens
Anotação de funções comuns	high	A nomeação exige raciocínio sobre o fluxo de dados
Sessões longas com múltiplas funções	xhigh	Feito para execuções com mais de 30 minutos
Código ofuscado ou com muitos ponteiros	max	Raciocínio mais profundo, custo mais alto

Aumente o esforço por função, não por sessão.

Passo 3: Roteie o alvo antes de abrir qualquer coisa

O erro mais comum de iniciantes é abrir um desmontador em um app Electron cujo JavaScript está à vista de todos. O REA cobre instalações desktop, binários nativos, apps JavaScript e Electron, assemblies .NET, APKs Android, WASM, sites e capturas de rede salvas, cada um com sua própria ferramenta de entrada. Seu primeiro prompt deve apenas identificar o alvo:

I want to understand how [FEATURE] works in [APP] at [ABSOLUTE PATH].
First tell me what kind of target this is (native, Electron/JS, .NET, APK, WASM)
and which REA tool opens it. Don't start deep analysis yet.
Then give me a one-paragraph map and where you'd look first for [FEATURE].
Keep observations, inferences and unknowns separate.

Um alvo Electron vai para analyze-javascript-application (módulos, imports, limites de IPC, sem motor). Um alvo nativo vai para open_binary.

Passo 4: Mapeie strings e classifique funções por referências cruzadas

Ainda não leia o código. Para um alvo nativo, comece com um inventário:

rea inspect /absolute/path/to/program --provider ghidra --json
rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json

As strings são sua pista mais rápida: URLs, mensagens de erro e nomes de funcionalidades. Uma URL base ou uma string `[REDACTED CREDENTIAL] também indica que o binário se comunica com uma API, o que importa no Passo 9.

Em seguida, classifique as funções por referências cruzadas (quantos lugares as chamam). Uma função com 147 chamadores provavelmente é infraestrutura central, como um carregador de configuração; uma com dois chamadores pode esperar. Leia de cima para baixo.

Passo 5: Descompile uma função e deixe o Opus nomeá-la

Descompile uma única função crítica:

bash
rea function /absolute/path/to/program parseConfig --provider ghidra --json
rea decompile /absolute/path/to/program --procedure=parseConfig --provider ghidra --json


A saída é bruta (var_28, casts para todo lado). Entregue-a ao Opus 5.5 com esforço high e uma checklist fixa:

`text
Here is decompiled pseudocode for a function with 147 cross-references.

1. Rename every variable based on how it is used.
2. State the function's purpose in one sentence.
3. List the data structures it reads and writes.
4. Name the pattern (singleton, factory, state machine, observer).
5. Flag missing error handling, validation or security checks. Mark anything you're unsure of instead of guessing. `

Os descompiladores erram detalhes. No showcase do DX-Ball do REA, o primeiro pseudocódigo mostrava uma função de pan de som sem nenhuma entrada. Só a visualização de instruções revelou o parâmetro. A reconstrução final em C passa 3.205 casos de teste x86 originais e reproduz todos os 63 bytes das funções compiladas, porque o agente conferiu o pseudocódigo com o assembly e os chamadores. Peça rea instructions quando uma assinatura parecer estranha.

Passo 6: Orce o código ofuscado, não o moa

É aqui que o curso viral precisa de correção. Ele cita o benchmark de ofuscação do Elastic Security Labs como um teste do “Claude Opus”. O estudo da Elastic, publicado em 21 de abril de 2026, testou o Claude Opus 4.6, não o Opus 5.5. Os números:

Fase do Tigress	Resolvidos
Sem transformações	1 de 1
Transformações únicas	4 de 6
Transformações emparelhadas	3 de 6
Pesado, multicamadas	0 de 6

No total, o Opus 4.6 resolveu 8 de 20 alvos avaliáveis (40%). Os sucessos custaram em média US$ 2,39 e as falhas, US$ 4,83, então uma falha custa cerca de duas vezes um sucesso. Trate esses dados como um piso, não como uma medição do Opus 5.5; não encontramos equivalente publicado para o 5.5.

Segundo ponto: o curso afirma que uma ferramenta chamada Caveman “remove cerca de 75%” do lixo descompilado. A Elastic descreve o Caveman como um plugin que reduz em até 75% a verbosidade do próprio modelo, e não um filtro de código descompilado.

A lição continua válida: limite o gasto por função ofuscada, peça uma pontuação de confiança de 1 a 10 e deixe de lado qualquer coisa abaixo de 6 até que suas vizinhas sejam resolvidas.

Passo 7: Divida alvos grandes em um controlador e workers

Uma única conversa não comporta 500 funções; ela esquece nomes e se contradiz. A solução do curso é um controlador que nunca analisa código e workers que recebem uma função cada:

text
Controller: The function map is in functions.json (address, name, size, xrefs).
Cluster functions by call-graph proximity, order clusters by xref count,
send each cluster to a worker, inject already-resolved struct names into every
brief, and queue a second pass for any result with confidence below 6.
Report token spend after each cluster.


Cada worker retorna o endereço, o propósito, uma pontuação de confiança de 1 a 10, as structs que usou ou encontrou e o código-fonte limpo, reutilizando os nomes de struct do controlador. O benchmark da Elastic usou o mesmo formato de controlador e workers.

Passo 8: Escreva uma especificação somente de comportamento em um contexto limpo

Uma reconstrução em sala limpa copia o que o software faz, nunca o seu código. Peça ao Opus uma especificação somente de comportamento: interfaces públicas, o modelo de dados, cada funcionalidade como um requisito testável, formatos de arquivo baseados em padrões públicos e tratamento de erros. Proíba endereços, nomes descompilados e qualquer coisa copiada.

Depois, implemente a partir dessa especificação em um contexto diferente, que nunca vê a análise. Essa separação é a fronteira da sala limpa. Isso é prática de engenharia, não aconselhamento jurídico.

Passo 9: Recupere o contrato da API e teste-o com o Apidog CLI

As strings do Passo 4 costumam revelar uma URL base e um cabeçalho de autenticação, então parte do comportamento vive atrás de uma API. Sua reconstrução só combina se também respeitar esse contrato, e o tráfego mostra isso mais rápido do que o assembly.

Grave um HAR em uma conta de teste que você possui e deixe o REA resumi-lo:

bash
rea inspect-web-network-capture /absolute/session.har har --json


Depois, deixe seu agente transformar essa captura em um contrato testado com o Apidog CLI. Configure-o uma vez:

bash
npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install


Dê ao agente um único [REDACTED PROMPT]
Import session.har into Apidog project . List the endpoints it created,
remove anything that isn't part of [FEATURE], and write one test case per
endpoint that asserts status code, required fields and response schema.
Run them against the original-service environment, then against my rebuild's
environment, and report every endpoint where the two disagree.
`shell

O agente executa a importação, verifica os formatos de payload antes de escrever e roda os dois ambientes:

`bash
apidog import --project <id> --format har --file ./session.har
apidog endpoint list --project <id>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog test-case run --project <id> --endpoint <endpointId> -e <originalEnvId> -r cli,json
apidog test-case run --project <id> --endpoint <endpointId> -e <rebuildEnvId> -r cli,json
`

Os mesmos casos, dois ambientes, um diff, reexecutável a cada commit com -r junit (veja nosso guia de CI/CD do Apidog CLI). Se preferir conduzir tudo pelo Claude Code, veja Apidog CLI no Claude Code. O plano gratuito do Apidog cobre até 4 usuários. Para a abordagem manual, veja engenharia reversa de APIs.

Passo 10: Comprove a paridade antes de publicar

“Acho que combina” não é evidência. Para o comportamento local, peça ao Opus para construir um harness que forneça as mesmas entradas ao original e à reconstrução:

`text
Generate 50 inputs: 30 normal, 10 edge (empty, max size, unicode), 10 error
(malformed, missing fields, corrupt). Run each through both programs. Compare
byte-for-byte where possible, semantically otherwise. Report the match rate and
every divergence as cosmetic, behavioral or critical.
`

Com a execução de API do Passo 9, você obtém dois números para mostrar a qualquer pessoa: uma taxa de correspondência local e uma taxa de correspondência de API. Teste enquanto constrói, não no final.

Perguntas frequentes

Engenharia reversa com o Opus 5.5 é legal? Depende da sua jurisdição, da licença e do seu propósito. O REA apoia pesquisa lícita, educação, interoperabilidade, preservação e análise de software que você possui ou está autorizado a examinar. Consulte um advogado antes de publicar comercialmente uma reconstrução.

Qual nível de esforço devo usar para engenharia reversa? Comece com medium para roteamento e reconhecimento, high para anotar funções, e reserve max para código ofuscado com um orçamento por função. O Opus 5.5 usa medium por padrão.

Quão bem o Claude lida com binários ofuscados? O único benchmark público, do Elastic Security Labs, testou o Opus 4.6: 40% dos 20 alvos Tigress resolvidos e 0% dos alvos pesados multicamadas. Nenhum teste equivalente do Opus 5.5 foi publicado.

Como testo a API que um app submetido à engenharia reversa usa? Capture um HAR em uma conta de teste, importe-o com apidog import --format har, crie casos de teste com o Apidog CLI e execute-os tanto contra o serviço original quanto contra a sua reconstrução.

O REA faz upload do meu binário? O REA executa a análise localmente. Apenas os achados que seu agente passa ao modelo (strings, pseudocódigo) chegam ao seu provedor de modelo.