Como descobrir onde a busca de um app acontece usando o REA (Reverse Engineer Anything)

Fala aí, beleza? Dá pra descobrir onde a busca de um app acontece sem ver uma linha do código-fonte

O caminho é pedir ao seu agente que investigue com o REA e cobrar evidência de CADA conclusão

O REA (Reverse Engineer Anything) é um servidor MCP e CLI que dá aos agentes de código ferramentas de engenharia reversa sobre binários, aplicações e comportamento em tempo de execução, sem acesso ao código-fonte

Se ainda não está claro por que o REA é um MCP, vale ler isso antes. Aqui o foco é outro, mais prático 🙂

O próprio README do projeto usa como exemplo entender como funciona a busca do app Notes, mostrar as evidências e construir algo parecido no seu projeto

Este post é um roteiro de investigação guiado por esse caso: como estreitar a hipótese, que tipo de evidência esperar e como validar o que o agente afirmou

Não é relato de teste próprio, beleza? É o método, montado em cima da documentação oficial

O que você precisa antes de investigar a busca de um app com o REA

Você precisa de Node.js, npm, um agente compatível e, dependendo do alvo, um motor de análise nativa

Se liga na lista:

• Node.js e npm: Node 22.x (>=22.19), 24.x (>=24.11) ou 26+, mais o npm
• Um agente compatível com o setup: Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• Fonte oficial: instale só pelo pacote npm rea-agents ou pelo repositório morluto/rea, porque existem forks e cópias de terceiros
• Motor nativo (só se precisar): binários nativos pedem Hopper, Ghidra ou IDA. Inspeção estática de JavaScript e .NET funciona sem motor nativo
• Linux: Ghidra, JADX, ferramentas de firmware e análise estática de JavaScript/Electron exigem um ps compatível com procps no PATH do REA

Sobre o motor nativo: o setup pode instalar o Hopper depois que você aprovar, enquanto Ghidra e IDA usam instalações que já existem na sua máquina

E o custo? O REA é gratuito e tem licença MIT

Os custos indiretos ficam por conta do agente que você usa e, em binários nativos, da licença do IDA Pro ou do Hopper (o Ghidra é gratuito)

A versão mais recente do rea-agents no npm é a 6.5.0, lançada em 13/10/2026

Passo a passo: como encontrar onde a busca do app acontece

A investigação segue o modelo de três etapas do REA: Decompile, Understand e Recreate

Decompile é abrir o app e recuperar código legível, strings, nomes e outras pistas

Understand é seguir o código de uma parte do app a outra até explicar como o recurso funciona

Recreate é transformar o aprendizado em um recurso do seu produto

Bora ver isso na prática, passo a passo?

1. Instale o REA pelo setup oficial

Com Node.js e npm instalados, rode:

npx rea-agents setup

Escolha os agentes, revise as mudanças propostas e aprove

O setup adiciona o servidor MCP e as instruções de fluxo de trabalho, e faz backup da sua configuração existente antes de mexer nela

Erro comum deste passo: instalar a partir de um fork ou de uma cópia não oficial

O projeto recomenda explicitamente só o pacote rea-agents ou o repositório morluto/rea. Ferramenta de engenharia reversa rodando na sua máquina com acesso a binários? Tome cuidado com a origem!

2. Formule o pedido focado na busca

O prompt citado na página do REA é este:

Reverse engineer the Notes app. Find how offline search works, explain it, and build a version for my project using TypeScript and SQLite.

Repara que ele tem três partes bem separadas:

• "Reverse engineer the Notes app": define o alvo
• "Find how offline search works, explain it": define UM recurso e pede explicação, não só um resumo
• "build a version for my project using TypeScript and SQLite": define a stack da recriação, já pensando no seu projeto

Troque o nome do app e o recurso pelo seu caso, mantendo essa estrutura

Erro comum deste passo: pedir "faça engenharia reversa do app inteiro"

Aí o agente se espalha por tudo e você recebe um relatório genérico. Um recurso específico (a busca) dá uma investigação com começo, meio e fim

3. Decompile: o que esperar da primeira etapa

Nessa etapa o agente chama o REA via MCP pra inspecionar o alvo, e o retorno são pistas: código legível, strings, nomes, pseudocódigo e grafos de módulos

O tipo de alvo muda bastante a coisa. O REA suporta binários nativos, apps Electron, assemblies .NET, APKs Android, firmware e sites

Se o seu alvo é Electron, tem um roteiro específico pra features de apps Electron

A análise roda localmente e os resultados vêm com a evidência e as limitações de cada conclusão

Uma pista boa aqui é o vocabulário da busca: strings e nomes que lembram termos como search, query ou index ajudam o agente a escolher por onde começar

4. Estreite a hipótese: a busca usa um banco local?

