Como investigar um assembly .NET com o REA sem ter o código-fonte

Dá pra entender um app .NET de terceiro sem ter o código-fonte, sim!

O caminho é pedir pro seu agente investigar o assembly com o REA e exigir evidência pra cada conclusão que ele tirar

Fala aí, beleza? Se você já precisou mexer num app .NET que chegou só como DLL ou EXE, sem fonte nenhuma, sabe o drama 😛

O REA (Reverse Engineer Anything) é um servidor MCP e CLI open source que dá a agentes de código, como Claude Code, Codex e Cursor, ferramentas pra analisar software sem acesso ao código-fonte

O repositório oficial é o morluto/rea, e o código escrito pelo REA é licenciado sob MIT

Agora, se liga no que ele NÃO promete: o REA não afirma recuperar o código-fonte original nem clonar um app automaticamente

Ele te dá evidência pra entender o app, o resto é investigação sua com o agente =)

O que você precisa antes de começar:

O REA roda em cima de Node.js e npm, então a primeira coisa é conferir a versão do Node

As versões suportadas são:

• Node.js 22.x (>=22.19)
• Node.js 24.x (>=24.11)
• Node.js 26+

Node.js 23, 25 e prereleases não são suportados

Além disso, você vai precisar de:

• Um agente suportado pelo setup: Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros
• O assembly .NET que quer investigar (o artefato PE/CLI, aquela DLL ou EXE gerenciado)

E motor extra? Não precisa!

A análise estática de .NET roda internamente no REA, sem Ghidra, IDA ou qualquer outro motor

O ILSpy é opcional e você traz o seu, porque o REA não instala ele

Sobre versão: a release mais recente encontrada é a rea-agents v6.5.0, publicada em 13/10/2026, e o projeto lança versões com frequência (a v5.0.0 saiu em 07/10/2026), então vale conferir as releases antes de seguir

Tome cuidado: existem vários forks com o mesmo texto de descrição do projeto, a referência é o morluto/rea

Passo a passo: investigando o assembly .NET com o REA

A ideia aqui é ir do geral pro específico: primeiro entender o que é o assembly, depois descer nos membros, depois olhar a fronteira nativa

Comparar builds e usar ILSpy ficam por último, como extras

1. Instale e configure o REA no seu agente

Rode o setup:

npx rea-agents setup

O setup te deixa escolher quais agentes configurar, mostra os caminhos e as mudanças propostas, e só aplica depois que você aprova o plano

Lê com calma antes de aprovar, beleza? Não é aquele next, next e finish haha

Erro comum deste passo: estar com uma versão de Node não suportada, como a 23 ou a 25. Se for o seu caso, troca pra uma 22.x (>=22.19), 24.x (>=24.11) ou 26+ antes de rodar o setup

2. Peça a visão geral do assembly

Aqui entra a ferramenta MCP inspect_managed_artifact com detalhe summary

Por CLI, o comando equivalente é rea inspect-managed-artifact (as flags completas você confere na documentação de análise gerenciada)

Um pedido pro agente pode ser assim:

Use o REA para inspecionar o assembly MeuApp.dll com inspect_managed_artifact em detalhe summary. Me diga o que ele é, quais frameworks usa e quais limitações a análise apontou.

O que volta é uma visão inspect_analysis_view com:

• PE/CLI completo
• Classificação do artefato e a evidência dessa classificação
• Status de metadados
• Módulo e MVID
• Assembly
• Frameworks
• Contagem de linhas retornadas
• Cobertura e problemas encontrados
• Limitações

Que MVID? É o identificador do módulo, útil pra saber se dois arquivos são de fato o mesmo módulo ou não

Erro comum deste passo: achar que o REA vai rodar o app pra descobrir as coisas. Ele inspeciona o artefato .NET sem carregar nem executar o código, é tudo estático

3. Desça aos membros

Com a visão geral em mãos, use inspect_managed_members (ou rea inspect-managed-members pela CLI)

Ela inspeciona tipos, assinaturas, corpos de métodos, chamadas e acesso a campos

É aqui que a investigação fica massa, porque você começa a ver quem chama quem 😀

Exemplo de pedido, adaptado do próprio README do projeto (que traz "Understand how search works in the Notes app, show me the evidence…"):

Entenda como funciona a busca no MeuApp.dll usando o REA. Mostre os tipos e métodos envolvidos, as chamadas entre eles e a evidência de cada conclusão.

