Como pedir uma investigação ao REA sem receber resposta genérica do agente

Fala aí, beleza? Se o REA te devolveu uma resposta genérica, a culpa quase sempre é do pedido genérico 😛

O REA (Reverse Engineer Anything) é um servidor MCP + CLI open source, no repositório morluto/rea, sob licença MIT, que dá ao agente de programação ferramentas pra analisar software sem acesso ao código-fonte

E aqui tem um detalhe que muda TUDO: ele não é um decompilador novo

Ele faz a ponte entre o seu agente e ferramentas que já existem, tipo Hopper, Ghidra ou IDA

Ou seja, com o REA a engenharia reversa vira uma conversa com o agente, e conversa boa depende de pergunta boa

Se o pedido chega vago, o agente não sabe qual alvo abrir, com qual ferramenta, atrás de qual feature… e aí vem aquele texto bonitão que não prova nada

Esse post é pra quem já rodou o setup, fez a primeira pergunta e recebeu resposta vaga

Bora ajustar o pedido? 🙂

O que você precisa antes de formular o pedido

Antes de culpar o prompt, confere se a base está montada, porque sem ela nenhum pedido bem escrito salva

• Node.js e npm instalados, que é o que o setup usa
• Setup do REA feito com o comando abaixo, escolhendo os agentes, revisando as alterações propostas e aprovando
• Agente compatível: o setup funciona com Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• Motor de análise nativa, se o alvo for binário: uma instalação existente de Hopper, Ghidra ou IDA (o setup também pode instalar o Hopper, se você aprovar)
• Artefato local em mãos: o arquivo, o bundle de app macOS, o diretório do app ou o ASAR

npx rea-agents setup

O setup adiciona o servidor MCP do REA e as instruções de workflow correspondentes no agente que você escolher

Se o seu alvo é JavaScript, se liga: a análise estática de JS não exige motor de análise nativa, então dá pra começar sem Ghidra, IDA ou Hopper

Passo a passo para pedir uma investigação que volta com evidência

A lógica aqui é simples: quanto mais coisa o agente precisa adivinhar, mais genérica fica a resposta

Então a gente tira o chute da equação, passo por passo

1. Defina uma feature só, pequena e com nome

Nada de "entende esse app pra mim"

Escolhe UMA coisa: a busca offline, a função que imprime um texto, o formato de um arquivo

A discussão oficial #2412, de 12/10/2026, orienta exatamente isso: perguntas pequenas e específicas, um arquivo, uma função ou um formato por vez, e depois conferir a resposta

Erro comum deste passo: os pedidos que a própria discussão cita como ruins, tipo REA, make no mistakes, go. ou Rebuild the program

É como chamar um mecânico e falar "conserta o carro" sem dizer o barulho que ele faz haha

2. Diga qual é o app e onde está o artefato

O workflow de investigação de feature trabalha com dois parâmetros no exemplo da documentação: feature (ex.: offline search) e document (ex.: Notes)

Então nomeia o app e passa o caminho do artefato no seu disco

Erro comum deste passo: deixar o agente adivinhar o alvo, principalmente quando tem mais de uma versão ou mais de um app parecido na máquina

3. Declare o tipo de alvo e o que você espera receber

Cada tipo de alvo segue um caminho diferente, e falar isso de cara evita o agente tentar a ferramenta errada:

• Binário nativo: entra por open_binary, que aceita arquivos e bundles de app macOS, e a análise devolve pseudocódigo e assembly
• JavaScript/Electron: entra por analyze_javascript_application com input_path, apontando pra um diretório local ou um ASAR, sem precisar de open_binary. Ele reconstrói estrutura de pacote, entrypoints, módulos Webpack/Rspack, imports, workers, endpoints, storage, source maps, BrowserWindow, preload, contextBridge, IPC, utility process e add-ons nativos
• .NET: análise estática de artefatos PE/CLI, sem carregar nem executar o código. Identifica o assembly, inspeciona metadados e CIL, compara membros entre builds e liga chamadas nativas declaradas a evidências de análise nativa que você fornecer
• Website: também é um tipo de alvo suportado, então vale dizer explicitamente que o alvo é um site

Erro comum deste passo: forçar open_binary num diretório de app Electron, quando o caminho certo pra esse alvo é analyze_javascript_application

4. Use o workflow certo

O REA expõe seis workflows de investigação pela capacidade de prompts do MCP