Se o recurso é busca offline, uma hipótese razoável é que exista algum armazenamento local envolvido

É hipótese, não conclusão, beleza? O agente precisa confirmar com evidência

A partir da 6.5.0, o REA inspeciona um snapshot SQLite offline escolhido explicitamente por você, com seleção de tabelas e colunas e Evidence limitada

Pra alvos SQLite, ele retorna tabelas, colunas, índices, views, triggers e linhas selecionadas de tabelas comuns

Índices e triggers são justamente o tipo de estrutura que pode indicar como os dados ficam preparados pra consulta. Por isso vale pedir ao agente que relacione o que achou no banco com o que achou no código

Erro comum deste passo: tratar a estrutura do banco como prova de como a consulta roda

Ver uma tabela ou um índice mostra que aquilo existe, não mostra que a busca usa aquilo daquele jeito. A ligação entre banco e código é outra evidência, que precisa aparecer no passo seguinte

5. Understand: siga o caminho da busca de ponta a ponta

Agora peça ao agente que siga o código de uma parte do app a outra até explicar como a busca funciona

Cobre três coisas na resposta: os achados, as localizações no código de cada um e o nível de confiança

A própria skill do REA orienta o agente a distinguir observações, inferências e incógnitas e a citar os IDs de Evidence, então você não está pedindo nada fora do padrão da ferramenta 😀

Se o relatório tem um buraco no meio (por exemplo, sabe onde o texto entra e onde fica guardado, mas não o que acontece entre os dois), isso deve aparecer como incógnita, não como frase bonita preenchendo a lacuna

6. Recreate: transforme o aprendizado no seu recurso

Com a explicação validada, aí sim peça a versão pro seu projeto, na stack que você definiu no prompt

Se liga num limite importante: o REA não afirma recuperar o código-fonte original e não clona apps

Ele entrega pseudocódigo, assembly, símbolos, strings e relações, com a evidência por trás de cada conclusão

Ou seja, o que você recria é a IDEIA do recurso implementada do seu jeito, não uma cópia do código de alguém

Como validar o que o agente afirmou sobre a busca

Valide pela evidência: cada conclusão sobre a busca precisa apontar pra um registro de Evidence e dizer se foi observada, derivada ou inferida

No REA, cada resultado bem-sucedido vira um registro Evidence v2, com identidade do artefato e do provedor, confiança, limitações e localizações no código

Esses registros distinguem confiança observada, derivada e inferida. E isso muda TUDO na hora de ler o relatório

Leia a resposta em três camadas

Separe cada frase do agente em uma de três caixas:

• Observação: algo que a ferramenta viu de fato no artefato, com ID de Evidence
• Inferência: uma conclusão tirada a partir das observações, que pode estar certa ou não
• Incógnita: o que ainda não se sabe e precisa de outra investigação

Se o relatório mistura as três num texto corrido e confiante, devolva pedindo a separação

Desconfie de "a busca roda assim" vindo de análise estática

A skill do REA orienta a nunca dar a entender que análise estática observou execução

Então, se o agente só olhou código e banco e afirma "quando o usuário digita, a consulta faz X", isso é inferência sobre comportamento, não observação de comportamento

Pode até estar certo, né? Mas tem que vir rotulado como tal

Use os comandos de evidência da CLI

A CLI do REA tem três comandos pra lidar com bundles de evidência:

rea evidence-import
rea evidence-export
rea compare

• rea evidence-import valida um bundle
• rea evidence-export exporta a forma canônica
• rea compare compara dois bundles, por exemplo entre versões do app

O rea compare é útil quando o app atualiza e você quer saber se o que concluiu sobre a busca ainda vale

Checklist de sinais de alerta

• Conclusão sem nenhum ID de Evidence citado
• Frase no presente sobre comportamento em execução vinda só de análise estática
• Inferência apresentada com a mesma certeza de uma observação
• Limitações e cobertura incompleta sumiram do resumo final
• Estrutura do banco usada como prova única de como a consulta funciona
• Promessa de "código original recuperado" ou de "clone do app" (o REA não afirma isso)

Apareceu um desses? Volte ao agente antes de escrever qualquer linha do seu recurso

Vídeo sobre o REA

Se você quer ver a ferramenta explicada em vídeo, aqui vai um conteúdo dedicado ao REA, mostrando como ele funciona, a instalação e o uso prático de engenharia reversa de sistemas e sites via servidor MCP

Próximo passo: aplique o roteiro em um recurso do seu próprio alvo

Escolha UM recurso de um app que você tem direito de analisar, rode o setup oficial e peça ao agente um relatório com IDs de Evidence antes de qualquer código

Só parta pro Recreate quando o relatório passar no checklist acima, sem observação e inferência misturadas

Pra documentação e atualizações, fique nas fontes oficiais: o repositório github.com/morluto/rea e o site rea.tools

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.