Quando o binário não explica a feature: o que observar em runtime com o REA

Fala aí, beleza? Se a feature só aparece quando o app está rodando, ficar lendo o binário não vai te dar a resposta

E isso não é achismo: o próprio REA deixa explícito que artefatos estáticos idênticos não provam que o comportamento em runtime continua o mesmo (fonte no repositório do projeto)

Pra quem chegou agora: o REA (Reverse Engineer Anything) é uma ferramenta open source de linha de comando e servidor MCP, mantida por um dev que publica como morluto, com licença MIT

Ele deixa agentes de código inspecionarem software compilado sem o código-fonte e explicarem como esse software funciona

O REA chegou ao topo do trending do GitHub no começo de outubro de 2026, e tem um detalhe que pouca gente percebe: ele não fica só no binário 😀

Cobre binários nativos, apps JavaScript e Electron, assemblies .NET, APKs Android, bytecode EVM, firmware, sites e capturas de rede salvas, e ainda tem observação em execução pra browser e Electron

Se tu quer o panorama geral da ferramenta, já falei sobre o REA como servidor MCP em outro post

Aqui o objetivo é mais prático: te ajudar a escolher o alvo certo da análise ANTES de gastar horas no lugar errado

Inspeção estática x captura em runtime no REA: qual a diferença?

A inspeção estática lê os arquivos que você fornece e não executa nada

A captura em runtime executa o alvo selecionado (ou interage com ele) usando as SUAS permissões de usuário, e cada guia de runtime descreve os efeitos dessa execução

Tome cuidado! Essa diferença não é só técnica: na estática o app fica parado, no runtime ele roda de verdade na sua máquina

O que a estática já entrega em Electron e JavaScript

Em apps Electron e JavaScript, a análise estática do REA retorna:

• módulos e imports
• source maps
• rotas
• IPC
• relações com add-ons nativos

E só exige Node.js e npm

Então, se a sua pergunta é qual módulo importa qual, ou por qual canal de IPC um botão conversa com o processo main, quem responde é a estática, sem rodar nada

E o Ghidra, o IDA e o Hopper?

O REA não substitui o desmontador

Ele funciona como ponte entre o agente e Ghidra, IDA Pro ou Hopper, mais ou menos como um intérprete: o desmontador continua fazendo o trabalho pesado e o REA leva isso até o agente

Sinais de que o binário não vai explicar a feature

A própria skill do REA indica o uso quando a afirmação depende de um binário ou pacote distribuído, de decompilação, de evidência passiva de runtime, de replay controlado ou de comparação com um comportamento que o código-fonte disponível não estabelece

Na prática, alguns sinais te avisam que é hora de olhar a execução 👇

A feature só aparece quando o app está rodando

Sintoma clássico: você lê tudo, não acha nada que explique o comportamento, e mesmo assim ele está lá

Alvo: observação em execução, se o app for browser ou Electron

Se for binário nativo, se liga no limite que eu explico mais abaixo…

Duas versões com artefatos iguais e comportamento diferente

Aqui entra exatamente aquele ponto do começo do post: arquivos estáticos idênticos não provam runtime idêntico

Alvo: captura controlada dos dois cenários, comparando as evidências resultantes

A comparação estática de versões existe (está no guia de aplicações JavaScript), mas ela não fecha esse caso sozinha

A feature depende de rede

Se o comportamento muda conforme o que o servidor devolve, o binário mostra só metade da história

Alvo: a captura de rede. A ferramenta inspect_web_network_capture lê offline um arquivo HAR ou, nativamente no Linux, uma gravação do mitmproxy

Esse caminho é massa porque tu analisa a captura sem precisar rodar o app de novo

O fluxo cruza renderer, preload e IPC até o main

Um exemplo publicado rastreou a API de clipboard do renderer, passando pelo preload e pelo IPC, até o processo main do Electron

Alvo: comece pela estática, que já te entrega IPC e imports, e use o runtime pra confirmar onde os scripts realmente foram parar

O que a observação em runtime do REA captura no browser e no Electron?

No browser, a investigação captura scripts, atividade de rede e resolução de módulos nativos usando Chrome DevTools Protocol e Playwright

Tem também um componente passivo que escuta o protocolo V8 Inspector pra observar scripts e localizações sem assumir o controle da página

Que passivo? É como ficar olhando pela janela: ele vê o que acontece, mas não mexe em nada lá dentro

As ferramentas de browser incluem capturas de cenário via CDP e auditorias de HAR de rede

Captura controlada de comportamento

Além de observar, o REA executa cenários aprovados de processo, browser ou Electron e compara as evidências resultantes

