Como investigar com o REA uma feature que passa por web, Electron e binário nativo

Fala aí, beleza? Sabe aquela feature que começa num clique no site, passa pelo app desktop e termina numa lib nativa que ninguém sabe o que faz? Dá pra investigar tudo isso numa apuração só 😀

A ideia é simples: tu começa pela camada de cima e só desce quando ela não respondeu a pergunta

Pra isso a gente vai usar o REA (Reverse Engineer Anything), um projeto open source que é ao mesmo tempo servidor MCP e CLI

Ele dá ao seu agente de código acesso a ferramentas de engenharia reversa em binários, aplicações e comportamento em runtime, tem licença MIT, é escrito em TypeScript, é distribuído no npm como rea-agents e roda localmente

O fluxo é sempre o mesmo: o agente chama o REA via MCP, inspeciona o alvo, rastreia o código relevante e recebe um achado junto com a evidência

Com isso ele faz a próxima pergunta, explica o comportamento ou parte pra escrever e testar uma implementação

Inspeciona, rastreia, achado com evidência, próxima pergunta, e por aí vai…

O que você precisa antes de começar

A lista é curta, mas cada camada pede um artefato diferente, então vale separar tudo antes de abrir o agente

Ambiente:

• Node.js e npm instalados
• Um agente suportado: o projeto cita Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• Pra etapa nativa, uma instalação de Hopper, Ghidra ou IDA (o setup pode instalar o Hopper, se você aprovar)

A instalação no agente é feita com:

npx rea-agents setup

Você escolhe os agentes, revisa as mudanças propostas e aprova

O setup adiciona o servidor MCP do REA e as instruções de workflow correspondentes, e faz backup da configuração que já existia, então nada de sair sobrescrevendo seu config na marra =)

Artefatos da investigação:

• Um arquivo HAR ou SAZ (do Fiddler Everywhere) salvo com a feature acontecendo
• O diretório extraído do app Electron ou o próprio arquivo ASAR
• O caminho absoluto do binário nativo, se chegar até ele

Se liga numa regra da própria skill do projeto: se as ferramentas do REA já estão disponíveis e o registro não está desatualizado, o agente deve ir direto ao alvo

Nada de rodar diagnóstico ou setup antes de cada investigação, isso só gasta tempo

Passo a passo: a apuração encadeada da web ao binário

A lógica aqui é de funil: cada camada responde parte da pergunta e o resultado decide se tu para ou desce

Se liga num detalhe antes: os comandos abaixo seguem a forma exata dos exemplos da documentação do REA, por isso uns aparecem como rea ... direto e o de JavaScript aparece como npx -y rea-agents@latest ...

Não são fluxos diferentes, é a CLI do pacote rea-agents nos dois casos, só muda a forma de chamar: com o npx, o pacote roda direto do npm (o -y pula a confirmação e o @latest pega a versão mais recente)

Passo 1: camada web, o que a feature manda pela rede?

Comece pela captura de rede da feature, porque ela mostra o que realmente trafega, sem precisar abrir nenhum código ainda

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

Se a captura for do Fiddler Everywhere, troque pra .saz e saz:

rea inspect-web-network-capture /absolute/session.saz saz --json

Essa operação é offline: as URLs gravadas não são buscadas de novo e nenhum navegador ou proxy é iniciado

O retorno traz requests, responses, payloads expostos e os locais no código-fonte relacionados

Prefere observar o site ao vivo? Existe o comando inspect-web-page, que observa a página via CDP (Chrome DevTools Protocol) e devolve estrutura da página, scripts, observações de rede e screenshots quando pedidos

Erro comum deste passo: procurar headers de autorização, cookies ou credenciais na URL dentro do resultado e achar que a captura veio quebrada

Não veio! A leitura do HAR valida cada entrada e preserva os corpos de request e response com seus digests, mas exclui esses dados estruturalmente

Critério de decisão: se o payload e o local no fonte já explicam a feature, a investigação acabou aqui

Se a chamada sai do app desktop e não do site, bora pro passo 2

Passo 2: camada JavaScript/Electron, onde a lógica mora no app?

Agora o alvo é o app em si, e a análise aqui é estática: o REA lê os arquivos sem rodar o app e não precisa de Ghidra, IDA nem Hopper

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

Você pode apontar pro diretório extraído do app ou direto pro ASAR

O resultado traz módulos, imports, source maps, rotas, IPC, as fronteiras do Electron e as relações com native add-ons, cada item com a sua evidência

