O que o REA (Reverse Engineer Anything) consegue inspecionar? Lista de alvos suportados por grupo

O nome promete "qualquer coisa", mas a pergunta que importa é outra: o SEU alvo está na lista? E o que ele exige pra funcionar na sua máquina?

Fala aí, beleza? Bora destrinchar isso de um jeito prático 🙂

O REA (Reverse Engineer Anything) é um projeto open source: um servidor MCP com CLI que dá a agentes de código as ferramentas pra analisar software sem acesso ao código-fonte

Ou seja, tu pluga ele no teu agente e o agente passa a enxergar pseudocódigo, símbolos, manifest de APK, tabelas de SQLite e por aí vai

Um detalhe importante logo de cara: ele é voltado pra investigação de alvos de software autorizados, com análise e evidência locais

E o que sai no final? Pseudocódigo com evidências e uma lista dos pontos que o agente não conseguiu resolver (os famosos unknowns), o que é bem mais honesto que um "confia em mim" da IA haha

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Tabela: cada alvo do REA, o que ele retorna e o que exige

Essa é a tabela de consulta rápida, montada a partir do README oficial

Agora bora quebrar isso em grupos, porque ninguém chega pensando "quero analisar um ELF offline", né? A pessoa chega com um PROBLEMA 😛

Binários compilados: nativos, ELF, Go, .NET e WASM:

Esse é o grupo clássico da engenharia reversa: executáveis e bibliotecas que tu recebeu sem o fonte

O REA analisa binários nativos?

Sim, e aqui ele devolve pseudocódigo, assembly, strings, símbolos, chamadas e referências

Porém, ele não faz isso sozinho: precisa de um backend como Hopper, Ghidra ou IDA

Se tu já tem um desses instalado, ele pode usar a instalação existente

E o setup pode instalar o Hopper opcionalmente, sempre pedindo tua aprovação antes

O REA lê arquivos ELF?

Sim, no modo de layout offline ele retorna seções, segmentos, símbolos e relocações originais

É aquele raio-x da estrutura do arquivo, útil pra entender como o binário foi montado antes de partir pro pseudocódigo

Dá pra analisar binários Go sem ter Go instalado?

Dá sim, e essa é uma das partes mais massa da lista

Ele extrai a versão do compilador embutida, os módulos, os replacements e as build settings

A inspeção é estática e embutida, cobrindo ELF, PE e Mach-O thin, sem exigir Go na máquina

O REA inspeciona assemblies .NET?

Sim: metadados, instruções CIL, dependências nativas declaradas e comparações de build

Aqui não tem dependência extra, é tudo análise estática

A comparação de build é interessante quando tu quer saber o que mudou entre duas versões do mesmo assembly

E WebAssembly (WASM)?

Também entra: validação, seções, formas WAT exatas de import/export e WAT decodificado

Só que exige o WABT 1.0.42, fornecido por você

Tome cuidado com isso! O requisito fala de uma versão específica, então não adianta ter "um WABT qualquer" jogado no PATH

Mobile: APKs, dispositivos Android e projetos JEB:

Segundo grupo, pra quem mexe com app Android

O REA decompila APK?

Sim, ele entrega declarações do manifest, classes, métodos decompilados e referências

O requisito é JADX headless e um JDK completo, em Linux, macOS ou Windows x64

Repara no "completo": um runtime enxuto não é a mesma coisa que o JDK inteiro

Dá pra inspecionar um celular Android conectado?

Dá: dispositivos, pacotes, processos, logs, dumps, capturas de tela e transferência de APK e arquivos

Pra isso tu precisa do adb, fornecido por você, e pode ser emulador ou hardware de verdade

Que diferença isso faz pro APK? O APK é o arquivo parado, o dispositivo é o app rodando, com processo e log ao vivo

O REA conversa com o JEB?

Sim, ele puxa units do projeto via engine, digests de artefatos e pseudocódigo de tipos e métodos

O esquema aqui é diferente: tu inicia um cliente JEB que serve MCP, e o REA aponta pra ele pela variável REA_JEB_MCP_URL

Web e rede: JavaScript, Electron, websites e capturas:

Terceiro grupo, e talvez o mais útil pra quem é dev web e cai num app "misterioso"

O REA analisa apps JavaScript e Electron?

Sim: módulos, imports, source maps, rotas, IPC e a relação com native add-ons