Cada cenário exige configuração e aprovação próprias, então não é rodar uma vez e sair testando tudo no next, next e finish haha

Quais guias da skill olhar

• references/runtime-observation.md: observação passiva de browser/Electron e reconciliação entre estático e runtime
• references/controlled-replay.md: replay controlado de JavaScript

Limites do runtime no REA: o que ele não consegue mostrar?

O runtime do REA ajuda MUITO, mas tem buraco, e saber disso antes evita frustração

Esperar que o V8 Inspector revele imports e IPC

Sintoma: você liga a observação esperando ver quais módulos foram executados ou o tráfego de IPC

Causa: a observação via Inspector registra localizações de scripts e eventos de contexto de execução. Ela não infere imports, atividade de IPC nem quais módulos foram executados

Solução: IPC e imports saem da estática, localizações e rede saem do runtime, e no fim você reconcilia as duas camadas

Tentar instrumentar um binário nativo

Sintoma: você quer ver módulos carregados, entrada e retorno de funções ou rodar scripts próprios em runtime num binário nativo

Causa: os agentes ainda não têm no REA um provedor reutilizável de instrumentação nativa. A integração com Frida existe como pedido de feature (issue #968) e a depuração nativa ao vivo via x64dbg, GDB e LLDB também está aberta como feature (issue #1267)

Solução: por enquanto, no nativo o REA fica na camada estática, com a ponte pros desmontadores

Tratar observação como prova causal

Sintoma: viu acontecer no runtime e já concluiu que A causa B

Causa: a skill trata observação em runtime e prova causal como afirmações distintas

Solução: registre o que foi observado e marque a relação causal como inferência até ter evidência que sustente

Como prevenir

Antes de rodar qualquer coisa, defina qual camada responde a sua pergunta: estática, runtime ou as duas reconciliadas

Parece besteira, mas é isso que evita gastar uma tarde inteira olhando pro lugar errado 😛

Como separar observação, inferência e desconhecido na conclusão?

A skill do REA exige que toda conclusão separe observações, inferências e pontos desconhecidos, citando IDs de evidência

E tem uma regra que vale ouro: nunca sugerir que a análise estática observou a execução

Evidências estáticas, evidências de runtime e inferências entre camadas ficam separadas, cada uma no seu canto

Pra organizar isso, o guia é o references/evidence-workflows.md, que cobre paginação de evidências, comparações, desconhecidos residuais e verificação

E vale lembrar as limitações declaradas: o REA não promete recuperar o código-fonte original nem clonar um app automaticamente

Ou seja, o resultado é uma explicação com evidência, não um botão mágico de copiar sistema

Vídeo: o REA olhando além do binário

O vídeo abaixo, do canal Hora de Codar, apresenta o REA e explica que ele analisa sistemas e sites olhando também o comportamento em execução, testando as funcionalidades, e não só o código ou o binário, pra montar uma spec

Assiste com as limitações de cima na cabeça: observação, inferência e desconhecido continuam sendo coisas diferentes

Próximo passo: escolher o alvo antes de rodar a análise

O próximo passo é transformar a sua dúvida numa pergunta que uma camada específica consegue responder

1. Escreva a pergunta da investigação numa frase só (ex: por qual caminho o clipboard chega no processo main?)
2. Classifique: a resposta depende de execução ou os arquivos bastam? Se envolve rede, separe uma captura HAR pra ler offline
3. Escolha o guia: references/javascript-applications.md ou references/native-and-artifacts.md pra estática, references/runtime-observation.md ou references/controlled-replay.md pra execução, e references/evidence-workflows.md pra fechar a conclusão
4. Instale o REA, com Node.js e npm já instalados:

npx rea-agents setup

O setup funciona com Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros agentes, adiciona o servidor MCP e as instruções de workflow e faz backup da configuração existente

No Claude Code, ele grava mcpServers.rea em ~/.claude.json e instala a skill em ~/.claude/skills, então qualquer projeto aberto no Claude Code consegue chamar o REA

Um aviso importante: o README limita o REA a pesquisa, análise e reconstrução legais, e a responsabilidade pela autorização é sua

E lembra que a captura em runtime executa o alvo com as suas permissões, então rode só o que tu tem autorização pra analisar

Até o próximo post! 🙂

Perguntas frequentes

O repositório github.com/morluto/rea é o único do REA?

Não. Esse é o repositório principal, mantido por um desenvolvedor que publica como morluto, mas existem outros como OF12138/REA, shijianzhong/rea e sqmagellan/rea com a mesma descrição, que parecem ser forks ou cópias.

Em que linguagem o REA foi escrito?

O código de autoria do REA é escrito em TypeScript e distribuído como o pacote rea-agents.

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.