Quer se aprofundar só nessa camada? Tem um post focado em entender uma feature de app Electron com o REA

Erros comuns deste passo:

• Passar caminho relativo: os exemplos da documentação usam caminho absoluto, então siga o padrão
• Confundir inspeção estática com captura em runtime: a estática só lê os arquivos, já a captura em runtime executa o alvo ou interage com ele, então pense duas vezes antes de rodar algo que você não conhece

Critério de decisão: se o IPC ou um native add-on é quem carrega a lógica da feature, o JavaScript só está repassando a bola, aí desce pro passo 3

Passo 3: camada nativa, o que o binário faz de verdade?

Aqui entra o pesado: pseudocódigo, assembly, strings, símbolos, chamadas e referências do binário

O REA usa uma instalação já existente de Hopper, Ghidra ou IDA como provedor

Os comandos nativos da CLI são rea analyze, rea search, rea function, rea decompile, rea xrefs e rea trace, todos aceitando --provider ghidra

O exemplo da documentação descompila a função num endereço:

rea decompile /absolute/path/to/program 0x1000 --provider ghidra --json

O 0x1000 é só o endereço do exemplo, no seu caso o endereço vem do que você achou com search, function ou xrefs

Erro comum deste passo: rodar os comandos nativos sem nenhum provedor instalado

O REA não traz descompilador próprio, ele conversa com o que já está na máquina, então garanta que o Ghidra, IDA ou Hopper está lá antes (ou aprove a instalação do Hopper no setup)

Quando parar e quando descer mais uma camada

A resposta curta: tu para quando a evidência responde a pergunta, e desce quando as limitações apontam pra camada de baixo

Quando usar o REA (e quando não usar)

Pela skill do projeto, o REA faz sentido quando a afirmação depende de:

• Binário ou pacote distribuído
• Descompilação
• Evidência passiva de runtime
• Comparação com um comportamento que o código-fonte disponível não comprova

Agora, se o repositório de código-fonte está completo, use as ferramentas normais de repositório e não rode os comandos de readiness ou de provedor do REA

Parece óbvio, mas é a armadilha clássica: fazer engenharia reversa de algo que tá aberto no GitHub haha

Se a dúvida é se não bastaria jogar o arquivo direto no chat do agente, vale ler sobre a diferença na prática do MCP

Como ler o Evidence v2 pra decidir o próximo passo

Toda chamada bem-sucedida fica registrada como um registro Evidence v2, com:

• Identidade do artefato
• Identidade do provedor
• Confiança
• Limitações

É esse registro que guia a decisão entre camadas

Confiança suficiente no achado? A pergunta foi respondida, encerra ali

As limitações dizem o que continua desconhecido, e é justamente isso que aponta qual camada atacar em seguida

Exemplo do raciocínio: a captura mostrou o payload, mas a limitação diz que a origem da chamada não está no fonte web, então o próximo alvo é o app Electron

A skill que guia o agente

O repositório traz a skill reverse-engineer-anything, em .agents/skills/reverse-engineer-anything/SKILL.md

Ela cobre alvos nativos, gerenciados, Electron/JavaScript, empacotados, firmware e navegador, e orienta o agente a explicar features, comparar versões, descompilar ou guiar uma reconstrução

Ou seja, tu não precisa ficar ensinando o agente a cada sessão como conduzir a apuração

Vídeo: introdução ao REA

Se você ainda não viu a ferramenta rodando, este vídeo do canal é uma introdução geral ao REA e à ideia de apontar a ferramenta pra um sistema e entender como ele funciona

Próximo passo: rode a primeira camada hoje

Escolhe uma feature que te deixa curioso e salva um HAR dela acontecendo no navegador

Roda o rea inspect-web-network-capture em cima desse arquivo com --json e procura no resultado se algum local no código-fonte aponta pro app Electron

Se apontar, aí sim tu parte pro analyze-javascript-application, se não apontar, a resposta provavelmente já está ali na sua frente 🙂

Até o próximo post!

Perguntas frequentes

O REA só investiga site, Electron e binário nativo, ou dá pra usar em outros tipos de alvo?

Essa trilha de web, Electron e binário é só um dos caminhos possíveis. O REA também suporta assemblies .NET, apps Android, firmware, WebAssembly e Flutter, sempre com o mesmo fluxo de inspecionar, rastrear e devolver achado com evidência.

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.