A análise estática de JS não exige engine de análise nativa, então dá pra começar sem instalar Ghidra e afins

O IPC e os native add-ons são justamente onde um app Electron costuma esconder a parte interessante 😀

Ele consegue inspecionar um website?

Consegue: estrutura da página, scripts, observações de rede e screenshots quando solicitados

O requisito é um navegador da família Chrome

E capturas de rede salvas?

Também: requests, responses, payloads expostos e as localizações no código-fonte

Essa última parte é a que liga o tráfego com o código, ou seja, não fica só no "saiu um request", mas em de onde ele saiu

Dados, crashes, firmware, contratos e pacotes:

Quarto grupo, com alvos que não são "um programa" óbvio, mas que aparecem MUITO no dia a dia

O REA abre banco SQLite?

Sim: tabelas, colunas, índices, views, triggers e linhas selecionadas de tabelas comuns

Útil quando um app guarda estado num .db local e tu quer entender o esquema

Dá pra analisar crash no Linux?

Dá, a partir de crashes gravados: notas brutas, registradores e sinais de cada thread gravada e candidatos de mapeamento opcionais

O REA trabalha com firmware?

Sim: regiões, resultados de extração e handoff pra análise nativa

Esse handoff é a parte esperta: extrai o que tem dentro do firmware e passa pros backends de binário nativo

O requisito é Binwalk ou Unblob em Linux

E contratos inteligentes (bytecode EVM)?

Também entra: seletores de dispatch, offsets de bytes, argumentos e mutabilidade inferidos

Repara no "inferidos": sem fonte, é dedução a partir do bytecode, não certeza

Exige carrier raw/hex local em Linux x64

O REA inspeciona pacotes e bundles?

Sim: inventário de arquivos, digests, plists, anatomia de bundles Apple e recursos extraídos

Bom pra quando tu quer entender o que vem dentro de um app antes de partir pro binário em si

Qual grupo resolve o seu problema?

Bora traduzir a lista pra situações reais, sem prometer milagre, beleza?

• Tenho um .exe ou .dylib sem fonte: binários nativos, com Hopper, Ghidra ou IDA
• App Electron fazendo chamadas estranhas: JS/Electron pra ver IPC e rotas, mais capturas de rede pra ligar o tráfego ao código
• App Android: APK se tu tem o arquivo, dispositivo Android se quer ver o app rodando
• Crash em produção no Linux: crashes Linux gravados
• Contrato inteligente só com bytecode: bytecode EVM
• Dump de firmware: firmware, com handoff pros binários nativos
• Executável Go ou assembly .NET: os grupos de Go e .NET, que dispensam ferramenta extra

Se liga nisso: quem decide se o alvo funciona na TUA máquina não é o REA, é a dependência externa

Ghidra, JADX, adb, WABT, Binwalk, navegador da família Chrome… se a peça não está lá, o alvo não roda

É a mesma lógica de checar o que o NotebookLM aceita como fonte antes de subir um arquivo: primeiro confirma a compatibilidade, depois perde tempo 😛

E de novo, porque é sério: só alvos autorizados

Engenharia reversa em software que tu não tem permissão pra analisar não vira legítima só porque foi um agente que fez

Próximo passo: instalar o REA no seu agente:

Recapitulando o caminho:

1. Identifique em qual grupo o teu alvo cai (binários, mobile, web e rede ou dados/crashes/firmware/contratos/pacotes)
2. Garanta a ferramenta que esse alvo exige, conforme a tabela lá de cima
3. Rode o setup no terminal:

npx rea-agents@latest setup

Esse comando registra o REA no teu agente e instala as instruções de workflow correspondentes

O erro comum aqui é rodar o setup achando que ele resolve tudo e esquecer o passo 2: o REA fica registrado, mas o alvo que depende de JADX ou WABT, por exemplo, não vai funcionar sem eles

Os agentes suportados no setup são Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros

O repositório oficial é o morluto/rea no GitHub, com a documentação em morluto.github.io/rea

Cuidado com repositórios de nome parecido prometendo download de zip: confira se tu está mesmo no morluto/rea antes de instalar qualquer coisa

No fim, o "Anything" do nome é menos sobre fazer tudo e mais sobre cobrir MUITO terreno, desde que tu traga a ferramenta certa pra cada alvo

Até o próximo post! 🙂