Pra entender uma feature, o certo é investigate_feature, que rastreia a feature desde a descoberta até a evidência nas funções relevantes

Os outros cinco existem pra outros objetivos, então vale conhecer pelo nome:

• compare_application_versions
• verify_reconstruction
• trace_crash
• audit_residual_unknowns
• prepare_bounded_process_capture

Se tu quer comparar duas versões de um app, por exemplo, pedir investigate_feature é usar a chave errada pra porta certa

5. Exija evidência junto da conclusão

Esse é o passo que mais separa resposta útil de resposta genérica

O REA separa nos resultados o que foi observado, as inferências estruturais e o que segue desconhecido, mantendo nomes inferidos distintos das estruturas observadas nos bytes

Então PEDE essa separação explicitamente, e pede a evidência (função, módulo, trecho) do lado de cada conclusão

O próprio README dá o tom com o prompt de exemplo: Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project.

Repara que ele tem feature (search), app (Notes) e pede evidência 😀

Só que ele junta três coisas num pedido só: entender a busca, mostrar a evidência e construir algo parecido no seu projeto

Pra seguir a regra de uma coisa por vez, quebra em etapas: primeiro pede só o entendimento da busca com evidência, confere, e só depois pede pra construir

A discussão #2412 traz outros pedidos bons, bem curtinhos:

• I compiled hello.c myself. Open hello and show me main. What does each part do?
• Which function prints this text? Who calls it?

Juntando tudo, um pedido em português ficaria mais ou menos assim (é um exemplo didático de formulação, não uma execução testada):

Use o workflow investigate_feature.
feature: busca offline
document: Notes
Tipo de alvo: app JavaScript/Electron, diretório em <caminho do artefato>.
Analise só a busca offline, nada além disso.
Para cada conclusão, mostre a evidência (módulo, função ou trecho).
Separe a resposta em: observado, inferido e desconhecido.

O resultado que você procura é uma resposta onde dá pra apontar de onde veio cada afirmação

Se não dá, volta pro passo 1 e diminui o escopo

Por que o REA ainda devolve resposta vaga (e como corrigir)?

Na maioria das vezes, porque ainda sobrou coisa pro agente adivinhar

Sintomas:

• Conclusão sem nenhuma função ou módulo citado
• Nomes inferidos misturados com nomes observados, sem dizer qual é qual
• Resposta que tenta "reconstruir tudo" de uma vez

Causas:

• Escopo amplo demais: o clássico "rebuild the program"
• Alvo ambíguo: app ou caminho do artefato não informados
• Tipo de alvo errado: tratar app Electron como binário nativo, por exemplo
• Motor nativo ausente: alvo binário sem Hopper, Ghidra ou IDA disponível

Solução:

Reduz o escopo pra uma feature, uma função ou um formato

Nomeia o artefato e o tipo de alvo

E pede a lista do que segue desconhecido, que tem até workflow com nome bem direto pra isso: audit_residual_unknowns

Muita coisa aqui é o mesmo problema de qualquer IA, aliás: se quiser ir mais fundo, vale olhar os erros mais comuns de prompt e como corrigir cada um

Como prevenir:

Uma pergunta por vez, e confere a resposta antes de fazer a próxima

Tome cuidado com um ponto: a própria discussão #2412 avisa que respostas de IA podem ser parciais ou erradas, e que nenhum prompt garante "zero erros"

Nada de prompt mágico aqui, beleza? A evidência existe justamente pra você conferir

O REA explicado em vídeo

No vídeo do canal Hora de Codar sobre o REA tem a explicação de como instalar a ferramenta e usar ela pra apontar uma feature ou sistema alvo e gerar a spec via engenharia reversa, que é exatamente a parte em que o pedido bem formulado faz diferença

Próximo passo: comece por um alvo que você controla

Antes de apontar o REA pra app de terceiro, faz o teste num alvo que você conhece de cor

É o que a discussão #2412 sugere: compila um programa simples seu, tipo um hello.c, e pede pro agente abrir o hello e mostrar o main, explicando o que cada parte faz

Aí compara a resposta com o código que você mesmo escreveu

Se bateu, tu já sabe como ler uma resposta com evidência, e pode subir o nível pra uma feature de verdade, sempre uma de cada vez

Se não bateu, ótimo também: você descobriu onde o agente erra num cenário seguro 😀

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.