Erro comum deste passo: esperar C# bonitinho na resposta. O corpo dos métodos vem em CIL (Common Intermediate Language), que é a linguagem intermediária do .NET, não o C# original

4. Mapeie a fronteira nativa

Muito app .NET chama código nativo em algum ponto, e isso muda a investigação

A inspect_managed_native_boundaries lista as chamadas nativas declaradas e os indicadores de implementação nativa

Se você tiver evidência de análise nativa, o REA pode ligar essas chamadas a ela

Erro comum deste passo: tratar uma chamada nativa declarada como se ela fosse executada. Declarada não é o mesmo que chamada em runtime

5. (Opcional) Compare builds

Tem duas versões do mesmo assembly e quer saber o que mudou? A compare_managed_members compara membros entre builds e mapeia os tokens locais de cada build

Isso ajuda porque tokens não são estáveis entre builds, então comparar "na mão" engana fácil

Erro comum deste passo: esperar resultado bom em código ofuscado. Melhorar a comparação de código gerenciado ofuscado ainda consta no roadmap, não é capacidade madura hoje

6. (Opcional) Reconstrução com ILSpy

Se você quiser um C# aproximado pra ler, aponte o REA pro seu ilspycmd com caminho absoluto:

REA_ILSPY_CMD_PATH=/caminho/absoluto/para/ilspycmd

Com isso configurado, o C# gerado pelo ILSpy entra via import_managed_reconstruction como inferência de reconstrução, confrontada com a evidência estática exata dos membros

Erro comum deste passo: tratar a saída do decompilador como verdade. O REA não considera esse texto metadado canônico nem observação de CIL, e você também não deveria

Como ler as evidências e limitações que o REA devolve?

Essa é a parte que separa uma investigação séria de um chute com cara de análise

Pra cada conclusão, o REA retorna a evidência de suporte e as limitações

Cada resultado bem-sucedido é guardado como um registro estruturado Evidence v2, com provider, confiança e limitações conhecidas

Ou seja: não é só "o método X faz Y", é "o método X faz Y, segundo tal provider, com tal confiança, e com essas limitações"

Evidência estática prova o quê?

Prova o que está no artefato, não o que acontece quando o app roda

O próprio REA deixa isso explícito:

• Análise estática não prova comportamento em runtime
• Um módulo presente não é reportado como executado
• Evidência estática e de runtime ficam separadas

Na prática, se o agente disser "o app envia dados pra tal lugar" e a única base for uma chamada encontrada no CIL, isso é hipótese, não fato

E a saída do ILSpy?

É inferência, sempre

Ela vem confrontada com a evidência exata dos membros, então quando o C# reconstruído e o CIL discordarem, quem manda é a evidência dos membros

A ação que resolve tudo isso:

Antes de aceitar qualquer conclusão, peça ao agente algo assim:

Para cada afirmação que você fez sobre o MeuApp.dll, cite a evidência do REA que a sustenta e a limitação apontada. Marque como HIPÓTESE tudo que só tem suporte estático.

Se uma afirmação não tiver evidência associada, ela sai da conclusão

Essa mesma lógica de exigir base antes de aceitar a resposta vale quando você pede performance ao Claude Code sem ter métrica nenhuma: sem evidência, é opinião do modelo

Vídeo sobre o REA:

Se você quiser ver o REA de forma mais geral, esse vídeo apresenta a ferramenta: como instalar, o servidor MCP e o fluxo de apontar o REA para um sistema e gerar uma spec a partir dele

Próximo passo:

Pega um assembly pequeno e UMA pergunta específica, tipo "como a funcionalidade X funciona?"

Roda a visão geral, desce nos membros e exige evidência e limitação em cada conclusão

Só depois que esse fluxo estiver redondo vale partir pra comparação entre builds ou pra reconstrução com ILSpy

E fica de olho nas releases do morluto/rea, porque o projeto lança versão com frequência e as capacidades podem mudar rápido…

Até o próximo post! 🙂

Perguntas frequentes

O REA analisa só assembly .NET ou outros tipos de artefato também?

O REA também faz análise estática de JavaScript e Electron, rodando internamente, sem precisar de Ghidra, IDA ou outro motor extra.

A lógica é a mesma do fluxo .NET: evidência e limitação pra cada conclusão, sem executar o código analisado.

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.